Databricks 高管复盘 AI 编码成本治理，从账单失控到单位成本降 90%

Databricks：Blog·2026-10-23 02:12· 1 小时前AI 评分66

AI 账单即将到来

AI 导读

Databricks 负责 AI 产品的 Patrick 在访谈中讲述公司全面采用 AI 编码智能体后成本一度指数级上涨，最终部分场景单位成本下降达 90%。

正文 · 原文

在这次对话中，Catherine Brown 与 Patrick 讨论了 Databricks 全面投入 AI 编码智能体后发生了什么：成本最初如何随着使用量增长而螺旋上升，究竟是什么让单位成本下降了多达 90%，以及为什么每个工程组织都需要在开发者和模型之间设置一个控制层。这个控制层最初是为了解决 Databricks 自身的 AI 账单问题而做的内部修复，后来成为了 Unity Gateway 的灵感来源。

工程产出才是瓶颈

Catherine：你负责 Databricks 的 AI 产品，同时也是公司内部推动 AI 采用的倡导者。为什么这件事对你来说成了如此重要的个人优先事项？

Patrick：因为工程产出是我们业务的主要瓶颈。每家公司都需要工程团队跑得更快，如果你能给他们带来真正提升生产力的东西，那价值巨大。早期的聊天产品有一定用处。但 ROI 真正发生变化大概是在一年前，第一批真正优秀的编码模型出现的时候。

Catherine：你如何判断是否从 AI 工具中获得了生产力提升？

Patrick：我们追踪一系列产出指标：拉取请求、交付的功能和代码行数。单独看，没有哪个指标是完美的。我把研发看作一台大机器。你投入资源，产出功能和代码，然后可以衡量多出来的产出有多少。总体来看，我们在团队规模不变的情况下产出接近翻倍。那些围绕 AI 重建了流程的团队，速度要快得多。

从 Tokenmaxxing 到 ValueMaxxing

Catherine：Databricks 最初推出 AI 编码工具时，你们做错了什么？

Patrick：有点好笑，因为一开始我们的问题是反过来的。没人愿意尝试新东西。我到处去烦人。所以我们做了大家都在做的事：移除一切障碍——最贵的模型，想用多少 token 就用多少。我觉得出发点是好的。你是想帮大家跨过这道坎。

然后人们真的开始用了，我们看到了这条指数级的成本曲线。这些工具现在都是按用量计费，而不是按席位，所以单个用户在理论上可以花掉无上限的钱。他们可以在最贵的模型上跑一个小循环然后去吃午饭。也许那个循环在做非常有价值的事，但也许只是在烧 token。如果你的成本指数级增长而收入没有，那迟早会出问题。我们到了成本有可能逆转效率提升的地步，而效率提升正是我们做这一切的全部理由。

那时我个人深度介入了。我和我认识的其他大规模采用 AI 的科技公司领导者（Coinbase、Uber、Stripe 等）交流了经验。我们中的许多人 collectively 都在采用类似的技术。今天，在 Databricks，我们的人均 token 支出现在大致持平，即使总使用量和价值持续上升。

别再给你最好的开发者设硬性上限

Catherine：大多数公司的第一反应是设硬性支出上限。你试过了。结果怎样？

Patrick：这显然是最先想到的做法，而且你确实需要这个机制。但硬性切断体验很差。你在任务进行到一半时切断某人，他们会失去心流，可能损失数小时的工作。而触及上限的人往往是你的最佳用户。切断他们，其中一些人就会去用个人账户，现在你就什么都看不到了。

所以我们转向逐步升级的摩擦，Unity Gateway 处理这一切。首先警告，然后审批，接着把你降级到更便宜的模型，让你能继续工作。真正切断某人只是最后手段。我们还会定期向每个人发送其自身支出的明细，并附上节省建议。仅这一项就值大约 10%。我认识的一家公司把模型和成本直接放进每个拉取请求。所以如果你为一件小事用了昂贵模型，基本上就是公开处刑。我喜欢这个。

最好的成本优化是开发者根本注意不到的

Catherine：你写过降低这些成本的四个杠杆。哪一个影响最大？

Patrick：我们最喜欢的一个有点无聊：更好、更便宜的模型不断出现，你把流量迁移过去。专有和开源厂商每周大概会发布五个模型。并非每一个都在成本上更进一步，但也许每一两周就有一个。这是水涨船高。你花更少的钱得到同样的输出，而且没人需要改任何东西。不需要花哨的路由，什么都不用。

让你感受一下这有多快：最近某个便宜模型大致相当于大约九个月前前沿模型能做到的水平，而每个任务的成本约为其 1%。不到一年成本下降了 100 倍。这仍是初步结果，但方向如此。

问题在于你必须真的迁移。如果新模型出来了，而你公司里没人在用，那就是树林里一棵树倒下。所以我们擅长快速评估新模型，并在某个模型足够好时迁移工作负载。因为一切都经过 Unity Gateway，我们可以在一个地方完成切换，开发者无需改动任何东西。这是我们做过的影响最大的事，单这一项就有 50% 或更多。再加上路由、支出可见性和削减 token 开销，在某些情况下，我们的单位成本降幅高达 90%。

模型的 token 价格无法预测它的实际成本

Catherine：你的团队用 Databricks 自己数百万行的代码库对编码智能体进行基准测试。为什么不直接相信公开基准？

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

有些结果让人意外。一个开源模型 GLM 5.2 在质量上与 Opus 4.8 持平，而每个任务成本约低三分之一。有一个模型每 token 便宜 1.7 倍，但每个任务成本更高，因为它消耗了更多 token。而 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。正是这一点让我们真正看清了钱花在了哪里。后来我们意识到每个客户都有同样的问题，于是把它产品化为 Unity Gateway。现在有数千家客户在使用。

Catherine： 路由最终会变得和模型本身一样具有竞争力吗？

Patrick： 这是我们的看法。随着模型利润变薄，弄清楚哪个模型用于什么场景，是一个相当有意思的位置。路由模型必须小而快。而且要做好也很难。在实际使用这些模型方面，有很多开放的研究问题，我认为把它做对确实有真正的知识产权价值。

你无法优化你看不见的东西

Catherine： 如果只能给一位面对不断增长的 AI 账单的 CTO 一条建议，你会说什么？

Patrick： 弄清楚钱花到哪里去了。大多数公司无法告诉你他们按团队或按模型在 AI 上花了多少，更不用说是否划算。在你的模型前面放一个网关，让所有流量都经过一个地方，你就能看见了。之后其他一切都会变得更容易。而且不要放慢脚步。生产力提升是真实的。但这些东西会复利增长，如果你等待，账单会比你想象的大得多。

AI 账单正在到来，但它不必成为赢家

Patrick 向工程负责人传达的信息是：你不必在 AI 生产力与成本控制之间做选择。做对这件事的公司会保持对最佳模型的广泛访问，在自己的代码上测试新模型，一旦新模型足够好就转向更便宜的模型，并给开发者提供可见性而不是围墙。在这一切之下是一个控制层，即网关，它让 AI 支出成为你可以看见并引导的东西。在 Databricks，这一层成为了 Unity Gateway。

要了解更多关于 Databricks 如何管理自身 AI 编码支出的信息，请阅读 Patrick 的博客“大规模管理 AI 编码成本”，并试用 Databricks Unity Gateway。

来源：Databricks：Blog · databricks.com