Cloudflare 推理优化将审查成本降低 68%，但质量结果参差不齐

Cloudflare 表示，在单次审查支出大致翻倍后，该公司将其 AI 代码审查器的推理成本降低了 68%。推理是指训练完成的模型在处理请求时执行的计算。Cloudflare 于 10 月 19 日发布的推理优化报告描述了成本更低、完成速度更快的审查，但质量结果并不均衡。

根据该公司的推理优化分析，审查耗时中位数从 4 分 9 秒降至 1 分 32 秒。约 40% 的节省来自代码变更，其余来自模型和推理力度的调整。这些均为公司自行报告的结果，尚未经独立验证。

核心较量在于减少不必要的计算，同时保留有价值的审查。Anthropic 的智能体指南和 Google 的缓存方法提供了背景信息，但两者都无法独立验证 Cloudflare 的成果。对工程负责人而言，关键问题在于：成本更低的审查是否仍能发现值得关注的问题。

Cloudflare 推理优化改变了分析单位

有价值的比较单位是覆盖范围可接受的完整审查，而非孤立的模型请求。

这一差异改变了读者解读推理账单的方式。模型请求是附着于某个中间操作的支出。审查则是开发者实际使用的产品结果。

系统可以降低单个请求的成本，同时增加完成任务所需的请求数量。它也可以生成更短的回答，却让开发者需要进行更多调查。这两种结果都未必改善完整工作流的经济性。

以账户权限变更的一次示例审查为例。可见输出可能是一条关于访问检查的简短警告。生成该警告可能涉及阅读代码、检查周边行为、比对项目规则，以及评估该问题是否值得升级处理。

这些活动具有不同目的。有些用于建立必要证据，另一些则用于协调流程。将其合并成本视为毫无区分的模型支出，会让人难以区分富有成效的调查与行政性的重复操作。

这正是核算边界重要的原因。审查产品的存在，是为了帮助某人在变更推进前判断哪些事项需要关注。其经济价值部分取决于它从那个人日常工作中移除了多少负担。

需要大量验证的低价回答，可能只是把成本转移给开发者。能够避免严重缺陷的高价回答，则可能足以证明其计算需求合理。单看账单无法区分这些结果。

比较模型供应商时，同样适用这一逻辑。宣传中的输入价格描述的是支出的一个组成部分。它无法说明模型会在多大程度上要求补充证据、重复操作，或无法完成任务。

同样，更快的响应并不等于更快的完成。开发者在意的是获得有用结论、理解其含义，以及决定需要作何修改。等待最初几个字出现，只是这段体验的一部分。

因此，Cloudflare 所报告的支出下降与审查缩短相结合的结果，其意义不止于采购。它将注意力引向完整应用程序的行为。这正是工程决策与模型行为交汇之处。

这也带来一项报告层面的影响。当节省声明的分母保持明确时，其评估会更容易。按提交变更、完成审查和被接受发现计算的支出，回答的是不同问题。

评估这一案例的团队应避免将标题中的数字转化为普遍目标。它更持久的贡献在于提出了一个核算问题：审查中的哪些部分创造了有价值的证据，哪些部分只是让机器继续运转？

这一问题直接引向架构压力。一旦 AI 功能成为常规组成部分，周边应用程序就需要接受与模型本身同等严格的审视。

工程负责人必须核算答案之间的工作

如果应用程序反复要求模型执行不必要的工作，模型能力无法在经济层面弥补这一问题。

AI 智能体是指在执行任务时利用模型选择行动的软件。其周边控制循环决定了可用工具、输入信息以及执行何时结束。

在模型选择进入讨论之前，这些决策就已经塑造了工作负载。工具描述可能诱发毫无意义的操作。缺失的上下文可能需要额外请求。不清晰的停止条件可能延长已经完成的任务。

这些是会产生直接财务后果的应用程序设计问题。即使模型由外部供应商提供，它们也属于构建该功能的团队职责。

压力尤其落在同时批准产品行为和基础设施支出的工程负责人身上。采购决策无法解决低效的操作序列。提示词调整也无法确定该序列是否必要。

Anthropic 的历史智能体工作流指南建议从简单方法开始，并在有充分理由时再增加复杂性。该指南还描述了路由，即将不同输入导向专门的流程、提示词、工具或模型。

这一指南为架构热情提供了有益的制衡。将任务拆分给不同专家可以提升聚焦度，但每一次拆分都会引入协调成本。由此产生的系统需要证据证明，专业化带来的额外工作是值得的。

对于代码审查器而言，专业化很有吸引力。安全性、性能和可维护性涉及不同问题。然而，其经济合理性取决于独立调查是否产生了不同的价值。

一次示例性的安全审查可能需要追踪不受信任的输入如何抵达敏感操作。格式检查可能只需要进行有限范围的检查。赋予两项任务完全相同的调查自由度，会忽视它们对证据的不同要求。

相反的错误同样可能发生。过于僵化且范围狭窄的工作流，可能阻止安全审查器检查周边代码。此时，支出下降反映的便是对有价值工作的限制。

这使产品团队承担了一项无法完全委托给模型的设计责任。他们必须定义每项任务需要何种证据，以及何为完成。这些定义构成评估效率的基础。

在比较商业审查产品与内部系统时，买方面临相关问题。托管产品可以隐藏运营复杂性，但其用户仍需了解覆盖范围、故障行为和审查限制。

内部系统提供更多控制权，但所有权伴随着持续维护负担。随着应用程序变化，必须有人确保任务定义、评估示例和模型配置保持一致。

这使文档成为成本控制的一部分。团队需要一份共享记录，说明审查器为何获得某些证据，以及何时需要更深入的调查。可搜索的知识库有助于在工程交接过程中保留这些决策。

更广泛的含义是组织性的，而非宣传性的。推理支出横跨应用程序设计、评估和采购。若只将其归于基础设施财务部门，许多重要原因就会被排除在讨论之外。

提示词缓存奖励一致性，但重复工作仍然重要

复用计算与消除不必要的计算解决的是不同问题，因此健康的缓存指标无法证明整体效率。

提示词缓存会复用此前针对匹配输入内容完成的处理。前缀是请求的开头部分，共享指令和其他稳定内容可以出现在这里。

Anthropic 的提示词缓存文档介绍了自动缓存和显式断点。文档解释了围绕匹配前缀的复用，其缓存行为会受到请求结构和支持的保留设置影响。

对应用程序而言，重要区别在于语义相似性与可复用输入并不相同。指令对人而言可能表达相同意思，但其实际表示形式可能不同。围绕精确匹配设计的系统，需要在这种表示层面保持一致性。

一个示例性的文档助手可能会在不断变化的项目标识符之外，加入稳定的政策指令。两者都属于请求内容，但其复用特征不同。它们的位置会影响可供复用的共享内容比例。

这使应用程序格式与基础设施支出之间形成了一种不同寻常的关系。请求构建不再只是外观问题，而成为执行策略的一部分。

然而，复用并不会使重复操作本身变得有价值。如果应用程序发送了不必要的请求，缓存可以减轻其处理负担，却不能为该请求的存在创造理由。

一个有用的类比是频繁访问的参考文档。将其放在手边有助于审查者高效查阅。但如果没有需要作出的决定，要求审查者反复阅读它仍会消耗注意力。

这一差异也解释了为何百分比需要背景。比例描述的是工作负载中各类别之间的关系。它无法证明工作负载本身是否处于合理规模。

对产品团队而言，这意味着运营报告除了比例之外还需要绝对活动量。完成的工作量独立于该工作被如何分类而具有重要性。看似良好的复用指标，可能与不必要地复杂的流程并存。

Google 的上下文缓存方法提供了一个对比。Vertex AI 支持隐式复用和显式缓存内容，二者具有不同的控制方式和存储考量。

Google 的文档将重复使用的文档、代码和企业知识描述为相关工作负载。这确立了缓存是跨供应商共享的基础设施问题，但并不意味着行为完全相同，也不代表经济性可以互换。

当组织评估可移植性时，这一点尤为重要。应用程序可以在供应商之间迁移其指令，同时保留已不再适用的假设。在迁移过程中，复用行为本身值得单独审查。

因此，实际的竞争问题比哪家供应商提供缓存更广泛。买家需要了解其实际应用程序如何与该供应商的机制交互。仅有可用性并不能证明有效使用。

就这个故事而言，Cloudflare 提示词缓存属于这一更大的区别之中。复用有助于提升效率，而任务设计决定了首先应发生多少工作。

两种机制都无法取代评估。结构始终一致的请求，仍可能提出错误问题、包含不足的证据，或得出不可靠的结论。

模型路由让审查质量成为资源分配决策

模型路由的经济价值取决于识别哪些任务可以接受较少计算，哪些任务需要更深入的调查。

模型路由会根据任务要求，将请求分配给不同的模型或处理配置。它将模型选择从一次性的采购决策，转变为一项运营策略。

这一策略需要定义“难度”。请求长度能够描述输入规模，但不一定能描述调查复杂度。对授权规则的简短修改，可能比冗长的机械性更新更值得仔细审查。

同样，看似熟悉的请求也可能隐藏着陌生的故障模式。依赖表面信号的路由器，可能会反复为风险尚未显现的任务选择经济型路径。

由 Isaac Ong 及其合作者主导的 RouteLLM research 研究了如何在能力较强和较弱的模型之间进行学习式选择。作者报告称，在保持已测量响应质量的同时，评估基准上的成本有所下降。

该论文为模型能力分配提供了研究背景。它并未验证 Cloudflare 的审查器、其配置或其发现结果的质量。基准测试结果与生产环境中的审查结果仍属于不同的证据。

这种区分很重要，因为对话偏好与缺陷检测是不同的目标。一条回复可能读起来很流畅，却忽略了某项依赖关系。一条警告可能措辞谨慎，却没有指出任何可操作的问题。

对于代码审查而言，相关的分配决策不仅涉及回答生成，也涉及证据收集。审查器有时必须检查周边行为，才能判断一个表面问题是否真实存在。

限制这种调查可能会产生一种看似干净的输出。回复之所以更短，是因为系统做的工作更少，但读者无法看到被省略的调查。

反过来，允许广泛调查也不保证能带来价值。模型可能浏览无关文件、重复先前推理，或提出推测性的担忧。更多活动需要以更好的决策为依据。

应将 Cloudflare 模型路由放在这一分配问题中理解。总体目标是在能够提升审查实用性的地方保留昂贵的调查能力。具体分配则必须依据工作负载的证据。

这使得升级行为变得重要。经济型路径需要能够识别值得进一步检查的不确定性。否则，这种架构就假设简单任务和困难任务总能在工作开始前被区分开来。

这也有产品层面的含义。一个会悄然改变审查力度的系统，可能让用户误以为其覆盖范围始终一致。审查预期应反映系统实际检查的内容。

工程团队还需要区分模型能力与其周围的配置。同一模型在获得不同工具、证据、指令或计算额度时，可能表现不同。

如果供应商比较同时改变了所有这些条件，就无法分离改进的来源。它仍可识别出有用的生产配置，但结论应保持适当的范围。

模型供应商面临的战略压力正来自这一差异。评估完整任务的买方，会关注模型在整个执行过程中的有效表现。每个 token 的优惠价格只是这一价值主张的一部分。

质量证据限制了节省声明的含义

只有当审查结果仍然符合预期用途时，较低支出才能支持效率提升的说法。

Cloudflare 的质量发现使这一限定变得具体。该公司表示，高努力程度下的代码质量审查保留了大致相当的有用发现，而中等努力程度下的表现遗漏了重要发现。安全性方面仍存在不确定性。

Cloudflare 还承认，其整体节省归因并非一项受控实验。其质量评估采用开发者编辑和模型评判，样本组较小，且近期观察窗口较短。

这些限制条件界定了边界，而不是否定这项工作的理由。生产环境的测量可以揭示有价值的运营变化，而无需回答每一个因果问题。错误在于将标题数字视为覆盖范围未变的证明。

开发者行为是有用的证据，因为它将警告与后续行动联系起来。但行动本身无法证明正确性。开发者可能出于防御性考虑修改代码、误解警告，或进行无关的编辑。

反向问题同样重要。一条正确的警告可能不会立即引发修改，因为问题已经被理解，或被安排留待后续处理。没有行动并不必然意味着该发现没有价值。

自动化评判带来了另一种视角，但也需要自身接受审查。模型评判器是用来评估另一系统输出的模型。评判器之间的一致性，是关于其评估的证据，而非对每个底层缺陷的直接观察。

最难衡量的是遗漏的发现。审查已发布的警告可以暴露误报和夸大的严重程度，却无法仅凭这一点发现审查器没有提及的所有问题。

因此，输出更少的系统带来了一个解释难题。它可能变得更有选择性、更准确，也可能变得不够彻底。没有额外证据，输出数量无法区分这些解释。

一个示例性的性能回归说明了覆盖范围为何重要。一项改动在局部看来可能合理，却会让频繁执行的路径成本更高。发现这一问题可能需要编辑行之外的上下文。

应当奖励避免不必要探索的审查器。但在检查相关行为之前就停止的审查器，不应得到同样的认可。两者在执行日志中都可能显得经济。

因此，Cloudflare 推理优化应被视为依赖配置的结果。适当的结论仅适用于特定设置下的特定任务。它并未确立“减少计算仍能保持质量”的一般规律。

这也改变了团队内部讨论节省的方式。财务部门可能希望得到一个单一的降低数字，而工程部门需要的是结果分布。要结合这两种视角，就必须保留经济型配置表现不佳的案例。

可信的评估应让这些失败可见。否则，平均改善可能掩盖最重要审查中的集中性弱点。

商业风险是工作转移或风险暴露转移。开发者可能需要花更多时间检查不确定的输出，或缺陷可能得到更少审查。这两种结果都应纳入经济讨论。

关注覆盖范围、持久性与有用发现的成本

下一阶段的证据应说明：在有用审查覆盖得以维持时，节省是否能在日常工作负载下持续存在。

第一个信号是针对高努力程度性能和安全审查的公开后续报告，Cloudflare 将其列为尚未完成的测试。更强且有用的发现将澄清在哪些场景下额外计算值得其成本。

这一结果将加强选择性分配的理由。它表明，该架构可以维持广泛效率，同时在脆弱的审查类别上投入更多资源。持续的损失则会缩小所声称的收益。

相关报告需要将发现与其重要性及支持证据联系起来。仅仅提高警告数量仍无法解决核心问题。更多输出可能代表更多覆盖，也可能代表更多噪声。

第二个信号是具有可比工作负载类别的更长期生产观察。持久的结果应能经受代码库活动、请求复杂度和提交工作组合变化的考验。

这并不要求生产条件完全静止。它要求提供足够的背景信息，以理解系统之外还发生了哪些变化。读者应能区分配置效果与更容易的输入工作。

重复报告会增强对运营结果的信心。在不同工作负载下出现反转，则会显示该配置需要在哪些地方调整。两种结果都比无限延长原始标题更具信息价值。

第三个信号是独立报告，将支出与有用审查结果进行衡量。由另一家组织复现，将检验底层方法能否迁移到 Cloudflare 的应用和工程环境之外。

对于 Cloudflare 模型路由，这意味着依据明确的质量标准检查完整任务。对于 Cloudflare 提示缓存，则意味着同时报告实际复用情况和工作负载行为。两者都不应通过孤立的有利指标来评估。

独立结果还将澄清实施负担。拥有专门基础设施和评估资源的组织，能够维持某些其他团队难以坚持的做法。运营投入应与推理支出并列讨论。

这些信号不需要推测性的发布日期或承诺中的行业反应。它们是读者可以在后续工程报告中寻找的具体证据形式。若缺少这些证据，当前结论就仍受限于现有案例研究。

对工程采购方而言，直接价值在于获得一组更精确的问题。审查器检查什么？哪些配置会得到更深入的调查？如何发现遗漏的问题，由谁维护评估？

这些问题同样适用于其他 AI 工作流。文档助手、研究系统或内部知识工具可能看似高效，却将验证工作转移给用户。有用的完成结果仍然是有意义的商业成果。

在将 Cloudflare 推理优化作为预算目标之前，请将这一主张与自身应用的实际目的进行比较。要求提供关于已完成任务、相关失败和人工后续处理的证据。记录哪些变更消除了重复工作，哪些变更限制了调查。保留额外审查改变决策的示例，因为这些案例揭示了节省从何处开始变得昂贵。在了解其覆盖范围之前，应将更安静的审查器视为一个衡量问题。随后再评估完整工作流，包括依赖它的人。当前值得采取的行动是让这些结果可见：你的团队能否证明，更便宜的 AI 审查仍能发现开发者需要修复的问题？