亚马逊用 Strands Decider 替换 Sonnet 4.6 做工单分类，年省数百万美元

有一段时间，Amazon 和 AWS 团队依赖 Claude Sonnet 4.6 在内部系统中为工单打标签，同时又不至于花费过高。

Sonnet 4.6 恰好是兼顾智能与成本的理想选择。考虑到它要处理的是全球最大的内部工单系统之一，这个已有九个月历史的模型表现相当不错。然而，最近两位 Amazon 工程师用Strands Decider 替换了 Sonnet 4.6——这是我们一个月前推出的决策模型，其表现同样出色，成本却降低了 98%。这一改动每年将节省数百万美元的 token 成本。

负责内部工单系统的 Carr 和 Mehul 在下面详细介绍了这一过程。

用决策模型替代 LLM 的工作

我们此前用 Sonnet 4.6 以极大规模为工单打标签。这些工单可能是客户升级、容量请求、自动告警、安全发现，或公司内任何需要归入 20 个类别类型之一的其他事项。该 agent 对每张工单都使用一段很长的系统提示词运行，生成 JSON 并针对一组固定标签进行推理。

决策模型无法生成文本。它首先接收某种状态和一个带有若干选项的问题，然后决策模型会为每个选项返回一个概率以及一个置信度分数。我们发现这种方法与工单打标签完美契合：状态就是工单，选项就是标签目录。

我们从最初的 Strands Decider 2B 开始。在一组测试工单上，E4B Gemma 4 build 取得了明显更好的结果，于是我们切换到了它。之后，我们调整了模型在应用标签之前需要达到的置信度。结果显示，E4B 在我们另一组工单上胜过了生产环境中的 Sonnet。

我们在 SageMaker ml.g5.xlarge 实例（每台一块 A10G，24 GB）上运行 E4B。模型占用约 19 GiB，单个实例上一次请求耗时约 640 ms。该端点会随流量自动扩缩容，但其网络是隔离的，阻止容器对外访问。SageMaker 会在启动前从 S3 复制模型权重。

客户也可以这样做！除了我们的工单 API 之外，整条路径上的所有组件都是标准 AWS 服务。工单事件进入 SQS 队列，进而触发 Lambda 函数。该函数读取工单数据并调用模型，即带有 Strands Decider 的 SageMaker AI Endpoint。AppConfig 保存开关（见下文），CloudWatch 承载日志、指标和告警。整个技术栈用 CDK 定义，并设有 Beta、Gamma 和 Prod 部署阶段。

在同一批工单上同时运行 Sonnet 4.6 和 Strands Decider

我们不想只是拨动开关然后祈祷。打标签的 Lambda 对每条消息都会从 AWS AppConfig 读取一个三向设置：

BEDROCK：Sonnet 为每张工单打标签，但不调用 Strands Decider。
DUAL：并行调用 Sonnet 和 Strands Decider 两个模型。Sonnet 模型的结果会应用到工单上，并与 Strands Decider 的结果进行比较。
DECIDER：Strands Decider 为每张工单打标签，不调用 Bedrock。

我们测量的指标

	Claude Sonnet 4.6	Strands Decider E4B	% 提升
每次调用平均耗时	4,215 ms	897 ms	78%
每张工单输入 token 数	6,554	2,009
每张工单输出 token 数	170	1
每张工单总 token 数	6,724	2,010	70%

token 消耗下降有两个来源。Strands Decider 只产生一个输出，即选择结果，而不是 JSON 答案。它的提示词也比 Sonnet 4.6 短得多。仅生产环境的标签描述就比 Strands Decider 的 4,096 token 窗口更长，因此我们将 20 个标签分别改写为一到两句话的判定标准，并将它们作为单选题的选项发送，外加一个“none”选项。工单数据与 Sonnet 收到的相同，只是在长工单上，Strands Decider 会丢弃最旧的评论以适应窗口。

下图是我们停用 Sonnet 当天 Lambda 执行时长的图表，显示 Lambda 平均执行时长下降了 74%。

成本

按 us-east-1 按需实例的公开价格：

	Claude Sonnet 4.6（Bedrock，全球端点）	Strands Decider E4B（SageMaker，`ml.g5.xlarge`）
价格	每 100 万输入 token 3.00 美元，每 100 万输出 token 15.00 美元	每实例小时 1.408 美元
每张工单	$0.0222	约 0.0005 美元
每百万张工单	约 22,200 美元	约 500 美元

Sonnet 的每张工单成本直接来自上述 token 数量。Strands Decider 的成本取决于每个实例的繁忙程度。按每请求约 640 毫秒计算，一个实例每小时可处理约 5,600 张工单，满负荷使用时每百万张工单成本为 250 美元。我们为突发流量预留了余量，实际约为每百万张工单 500 美元。这比 Sonnet 便宜约 44 倍，降幅为 98%。

以上为公开标价。这些价格未包含 Lambda，而 Lambda 现在每张工单的运行时间也更短了。

让我们意外的一点是，JSON 键的顺序会改变答案。发送相同内容但键的顺序不同，会使输出概率最多变化 0.19。我们现在发送每个请求时都对键排序，因此如果你通过 API 提供决策模型服务，在比较运行结果之前请检查这一点。

我们的经验

之所以奏效，是因为任务是从已知目录中做封闭选择、调用量大，而且旧路径的延迟很重要。如果你的标签需要解释性文本、目录每周变化，或者无法将有用的上下文放进几千个 token 内，决策模型可能无法替代 LLM 的工作。

无论用什么模型，我们都会照搬的部分是三路开关。在真实流量上同时运行两者，然后评判每一个分歧，这比任何离线评估告诉我们的都多。这也意味着回滚只需 45 秒的配置更改。

有了决策模型，智能体的世界变得更加令人兴奋（成本也更低）。如果你在运行分类智能体，试试 Strands Decider 仓库及其服务说明。