微软数据：Claude Sonnet 5 比 Sonnet 4.6 更便宜却可能更贵

新模型发布，每 token 价格更低，基准测试分数更好，所以显而易见的做法就是切换，对吧？标价似乎很少能预测真实世界的成本。正如 Tessl 最近所展示的，Gemini 的 Flash 层级，尽管名字暗示是更便宜的选择，在每项任务上最终可能比 Gemini 的 Pro 层级花费更多，而分数却几乎相同；同时，一项将开源模型与 Sonnet 4.6 进行对比的研究发现结果五花八门，从彻底击败它到太不可靠而无法信任，应有尽有。

微软现在报告了更奇怪的事情：在同一模型家族的两个版本之间切换，其表现并不像定价页面所暗示的那样。Waldek Mastykarz，微软的首席开发者倡导者，表示他的团队在 VS Code 中的 GitHub Copilot Chat 里，针对 15 个场景运行了 150 个代理任务，比较 Claude Sonnet 4.6 与 Claude Sonnet 5。

Sonnet 5 既更新，每 token 又比 Sonnet 4.6 便宜 33%，表面上看是一次轻松的升级。Mastykarz 的研究检验的是，一旦衡量真实任务和 token 消耗，而非仅看每 token 价格，这种组合是否依然成立。

Sonnet 4.6 vs Sonnet 5 Pricing (credit: Microsoft) — Sonnet 4.6 与 Sonnet 5 定价（图片来源：微软）

更便宜的 token，更昂贵的运行

当然，Sonnet 5 的每 token 价格全面更低，但决定最终账单的是 token 消耗量，而 Sonnet 5 完成相同任务使用了远更多的 token。

在测试 Azure 架构和设计任务的 12 个场景中，依据 Microsoft Learn（微软面向其开发者和企业产品的文档平台）进行评估，Sonnet 5 的 token 消耗中位数是 Sonnet 4.6 的 12 倍，其中一次运行达到了典型消耗量的 47 倍。

在三个 SharePoint Framework 升级场景中——包括从 gulp 到 Heft 的构建工具迁移，以及从旧式到扁平式 ESLint 配置的迁移——差距较小但仍然可观，token 消耗为 10 倍。

值得注意的是，成本结果因任务而异。在代码升级上，Sonnet 5 更大的 token 消耗将每次运行成本推高至 2.01 美元，而 Sonnet 4.6 为 0.55 美元，尽管标价更低。架构任务则讲述了不同的故事：Sonnet 5 在那里略微领先，每次运行 0.47 美元，而旧模型为 0.54 美元，因为相对于折扣，token 开销较小。

总体而言，一致性是 Sonnet 5 更大的问题。Sonnet 4.6 的 token 消耗中位数为 40,000，而 Sonnet 5 为 199,000，并且新模型在典型运行与最差运行之间的差距要大得多——在一个架构任务上，相同运行的 token 计数从 16,000 到 660 万不等。

Token consumption per run for Sonnet 4.6 (blue) versus Sonnet 5 (red). (Credit: Microsoft) — Sonnet 4.6（蓝色）与 Sonnet 5（红色）每次运行的 token 消耗。（图片来源：微软）

然而，成本只是故事的一部分。另一个问题是，额外的 token 是否换来了任何回报。

Sonnet 5 在代码上胜出，Sonnet 4.6 在架构上胜出

这正是微软数据真正发挥作用的地方：不仅展示了成本表现奇怪，而且在同一项研究中，“升级”在一种任务上倒退，而在另一种任务上进步。

在架构工作上，两个模型以相近的比例尝试了正确的任务，通过微软完成门槛的比例均为 75%。Sonnet 4.6 在微软的惯用输出指标上得分 90%，该指标检查结果是否遵循既定的编码规范，而 Sonnet 5 为 78%，Sonnet 4.6 在 9 个可比场景中的 8 个里表现更优。

代码升级任务则呈现相反的情况。Sonnet 4.6 在 60% 的运行中通过了完成门槛；Sonnet 5 则 100% 通过。最明显的例子：一个要求智能体将项目升级到特定目标版本的任务。Sonnet 4.6 忽略了所请求的版本，每次都默认使用另一个版本，依据是其自身文档搜索的建议——而 Sonnet 5 每次都遵循了给出的确切指令。

Sonnet 4.6 vs. Sonnet 5 across architecture and code upgrade tasks (credit: Microsoft) — Sonnet 4.6 与 Sonnet 5 在架构和代码升级任务上的对比（图片来源：微软）

先测量，后升级的重要性

具体到 SharePoint Framework 升级，两个模型在所有场景中的配置正确率均为 0%。两者都无法完成诸如迁移构建工具或配置格式之类的结构性变更，因为所涉及的具体步骤从未被写下来，智能体无从查找。

Mastykarz 的团队找出了文档中完全缺失的七处具体文件和配置变更，这些是任何模型都无法自行发现的。

“模型升级是一种假设，即更新的模型对你的特定任务更好，”Mastykarz 写道——这一假设只有在底层内容也匹配时才成立。

Mastykarz 引用研究者 Ethan Mollick 的“锯齿状前沿”概念来描述这一现象：AI 模型能很好地处理某些任务，却在难度相近的其他任务上栽跟头，且没有明显的规律可预测哪些是哪些。Sonnet 5 自身的结果也印证了这一点——代码升级的任务完成率从 60% 跃升至 100%，而在同一条升级路径上，架构质量却从 90% 下降到 78%。

某个给定工作负载落在分界线的哪一侧，事先无法知晓。微软的建议是，在切换之前针对实际任务进行测试，并首先检查智能体是否具备所需的依据材料。

或者，正如 Mastykarz 所说：“先测量，后升级。”