
亚马逊用Strands Decider替换Sonnet 4.6,节省数百万美元
来源标题:Amazon saves millions by replacing Sonnet 4.6 with Strands Decider
亚马逊工程师将内部工单系统的Claude Sonnet 4.6替换为Strands Decider,成本降低98%,效果相当。该工单系统需将各类工单归入20个类别,更换后每年可节省数百万美元的token费用。
以下正文由 AI 翻译自 Hacker News(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
所有文章2026年11月9日5分钟阅读 Amazon 用 Strands Decider 替换 Sonnet 4.6,节省数百万美元 两位 Amazon 工程师在全球最大的内部工单系统之一中,用一款决策模型替换了 Claude Sonnet 4.6。 有一段时间,Amazon 和 AWS 团队依赖 Claude Sonnet 4.6 为内部系统中的工单打标签, 同时又不至于花费过高。 Sonnet 4.6 恰好是兼顾智能与成本的理想选择。考虑到它面对的是全球最大的内部工单系统之一,这款已有九个月历史的模型表现相当不错。然而,两位 Amazon 工程师最近将 Sonnet 4.6 换成了 Strands Decider——我们一个月前推出的一款决策模型——其表现同样出色,成本却降低了 98%。这一改动每年将节省数百万美元的 token 成本。 负责该内部工单系统的 Carr 和 Mehul 在下面详细讲述了事情的经过。 我们此前用 Sonnet 4.6 在极大规模下为工单打标签。这些工单可能是客户升级、容量请求、自动告警、安全发现,或公司内部任何需要归入 20 个类别类型之一的其他事项。该 agent 对每张工单都带着一段很长的 system prompt 运行,生成 JSON 并针对一组固定标签进行推理。 决策模型不能生成文本。它首先接收某种状态和一个带有若干选项的问题,然后为每个选项返回一个概率以及一个置信度分数。我们发现这种方法与工单打标签完美契合:状态就是工单,选项就是标签目录。 我们最初使用的是原始的 Strands Decider 2B。在一组测试工单上,E4B Gemma 4 版本的结果明显更好,于是我们切换到了它。之后,我们调整了模型在应用某个标签之前需要达到的置信度。结果显示,在另一组我们的工单上,E4B 胜过了生产环境中的 Sonnet。 我们在 SageMaker ml.g5.xlarge 实例(每台一个 A10G,24 GB)上运行 E4B。模型占用约 19 GiB,单个实例上一个请求大约耗时 640 ms。该 endpoint 会随流量自动扩缩容,但其网络是隔离的,阻止容器对外访问。SageMaker 会在启动前从 S3 复制模型权重。 客户也可以这样做!除了我们的工单 API 之外,这条路径上的所有组件都是标准 AWS 服务。工单事件进入一个 SQS 队列,进而触发一个 Lambda 函数。该函数读取工单数据并调用模型——一个带有 Strands Decider 的 SageMaker AI Endpoint。AppConfig 保存开关(见下文),CloudWatch 承载日志、指标和告警。整个技术栈用 CDK 定义,并设有 Beta、Gamma 和 Prod 三个部署阶段。 我们不想只是拨动一个开关然后祈祷顺利。打标签的 Lambda 对每条消息都会从 AWS AppConfig 读取一个三向设置: token 量的下降有两个来源。Strands Decider 只产生一个输出——选择结果,而不是一段 JSON 答案。它的 prompt 也比 Sonnet 4.6 的短得多。仅生产环境的标签描述就比 Strands Decider 的 4,096 token 窗口更长,因此我们将 20 个标签分别改写为一两句话的标准,并将它们作为一道单选题的选项发送,另外加上一个“none”选项。工单数据与 Sonnet 收到的相同,只是对于长工单,Strands Decider 会丢弃最旧的评论以适配窗口。 下图是我们在停用 Sonnet 当天 Lambda 执行时长的图表,显示 Lambda 平均执行时长下降了 74%。 Sonnet 的单工单成本直接来自上面的 token 数量。Strands Decider 的成本则取决于每个实例的繁忙程度。按每个请求约 640 ms 计算,一个实例每小时可处理约 5,600 张工单,满负荷使用时相当于每百万张工单 250 美元。我们为突发流量留了余量,实际约为每百万张工单 500 美元。这比 Sonnet 便宜约 44 倍,降幅 98%。 以上均为公开标价。这些数字未计入 Lambda,而 Lambda 现在每张工单的运行时间也更短了。 让我们意外的一点是,JSON 键的顺序会改变答案。发送相同内容但键的顺序不同,会使输出概率最多变动 0.19。我们现在发送每个请求时都对键进行排序,所以如果你通过 API 提供决策模型服务,在比较不同运行结果之前请先检查这一点。 这套方案之所以奏效,是因为任务是从已知目录中做封闭选择、数据量很大,而且旧路径的延迟很重要。如果你的标签需要解释性文本,如果目录每周都在变化,或者你无法将有用的上下文放进几千个 token 以内,那么决策模型可能无法替代 LLM 的工作。 无论用什么模型,我们都会照搬的部分是三向开关。让两者同时处理真实流量,然后评判每一处分歧,这比任何离线评估都告诉了我们更多信息。这也意味着回退只需 45 秒的配置更改。 有了决策模型,agent 的世界变得更加令人兴奋(成本也更低)。如果你正在运行一个分类 agent,可以试试 Strands Decider 仓库 及其 服务说明。
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。