Databricks 谈 AI 账单：如何把编码智能体单位成本降低九成

在这个对话中，凯瑟琳·布朗与帕特里克讨论了当 Databricks 全力投入 AI 编码代理时发生了什么：最初随着使用量的增加成本是如何急剧上升的，是什么实际将单位成本降低了高达 90%，以及为什么每个工程组织都需要在其开发者和模型之间设置一个控制层。这个控制层最初是作为 Databricks 自己 AI 账单的内部解决方案开始的，并成为了 Unity Gateway 的灵感来源。

工程产出是瓶颈

凯瑟琳：你运营 Databricks 的 AI 产品，并且也一直是 AI 采用的内部倡导者。为什么这对你来说变成了如此个人的优先事项？

帕特里克：因为工程产出是我们业务中的主要瓶颈。每家公司都需要其工程团队更快地行动，如果你能给他们一些能显著提高他们生产力的东西，那这就是一笔巨大的投资。早期的聊天产品有点用处。但投资回报率大概一年前发生了变化，当时出现了第一批真正优秀的编码模型。

凯瑟琳：你如何知道你是否从 AI 工具中获得了生产力提升？

帕特里克：我们跟踪一系列产出指标：拉取请求、已发布的功能和代码行数。它们单独来看都不完美。我认为研发就像一台大机器。你投入资源，产出功能和代码，并且你可以测量出更多产出量。总的来说，我们几乎是用相同的团队实现了产出的近两倍。那些围绕 AI 重建流程的团队比这个速度还要快得多。

从 Tokenmaxxing 到 ValueMaxxing

凯瑟琳：当 Databricks 首次推出 AI 编码工具时，你们做错了什么？

帕特里克：有点好笑，因为一开始我们遇到了相反的问题。没有人想尝试新东西。我到处跑着烦扰人们。所以我们做了每个人都做的事情，移除了所有障碍：最昂贵的模型，你想用多少 token 就用多少。我想这出发点是好的。你正试图让人们跨过这个坎。

然后人们真的开始使用它了，我们看到了这个指数级的成本曲线。这些工具现在都是按消耗计价的，不是按座位计价的，所以一个单一用户原则上可以无限制地花钱。他们可以在最昂贵的模型上运行一个小循环就去吃午饭。也许这个循环在做些真正有价值的事情，也许它只是在消耗 token。如果你的成本呈指数级增长而你的收入没有，那么在某个时刻，你就有问题了。我们到了成本威胁要逆转效率提升的地步，而效率提升正是我们做这件事的整个原因。

那是我非常个人地介入的时候。我与我知道在规模化采用 AI 的其他科技公司（Coinbase、Uber、Stripe 等等）的领导者们交换了意见。我们许多人集体正在追求类似的技术。今天，在 Databricks，我们每个人的 token 花费大致是稳定的，即使总使用量和价值仍在持续增长。

停止对你最好的开发者设置硬性上限

凯瑟琳：大多数公司的第一反应是设置硬性支出上限。你们试过了。发生了什么？

Patrick: 这是最明显的第一步，而且你确实需要这个机制。但硬性停止会带来糟糕的体验。你在别人任务中途打断他们，他们会失去自己的节奏，可能损失数小时的工作。而且达到上限的人往往是你的最佳用户。把他们断开，其中一些人就会转而使用个人账户，现在你就无法看到任何情况了。

所以我们转向了逐渐增加的摩擦力，而 Unity Gateway 处理所有这些。首先是一个警告，然后是批准，然后我们把你们转移到更便宜的模型，这样你们就可以继续工作。实际上断开连接是一个最后的手段。我们还向每个人发送他们自己的支出明细和节省建议。仅此一项就值约 10%。我认识的一家公司把模型和成本放在每个拉取请求中。所以如果你用昂贵的模型处理小事，基本上就是公开羞辱。我喜欢这一点。

最好的成本优化是开发者从未注意到的。

Catherine: 您已经 写到了 四个降低这些成本的手段。哪一个产生了最大的影响？

Patrick: 我们最喜欢的一个有点无聊：更好的、更便宜的模型不断推出，而你把流量转移到它们上。在专有和开源供应商之间，每周可能发布五个模型。并非每个模型在成本上都是进步，但可能每周或每两周有一个。这是一个不断上涨的潮水。你用更少的钱得到同样的输出，而且没有人需要改变任何东西。没有复杂的路由，什么都没有。

为了让你了解这个速度有多快：最近的一个便宜模型大致相当于九个月前前沿模型所能做到的事情，每项任务的成本约为 1%。在不到一年的时间内下降了 100 倍。这仍然是初步的，但它是指向。

问题是你要真正移动。如果推出了一个新模型，而你们公司没有人使用它，那就如同树林中倒下一棵树。所以我们擅长快速评估新模型，并在一个足够好的时候转移工作负载。因为所有东西都通过 Unity Gateway，我们可以在一个地方进行切换，开发者不需要改变任何东西。这是我们所做的最有影响的事情，仅此一项就贡献了 50% 或更多。加上路由、支出可见性和减少令牌开销，在某些情况下，我们的单位成本降低了 90%。

一个模型的令牌价格并不能很好地预测它的成本。

Catherine: 你的团队 将编码代理与 Databricks 自己的百万行代码库进行基准测试。为什么不只信任公开的基准测试？

Patrick: 公开的基准测试并不能告诉你很多关于你自己的代码。任务会泄露到训练数据中，而且它们看起来不像一个大企业的代码库。所以我们从我们仓库中的真实拉取请求中构建了自己的基准，我们通过实际运行测试来评分。我们不使用 LLM 作为评判者，因为那往往会奖励听起来正确而不是正确。

一些结果让一些人感到惊讶。一个开源模型 GLM 5.2 在质量上与 Opus 4.8 相当，每项任务的成本大约降低了三分之一。一个模型每令牌成本便宜 1.7 倍，但每项任务的成本更高，因为它消耗了更多的令牌。而且 harness（模型周围的编码工具）也很重要，与模型本身差不多。相同的模型，不同的 harness，成本差异超过 2 倍。仅仅调整 harness 和缓存设置就为我们节省了近 50%。

前沿模型用于前沿问题

Catherine: 最便宜和最贵型号之间的差距可以达到100倍。工程领导者应该如何考虑这个范围？

Patrick: 想象一下汽车。有兰博基尼、本田和自行车。你不需要每次都开兰博基尼，而且大多数编码工作也不需要最大的型号。

Astra是一个很好的例子。我们向所有工程师推广了它，大约有3,500人，据我们所知，我们是第一个公开分享这种推广的公司的公司。它在处理复杂问题时明显更好，比如系统设计。但成本增加了约60%，而且它并没有明显地帮助日常任务，而现有型号已经可以很好地处理这些任务。很多都是浪费，人们用Astra处理本应该用其他型号处理的事情。所以我们在Unity Gateway中给它单独分配了预算。用于处理复杂问题。

从长远来看，我不知道会走向何方。便宜的型号不断接管更多的常规工作，但人们也在向AI提出越来越难的问题。这就是它的目的。你想能够引导任何一方。

模型路由是新的AI战场

Catherine: 你认为AI成本是一个基础设施问题，而不是采购问题。为什么预算和政策不能解决这个问题？

Patrick: 预算有帮助，但预算不能决定哪个型号应该处理给定的请求。那是路由。重命名组件会交给便宜的型号；一个复杂、开放的问题会交给能力强的型号。我们的智能路由器将平均任务成本降低了30%以上，质量大致与最贵的型号相当。它还允许我们停止要求用户决定何时使用更贵的型号……那自然而然发生了。

要完成任何这些，你需要在你的开发者和模型之间有一层。我们建造了自己的，因为我们不得不这么做。我们所有的编码工具流量都通过一个网关，无论是Claude Code、Codex、Cursor还是Omnigent，我们的元 harness。那就是让我们实际上看到钱花在哪里的方式。然后我们意识到每个客户都有同样的问题，所以我们将其产品化为Unity Gateway。现在有数千个客户在使用它。

Catherine: 路由最终会像模型本身一样具有竞争力吗？

Patrick: 这是我们观点。随着模型的利润越来越薄，决定用什么型号来处理什么是一个相当有趣的地方。路由模型必须很小且快速。这也很难做好。在使用这些模型的实际方面有很多开放的研究问题，我认为在正确处理方面有真正的知识产权。

你无法优化你无法看到的东西

Catherine: 如果你只能给一个盯着不断增长的AI账单的CTO一条建议，你会是什么？

Patrick: 弄清楚钱花在哪里。大多数公司无法告诉你他们在团队或模型上的AI支出是多少，更不用说它是否有效了。在你的模型前面放一个网关，让所有流量都通过一个地方，这样你就可以看到它。之后一切都更容易了。而且不要放缓。生产力的提升是真实的。但这会成倍增加，如果你等待，账单将会比你想象的要大得多。

AI账单即将到来，但它不必获胜

Patrick 对工程领导者传达的信息是，你不必在 AI 生产力与成本控制之间做出选择。那些处理得当的公司保持对最佳模型的广泛访问，在自己的代码上测试新模型，一旦足够好就转向更便宜的模型，并为开发者提供可见性而不是障碍。所有这一切之下是一个控制层，一个网关，它使 AI 支出变得可见且可控。在 Databricks，这一层成为了 Unity Gateway。

要了解更多关于 Databricks 如何管理其 AI 编码支出的信息，请阅读 Patrick 的博客 "Managing AI Coding Costs at Scale"，并尝试 Databricks Unity Gateway。