article_id: cbbc51409127fc34eb701bb4c0b86bb7

title_zh: 路由省三成、token 砍半：Databricks 控费法

source: Databricks 官方博客

published_at: 2026-08-08

—

AI 编程工具给企业带来的效率提升有目共睹，但当它铺开到整个研发团队，账单却常常以指数级膨胀，甚至有可能超过工具本身创造的价值。Databricks 近期发布长文，结合自家与 Stripe、Coinbase、Uber、Ramp 等公司的一线经验，总结出一套把成本压回可控区间、又不牺牲效率的方法论。

比“最聪明”更重要的是“最划算”

文章提出一个核心概念——“效率前沿”（efficiency frontier）。与追求峰值智力的“智能前沿”不同，效率前沿指的是在给定智力水平下价格最优的那一批模型。日常编程大多不需要证明数学定理或破解全新安全漏洞，真正决定总体开销的，是达到普通软件工程质量门槛的模型单价。Databricks 观察到，效率前沿的推进速度远快于智能前沿，几乎每周都有性价比更高的新模型出现。

成本杠杆的第一招，是果断切换到开源与低成本模型。难点在于公开榜单往往不能反映真实编码表现，因此多家公司自建了更接近内部研发场景的自动评测。Databricks 公布的评测显示，GLM 系列模型性价比突出，已向内部开发者推广。反面案例同样有说服力：Stripe 发现 Opus 4.7 相比 4.6 并没有明显的质量提升，却更贵，于是决定不在内部放开 4.7；Databricks 在对比 Opus 5.0 与 4.8 时也观察到了类似的“成本倒退”。

让请求自动选最便宜的模型

第二大杠杆是动态路由。与其让用户手动挑模型，不如用代理在请求层或任务层自动派单。Databricks 自家的 Unity AI Gateway 中的 Smart Router，能把单个任务的平均成本压低超过 30%，同时质量与最贵模型基本持平。类似思路也出现在 Cursor Router、OpenRouter 的 AutoRouter、Ramp 的 Router 等功能中。在元调度（meta-harness）层面，Omnigent 这类工具把任务按复杂度分派给不同底层模型，既保留模型选择的灵活性，又降低了开发者的切换成本。

用“可见性”替代“硬预算”

第三招是给开发者可见性、预警线和弹性预算。文章指出，简单粗暴地设月度硬上限在每家受访公司都很少作为首选——开发者一旦撞上上限被断供，生产力会瞬间瘫痪；而真正高消耗的用户，往往正是借助 AI 拿到巨大产出的人。更通行的做法是提供实时花费面板、在花费升高时逐步增加摩擦（自助确认提醒、升级到主管审批），以及把用户“降档”到更便宜的模型而非直接停权。

砍掉被浪费的 token

第四招针对被忽视的 token 开销。用户一句简短指令，背后却会被代理拉取大量上下文、调用一堆工具、检索整个代码库——真正由用户显式写出的内容，在喂给模型的数据里只占极小比例。Databricks 通过更频繁地压缩上下文、调低代理的“话痨”程度、精简常用工具的冗余输出、把任务拆小，并对提示词缓存做针对性调优，在不损失质量的前提下让生成 token 数和相关成本下降近 50%。

文中提到的基础设施，Databricks 已以开源或免费软件形式放出：统一管理的 Unity AI Gateway，以及面向开发者的元调度工具 Omnigent。把这套组合拳用起来，企业才有机会同时满足“广泛、低摩擦地开放 AI 工具”与“成本可预测”这两个原本相互拉扯的目标。

来源：Databricks 官方博客《Managing AI Coding Costs at Scale》

在技术社区看来，这个结论里可信的部分和站不住的部分，需要分开来看。

先说可信的一半：这笔账确实算得过来

检索早就不是”查一次就完事”了。2022 年前后，行业普遍押注向量嵌入检索，几乎每家数据库厂商都补上了这项能力，pgvector 一度是 Neon 下载量最高的扩展。工程师手工搭建检索增强生成流水线，本质上就是做一次相似度匹配。

到了 2025 年，智能体开始流行，开发者转向多跳检索：把大问题拆成小问题，模型规划一次查询、读取结果、判断信息不够、重新组织问题、再查一次，最后带引用汇总成答案。检索从一次性系统变成了循环系统，而循环的每一轮都意味着又一次调用前沿模型，且携带着不断累积的上下文。

成本压力就出在这里。Neon 给出的数字是：一次典型的多轮检索请求交给 GPT-5.6 Sol 处理，端到端耗时超过 10 秒，费用约 0.03 美元。按 Sol 每百万输入词元（token）5 美元、每百万输出词元 30 美元的公开定价推算，这个数字是站得住的，不属于营销注水。

把量放大就更直观：每月一百万次请求——对企业内部搜索或客服自助这类场景来说算不上大流量——账单就是每月三万美元，还要忍受两位数秒级的延迟。而这项工作的实质，不过是”在自家文档里找到那一段话”。同样的请求交给一个 40 亿参数的小模型在通用推理设施上跑，成本是几分之一美分。这个差距，正是这类产品存在的理由。

Castform 究竟做了什么

强化学习后训练要跑起来，需要三样东西：一个任务、一个供智能体活动的环境、一个奖励函数。三者齐备之后，训练就是一轮轮试错——模型带着工具尝试任务，奖励函数给这次尝试打分，反馈信号指引模型一步步爬向更优表现。

问题在于，绝大多数公司手里并没有现成的任务集和奖励函数。它们有的是大量私有资料：内部文档、产品记录、支持文章、客户沟通记录、维基和业务数据库。知识确实在里面，但把这些原始资料变成可用的训练集，通常需要大量数据工程和人工标注。于是很多团队直接放弃了后训练，理由无非两个：没有训练数据，或者微调太难、缺少基础设施。

Castform 的做法是把这两步一起包掉：先把已有语料自动转成训练任务，再托管整个强化学习循环。官方举的例子是一份差旅政策文档——原文规定”通过 Navan 预订的火车票由 GitLab 差旅卡支付，必须选标准舱且提前 14 天预订”，系统据此抽出标准答案，再合成出一个自然语言问题去考模型。

奖励函数被拆成三部分：是否检索到正确的文档片段、是否引用了正确的来源、最终答案是否正确。Neon 在其中承担基础设施角色：原始文档存放在 Neon 上的 Postgres 里，训练任务生成、每一轮回放的检索调用以及最终上线推理，全部走同一套 Lakebase 检索扩展。数千条并行回放会造成极其突发的负载峰值，Neon 的动态算力伸缩把这些尖峰吸收掉，空闲时再缩回去。Neon 是 Databricks 在 2025 年收购的无服务器 Postgres 部门，Castform 则在今年 6 月才开放测试。

争议在于：整篇文章没有一个准确率数字

对这套说法的质疑同样具体。这篇博客始终没有点名所用的基座模型是哪一个，也没有给出任何准确率数据，全文唯一的图表是训练过程中的平均奖励曲线——用自己写的评分标准给自己的作业打分。Hacker News 上有评论直接追问：既然结论是”追平前沿模型”，为什么不跑一个像 BrowseComp-Plus 这样的公开检索基准？在有人这么做之前，”和 GPT-5.6 Sol 一样准”只是一句主张，不是一个结果。

对比基准的选择也偏向有利。Sol 是 GPT-5.6 家族的旗舰档位，而同系列的 Luna 正是为工具调用循环这类任务准备的高速低价档，GPT-5.4 的价格是 Sol 的一半，缓存输入更是低至每百万词元 0.50 美元——而智能体循环恰恰充满了重复上下文。真正诚实的比法，是拿”能达到准确率要求的最便宜配置”来比，这么一算，”100 倍”会明显缩水。有评论说得很干脆：跟 Luna 比。

技术路线本身也算不上新鲜。2025 年的 Search-R1 系列工作已经证明，带可验证奖励的强化学习能教会 30 亿到 70 亿参数的模型把推理和检索调用交替进行；DeepSeek 的 GRPO 方案则把相关工具链推向开源。这个赛道甚至已经开始整合：OpenPipe 被 CoreWeave 收入，Predibase 归入 Rubrik。真正新的地方不在算法，而在于需要自己搭建的部分变得很少。

两个更深的隐患

即便未来跑出一份公允的基准成绩，还有两个问题绕不过去。

第一，从自家语料里蒸馏出来的奖励函数，会一并继承语料本身的陈腐内容。过期的政策文档不会被识别为过期，只会变成”言之凿凿并附上引用”的错误答案——而且这次是训练进模型权重里，不再是提示词里可以随时改掉的东西。

第二是维护成本。Castform 一位作者在 Hacker News 上回应称，换一个新的开源权重基座重跑流水线很容易。这话没错，但也略微偏离了要点：流水线可以重跑，业务语料却在持续变化，模型需要多久重训一次、由谁负责判断该重训了，这些问题目前都没有答案。

对国内团队而言，这套思路的参考价值大于结论本身：垂直检索任务并不需要动用最贵的前沿模型，把小模型针对自家语料做一轮后训练，往往能在准确率和成本之间找到更合理的位置。但在公开基准数据出来之前，”便宜 100 倍且一样准”这句话，最好只当作一个待验证的假设。

来源：Neon 官方博客 / Pranav Aurora、Ying Hang Seah、Angel Pan，SourceFeed 分析报道，Hacker News 讨论