大规模管理 AI 编码成本

AI 编码工具带来了巨大的价值：在 Databricks，代理式编码（agentic coding）显著改善了我们跟踪的每一项速度指标，并且在某些团队中，使产出提升了一个数量级。但几乎所有大规模部署 AI 工具的公司都撞上了同一堵墙：成本指数级增长。这条曲线是不可持续的——如果放任不管，最终会超过收入。支出激增使企业陷入一种悖论：一方面，企业希望最大化推进 AI 转型，把强大的工具交到员工手中；另一方面，又不得不面对一种总体成本结构，这种结构可能破坏甚至逆转 AI 所带来的效率提升。

幸运的是，一些最早进行大规模采用的公司已经收敛出一套解决这一难题的方法，实现了“双重目标”：(a) 以尽可能低的摩擦向更广泛人群提供 AI 工具访问；(b) 将总体成本控制在按用户大致固定的范围内。本文基于我们在 Databricks 的经验，以及与 Stripe、Coinbase、Uber 和 Ramp 等多家数字原生公司的交流，梳理了已被验证的成本管理技术。下表汇总了当前技术及其对应节省；其中数字仅供参考，基于对开发团队的一次非正式调研：

其中一些技术可以通过许多公司已经在使用的软件轻松实现。另一些则需要新的基础设施，尤其是那些会修改终端用户客户端或在不同模型之间转移流量的技术。在 Databricks，我们已将关键基础设施组件开源或免费提供：一个终端用户 meta-harness（Omnigent）以及我们的 AI Gateway（Unity AI Gateway）。为求完整，本文也涵盖了我们所交流的其他公司所使用的软件。

编码模型的“效率前沿”

在将编码支出转向更高效模型的过程中，单一最重要的成本杠杆，就是随着新模型发布，迅速迁移到这些更高效的模型。这个点值得展开说明，因为“更便宜的模型”这一简单说法，实际上掩盖了模型成本与质量之间复杂的关系。

口语上，前沿模型（frontier model）通常指“智能水平最高的模型”，而前沿实验室（frontier labs）大多聚焦于提升峰值智能。前沿模型如今已经能解决数学或网络安全中的新问题。但当 AI 大规模落地时，另一种“前沿”更重要：效率前沿（efficiency frontier）。效率前沿由在给定智能水平下性价比最高的模型构成。 大多数日常编码并不需要数学证明或全新的安全洞见，因此总体上更重要的是，满足典型软件工程工作质量门槛的模型成本。这个“效率前沿”的推进速度远快于“智能前沿”，新模型几乎每周发布一次，在单位价格上提供比前代模型更高的智能水平。

成本杠杆 #1：迁移到开源和更低成本的模型

快速采用更新、更高效的模型，往往能带来所有技术中最大的成本收益。但要捕捉这些收益，公司首先需要知道哪些模型确实优于现有模型。这并不容易，因为公开基准很难准确反映真实世界中的编码任务表现。为了评估新模型，许多公司构建了自动化评测体系，他们认为这些评测更能代表自身的内部开发工作负载。Databricks 最近发布了一个此类基准的示例，在其中我们观察到 GLM 模型具有极具竞争力的性价比。该基准促使我们将 GLM 推广到内部开发者。很多时候，新模型并不会推进效率前沿，而且评测结果常常是负面的：Stripe 发现 Opus 4.7 相比 Opus 4.6 并未显著提升质量，反而增加了成本。因此，他们没有将 Opus 4.7 提供给内部使用。Databricks 在比较 Opus 5.0 和 4.8 时也看到了类似的成本回退。

Harness 与模型灵活性

既然最大的收益来自切换到新模型，那么采用支持模型灵活性的终端用户工具，正在成为压低成本的关键组成部分。与特定模型配合使用最常见的工具被称为 harness。专有前沿模型越来越多地与特定 harness 共同设计，以便更好地协同工作，这意味着某些 harness 与某些模型“更合拍”。如果公司希望保持模型独立性，大致有两种做法：

要求用户切换 harness。 一种方式是向开发者提供一组 harness（Claude Code、Codex 或 Cursor），然后在公司希望把支出迁移到更低成本模型时，要求他们在这些 harness 之间切换。这样用户在可能的情况下仍可在自己偏好的 harness 中工作，但缺点是，单个开发者的切换成本可能很高。如果切换成本过高，harness 本身就会事实上锁定到某个模型家族，从而限制把支出迁移到更有竞争力模型的能力。

使用 meta-harness。 一种新的、且越来越流行的方式是使用 meta-harness，它向开发者呈现统一的用户体验，同时将请求分发到底层 harness（既包括专有，也包括开源）。这种方式既能保持模型/harness 独立性，又能降低开发者切换成本。在 Databricks，使用 Omnigent 的开发者默认采用这种模式。我们交流过的一些公司也构建了自定义的内部 meta-harness，并将其集成到自己的开发工具链中。

成本杠杆 #2：动态请求与任务路由

越来越多的研究表明，与其让用户自己选择适合任务的模型，不如通过自动化的模型和工具选择，进一步挤压代理式编码工作流中的效率空间。路由方法大致分为三类：

• 请求级路由（Request Level Routing）： 一个有状态的代理位于客户端（如编码 harness）与底层基础模型之间。该代理尝试将请求路由到能够回答每次推理请求的最低成本模型。代理式用例的路由还需要考虑服务端缓存，因为对于大上下文工作负载，冷缓存命中会带来很高的成本。新一波产品已经在路由方面展现出早期且令人鼓舞的结果。示例如：Cursor Router、OpenRouter 的 AutoRouter、Ramp 的 Router 功能，以及 Databricks 在 Unity AI Gateway 中提供的 Smart Routing 功能。
• 任务级路由（Meta Harness）： 客户端进程根据任务复杂度，将用户任务分发给不同的 harness。用户任务可能是“把这个组件从 X 重命名为 Y”（简单任务），也可能是“探索可降低延迟的设计考虑”（开放式复杂任务）。调度器通常称为 Meta Harness，它会判断某个任务需要哪一级底层模型，然后将整个端到端任务委派给该模型。Omnigent 就是支持这一模式的 Meta Harness 示例。
• 升级/委派模式（Escalation/Delegation Patterns）： 一个 harness 配对两个模型（一个昂贵、高智能的模型和一个便宜的工作模型）。在某些方案中，例如 Claude 的 Advisor Tool，更便宜的模型负责主导，并在判断任务需要更多算力时进行 升级。也存在相反的模式：在 Cognition 的 Devin Fusion 中，更高成本的模型作为主循环，并有选择地把工作外包给更便宜的模型。 Databricks 的内部结果表明，我们的 AI Gateway Smart Router 能够持续将平均任务成本降低 30% 以上，同时质量大致与工作集里最昂贵的模型持平。我们交流过的其他公司也看到了类似结果。

成本杠杆 #3：让开发者看到支出、预警阈值和预算

也许令人惊讶的是，这整篇文章并没有以“给用户设一个月度预算，然后就结束了”开头并结尾。硬预算（hard budgets）——即在某个具体支出阈值后完全切断使用——在我们交流过的每家公司中，往往都只是最后手段。硬性的 token 预算之所以对 AI 支出管理并不特别有效，有两个原因：第一，如果开发者触碰到预算上限，切断其继续访问 AI 工具的权限会严重损害生产力。公司和员工其实都不希望出现这样的结果。第二，至少有一部分“高支出”用户，实际上是借助 AI 实现了巨大的效率提升并产出了海量成果。打击这些用户，反而适得其反。

与其设置硬性的用户支出上限，大多数公司正在采用一种更细腻、渐进式的方法：重点是让终端用户看得见支出，并随着支出增加而逐步提高使用摩擦。

1. 可见性： 我们交流过的每家公司都有机制，能向用户近乎实时地反馈其持续支出，其中许多还会提供具体建议或洞见，告诉用户如何通过使用更便宜的模型来降低支出。让用户能够看到自己在所有工具上的支出很重要，因为他们可能希望在 ROI 最高的地方，影响自己对工具的选择。 Databricks 的开发者仪表板，显示当前支出
2. 支出门槛（Spend Gates）： 可以要求开发者在支出增加到一定程度时采取行动或寻求审批。最简单的支出门槛是可由用户自行解除的 self-clearing 门槛，它起到警示作用，提示支出速率正在超过某个阈值。在 Databricks，我们发现 self-clearing 门槛是防止意外或无意支出的有效机制。还可以设置更进一步的门槛，要求明确的预算审批（通常通过管理链路）。
3. 降档（Downshifting）： 如果开发者触发了支出门槛，可以将其降档到更低成本的模型，而不是完全暂停其 token 访问。由于最低成本模型比前沿智能模型便宜得多，这种做法让开发者能够继续完成工作，而不会产生巨额持续支出。
4. 暂停： 在极端情况下，大多数系统确实保留了将用户完全暂停全部 token 访问的能力。正如上文所述，这通常只是临时措施，也是开启一场关于如何高效利用 AI 的讨论的起点。

成本杠杆 #4：降低 Token 开销

当用户在 AI 编码代理中输入一个相对简单的请求（例如“请调查并修复这个 bug。”）时，该代理随后会收集大量相关上下文，调用大量工具，搜索整个代码库，并整合公司提供的技能或系统信息。等到昂贵的 LLM 推理真正发生时，用户最初输入的语句只占输入给 AI 系统数据的极小一部分，这意味着成本主要由用户并未显式提供的上下文所驱动。降低上下文膨胀（context bloat）的技术仍然较新，但已有若干有前景的探索方向，例如：

• 促使更频繁地对活动上下文进行压缩（compaction）。
• 使用“没那么啰嗦”的 harness（更高 token 效率），或调优现有 harness 以生成更少的 token 开销。
• 审计常用工具并降低其输出冗余。
• 鼓励开发者将任务拆分为更小的独立工作单元，从而缩小上下文范围。

当上下文变大时，prompt 缓存（caching）在整体性能中也会发挥重要作用。无论是专有还是开源 LLM，都提供了启用 prompt 缓存并调整缓存存储时长的设置。缓存写入需要成本，但缓存读取可以显著降低单次推理成本。这种权衡取决于公司的具体工作负载，因此通过人工调优默认缓存设置、提高整体缓存命中率，往往能显著改善总体成本。

在 Databricks，对我们的 harness 和缓存设置做相对简单的调优，就让生成的 token 数量及相关成本减少了将近 50%，而开发者未观察到质量下降。我们仍在探索这一领域的技术，并认为仍有相当大的进一步优化空间。

通过消除多余的推理调用并减少缓存写入，实现每次会话 token 数量的大幅下降。

AI Gateway 设计模式

上面的技术都有许多隐含的技术要求：要快速利用新模型，公司必须有一个集中管理“模型菜单”的位置，而终端用户必须拥有支持模型混用的工具链。要在多个 AI 工具之间提供预算可见性，就必须具备统一的成本可观测能力。要管理上下文膨胀，公司需要一种观察典型工具调用输出并强制压缩或 compaction 的方式。这些需求正由一类新的基础设施软件共同解决，最恰当地称之为 AI Gateway。AI Gateway 是一个集中地点，所有以下事情都在这里发生：

1. 对底层模型（包括专有模型和 OSS 模型）的访问进行容量管理和代理转发。
2. 预算跟踪与执行，包括诸如渐进式摩擦等级和模型降档等复杂预算策略。
3. 面向终端用户工具的配置管理，用于强制执行模型白名单、compaction 设置以及其他本地中介方面。
4. 记录编码会话轨迹，供后续效率分析和基准测试使用。

在 Databricks，我们在所有这些能力上都高度依赖 Unity AI Gateway。

综上所述

AI 编码成本的指数级增长并非不可避免，它是一个可以通过工程与治理解决的问题。那些成功将其驯服的公司有一套共同的做法：持续追逐效率前沿而非智能前沿，采用能保持模型灵活性的工具，智能地把工作路由到最便宜且胜任的模型，用可见性和渐进式摩擦取代硬预算，并削减主导真实世界支出的 token 开销。上述技术都不需要牺牲最初促使 AI 采用变得值得的生产力收益；合在一起，它们使组织能够在可预测的成本范围内，实现广泛、低摩擦访问这一双重目标。

一套新的基础设施抽象正在出现，为公司提供管理成本所需的工具。在 Databricks，我们已将成本管理栈中的关键组件以开源或免费软件产品的形式发布：用于集中管理的 Unity AI Gateway，以及面向开发者工具链的 Omnigent。每天都有数千家公司在使用这些组件。随着这一技术格局快速演进，我们欢迎更多公司分享发现并比较不同方法。

致谢：感谢 Uber、Stripe、Coinbase 和 Ramp 的基础设施负责人对本文提供评论和审阅。也感谢 Thrive Capital 对本文早期草稿提出的反馈。