返回
RSS Databricks Blog 发布 2026-08-07 19:50 25

Databricks谈大规模AI编码成本管理

Databricks博客指出,AI编码工具虽能带来数量级效率提升,但成本指数增长不可持续。为兼顾广泛访问与成本可控,他们与Stripe、Coinbase、Uber、Ramp等企业交流,总结出多项成本管理技术,并开源了Omnigent和Unity AI Gateway等关键组件。
推荐理由:数据从业者可从头部数据平台的实际经验中,了解AI编码及Agent场景下的成本控制方法,对构建数据Agent和AI数据平台有直接借鉴意义。
平台AI化Databricks

译文 AI 逐段翻译

AI编码工具带来了巨大价值:在Databricks,智能体编码显著提升了我们追踪的每一项速度指标,在某些团队中,产出实现了数量级的增长。但几乎所有大规模部署AI工具的公司都遇到了同一堵墙:成本呈指数增长。这条曲线不可持续——如果不加控制,最终将超过收入。支出激增使企业陷入两难境地:一方面,希望最大限度地推进AI转型,将强大工具交到员工手中;另一方面,又不得不面对总成本状况,这可能削弱甚至逆转AI带来的效率提升。

幸运的是,一些最早的大规模采用者已经汇聚出一套解决这一难题的方法,实现了“双重使命”:(a)提供广泛的AI工具访问,摩擦最小化;以及(b)将总成本控制在每个用户大致固定的范围内。本文基于我们在Databricks的经验以及与其他几家数字原生公司(包括Stripe、Coinbase、Uber和Ramp)的交流,概述了经过验证的成本管理技术。下表总结了当前技术及相关节省;数字为方向性指导,基于对开发团队的非正式调查:

其中一些技术可以借助许多公司已使用的软件轻松实现。其他技术则需要新的基础设施,特别是修改最终用户客户端或在模型之间转移流量的技术。在Databricks,我们已开源或免费提供关键基础设施组件:最终用户元框架(Omnigent)和我们的AI网关(Unity AI Gateway)。为完整起见,本文还涵盖了我们咨询的其他公司所使用的软件。

编码模型的“效率前沿”

最大的成本杠杆是随着新模型发布,将编码支出转向更高效的模型。这一点值得讨论,因为“更便宜的模型”这一简单解释实际上隐藏了模型成本与质量之间的微妙关系。

通常,“前沿模型”指的是“最高智能的模型”,而“前沿实验室”主要专注于推进峰值智能。前沿模型现在可以解决数学或网络安全领域的新问题。但当AI大规模部署时,另一种前沿更重要:“效率前沿”。效率前沿由在给定智能水平下价格最优的模型集合定义。大多数日常编码并不需要数学证明或新颖的安全见解,因此总体而言,重要的是满足典型软件工程工作质量标准的模型成本。这个“效率前沿”的推进速度远快于智能前沿,几乎每周都有新模型发布,提供比之前模型更好的每单位价格智能。

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

快速采用更新、更高效的模型是所有技术中带来最大成本收益的。但要获得这些收益,公司首先需要知道哪些模型实际上击败了现有模型。这可能很困难,因为公开基准在指示编码任务的实际性能方面表现不佳。为了评估新模型,许多公司构建了他们认为更能代表其内部开发组合的自动化评估。Databricks最近发布了一个此类基准的示例,其中我们观察到GLM模型具有极具竞争力的性价比。该基准促使我们在内部向开发人员推出GLM。通常,新模型并不推进效率前沿,评估常常产生负面结果:Stripe发现Opus 4.7在质量上并未比Opus 4.6有显著提升,而成本却增加。因此,他们拒绝在内部提供Opus 4.7。Databricks在比较Opus 5.0与4.8时也看到了类似的成本退化。

框架和模型灵活性

由于最大的收益来自切换新模型,采用允许模型灵活性的最终用户工具成为控制成本的关键组成部分。与特定模型配合使用的最常用工具称为框架。专有前沿模型日益与特定框架协同设计,这意味着某些框架与某些模型“配合得更好”。如果公司希望保持模型独立性,大致有两种方法:

要求用户切换框架。一种方法是向开发人员提供一组框架(Claude Code、Codex或Cursor),然后当公司希望将支出转移到低成本模型时,要求他们切换框架。这允许用户在可能的情况下使用他们偏好的框架,但这种方法的缺点是单个开发人员的切换成本可能很高。如果切换成本过高,框架本身就会成为对模型家族的事实锁定,限制了将支出转移到更具竞争力模型的能力。

使用元框架。一种新的且日益流行的方法是使用元框架,它为开发人员提供统一的用户体验,同时将请求分派到底层框架(专有和开源)。这种方法既实现了模型/框架独立性,又降低了开发人员的切换成本。在Databricks,这是利用Omnigent的开发人员的默认模式。我们交谈过的一些公司已经构建了与其开发工具链集成的自定义内部元框架。

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

越来越多的研究表明,不是让用户自己选择适合任务的模型,而是自动进行模型和工具选择可能进一步压榨智能体编码工作流的效率。路由方法大致分为三类:

  • 请求级路由:有状态代理位于客户端(如编码工具)和底层基础模型之间。代理尝试将请求路由到能够回答每个推理请求的最低成本模型。对于代理用例,路由还需要考虑服务器端缓存,因为对于大型上下文工作负载,冷缓存命中的成本非常高。新一波产品在路由方面显示出早期有希望的结果。例如:Cursor Router,OpenRouter 的 AutoRouter,Ramps 的 Router 功能 以及 Databricks 在 Unity AI Gateway 中的 Smart Routing 功能。
  • 任务级路由(元工具):客户端进程根据任务的复杂性将用户任务分派到不同的工具。用户任务可能是“将此组件从 X 重命名为 Y”(简单任务)或开放式任务,如“探索减少延迟的设计考虑”(复杂任务)。调度器,通常称为元工具,检查任务需要什么级别的底层模型,然后将整个端到端任务委托给该模型。Omnigent 是支持这种模式的元工具的一个例子。
  • 升级/委派模式:单个工具将两个模型配对(一个昂贵的高智能模型和一个廉价的工人模型)。在某些方法中,如Claude 的 Advisor 工具,较便宜的模型负责运行,并在认为任务需要更强大的能力时升级。反向模式也存在:在Cognition 的 Devin Fusion中,高成本模型是主循环,它选择性地将工作外包给较便宜的模型。Databricks 的内部结果表明,我们的 AI Gateway Smart Router 能够持续将平均任务成本降低 30% 以上,同时大致匹配工作集中最昂贵模型的质量。我们采访的其他公司也看到了类似的结果。
image9.png

成本杠杆 3:为开发者提供可见性、触发器和预算

可能令人惊讶的是,这篇文章并没有以“给用户一个每月预算,就此结束”开始和结束。硬性预算,即在特定花费阈值处完全切断使用,在我们采访的每家公司中通常仅用作最后手段。硬性令牌预算对 AI 支出管理不太有效有两个原因:首先,如果开发人员达到预算上限,切断他们对 AI 工具的进一步访问将对生产力造成严重损害。公司和员工都不希望出现这种结果。其次,至少一些“高支出”用户实际上是那些通过 AI 获得了巨大效率提升并产生大量输出的人。劝阻这些用户是适得其反的。

大多数公司没有采用硬性用户支出上限,而是采用了更细致和渐进的方法,侧重于最终用户的可见性以及随着支出增加而增加的摩擦程度。

大规模管理 AI 编码成本
  1. 可见性:我们采访的每家公司都有一种机制,为用户提供关于其持续支出的近乎即时的反馈,许多公司还提供关于如何通过使用更便宜的模型来减少支出的具体提示或见解。重要的是,用户能够看到他们在所有工具上的支出,因为他们可能希望影响他们选择投资回报率最高的工具。Databricks 的开发人员仪表板显示活动支出
  2. 支出门控:可以要求开发人员在支出水平增加时采取行动或寻求批准。最简单的支出门控形式是自动清除的,并作为支出率超过某个阈值的警告。在 Databricks,我们发现自动清除门控是防止意外或无意识支出的有用机制。可以引入需要明确预算批准(通常通过管理链)的进一步门控。
  3. 降级:如果开发人员已达到支出门控,可以将其降级到成本较低的模型,而不是完全暂停其令牌访问。由于最低成本模型比前沿智能模型便宜得多,这种技术允许开发人员继续完成工作,而不会产生大量持续支出。
  4. 暂停:在极限情况下,大多数系统确实保留完全暂停用户所有令牌访问的能力。如上所述,这通常只是临时措施,也是关于如何有效利用 AI 的对话的起点。

成本杠杆 4:减少令牌开销

当用户向 AI 编码代理输入相对简单的请求(例如“请调查并修复此错误。”)时,该代理随后收集大量相关上下文,调用大量工具,搜索代码库,并集成公司提供的技能或系统信息。当昂贵的 LLM 推理发生时,用户的初始语句仅占输入 AI 系统的数据的很小部分,这意味着成本主要由用户未明确包含的上下文驱动。减少上下文膨胀的技术仍然很新,但正在探索几种有希望的方法,例如:

  • 强制更频繁地压缩(压缩)活动上下文。
  • 使用“更少啰嗦”(更节省令牌)的工具,或调整现有工具以减少令牌开销。
  • 审计流行工具并降低其冗长程度。
  • 鼓励开发者将任务分解为更小的独立工作单元,缩小上下文范围。

当上下文变大时,提示缓存也对整体性能起着重要作用。专有和开源 LLM 都有设置,允许你启用提示缓存并调整缓存存储的时间。缓存写入需要花钱,但缓存读取可以大幅降低每次推理的成本。这种权衡取决于公司的具体工作负载,因此手动调整默认缓存设置以提高整体缓存命中率可以对整体成本产生巨大改善。

在Databricks,我们相对简单地调整了测试框架和缓存设置,使得生成的令牌数量和相关成本减少了近50%,而开发者没有观察到质量下降。我们将继续在这一领域探索技术,并认为仍有意义深远的额外优化空间。

通过消除多余的推理调用和减少缓存写入,每个会话的令牌数量大幅减少。

AI网关设计模式

上述技术有许多隐含的技术要求:为了快速利用新模型,公司必须有一个中心位置来管理“模型菜单”,最终用户必须拥有支持模型混合的工具链。为了提供跨多种AI工具的预算可见性,必须存在统一成本可观测性能力。为了管理上下文膨胀,公司需要一种观察典型工具调用输出并强制执行压缩或压缩的方法。这些需求正被一类新的基础设施软件共同解决,最好将其描述为“AI网关”。AI网关是所有以下活动的中心位置:

  1. 容量管理和对底层模型(包括专有和开源模型)访问的代理。
  2. 预算跟踪和执行,包括复杂预算策略,如渐进式摩擦级别和模型降级。
  3. 最终用户工具的配置管理,以强制模型允许列表、压缩设置和其他本地调解方面。
  4. 记录编码会话轨迹,用于下游效率分析和基准测试。

在Databricks,我们严重依赖Unity AI网关来提供所有这些能力。

综合应用

AI编码成本的指数级增长并非不可避免,而是一个可解决的工程和治理问题。已经控制住这一问题的公司有一个共同的策略:不懈地追求效率前沿而不是智能前沿,采用保持模型灵活性的工具,智能地将工作路由到最便宜的可用模型,用可见性和渐进式摩擦取代硬性预算,并削减主导实际支出开销的令牌开销。这些技术都不需要牺牲最初使AI采用有价值的生产力收益;它们共同使组织能够在可预测的成本范围内满足广泛、低摩擦访问的双重要求。

一系列新的基础设施抽象正在出现,为公司提供管理成本的工具。在Databricks,我们已将成本管理栈的关键组件作为开源或免费软件产品发布:我们的Unity AI网关用于集中管理,以及Omnigent用于开发者工具。每天都有数千家公司使用这些组件。我们邀请更多公司分享发现并比较技术,因为这个技术领域正在迅速发展。

致谢:感谢Uber(Ty Smith)、Stripe(Aaron Spinks)、Coinbase(Siwei Shen)和Ramp(Veeral Patel)的基础设施领导者对本文的评论和审阅。感谢Thrive Capital对本文早期草稿的反馈。

分享这条资讯
分享海报
保存图片
iOS 也可以长按图片保存