
目录
- 编码模型的“效率前沿”
- 成本杠杆1:转向开源和低成本模型
- 工具套件与模型灵活性
- 成本杠杆2:动态请求和任务路由
- 成本杠杆3:为开发人员提供可见性、预警和预算
- 成本杠杆4:减少令牌开销
- AI网关设计模式
- 总结
公告
2026年8月7日
AI编码工具具有巨大价值,在Databricks,智能编码显著提升了所追踪的各项速度指标,部分团队的产出更是实现了数量级的增长。然而,几乎所有大规模部署AI工具的公司都遇到成本呈指数级增长的难题,若不控制,最终成本将超过收入。这让企业陷入两难:既想推进AI转型为员工提供强大工具,又要面对总体成本过高可能削弱AI效率提升的问题。
幸运的是,一些早期大规模应用AI的公司找到解决方案,实现“双重目标”:一是让员工轻松使用AI工具;二是将每个用户的总体成本控制在相对固定范围内。本文基于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] 中的智能路由功能。
- 任务级路由(元工具套件):客户端进程根据任务的复杂性将用户任务分配给不同的工具套件。用户任务可能是“将此组件从X重命名为Y”(简单任务),也可能是“探索降低延迟的设计考虑因素”(复杂任务)。这个调度器通常被称为“元工具套件”,它会检查任务所需的底层模型级别,然后将整个端到端任务委托给相应的模型。[Omnigent] 就是一个支持这种模式的元工具套件示例。
- 升级/委派模式:单个工具套件结合两个模型(一个昂贵的高智能模型和一个便宜的工作模型)。在某些方法中,如 [Claude的Advisor Tool],较便宜的模型主导流程,当它认为任务需要更强大的计算能力时会“升级”。相反的模式也存在,如 [Cognition的Devin Fusion],较高成本的模型是主循环,它会选择性地将工作委派给较便宜的模型。
Databricks的内部测试结果表明,其AI网关智能路由器能持续将平均任务成本降低30%以上,同时在质量上与工作集里最昂贵的模型相当。交流过的其他公司也有类似结果。

成本杠杆3:为开发人员提供可见性、预警和预算
本文未一开始就建议“给用户设定每月预算,然后就万事大吉”。在交流过的所有公司中,“硬预算”(即当使用量达到特定支出阈值时完全切断使用权限)通常只是最后的手段。硬令牌预算在AI支出管理中效果不佳,主要有两个原因:一是开发人员达到预算上限时,切断其对AI工具的访问会严重影响生产力,对公司和员工都不利;二是至少有一部分“高支出”用户实际上通过AI实现了巨大效率提升并产出颇丰,限制他们的使用反而适得其反。
因此,大多数公司采用更细致、渐进的方法,重点是让终端用户了解支出情况,并随支出增加逐步增加使用限制。
- 可见性:交流过的每家公司都有机制为用户提供实时的支出反馈,许多公司还会提供具体建议或见解,帮助用户通过使用更便宜的模型来降低支出。用户能查看所有工具的支出情况很重要,因为他们可根据投资回报率来选择工具。
Databricks的开发人员仪表盘,显示当前支出情况 - 支出门槛:可要求开发人员在支出达到不同水平时采取行动或寻求批准。最简单的支出门槛可“自行解除”,作为警告提示支出速率超过阈值。在Databricks,这种自行解除的门槛是防止意外或无意识支出的有效机制。还可设置需要明确预算批准(通常通过管理链)的门槛。
- 降级使用:若开发人员达到支出门槛,可降级到使用低成本模型,而非完全禁止使用令牌。由于最低成本模型的价格远低于前沿智能模型,这种方法可让开发人员继续工作,而不会产生巨额的持续支出。
- 暂停使用:在极端情况下,大多数系统仍保留完全暂停用户使用所有令牌的能力。如前所述,这通常只是临时措施,也是开始讨论如何有效利用AI的契机。
成本杠杆4:减少令牌开销
当用户向AI编码代理输入简单请求(如“请调查并修复这个bug”)时,代理随后会收集大量相关上下文,调用大量工具,搜索代码库,并整合公司提供的技能或系统信息。到进行高成本的大语言模型(LLM)推理时,用户最初的输入在输入到AI系统的数据中只占很小一部分,意味着成本主要由用户未明确提供的上下文决定。减少上下文冗余的技术仍处于起步阶段,但目前正在探索一些有前景的方法,例如:
- 促使更频繁地压缩活动上下文。
- 使用“简洁”(更节省令牌)的工具套件,或调整现有工具套件以减少令牌开销。
- 审查常用工具并减少其冗长性。
- 鼓励开发人员将任务分解为更小的工作单元,缩小上下文范围。
当上下文变得很大时,提示 缓存 在整体性能中起重要作用。专有和开源的LLM都有设置选项,可启用提示缓存并调整缓存的存储时间。缓存写入需要成本,但缓存读取可大幅降低每次推理的成本。这种权衡取决于公司的具体工作负载,因此手动调整默认缓存设置以提高总体缓存命中率可显著降低总体成本。
在Databricks,对工具套件和缓存设置进行相对简单的调整后,生成的令牌数量和相关成本减少了近50%,且开发人员并未发现质量下降。将继续探索这一领域的技术,并认为还有很大的优化空间。
通过消除不必要的推理调用和减少缓存写入,每次会话的令牌数量大幅减少
AI网关设计模式
上述技术隐含许多技术要求:为快速利用新模型,公司需要集中管理“模型菜单”的地方,且终端用户的工具链需支持模型切换;为提供多个AI工具的预算可见性,需要统一的成本监控功能;为管理上下文冗余,公司需要能观察典型工具调用的输出,并强制进行压缩。这些需求正由一类新的基础设施软件—— AI网关 来解决。AI网关是集中的地方,可实现以下功能:
- 管理对底层模型(包括专有和开源模型)的访问权限和容量。
- 跟踪和执行预算,包括复杂的预算政策,如渐进式限制和模型降级。
- 管理终端用户工具的配置,以执行模型白名单、压缩设置和其他本地调解方面的操作。
- 记录编码会话跟踪,以便进行下游效率分析和基准测试。
在Databricks,主要依靠 [Unity AI Gateway] 来实现所有这些功能。
总结
AI编码成本的指数级增长并非不可避免,可通过工程和治理手段解决。成功控制成本的公司有共同策略:不断追求效率前沿,而非仅关注智能前沿;采用支持模型灵活切换的工具;将工作智能地路由到成本最低且能胜任的模型;用可见性和渐进式限制取代硬预算;削减在实际应用中占主导地位的令牌开销。这些技术不会牺牲最初采用AI所带来的生产力提升;综合运用这些技术,组织可在可预测的成本范围内实现广泛、便捷的AI访问这一双重目标。
一系列新的基础设施抽象正在涌现,为公司提供管理成本的工具。在Databricks,已将成本管理堆栈中的关键组件作为开源或免费软件产品发布:用于集中管理的 [Unity AI Gateway] 和用于开发人员工具的 [Omnigent]。每天都有成千上万家公司使用这些组件。随着技术的快速发展,邀请更多公司分享经验并交流技术。
致谢:感谢Uber、Stripe、Coinbase和Ramp的基础设施负责人对本文提供的评论和反馈。感谢Thrive Capital对本文初稿的意见。
订阅获取最新文章
订阅博客,将最新文章直接发送到您的收件箱。
为何选择Databricks
探索
客户案例
合作伙伴
产品
Databricks平台
定价
开源
集成与数据
解决方案
Databricks行业解决方案
跨行业解决方案
数据迁移
前沿部署工程
解决方案加速器
资源
学习资源
活动
博客与播客
关于我们
公司信息
职业发展
媒体资讯
安全与信任
Databricks公司
地址:美国加利福尼亚州旧金山Spear街160号15层
邮编:94105
电话:1 - 866 - 330 - 0121
© 2026 Databricks保留所有权利。Apache、Apache Spark、Spark、Spark标志、Apache Iceberg、Iceberg和Apache Iceberg标志是 [Apache软件基金会] 的商标。


被折叠的 条评论
为什么被折叠?



