Databricks 谈 AI 成本管理新经济学：从 tokenmaxxing 转向 valuemaxxing

Databricks：Blog·2026-10-23 03:14· 3 分钟前AI 评分50

AI 成本管理的新经济学

AI 导读

Databricks 高级主任工程师 Kevin Stumpf 提出，企业 AI 的衡量重心正从 tokenmaxxing 转向 valuemaxxing，即用 AI 产生的业务影响除以成本来评估投入回报。

正文 · 原文

过去两年，围绕企业 AI 应用的叙事，主要都是如何让人们用起来。而在过去几个月里，这一叙事在许多组织中正迅速发生变化。曾经以 token 数量衡量成功的 AI 可观测性，正开始以投资回报率衡量成功；而那些率先厘清成本管理的企业，将能够在不使支出增速超过收入增速的情况下扩展 AI。

从本质上讲，AI 成本管理是指在模型、智能体、应用和团队之间衡量、归因、控制和优化 AI 支出的实践。其目标并非简单地少用 token，而是让每一美元支出所产生的业务价值最大化。随着 AI 智能体承担更多自主工作，这一实践也日益延伸到管理智能体推理、工具调用以及为其提供支持的模型的成本。

我们与 Databricks 高级主任工程师、Unity Gateway 技术负责人 Kevin Stumpf 坐下来聊了聊，团队究竟该如何把这一实践落到实处：不把 AI 成本当作要尽量压低的单列开支，而是当作一个需要管理的系统。

从 tokenmaxxing 到 valuemaxxing

社交媒体上满是这样的领导者，他们主张“tokenmaxxing”——尽可能高强度、高频次地运行 AI——才是加速创新的正确方式。除了显而易见的成本影响之外，为什么这种看待 AI 应用的方式是错误的？

Kevin Stumpf：行业正从 tokenmaxxing 转向 valuemaxxing。早期有公开排行榜，展示人们消耗了多少 token，这在当时作为一种策略是说得通的。很多人当时不愿开始使用 AI，所以展示大家所敬仰的领导者都是 AI 的重度用户，给了其他人跟随的理由。如果我看到我尊敬的人大量使用 AI，我也想成为那样的人。

但这套体系被钻了空子。一旦登上排行榜榜首成为一种身份象征，人们就发现最快的登顶方式不是做出好工作，而是堆量。启动一个在循环中运行的笨拙智能体，让它一遍又一遍地问天气如何，在几乎什么都没做的情况下烧掉大量 token。这是一种奖励原始使用量而非结果的激励机制所必然导致的结果。

如今，各组织已普遍接受 AI，讨论已转向负责任、有效的使用。我们真正应该努力构建的是另一种排行榜，按人们用 AI 产生的影响除以产生这些影响所花费的成本来排名。这就是投资回报率，它比原始 token 数量难量化得多，但却是真正重要的数字。相关阅读：是什么在推动企业 AI 应用？

成本归因在实践中究竟意味着什么

你能给我们讲讲“成本归因”在 AI 中究竟意味着什么吗？

Kevin Stumpf：AI 成本归因归根结底是要回答两个问题：我的花费从何而来，我又从中得到了什么？在最简单的层面上，这意味着把成本归因到单个用户或某个团队，比如数据科学团队或软件工程团队。它也可以映射到某个具体项目，或组织架构图中的某个节点，比如了解 AI 副总裁与工程高级副总裁各自管辖的花费有多少。

目标是实现足够细粒度的可见性，让你能够对数据进行切片和切块，真正理解成本来自哪里，因为你无法管理你无法衡量的东西。Databricks 开箱即用地提供按用户、群组、智能体、AI 网关端点、模型、提供商和时间段的成本归因。但组织也可以使用请求级标签对其进行高度自定义。标签可以代表你的组织关心的任何事物，比如某个具体的拉取请求、某个功能或某个外部客户；一旦每个请求都携带该标签，你就可以按需据此汇总花费。

客户情绪的这种转变是真实存在的。六个月前，最令人担忧的是在 AI 采用上落后。现在情况恰恰相反：AI 常被用于无聊的事情，成本增长快于收入，领导者们在问如何在这条成本曲线侵蚀盈利能力之前将其扭转。这不是假设。这几乎是我们交谈过的每家组织董事会层面的讨论话题，包括 Databricks 内部。

驯服上下文膨胀

Token 用量和上下文窗口大小常被归咎，却很少得到很好的解释。上下文膨胀在生产系统中实际是什么样子，务实的解决办法又是什么？

Kevin Stumpf：上下文膨胀意味着向智能体投喂远超其做出良好决策所需的信息。这带来两个问题。第一，它消耗了不必要的 token。第二，它会分散注意力：智能体必须处理这些额外信息并判断其是否相关，这本身就是一种开销。这就像递给一个人一叠无关文档，让他在开始任务之前先弄清楚哪些重要。

最好的解决办法不是在事后裁剪或缓存，而是一开始就不产生膨胀。一种常见且有效的模式是让智能体通过工具、MCP 服务器或技能按需拉取相关上下文，而不是预先主动推送它可能需要的所有内容。只有当你有 90% 或更高把握某段上下文对当前任务确实重要时，才应默认将其推送给智能体。否则，让智能体知道有哪些可用内容，并允许它在需要时获取所需内容。

动态模型与执行框架路由

模型选择通常是一个“一次选定”的决定。为什么它应该是动态的，智能路由又如何实时判断一项任务需要前沿模型还是更便宜、更快的模型？同样的思路是否也适用于在不同智能体执行框架之间做选择？

Kevin Stumpf：AI 成本优化并不是一味选择最便宜的模型，团队应当转向选择能够达到任务所需质量的最低成本模型或 harness。当前的现实是，前沿模型能力极强但价格昂贵，而非前沿模型依然相当有能力，只是更便宜。大约 5% 到 10% 的任务确实需要前沿模型，要么是因为风险足够高、你希望得到尽可能好的结果，要么是因为问题太复杂，其他模型无法胜任。其余 90% 的任务都可以由较弱的模型解决，无论是你自行托管的开源模型，还是各大实验室更便宜的模型系列。

如果任由员工按自身动机行事，大多数人会默认选择可用的最贵模型，因为他们的目标只是把问题解决掉，而没有人会去关注这给他们个人带来了多少成本。智能路由通过插入一个层来解决这个问题：该层实时评估任务复杂度，并决定请求应发送给前沿模型还是成本更低的模型，目标是以更低的成本维持同等质量的输出。

Harness 路由是超越模型路由的下一层。新兴研究表明，完全相同的模型在不同的 harness 下运行，可能产生显著不同的成本。这很合理，因为 harness 决定了模型如何与其环境交互：它遵循什么规则、何时压缩上下文窗口、什么业务逻辑支配其行为。所有这些都直接影响 token 的消耗量。Harness 路由是成本优化“爬-走-跑”演进过程中的下一步，我们通过 Unity Gateway 和我们的元 harness Omnigent 来实现这一点。

设计支出护栏

我们来谈谈支出本身的护栏，比如硬性上限、预算和速率限制。应该如何设计这些机制，才能阻止成本失控，同时又不损害开发者生产力或破坏生产工作流？

Kevin Stumpf：有些规则适用于所有组织，另一些则取决于用例或公司。每个组织都应设置硬性支出上限，以捕捉失控的使用情况。如果你的典型重度用户每天在 AI 上最多花费约 300 美元，就把硬性上限设得稍高一些，比如 500 美元。这个差额为你留出了捕捉真正错误的空间，比如某个 agent 意外陷入循环持续运行，同时又不会限制合法的高用量日子。

在这个基线之上，按团队或项目设置差异化预算非常合理。一个为 CEO 处理关键事务的团队，可能值得比处理低优先级工作的团队高得多的预算，而这个决定应当权衡该团队产出成果的价值与给予他们更多余量所付出的成本。

预算还应当能够触发不同类型的响应，而不仅仅是硬性停止。例如，它们可以发送告警、施加硬性上限或降低可用的模型容量——比如某团队用掉 70% 的预算后，切断其对前沿模型的默认访问权限，并将其余请求改为路由到开源模型。适用于所有地方的核心原则是：防止支出失控、按组或项目设置差异化限制、在上限之前先告警，并内置智能的容量削减机制，而不是突然关停。

衡量 AI 实际带来的价值

哪些平台能同时提供智能体监控和成本追踪，这种可见性距离衡量真实 ROI（而不只是花费）还有多远？

Kevin Stumpf：衡量成本比把成本与投资回报联系起来要容易得多，而后者是每个人都想得到答案、却几乎没有人完全解决的问题。会话级或请求级打标签让这成为可能。如果一个智能体正在处理某个特定的拉取请求，它可以把自己生成的会话或特定请求打上该拉取请求标识符的标签。这种归因会回流到成本仪表盘，于是你可以看到，例如，完成某个给定拉取请求花费了 300 美元。这是我们在 Databricks 内部已经在做的事情。

在理想状态下——这也是我们正在构建进 Unity Gateway 产品中的能力——你可以更进一步，把该拉取请求关联到某个特定功能，再把该功能关联到可衡量的结果，比如它在给定时间段内产生了多少收入或销售管道。这就是圣杯：不仅知道 AI 花了多少，还知道它回报了多少。借助 Unity Gateway，我们已经有了一个高度可定制的平台来构建这一能力，并且我们正在投入资源，让这种成本到回报的视图开箱即用，而不是让团队自己去搭建。

花费可见性需要一个集中式系统

对于一家在多个团队中运行多种模型、智能体和工具的公司来说，良好的花费可见性实际上需要什么？这是仪表盘问题、治理问题还是 FinOps 问题？

Kevin Stumpf：良好的花费可见性要求每一次 AI 交互都流经一个集中式系统。正是这一点让你能够一致地锁定正确的信息，从而在其上构建可靠的仪表盘和告警。AI 网关为跨模型、智能体、工具和团队的 AI 成本管理提供了一个集中式控制点。Databricks Unity Gateway 旨在跨模型、智能体、工具和编码智能体提供这一集中式控制点。当 AI 交互流经一个共同的控制点时，组织就可以在一个地方观察使用情况、归因成本、执行预算并优化花费。

但仅有集中式系统本身还不够。你还需要一种方式来确保每个人都确实把他们的 AI 流量路由通过它。可见性只有在采用是普遍的、而非可选的时候才有效。

平衡成本优化与输出质量

成本控制不能以牺牲质量或可靠性为代价。你如何知道某项优化已经走得太远、开始损害输出了？

Kevin Stumpf：这确实因用例而异。你需要一个反馈机制，它可以是主观的，也可以是客观的。主观反馈是轶事性的，比如团队里有人告诉你，他们在当前预算内无法完成工作。这种反馈来得快，但很容易被当作一个人的抱怨而不予理会。客观反馈来自自动化评估，它更难搭建，但可靠得多。

对于像编码智能体这样的常见用例，这可能意味着定义一个衡量质量的代理指标，例如两周内未被回滚的已合并拉取请求。在此基础上，你可以进行实验：将预算减半，观察这个黄金指标是变化、保持稳定还是甚至有所改善，因为约束有时能激发创造力。在不同团队之间，以不同的预算、模型和运行框架开展并行实验，或者进行为期数周的时间限定对比，可以让你推断出给定预算是在创造价值还是在摧毁价值，而不是靠猜测。

端到端追踪的价值

端到端追踪和监控在这里扮演什么角色？一旦你能够看到整个智能体工作流中的提示词、工具调用和 token 使用情况，这能解锁哪些你以前做不到的事情？

Kevin Stumpf：追踪就是收集智能体所做事情的全部“尾气”：它们在思考什么、在调用什么工具、在拉取什么数据、提示词是好是坏。这些原始数据正是你可以挖掘洞察的来源，无论是识别滥用、浪费、安全泄露，还是仅仅发现你从未想过要寻找的模式。

这与更广泛的数据行业所发生的情况如出一辙。早期，我们只有数据库里干净的结构化数据。后来出现了数据湖，有一段时间它们变成了数据沼泽，因为人们把非结构化数据倾倒进去，却没有办法从中提取价值。最终，这些沼泽又变回了可用的数据湖，而我们现在比以往任何时候都更有能力从非结构化和半结构化数据中提取洞察，这在很大程度上是因为 LLM 足够灵活，能够处理这些数据。智能体追踪也属于同一类别。你收集得越多，可获得的洞察就越多，而且获取这些洞察比以往任何时候都更容易。

扩展到智能体集群

许多企业正在从单一 AI 应用转向智能体集群。与在一个应用背后运行一个模型相比，这种转变会改变成本等式吗（新的成本驱动因素？新的盲点？）？

Kevin Stumpf：它与其说是改变了等式，不如说是将其成倍放大。智能体集群将成为新的现实，其中每一个智能体都会消耗需要归属、监控和管理的 token。现在正是建立正确的成本可见性和管理基础的时候，要赶在生产环境中智能体数量按预期增长之前。

编码智能体是当今消耗 token 的主导类别，但这将扩展到许多其他类别的智能体，它们全天候执行自主工作，智能体调用智能体，再调用智能体。那些等到这种复杂性到来才构建集中式 AI 可观测性和成本管理基础设施的组织，将不得不在压力下构建，而不是按自己的节奏来构建。

如果必须让企业 AI 领导者带着一个关于成本管理的思维转变进入明年，那会是什么？

Kevin Stumpf：我不会等到明年。这件事很紧迫，从现在起就应该以紧迫的态度对待它。如果非要归结为一个核心观点，那就是：你无法管理你未曾衡量的东西。这适用于原材料，适用于人，也同样适用于 AI。AI 正迅速成为公司现金流量表上最重要的项目之一，它需要被完整地监测，以便能够被衡量，进而被管理。它不过是生产组织商品或服务的系统中的又一种原材料，理应受到同样严谨的对待。

计时从现在开始 在跨团队、使用多种模型和工具的情况下控制 AI 成本，不是靠单个仪表盘或一次性的模型选择就能解决的问题。它是一种运营纪律：归因要足够精细，能把支出追溯到某个人或某个项目；路由要能根据任务需求实时调整；防护机制要在失控支出成为头条新闻之前将其拦截；追踪要足够详细，能把原始使用数据转化为真正的洞察。在这方面走在前面的组织，并不是在 AI 上花钱最少的那些，而是能够自信地说清楚自己花了多少钱、换来了什么成果的那些。

进一步了解 Unity Gateway 如何在你的整个 AI 资产中集中实现成本归因、智能路由和支出防护。

来源：Databricks：Blog · databricks.com