Cloudflare 通过持续优化，将推理费用降低 68%

四月我们在博客介绍人工智能代码审查器时，平均每次审查的费用为尚可接受的 1.19 美元。到八月底，这个数字已经涨至约 2.46 美元。期间没有进行显著的架构调整：协调智能体仍将工作分配给同一组专业审查器，也仍由相同的风险等级决定审查深度。

九月中旬，我们让智能体查清这些词元究竟用在了哪里，并大幅削减。现在，将代码质量审查的推理强度设为高时，平均审查费用仅为 0.77 美元，比优化前费用最高的两周里平均 2.43 美元下降 68%。主要目标是降低成本，但这项工作也优化了审查器，使审查耗时中位数从此前的 4 分 09 秒降至 1 分 32 秒。

约 40% 的节省来自审查器代码的修改与优化，其余来自对所用模型和推理强度的实验。

一次审查的成本为何翻倍

下图显示了三月以来每个工作日的平均审查成本。图中固定了审查等级的构成，因此某天大型审查较多不会使数据偏斜。

每次审查成本从三月的 1.22 美元，逐步升至六月的 1.44 美元、七月的 1.74 美元，最终达到八月的 2.32 美元。其中一小部分原因是更多审查进入最昂贵的等级：三月占 59%，八月为 65%。我们认为原因很简单，模型越来越好、能力越来越强，工程师自然会产生更大、更复杂的修改，因此更多修改落入“完整审查”等级。不过，我们发现大部分成本增加其实来自这几个月的模型更换。

八月初，我们将所有审查器都迁移到 Anthropic 模型，每项任务的成本从 1.38 美元升至 2.03 美元。之所以这样选择，是因为评估发现，在这项特定工作负载中，Anthropic 模型比其他模型表现更好。

综合性能和可靠性考虑，内部规范审查器 Codex 最终使用 Claude Opus 4.7。这使它在八月的每次审查成本从约 0.25 美元升至 0.88 美元，甚至比协调智能体本身更贵。

缓存命中率也提高了，从四月的 85.7% 升至九月的 97%；与此同时，每次审查的词元数从 91 万增至 299 万，超过原来的三倍。即使缓存读取价格较低，三倍词元量上的高命中率，仍意味着大幅增加的费用。

上一篇文章之后还有哪些变化？

最大的变化之一，是审查器现在运行于从头重写的 OpenCode v2，而不再是 v1。全面迁移前，我们在每个灰度仓库中，让所有审查都同时通过 v1 和 v2 以对照影子模式运行。在测试的合并请求中，两者对是否批准的判断一致率为 98%，因此十月初我们一次性完成迁移，并移除 v1 代码。比较使用相同模型的两天数据，v2 上的完整等级审查约快 13%。我们也在尝试其他运行内部人工智能审查器的方式，包括通过 pi-durable 完全运行于 Durable Objects。希望很快能分享更多进展，敬请关注。

词元究竟花在了哪里？

开始集中优化成本之前，人工智能审查支出中，输出词元约占 23%，缓存写入占 43%，缓存读取占 34%。也就是说，大部分费用花在了模型已经见过或即将再次见到的上下文上。

查看单次会话就能理解这一点。代码质量审查器每次审查平均调用大语言模型 16.6 次，在这些调用中向缓存写入 7.2 万个词元，又读取 108 万个，因为每次调用都会把整个对话作为上下文发送。会话成本随调用次数和上下文大小共同增长，过去几个月，我们缓慢增加了这两项。

值得花几分钟了解 Anthropic 的提示缓存机制。它会缓存提示中已经由大语言模型计算过的部分，称为前缀，因为它们只适用于对话开头的消息，不适用于中间或末尾。后续请求可以复用此前的前缀，直到对话与缓存内容不同的位置。对我们来说，运行框架工具、系统提示和人工智能审查会话开头的消息很少变化，非常适合前缀缓存。前缀只会保存在缓存断点结束的位置。写入缓存的价格是普通输入的 1.25 倍，读取为 0.1 倍；如果没有读取，缓存条目会在五分钟后过期。

因此，我们有两件事要做：让每次会话的首个请求读取缓存而非写入，并减少每个会话的调用次数。

让所有仓库共享缓存前缀

从九月十四日起，审查器记录每个审查智能体第一次模型调用的词元使用量，以及按实际发送给提供方的内容计算的首个系统消息块哈希。

数据显示，会话首个请求找到缓存前缀的比例只有 14% 至 26%。每次会话开头使用相同工具定义和智能体提示，共 1.1 万至 2.1 万个词元，在所有被审查仓库中都相同，因此几乎都应该命中缓存。

问题最终出在 OpenCode v1 构建系统提示的方式。它把智能体提示与包含工作目录和日期的环境部分合成一个消息块，并只在块末尾设置缓存断点。共享部分从未单独缓存，因此一个仓库的审查无法复用另一个仓库审查器写入的内容。

九月十六日，我们在每个智能体提示末尾添加标记，并通过插件钩子在标记处分成两块。第一块现在以所有任务共有的字节结束，并拥有独立断点。为保持这一特性，还必须移除它前面所有仓库特定内容，因此禁用了可用技能列表，并确保工具描述不会因任务而改变。

同一天，我们也将内部规范审查器 Codex 的参考索引，包括内部规范表、技能文件和参考文件列表，直接放入提示。此前每次会话都会用前三轮工具调用读取这些文件。调整后，每次运行的模型调用从 15.9 次降至 9.6 次，费用从 1.12 美元降至 0.72 美元。

这些变化一起将每次审查成本从 2.47 美元降到 2.02 美元，发布开始后就能明显看到下降。

减少调用，减少支出

下一批修改于九月二十一日和二十三日上线。单项看都不算显著，但合起来使每次审查再节省约 0.20 美元。

| 修改 | 此前情况 | 修改效果 | | --- | --- | --- | | 移除审查器无法使用的工具 | 子审查器能看到发布最终审查评论的工具。在 57% 至 76% 的会话中，它们会尝试调用，被服务器检查拒绝，再花一次调用恢复。 | 减少一次无效调用，并让每个子审查器请求中的工具定义减少约 2,900 个词元。 | | 并行读取文件 | 代码质量审查器的 64% 轮次中，模型只调用一次工具，通常只是读取单个文件。 | 审查器在首次响应中读取共享上下文和全部相关补丁，最多 150KB。 | | 复审时跳过部分审查器 | 约三分之二的任务是对同一合并请求的第二次或后续审查，而其中三个审查器往往没有新内容需要检查。 | 完整等级的复审中，AGENTS.md 审查有 56% 被跳过，性能审查为 23%，文档审查为 13%。 | | 审查发布后立即停止 | OpenCode 会把结果再交给模型一轮，后者重新读取整个对话，写出无人看到的总结。 | 每项任务节省约 0.07 美元。 | | 区分审查器运行较慢与提供方故障 | 达到时间限制的审查器此前被当作提供方故障处理，并按同一时间限制重新启动。 | 结合更长时限和更低推理强度，安全审查器的超时比例从 1.8% 降至接近零。 | | 真正停止已取消的任务 | GitLab 的 Kubernetes 执行器在任务取消时不会向任务脚本发送信号。在 446 项已取消任务的样本中，358 项仍一直运行到审查结束。 | 任务现在每 15 秒检查自身状态，若已取消则停止。 |

最复杂的修改，是让三个审查器共享同一前缀。代码质量、安全和性能审查器现在发送相同的首个请求，包含相同工具、共享规则文件，以及附带全部补丁的合并请求。各自的专用说明放在后面，并确保其中一个写入缓存，另两个读取缓存。

写入缓存的响应开始流式传输后，其他请求才能读取该条目，而三个审查器会同时启动。因此第二个和第三个会等待第一个响应开始，最多等 20 秒，再发送自己的首个请求。这会略微拖慢它们，但每个审查器约可节省九美分。

调整模型与推理强度

下图沿用九月初开始的同一条曲线，并标出了每次变化。

以每次发布和配置变化为界拆分时间段后，可以看到代码修改只贡献了较小一部分节省。

1.67 美元的降幅中，代码变化贡献 0.65 美元，模型和推理强度变化贡献 1.06 美元。每一步比较的是变化前后的工作日时段，因此这并不是统计意义上严谨的对照实验。

从八月起，协调器一直运行三种模型与推理强度组合。使用同一模型时，中等推理强度的完整等级任务提前 20% 完成，因此我们停用了另外两种组合。后续随机分组测试中，中等强度的 Opus 5.5 与 Opus 5 相比，在审查结论或严重问题发现上没有可测量的变化，于是我们切换了模型。高强度的 Opus 5.5 比中等强度更贵，却没有带来有意义的发现数量增长。

Opus 5.5 的单词元价格比 Opus 5 低，但价格只解释了约 0.20 美元的降幅，其余来自发送和生成更少的词元。自九月初以来，每次审查的缓存读取减少 82%，缓存写入减少 54%，输出减少 67%。

最近一次变化是引入新模型。十月三日，我们让每个 Sonnet 审查器的任务各有一半使用 Sonnet 5 和 Sonnet 5.5。两天半后，Sonnet 5.5 的每次运行成本在代码质量审查中低 62%，性能审查低 58%，安全审查低 47%。两个模型的单词元价格相同，因此差异全部来自更少的词元使用。完整等级审查中，5.5 审查器报告的严重和警告级问题数量与 Sonnet 5 大致相当，因此十月五日我们全部迁移至 5.5。

使用中等推理强度的 Sonnet 5.5 时，代码质量审查器每次运行调用模型 1.7 次，而非此前的 6.2 次，超过一半的运行只需一次调用就结束，也就是说没有打开仓库中的其他文件。高强度时，每次运行调用 3.4 次。我们担心这会让审查变浅，下面的质量部分会讨论这一点。

为了解更高推理强度能否在较大等级的审查中找回问题，从十月五日起，代码质量审查器在 5.5 上随机各用一半中等与高强度。一天后，高强度每次运行贵 61%，报告的严重和警告级问题多 58%。这相当于每次审查多约两美分，下文的质量分析表明这些额外发现值得保留，因此我们正将代码质量审查改为高强度。本文的成本数字基于这一设置。

延迟

我们的目标本来不是加快审查，但更少调用也意味着更少等待，进而使审查更快、工程师体验更好。

最慢的审查改善最大。九月十四日之前四周，有 37.9% 的审查超过五分钟，现在仅有 0.7%。如今的第 99 百分位耗时，比四月时四分之三的审查都快。各等级均有提速：完整审查中位数从 5 分 16 秒降至 1 分 54 秒，轻量审查从 2 分 58 秒降至 1 分 14 秒，简单审查从 77 秒降至 30 秒。

到八月，审查耗时中位数比四月报告时慢 14%，第 99 百分位慢 48%，因此这项工作的相当一部分只是让我们恢复到此前水平。

审查质量

如果成本更低的审查也发现更少的问题，那么节省就没有多大价值，而这里的第一张图看起来似乎正发生了这种情况。

代码质量审查使用高推理强度的 Sonnet 5.5 时，报告的严重和警告级问题比八月下旬少 40%。保持中等强度的安全和性能审查分别减少 56% 和 71%。严重问题数量下降，本身无法说明是漏掉了真实问题还是减少了噪声，因此我们从两个方向进行了检查。

首先，我们检查作者是否对审查器标记的问题采取行动。对严重和警告级问题样本，比较被审查的提交与作者下一次推送；如果问题指向的代码行有修改，就计为采取了行动。距离每项发现 30 至 40 行的位置，在各时期都有约 15% 被修改，可作为偶然编辑的基线。

调整前，作者会处理代码质量审查器严重问题中的 34%，现在是 59%。审查器标记的问题更少，但被标记后更可能引发修改，因此每千次审查中促成修改的问题数量大致相同：现在为 132 项，此前为 145 项，差异在误差范围内。合计四个审查器，每千次审查中促成修改的严重问题从 229 项增至 321 项。

其次，我们让来自不同提供方的两个模型，在不知道样本属于哪个时期的情况下，评判三个 Sonnet 审查器报告的 657 项发现，并提供各自涉及的代码差异。意见不一致时交给第三个模型。每项发现被标记为重要、轻微、重复、错误或无法验证，严重程度则标为恰当、过高或过低。

消失的大多是轻微问题，也包括一些重复问题和评判模型无法从差异中验证的问题。每次审查的重要发现从此前的 0.28 项变为现在的 0.30 项，区间重叠。更大的变化在严重程度：此前每次审查有 0.46 项严重或警告级发现，被评判为定级过高；现在为 0.14 项，下降 70%，这是研究中最清晰的结果。严重发现的许多降幅，来自审查器不再把轻微问题称为严重问题。

因此，答案取决于审查器。对高强度的代码质量审查来说，消失的主要是噪声和夸大的严重程度，发现真实问题的数量仍与此前相近。中等强度确实损失了真实发现。在随机分组中，中等强度代码质量审查促成处理的问题数量大约只有高强度的四分之一，这正是我们转向高强度的原因。性能审查也损失了真实发现：评判模型发现，每次审查的重要性能问题减少约 64%，实际相当于每 24 次完整等级审查少发现一个重要问题。安全问题减少约四分之一，但统计上并不显著。两者仍使用中等强度，下一步将测试高强度。

两种方法都不完美。作者修改了被标记的代码行，只能说明他们做了些什么，不能证明发现本身正确。评判者也是模型，而且每组只有 35 至 66 项发现。“现在”的观察窗口也仅有一天。即便如此，两种方法互相吻合，均未表明代码质量审查发现的真实问题减少。

可靠性也保持良好。没有给出结论就结束的审查比例从 0.79% 降至 0.27%，安全审查器重试比例从 3.5% 降至 0.04%。

目前的结论

平均每次审查现在花费 0.77 美元，而非 2.43 美元；耗时中位数为 1 分 32 秒，而非 4 分 09 秒。最大的单项节省来自检查每次会话首个请求实际发送给提供方的内容，并找到一种消息排列方式，使其在不同提交、合并请求和仓库之间尽可能一致。其余节省来自持续试验不同模型和推理强度组合，同时避免预先偏爱某个特定模型。

成本下降不必然意味着质量更差，但也不能自动认为质量没有问题。高强度代码质量审查发现的真实问题与此前大致相同，而噪声和夸大的严重等级显著减少。性能审查在中等强度下损失了真实发现，安全审查也可能如此，因此下一步是对两者测试高强度。如果你以一定规模运行智能体，我们建议先检查两件事：每次会话的首个请求是否真的读取了缓存，以及在你付费使用的推理强度下，审查器是否仍能发现真实问题。

如果你参加旧金山的 Cloudflare Connect，我将在太平洋夏令时间十月二十日星期二中午 12:30 的“现在是构建而不是购买的时候”演讲中，介绍我们为何自行构建审查器而非采购。下午 1:10 起，我也会在讲者交流休息区，欢迎就本文中的任何数字提问。

来源：Blog