Tessl 实测:token 更便宜的模型,代码审查账单反而更高
Cheaper Tokens, Bigger Bills: Token Price Isn't Agent Cost
Tessl 为旗下代码审查工具 Tessl Code Review 选默认模型时,用 10 个已合并 PR、4 款模型跑同一套审查流程,发现 token 单价更低的三个模型中有三个单次审查成本更高,其中一个 token 便宜近 3 倍、同一 PR 上却贵 2.8 倍。
Tessl 用自家代码审查工具实测四款模型,说明按 token 单价选模型会得出相反结论,并给出可迁移的成本核算公式。
我们需要为 Tessl Code Review(我们新的代码审查工具)选一个默认模型。候选名单看起来很容易比较:查看 token 价格,结合能力权衡,然后做出选择。随后我们通过真实的审查框架,让这些模型处理真实的拉取请求。结果,价目表会把我们引向错误的选择。
定价页面以 token 报价,因为 token 对供应商和买家来说都容易计数。而智能体工作负载又增加了一个变量:轮次。一轮就是一次模型调用,用于读取文件、运行检查或决定下一步做什么。模型自行决定需要多少轮,而你要为所有轮次付费。价目表无法体现这一点。我们测试的每个替代方案,其 token 价格都比 gpt-5.6-terra(我们实际运行的模型)更便宜,但其中三个每次审查的成本更高。有一个每 token 便宜近三倍,但在同一个拉取请求上却贵了 2.8 倍。
更有用的衡量标准是每个已验证结果的成本:即每个通过独立检查的结果所花费的金额。这能反映任务的完整成本,并剔除经不起检验的结果。与任何其他智能体评估一样,检查必须是独立的。不能信任模型给自己的作品打分。
为什么按 token 计价不再能预测你的账单
我们使用了来自 monorepo 的十个已合并拉取请求,固定在生产审查器所看到的提交上。四个模型经过相同的框架,使用相同的审查视角、修复智能体和循环:审查变更、应用修复,然后再次审查,最多四轮。在 2026 年 8 月,这在两种条件下产生了 100 次运行。只有模型发生了变化。
这项研究有两个重要局限。由于只有十个拉取请求,且每个模型对每个对象只运行一次,我们无法衡量运行间的方差。我们还选择了生产审查器已经发现问题的拉取请求。这提高了每个模型的召回率,却无法告诉我们任何关于误报的信息。因此,我们报告的是倍数而非百分比,并且不对落后于基线的模型进行相互排名。
所有成本均相对于 gpt-5.6-terra。“仅按价目表”显示的是,如果每个模型消耗的 token 与 terra 完全相同,其成本会是多少。“仅按消耗量”则是按 terra 的费率计算每个模型的实际用量。
| 模型 | 实际成本差距 | 仅按价目表 | 仅按消耗量 |
|---|---|---|---|
| gpt-5.6-terra,基线 | 1.0x | 1.0x | 1.0x |
| 一个成本更低的开放权重模型 | 0.4x | 0.16x | 2.33x |
| 第二个开放权重模型 | 1.7x | 0.54x | 3.23x |
| 第三个开放权重模型 | 2.8x | 0.37x | 7.59x |
价目表显示可节省 46% 到 84%,因此这三个替代方案在中间一列看起来都很有吸引力。它们的实际消耗改变了结果:完成同样的工作,它们多用了 2.3 到 7.6 倍。有一个模型确实更便宜,每次审查的成本是 terra 的 0.4 倍,但独立检查发现,它交付的输出也最没用。
轮次解释了大部分差距。Terra 用 42 轮完成一次审查,使用了 60 万输入 token。最贵的替代方案需要 156 轮和 500 万 token。两者都返回了审查结果,但其中一个花了远更多时间反复阅读文件并检查自己的工作。
对于输入受控、输出有界的单次调用,token 价格是合理的成本估算。而一个拥有工具和目标的智能体,对自己消耗的控制要大得多。token 价格仍然重要,但模型在框架内的行为可能更重要。

评估 AI 智能体的更好单位
我们使用这个公式:
cost per verified outcome =
price per token
x tokens consumed per task
x 1 / (share of output that survives verification)费率卡提供 token 价格。运行真实任务提供消耗量。独立评分器告诉你有多少输出存活下来。省略后两项中的任何一项,都可能彻底改变排名。
消耗量:造成损害的那一项
消耗量必须在你的工作上、通过你的测试框架来测量。在我们研究中,相同的输入在轮次上产生了四倍的差距,在 token 量上产生了八倍的差距。已发布的基准测试通常只问模型是否得出了正确答案,而不问它为此花费了多少,因此它们不会暴露这种差异。测量结果也会过期:更换模型或测试框架,消耗量也会随之改变。
有效性:通过独立检查后存活下来的部分
评审模型为其自身的发现分配了严重性等级。我们用同一个固定模型重新评级了全部 910 条发现,该模型只能看到发现本身及其 diff 片段。
由于每个评审都使用并抬高了自己的评分标准,我们无法直接比较原始标签。评审与评分器的一致率为 59%。当它们不一致时,评分器将 35% 的发现降级,将 6% 的发现升级。在作者称为关键的 70 条发现中,只有 6 条仍保持关键,而评分器没有将任何一条发现提升为关键。
重新评级推翻了一个表面上的领先。一个竞争模型报告了 73 条带严重性的发现,而 terra 报告了 62 条。评级后,terra 以 37 比 17 领先。我们还将每个模型与我们在相同提交上的生产评审发现进行了比较,该检查指向了相同的方向。
该表将花费与两项检查结合在一起。“已验证严重性发现”统计通过评级的严重性。下一列对每条已评级的主要或关键发现定价。最后一列显示模型还捕获了我们生产评审输出的多少。所有值均相对于 terra。
| 模型 | 已验证严重性发现 | 每条已评级主要或关键发现的成本 | 还捕获了我们自身评审发现的占比 |
|---|---|---|---|
| gpt-5.6-terra,基线 | 1.0x | 1.0x | 1.0x |
| 一个成本更低的开放权重模型 | 0.2x | 1.4x | 0.6x |
| 第二个开放权重模型 | 0.4x | 4.0x | 0.9x |
| 第三个开放权重模型 | 0.5x | 5.0x | 0.9x |
token 最贵的模型发现了最多的已验证严重性,并且每条已评级主要或关键发现的成本最低。
最便宜的模型确实在一项指标上胜出:每条与我们生产评审匹配的发现,成本仅为 terra 的一半。然而,该指标将小问题和数据完整性缺陷同等对待。同一个模型产生的已验证严重性仅为 terra 的五分之一,覆盖率达到其十分之六。它每次匹配的低成本反映的是它产生的输出类型,而不仅仅是效率。
即便在这里,费率卡也夸大了节省。其 token 成本是 terra 的 0.16 倍,而完成一次评审的成本却是 0.4 倍,因为该模型消耗了 2.3 倍。
可靠性:你最后才会发现的失败模式
成本和发现质量并不是唯一的差异。给每个模型完整的任务,暴露出了费率卡或单次调用基准测试会遗漏的失败。
我们的评审器首先发现问题,然后跨轮次对它们进行协调。协调意味着对照新代码检查每一条先前的发现,保留其身份,并生成一个在发布前通过验证的结构。当每个模型同时承担这两个角色时,四个模型中有两个无法可靠地生成该结构,导致它们的运行失败。而在所有分支共用一个协调器时,我们没有看到此类失败。
有一个模型在 10 次运行中有 6 次失败,而且报告的严重程度也最高。它自己的标签让它看起来像是最强的审查者。独立评分并不支持这一说法:它的严重程度标签只有三分之一站得住脚,是研究中一致性最差的,而且它 73 个带严重程度的发现降到了 17 个。由于它完成的轮次最少,它的汇总结果所依赖的证据也更少。
除了 terra 之外,只有一个模型在没有失败的情况下完成了监督者角色。它是最便宜的模型,成本是 terra 的 0.4 倍,但它在 10 次运行中有 8 次是通过判定没有什么可说的并批准变更来结束的。它的发现经独立评分者评估后也是最站不住脚的。它能可靠完成,是因为它尝试做的工作更少。
可重复性又增加了一个警告。在两种条件下,terra 在同一代码上复现了 71% 的发现。另一个模型复现了 24%。当下一次运行发现不同的东西时,一个好的结果就没那么有用了。
这对你选择模型的方式有何改变
我们的结果表明,团队在选择模型时可以做三项实用检查。
衡量任务成本。 用你将在生产环境中使用的测试框架运行你的工作负载,并检查账单。有用的数字是针对该模型和该框架的。如果 token 更便宜的选项每完成一个任务要贵 2.8 倍,那么更高的任务成本就是你要持续支付的。
使用独立评分者。 模型在夸大自己工作成果的程度上各不相同,从几乎没有夸大到接近四分之三个严重程度级别。没有任何固定的调整能让这些自我报告的分数变得可比。对每个候选模型都使用相同的独立检查。
分别测试各个角色。 发现问题与协调问题需要不同的能力。一个模型可以很好地完成前者,却仍然在后者上失败。在比较其余部分时,把任何可能导致整个运行失败的组件固定住。在我们的案例中,固定协调器让我们能够使用专家模型,而不会让循环变得不可靠。
值得认真对待的反对意见
较新的前沿模型可能比旧模型更严格地遵循关于投入程度和冗长程度的指令。我们的提示确实限定了审查范围,所以 terra 更低的轮次很可能既反映了原始效率,也反映了指令遵循。
这种区别不会改变账单。如果一个模型因为不太严格遵循范围而需要 156 轮,而另一个需要 42 轮,你仍然要为 156 轮付费。效率属于模型与框架的组合,而不是孤立地属于模型。这也是为什么 模型升级可能会让技能表现朝任一方向变化。衡量你打算运行的那个组合。
我们被问到的关于每结果成本的问题
这只适用于代码审查吗? 不。任何运行循环并决定何时结束的智能体都会控制自己的 token 用量。在这些工作负载上,费率卡定价的是输入而不是结果。对于单次分类或提取,由于消耗是有界的,token 价格仍然是合理的近似指标。
下一个模型发布会不会改变这一切? 它会改变数字,但不会改变方法。消耗取决于模型和框架的共同作用,所以每次发布都需要重新测量。上个季度在你的工作负载上高效的模型,今天可能并不高效。
如果我无法构建独立的评分器怎么办?评分器可以很小。我们的评分器只查看一条发现和相关的 diff 片段,并不知道是哪个模型生成的。重要的是保持一致性和独立性:每个候选模型都使用同一个评分器,且没有模型给自己打分。
你自己的数据会怎么说?
让我们困扰的是,错误的比较看起来有多么严谨。它使用了价格表、质量声明,以及两者之间合理的加权。这些都没有疏忽之处。但它仍然偏向了一个生产成本更高、却给出更差答案的模型。
你每个已验证结果的成本是多少,它会改变你选择的模型吗?
在你下一次更换模型之前,先拉取你自己的数据。轮次数量在你的日志里,token 用量在你的账单里,而第三项则需要对一部分输出进行一次独立评分。把它们代入公式。如果排名发生了变化,那才是你应该据以购买的数值。
Tessl Code Review 可免费试用,它会为你记录轮次和每次运行的成本。
来源:Tessl Blog · tessl.io