死磕推理优化，让我们的推理成本降低 68%

根据供应商 2026 年 10 月 19 日的工程报告，其高推理强度的代码质量审查目前平均每次成本为 $0.77，比优化开始前成本最高的两个周内 $2.43 的平均水平低 68%。审查耗时中位数也从 4 分 9 秒降至 1 分 32 秒。供应商称，约 40% 的节省来自审查器代码的改动，其余来自模型选择和降低推理强度。

为什么审查成本几乎翻倍

即使将审查层级的构成保持不变，供应商的平均成本仍从 2026 年 3 月的 $1.22 上升到 6 月的 $1.44、7 月的 $1.74 和 8 月的 $2.32。完整审查的占比从 59% 升至 65%，但模型变更才是更大的影响因素。8 月初，所有审查器都改用 Anthropic 模型后，单个任务成本从 $1.38 升至 $2.03；这一选择基于供应商针对该工作负载进行的内部性能评估。

负责内部标准审查的 Codex 因性能和可靠性方面的原因被迁移到 Claude Opus 4.7。其单次审查成本在 8 月从约 $0.25 升至 $0.88。与此同时，缓存命中率从 4 月的 85.7% 提高到 9 月的 97%，但每次审查的 token 数从 91 万增至 299 万，达到原来的三倍以上。即便是很高的命中率，作用于大得多的 token 流量，仍然产生了可观的账单。

token 都用在了哪里

优化前，供应商的审查支出分布为：输出 token 占 23%，缓存写入占 43%，缓存读取占 34%。代码质量审查器平均每次审查调用模型 16.6 次，写入缓存 72,000 个 token，并读回 108 万个 token，因为每次调用都会将对话作为上下文重新发送。

只有提示词前缀可以被缓存，而且缓存条目若在五分钟后仍未被读取便会过期。记录每个会话的首次请求后发现，共享前缀的命中率仅为 14% 至 26%。共享工具和智能体提示词占用了 11,000 至 21,000 个 token，但 OpenCode v1 将仓库特定信息和日期放在同一个区块中，并且唯一的缓存断点设在区块末尾。因此，在某个仓库中进行的审查无法复用另一个仓库创建的共享前缀。

9 月 16 日，供应商使用标记和插件钩子拆分了该区块，将仓库特定内容移到共享前缀之后，并修正了共享工具描述。它还将内部标准参考索引直接插入提示词，而不是通过开头的工具调用检索这些文件。供应商报告称，Codex 每次运行的调用次数从 15.9 次降至 9.6 次，成本从 $1.12 降至 $0.72，整体审查成本从 $2.47 降至 $2.02。

消除调用和重复工作的改动

审查器被提供了一个它们无法使用的工具。在 57% 至 76% 的会话中，审查器都尝试调用该工具，却只会被服务器拒绝。移除该工具后，每次子审查器请求节省了一次调用和约 2,900 个工具定义 token。
供应商发现 64% 的代码质量审查轮次恰好只包含一次工具调用，通常是读取单个文件，此后便将文件读取并行化。
对于没有新增检查内容的复审，系统会跳过相应审查器。在完整层级的复审中，AGENTS.md 审查有 56% 的时间被跳过，性能审查为 23%，文档审查为 13%。
审查器发布结果后便停止，不再生成无人查看的摘要，每次任务节省约 $0.07。
超时不再像服务提供商故障那样一发生就以相同的超时限制立即重启。供应商报告称，安全审查的超时率从运行次数的 1.8% 降至几乎为零。
已取消的任务开始每 15 秒检查一次自身状态。在 446 个已取消任务的样本中，改动前有 358 个仍持续运行直至完成。

供应商还在灰度仓库中以影子模式并行运行两个版本后，将系统迁移到 OpenCode v2。两者对受测合并请求的审批决定一致率为 98%，且在模型相同的情况下，v2 的完整层级审查快约 13%。

共享前缀和调整模型推理强度

代码质量、安全和性能审查器现在会复用同一个公共前缀，其中包含各自的工具、共享规则以及完整的合并请求补丁。供应商估计，每个审查器可节省约 $0.09；代价是必须等待最长 20 秒，让首个响应开始流式输出后，其他审查器才能读取缓存。

根据供应商对各发布阶段的比较，代码改动在总计 $1.67 的降本中占 $0.65，而模型和推理强度变更加起来为 $1.06。不过，这不是一项受控实验。在相同模型上，中等推理强度的完整审查完成速度快了 20%，供应商也未发现 Opus 5.5 在中等推理强度下与 Opus 5 的结果存在可测差异。随后，供应商发现，在每 token 单价相同的情况下，Sonnet 5.5 在代码质量、性能和安全审查中的单次运行成本分别比 Sonnet 5 低 62%、58% 和 47%。

由于在代码质量审查的分组对比中，更高推理强度发现的严重级别和警告级别发现项多出 58%，而每次审查仅增加约 $0.02 成本，供应商便将该审查器改为高推理强度。性能和安全审查在进一步测试完成前仍采用中等推理强度。

延迟和审查质量

供应商报告称，耗时超过五分钟的审查比例从 37.9% 降至 0.7%。完整层级审查的延迟中位数从 5 分 16 秒降至 1 分 54 秒，精简层级审查从 2 分 58 秒降至 1 分 14 秒，极简层级审查从 77 秒降至 30 秒。

严重级别和警告级别发现项的原始数量有所下降，因此供应商调查了重要问题是否被漏掉。在一项涵盖 657 个发现项的盲评中，来自不同服务商的两个模型对严重程度进行判断，再由第三个模型解决分歧。供应商报告称，每次审查的重要发现项数量基本稳定，从 0.28 变为 0.30；而严重程度评级高于实际应评级别的发现项，从每次审查 0.46 个降至 0.14 个。

在严重的代码质量发现项中，作者修改被标记行的比例为 59%，而优化前为 34%。经调整后，每 1,000 次审查中实际得到处理的发现项数量分别为 132 个和 145 个，供应商认为两者处于误差范围内。然而，中等推理强度的代码质量审查实际得到处理的发现项数量仅约为高推理强度的四分之一。性能审查的重要发现项数量下降了约 64%，相当于每 24 次完整层级审查少发现 1 个；安全审查的下降幅度约为 25%，但不具有统计显著性。

适用场景和剩余限制

这种方法最适用于具备以下特征的多审查器系统：反复处理合并请求，跨仓库复用稳定的系统提示词和工具，并生成足够大的上下文，使前缀缓存能够发挥作用。团队还应能够将不同推理强度与真实发现项进行比较，而不是仅将减少 token 用量视为成功。

这些结果仍是供应商内部报告的评估结果，而非通用基准。模型变更是在不同版本发布前后测得的，供应商也明确指出，这种比较在统计上缺乏依据。盲评还依赖模型评判，每组仅涵盖 35 至 66 个发现项，改动后的观察窗口也只有一天。作者修改被标记的行只能证明采取了行动，不能证明结论正确。更重要的是，供应商发现中等推理强度可能遗漏真实发现项，这说明剩余的成本削减仍然涉及质量权衡。

资料来源：Cutting our inference bill by 68% by being obsessive about optimization（2026-10-19）。