便宜44倍：亚马逊把Sonnet换成一个"选择题"模型

一张客服工单，成本从 2 分 2 厘降到 5 毫。

亚马逊内部那个处理海量事件的工单系统，最近把 Claude Sonnet 4.6 从链路里摘掉了，换成一个不会写字的模型：Strands Decider E4B。同一批工单、同样的标签质量，每百万张的账单从 2.22 万美元变成大约 500 美元，单次调用平均耗时从 4215 毫秒掉到 897 毫秒。

负责迁移的两位亚马逊工程师把账本写在了 Strands Agents 的博客里，细到每个 token。值得看的不是"亚马逊也自研模型了"，而是省下的钱记在哪一笔上，那笔账和大家想的不太一样。

它换掉的不是模型，是一类任务

Sonnet 接到一张工单要干什么？读几千个 token 的工单正文，加上二十个类别的完整描述，再生成一段 JSON，把类别、理由、置信度都写出来。

Strands Decider 接的活完全两样。它拿到工单文本和一份只有一两句话的类别判据，输出只有一个 token：选第几项。没有解释，没有理由，没有 JSON 骨架，只有"这张单属于二十个类别里的哪一个，或者哪个都不是"。

这类模型在产品页上叫 decision model。它给每个选项算一个概率，再附一个置信度，谁高选谁。你把它当成一个被训练过的多选题判卷器就行：给题干和选项，它填答题卡，不写作文。

参数小得离谱。Strands Decider 2B 建在 Qwen3.5-2B 的躯干上，把生成头换成百万参数左右的指针头，再套一个 rank 16 的 LoRA 适配器；亚马逊生产环境用的 E4B 版本换成了 Gemma 4 底座，因为在他们自己的工单测试集上表现更好。整套服务跑在一台 ml.g5.xlarge 上，一张 A10G、24GB 显存，内存占用约 19GiB。

Sonnet 那边要吐 170 个 token 才收工，Decider 这边吐 1 个就够了。差别不在参数多少，在这两套系统被要求干的事本来就不是一件。

98%的账，一半记在prompt上

先看 token 账本，这一栏最能说明问题。

同一张工单，Sonnet 4.6 读进去 6554 个输入 token，写出 170 个输出 token，合计 6724 个。Strands Decider 读进去 2009 个，写出 1 个，合计 2010 个，整体压掉七成。

输出侧从 170 降到 1，靠的是任务形态；输入侧从 6554 降到 2009，靠的是一次被迫的重写。

迁移的起点是窗口卡死。Strands Decider 只有4096 个 token，而亚马逊那二十个类别的原始描述，光描述本身就把窗口撑爆了。工程师的解法不是去模型货架上找个窗口更大的，是回去把这二十个类别挨个改写成一句到两句的判据，再摆成一道多选题的选项，末尾留一个"以上都不是"。

降 token 只是副产品。更值钱的是，重写判据逼着团队把"这个类别到底算什么"说清楚了。在这之前，那套定义散在每个人的脑子里和历年工单的习惯里，谁也没写成过一句话。

按 us-east-1 的公开价算一遍：Sonnet 4.6 输入 3 美元每百万 token、输出 15 美元每百万 token，一张工单 0.0222 美元；Strands Decider 按 SageMaker ml.g5.xlarge 每小时 1.408 美元算，一张工单大约 0.0005 美元。百万张工单，2.22 万对 500 美元，便宜 44 倍，成本降 98%。

44 倍里只有一部分来自模型变小，剩下那部分来自利用率。按每次请求 640 毫秒算，一台实例一小时能处理大约 5600 张工单，满载摊下来是250 美元/百万；实际报出来的是500 美元/百万，整整一倍，因为团队刻意留了容量吸收流量尖峰，没把每台机器压到满载。多出来的这一倍买的是排队时间，不是浪费。

切之前，他们先造了个开关

这套迁移里最值得抄的不是模型，是那个三态开关。

贴标签的 Lambda 每处理一条消息，都去 AWS AppConfig 读一次配置，值只有三种：BEDROCK，全部交给 Sonnet；DECIDER，全部交给新模型；DUAL，两个都调，Sonnet 的结果照常写进工单，Decider 的结果只存下来做比对。

DUAL 在真实流量上跑了几周，两边的分歧被一条条翻出来看。这比任何离线评测都准，因为测试集里没有的那些稀有工单，只在真实流量里出现。要退回旧路径，改一个配置值，45 秒生效，不动代码、不重新部署。

把 Sonnet 摘干净那天，Lambda 平均执行时长掉了74%。

还有个细节值得记一笔。团队发现同样的工单内容，只把 JSON 里的键顺序换一下，模型输出的概率最多能偏移 0.19。他们后来的规矩是：所有请求固定键序，再做任何跨版本比较。这个坑不影响正确性，却能让对比彻底失真——你以为是两个模型在比，其实是两种序列化顺序在比。

冷水：这套算法只在三种情况成立

AWS 自己发的基准测试给了反方向的数字，而且挺扎心。

同一份四问任务（该给哪个团队、是不是产品问题、有没有个人信息、要不要直接转人工），如果基线是"四次独立的模型调用"，Decider 先答、没把握再交给大模型，便宜 58%：1000 次请求1.69 美元对 4.06 美元。可要是基线换成"一次调用把四个问题一起答完"，差距只剩 4%，1.69 对 1.77。

被省掉的，其实是那些本来就没必要拆成四次的调用。

盈亏平衡点也在这份测试里：一台 SageMaker ml.g6.xlarge，大约3000 次请求/小时才追平一次精心设计的大模型调用；如果只有"路由"这一个问题交给大模型，门槛降到 1250 次/小时。低于这个量，自托管的固定成本会吃掉全部节省。同一份测试还指出，跟已经公开定价的托管决策 API 相比，自建在任何一台机器能承载的量级上都占不到价格优势，买到的是数据驻留和控制权。

反过来看，三种情况下这套不成立。标签需要解释性文本而不只是一个类别名，你要的是"为什么归到这类"，那就还得让模型写字。类别目录每周都在变也一样，判据要重写、置信度阈值要重标，维护成本最后会超过省下的 token。最容易忽略的是硬墙：有用信息装不进几千个 token，窗口就是装不下，只能回到大模型。

对着这三条筛一遍，你手里那些"AI 调用"大概会分成两堆：一堆是在已知目录里做选择，一堆是真的需要生成。只有第一堆值得拿去换模型，第二堆换了只会更贵。