分类任务换小模型，降本先算基线

Amazon 的内部工单分类器，曾让 Claude Sonnet 4.6 为每张工单生成约 170 个 token 的 JSON，实际用到的却只有一个标签。改用 Strands Decider 后，Amazon 报告成本下降约 98%，调用时间也明显缩短。

但这笔账不能只看降幅。原作者重算后指出，换一个更便宜的模型，成本差距就会收窄。对程序员更有参考价值的，是先检查任务到底需要什么输出，再用置信度决定哪些结果可以自动执行。

只需要一个标签，为什么要生成整段 JSON

这套分类任务的输出空间很小：从 20 个标签里选一个。原来的 Claude Sonnet 4.6 每次却要生成约 170 个 token 的 JSON，而下游只使用其中的标签字段。

替代方案 Strands Decider 是一个小型开源决策模型，输出一个 token 和一个置信度分数。它把生成过程压缩到分类任务需要的结果上。

按 Amazon 报告的数据，每百万张工单的成本从约 22,200 美元降到约 500 美元，降幅约 98%；调用时间从 4.2s 缩短到 0.9s。

先确认下游需要什么，往往比先选哪个模型更重要。

如果后续代码只读取一个枚举值，那么额外生成的内容就需要证明自己的用途。不过，原文没有列出那约 170 个 token 的完整结构，也没有说明其中是否包含其他校验字段，不能直接认定每个多余字段都毫无价值。

换成便宜模型，98% 的降幅还剩多少

原作者指出，Amazon 使用的对照基线是按公开标价计算的中档模型。这会放大替换后的成本优势。

按原文采用的 Haiku 5.5 价格、沿用相同 token 数量重新计算，LLM 方案每百万张工单约为 740 美元。它与约 500 美元的差距，已经远小于 22,200 美元与 500 美元的差距。

原作者还算出：单个自托管实例大约要超过每小时 1,900 张工单，才具备成本优势。自托管有持续占用资源的成本，流量不足时，便宜的 API 按量付费可能更合算。

这里要分清证据来源：98% 的降幅和调用时间来自 Amazon 的报告；Haiku 5.5 的费用与自托管盈亏平衡点，是原作者的重算。所给摘要没有展开硬件配置、实例单价和利用率假设，因此每小时 1,900 张不能直接当作其他团队的采购门槛。

原作者还提到在完整文章中比较了 Google 的 Decisions API，但摘要没有给出比较结果，无法据此判断谁更划算。

小模型之外，输入顺序和置信度更值得抄

原作者在普通 CPU 机器上运行了 2B 模型，做了两组小规模测试。

第一组检查 JSON 键顺序。键的排列会改变输入 token 的顺序，同样的信息也可能因此得到不同标签。在 16 张工单中，有一张仅因键顺序变化就翻转了标签；对键排序后，这 16 张工单都没有再出现这种漂移。

这对 Node 服务里的请求组装很有启发：输入字段相同，不代表模型收到的序列相同。固定序列化顺序，是一种成本很低的稳定性措施。但这次测试只覆盖 16 张工单，不能推导出排序能消除所有分类波动。

第二组检查置信度。原作者建议，分数达到 0.9 及以上时自动应用，低于该值则进入回退流程。在 26 个案例的冒烟测试中，所有错误答案的分数都低于 0.8。

置信度适合用来分流，阈值仍需要用自己的数据验证。

这组结果支持继续尝试置信度门槛，却不足以证明 0.9 以上一定正确。摘要也没有给出错误数量、正确答案的分数分布，以及回退流程的具体实现。

我的判断

我认同原作者最核心的提醒：别把「换模型省钱」与「原来的模型选贵了」混成一件事。Strands Decider 的收益值得研究，但 98% 不能脱离原始基线单独传播。

对于只需输出有限标签的任务，小型决策模型是合理候选；便宜的通用模型则是更容易落地的对照方案。原文没有提供充分的准确率对照，也没有展开自托管的运维成本，尚不足以支持全面替换。

相比成本标题，我更看重固定输入顺序和按置信度回退。这两项做法都容易验证。不过，16 张工单和 26 个案例提供的是初步实验线索，0.9 这个阈值仍属于需要复验的经验建议。

能拿来做什么

• 检查现有 AI 分类接口的返回结构，确认 Node 下游究竟读取哪些字段，并把仅需输出固定标签的任务挑出来单独评估。
• 做成本对比时，同时纳入当前模型、便宜模型和自托管方案，使用实际 token 数量与小时流量计算，别直接套用 98% 的降幅。
• 在请求组装层固定 JSON 键顺序，用同一批工单调整字段排列，检查标签是否会随输入顺序变化。
• 为自动分类增加置信度分流，先验证 0.9 门槛下的错误率和回退比例，再决定是否自动写入业务系统。