大规模 AI 编程成本控制实战指南

AI 编码工具带来了巨大的价值：在 Databricks，代理式编码在我们追踪的每一项速度指标上都有可衡量的提升，在某些团队中，产出甚至提升了一个数量级。但几乎所有大规模部署 AI 工具的公司都遇到了同样的瓶颈：成本呈指数级增长。这条曲线是不可持续的——如果不加控制，最终会超过收入。支出爆发让企业陷入了一个矛盾的局面：一方面希望最大化推动 AI 转型、将强大工具交到员工手中；另一方面又不得不面对总体成本轮廓，这种成本轮廓可能会削弱甚至逆转 AI 所带来的效率提升。

幸运的是，一些最早的大规模采用者已经 converge 在一套方案上，解决了这个难题，实现了"双重使命"：（a）提供广泛的 AI 工具访问，几乎没有摩擦；（b）将总体成本控制在每个用户大致固定的范围内。本文概述了经过验证的成本管理技术，基于我们在 Databricks 的经验以及与几家数字原生企业（包括 Stripe、 Coinbase、Uber 和 Ramp）的交流。下表总结了我们调查的开发团队目前使用的技术和相关节省效果；这些数字是方向性的：

其中一些技术可以轻松地使用许多公司已经在用的软件实现。另一些则需要新的基础设施，特别是那些修改最终用户客户端或将流量转移到不同模型的技術。在 Databricks，我们已经开源或免费提供了我们的关键基础设施组件：最终用户元 harness（Omnigent）和我们的 AI Gateway（Unity AI Gateway）。为完整起见，本文还涵盖了与我们交流的其他公司使用的软件。

Coding Models 的"效率边界"

在编程支出转向更高效模型的过程中，单一最大的成本杠杆。随着新模型的发布，这一点值得深入讨论，因为"更便宜的模型"这一简单解释实际上掩盖了模型成本与质量之间 nuanced 的关系。

俗话说的 frontier model 指的是"最高智能模型"，而 frontier labs 主要专注于推进峰值智能。当前的 frontier models 已经能够解决数学或网络安全方面的新问题。但当 AI 被大规模部署时，另一类 frontier 变得更加重要：效率边界。效率边界由一组模型定义，这些模型在给定智能水平下具有最佳的价格点。大多数日常 coding 并不需要数学证明或新颖的安全洞察，因此在 aggregate 重要的是满足典型软件工程工作质量标准的模型成本。这种"效率边界"的推进速度远远快于智能边界，几乎每周都有新模型发布，比之前的模型提供更好的 intelligence-per-unit-price。

成本杠杆 #1：转向开源和更低成本模型

快速采用更新、更高效的模型能够带来任何技术中最大的成本收益。但要获得这些收益，公司首先需要知道哪些模型实际上优于其现有模型。这可能很困难，因为 public benchmarks 在指示 coding 任务的真实世界性能方面做得不够好。为了评估新模型，许多公司构建了自动化评估，他们认为这些评估更能代表其内部开发组合。Databricks 最近发布了此类 benchmark 的一个示例，在其中我们观察到 GLM 模型具有非常有竞争力的价格/性能。该 benchmark 使我们能够在内部向开发人员推出 GLM。通常，新模型不会推进效率边界，评估经常产生负面结果：Stripe 发现 Opus 4.7 在质量上并没有比 Opus 4.6 有意义的提升，而成本却增加了。因此他们决定不在内部提供 Opus 4.7。Databricks 在比较 Opus 5.0 和 4.8 时也看到了类似的成本回归。

Harness 和模型灵活性

由于最大的收益来自切换到新模型，采用允许模型灵活性的最终用户工具正在成为保持低成本的关键组成部分。与特定模型一起使用的最常用工具称为 harness。专有的 frontier models 越来越倾向于与特定 harness 共同设计以更好地工作，这意味着某些 harness 与某些模型"配合得更好"。如果一家公司想要保持模型独立性，大致有两种方法：

让用户切换 harnesses。 一种方法是向开发人员提供一组 harnesses（Claude Code、Codex 或 Cursor），然后在公司希望将支出迁移到更低成本模型时，要求他们在 harnesses 之间切换。这种方法让用户可能在他们喜欢的 harness 中工作，但这种方法的缺点是单个开发人员的切换成本可能很高。如果切换成本变得太高，harness 本身就会成为事实上的模型系列 lock-in，限制了将支出转移到更具竞争力模型的能力。

使用元 harness。 一种越来越受欢迎的新方法是使用元 harness，它向开发人员呈现统一的用户体验，同时将请求 dispatch 到底层 harnesses（包括专有和开源的）。这种方法既实现了模型/harness 独立性，又降低了开发人员的切换成本。在 Databricks，这是使用 Omnigent 的开发人员的默认模式。我们交谈过的一些公司构建了定制的内部元 harness，与他们的开发工具链集成。

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

与要求用户自己选择适合任务的模型不同，越来越多的研究表明，自动模型和工具选择可能进一步压缩代理式编码工作流的效率。路由方法大致分为三类：

请求级路由： 一个有状态 proxy 坐在客户端（如 coding harness）和底层基础模型之间。proxy 尝试将请求路由到能够回答每个推理请求的最低成本模型。代理用例的路由还需要考虑服务器端缓存，因为对于大型上下文工作负载，缓存未命中成本非常高。一波新产品正在展示有希望的早期路由结果。例如：Cursor Router、OpenRouter 的 AutoRouter、Ramps Router 功能和 Databricks 自己的 Unity AI Gateway 中的 Smart Routing 功能。

任务级路由（元 harness）： 客户端进程根据任务的复杂性将用户任务 dispatch 到不同的 harnesses。用户任务可能是"将此组件从 X 重命名为 Y"（一个简单任务）或一个开放性任务如"探索减少延迟的设计考虑"（一个复杂任务）。调度器，通常称为 Meta Harness，检查任务需要哪一级的底层模型，然后将整个端到端任务委托给该模型。Omnigent 是支持这种模式的 Meta Harness 的一个示例。

升级/委托模式： 单一 harness 配对两个模型（一个昂贵的、高智能模型和一个便宜的 worker 模型）。在某些方法中，如 Claude 的 Advisor Tool，较便宜的模型运行主流程，当它认为任务需要更多马力时进行升级。反向模式也存在：在 Cognition 的 Devin Fusion 中，高成本模型是主循环，它选择性地将工作外包给更便宜的模型。Databricks 的内部结果表明，我们的 AI Gateway Smart Router 能够 consistently 将平均任务成本降低超过 30%，同时大致匹配工作集中最昂贵模型的质量。我们交谈过的其他公司也看到了类似的结果。

成本杠杆 #3：为开发人员提供可见性、触发线和预算

令人惊讶的是，这整篇文章并没有以"给用户一个每月预算然后完成"开始和结束。在我们交谈过的每家公司中，hard budgets（在使用达到特定支出阈值时完全切断访问）通常只作为 last resort 手段使用。Hard token budgets 对 AI 支出管理效果不佳有两个原因：首先，如果开发人员达到预算上限，完全切断他们对 AI 工具的访问会严重影响生产力。公司和员工都不希望看到这种结果。其次，至少部分"高消费"用户实际上是那些通过 AI 获得了巨大效率提升并正在产生大量产出的人。打击这些用户是自相矛盾的。

与 hard 用户消费上限不同，大多数公司正在采用一种更 nuanced 和渐进的方法，专注于为最终用户提供可见性，并随着支出的增加增加摩擦程度。

可见性： 我们交谈过的每家公司都有一种机制，向用户提供近乎即时的持续支出反馈，许多公司还提供关于如何使用更便宜模型减少支出的具体提示。让用户能够看到他们在所有工具上的支出是很重要的，因为他们可能希望在他们获得最高 ROI 的地方影响工具选择。Databricks 的开发人员仪表板显示活跃支出

可见性： 我们交谈过的每家公司都有一种机制，向用户提供近乎即时的持续支出反馈，许多公司还提供关于如何使用更便宜模型减少支出的具体提示。让用户能够看到他们在所有工具上的支出是很重要的，因为他们可能希望在他们获得最高 ROI 的地方影响工具选择。

Databricks 显示活跃支出的开发人员仪表板

支出闸门： 可以要求开发人员在更高的支出水平上采取行动或寻求批准。最简单的支出闸门形式是可以通过 self-cleared 的形式，它作为一种警告，表明支出率正在超过某个阈值。在 Databricks，我们发现 self-clearing gates 是防止意外或无意识支出的有用机制。可以引入进一步的 gates，需要明确的预算批准（通常通过管理层链）。

降档： 如果开发人员达到了支出闸门，他们可以被降档到更低成本的模型，而不是被完全暂停 token 访问。由于最低成本模型比 frontier-intelligence 模型便宜得多，这种技术允许开发人员继续完成工作，而不会产生大量持续支出。

暂停： 在极限情况下，大多数系统确实保留了完全暂停用户所有 token 访问的能力。如上所述，这通常只是一种临时措施，是关于如何高效利用 AI 的对话的起点。

成本杠杆 #4：减少 Token 开销

当用户向 AI coding agent 输入一个相对简单的请求时（如"请调查并修复此 bug。"），该 agent 随后会收集大量相关上下文，调用大量工具，搜索代码库，并整合公司提供的 skills 或系统信息。到昂贵的 LLM 推理发生时，用户最初的陈述只占输入 AI 系统的数据中微不足道的一部分，这意味着成本 dominated by 用户没有明确包含的上下文。减少上下文膨胀的技术仍然是新的，但正在探索几种有前途的方法，例如：

强制更频繁地压缩（compression）活动上下文。

使用"不那么冗长"（更 token 高效）的 harnesses，或调优现有 harnesses 以生成更少的 token 开销。

审计流行工具并降低其 verbosity。

鼓励开发人员将任务分解为更小的单个工作单元，减少上下文范围。

当上下文变得很大时，prompt caching 也在整体性能中发挥着重要作用。专有和开源 LLM 都有允许启用 prompt caching 并调优缓存存储时间的设置。缓存写入需要花钱，但缓存读取可以大幅降低每次推理成本。这种权衡取决于公司的特定工作负载，因此 hand-tuning 默认缓存设置以提高整体缓存命中率可以对整体成本产生显著改善。

在 Databricks对我们的 harness 和缓存设置进行相对简单的调优，导致生成的 token 数量和相关成本减少了近 50%，而开发人员没有观察到质量下降。我们继续探索这个领域的技术，并认为仍有有意义的进一步优化空间。

通过消除不必要的推理调用和减少缓存写入，大幅减少每个 session 的 token 数量。

AI Gateway 设计模式

上述技术有许多隐含的技术要求：要快速利用新模型，公司必须有一个中心位置来管理"模型菜单"，最终用户必须有一个支持模型混合的工具链。要在多个 AI 工具上提供预算可见性，必须存在统一的成本可观察性能力。要管理上下文膨胀，公司需要一种方式来观察典型的 toolcall 输出并强制执行压缩或 compaction。这些需求正在被一类新的基础设施软件共同解决，最能描述为 AI Gateway。AI gateway 是一个中心位置，发生以下所有事情：

底层模型（专有和 OSS 模型）访问的容量管理和代理。

预算跟踪和 enforcement，包括复杂的预算策略，如渐进摩擦级别和模型降档。

最终用户工具的配置管理，以 enforcement 模型 allow-lists、压缩设置和其他本地中介方面。

编码 session traces 的日志记录，用于下游效率分析和基准测试。

在 Databricks，我们严重依赖 Unity AI Gateway 来实现所有这些功能。

把这一切整合起来

AI 编码成本的指数增长并非不可避免，而是一个可解决的工程和治理问题。控制住它的公司有一个共同的 playbook：无情地追逐效率边界而不是智能边界，采用保持模型灵活性的工具，智能地将工作路由到最便宜的可行模型，用可见性和渐进摩擦取代硬性预算，并削减主导真实世界支出的 token 开销。这些技术都不需要牺牲使 AI 采用值得一试的生产力提升；它们共同让组织能够在可预测的成本 envelope 内满足广泛、低摩擦访问的双重使命。

一组新的基础设施抽象正在出现，为公司提供管理成本的工具。在 Databricks，我们已经将成本管理堆栈中的关键组件作为开源或免费软件产品发布：用于集中管理的 Unity AI Gateway 和用于开发人员工具的 Omnigent。每天有数以千计的公司使用这些组件。随着这个技术景观的快速发展，我们邀请更多公司分享发现并比较技术。

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

订阅我们的博客，获取最新帖子

订阅我们的博客，获取最新帖子 delivered 到您的收件箱。