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

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

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

我们与 Databricks 高级主任工程师、Unity Gateway 技术负责人 Kevin Stumpf 坐下来聊了聊，探讨团队究竟该如何将这一 discipline 付诸实践：不把 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 开箱即用地提供了按用户、用户组、agent、AI 网关端点、模型、提供商和时间段的成本归因。但组织也可以使用请求级标签对其进行高度自定义。标签可以代表你的组织关心的任何事物，比如某个特定的拉取请求、某个功能或某个外部客户，而一旦每个请求都带有该标签，你就可以根据需要针对它聚合支出。

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

驯服上下文膨胀

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

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

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

动态模型与 harness 路由

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

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 实际交付的价值

哪些平台同时提供 agent 监控和成本追踪，这种可见性能在多大程度上帮助你衡量实际 ROI，而不仅仅是支出？

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

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

支出可见性需要一个集中式系统

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

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

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

平衡成本优化与输出质量

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

Kevin Stumpf：这确实因用例而异。你需要一个反馈机制，它可以是主观的或客观的。主观反馈是轶事性的，团队中有人告诉你他们无法在当前预算内完成工作。这获取起来很快，但很容易被当作一个人的抱怨而忽视。客观反馈来自自动化评估，这更难设置但可靠得多。

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

端到端追踪的价值

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

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

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

扩展到智能体集群

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

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

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

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

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

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

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