Hacker News 上一条高讨论帖称，Amazon 用 Strands Decider 替换 Sonnet 4.6，节省了数百万美元。这个标题容易被读成“便宜模型打败贵模型”，但真正值得开发者看的是替换后的评估问题：省下的钱对应哪些请求、质量由谁兜底、决策错误如何发现。资料没有披露任务分布和质量指标，所以不能把“数百万”直接外推成通用结论。
生产系统里，模型成本通常不是单一单价，而是每成功任务成本。把请求统一交给一个大模型，账单直观；一旦按任务分流，成本会下降，但决策器本身也要维护：评估集、回退策略、日志和误判处理都是成本。更稳妥的做法是先采样真实请求，按任务类型和失败代价切片，给每类定义可自动判定的成功标准。高价值或高风险任务保留大模型回退；长尾任务再尝试更便宜的决策器。线上用 shadow 模式对比，记录决策器把难例误判为简单例的比例。这个比例比平均 token 降幅更能说明能否替换。
另一个容易被忽略的边界是模型版本。同一周 Gemini 4 Carbon 可用，说明模型供给和能力边界仍在变。今天有效的替换规则，可能在模型升级后失效；评估集如果不跟着更新，节省会变成隐性质量债。替换模型不是一次性迁移，而是持续校准。对多数团队，先做到“可回退、可观测、按成功任务计费”，再谈省下多少。
评论
还没有公开评论，欢迎留下第一条讨论。