亚马逊用决策模型替代 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 版本的结果明显更好，于是我们切换到了它。之后，我们调整了模型在应用标签前所需的置信度阈值。结果显示，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 仓库及其服务说明。