- 企业正从“tokenmaxxing”转向“valuemaxxing”，衡量每花一美元在 AI 上所产生的效果。
- 衡量 AI 投资回报率需要足够细的归因粒度，能够将支出追溯到某个用户、团队、项目，甚至单个 pull request
- 支出护栏、端到端可观测性，以及所有 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 gateway 端点、模型、提供商和时间段的 成本归因。但组织也可以使用请求级标签对其进行高度自定义。标签可以代表你组织关心的任何事物，比如某个具体的 pull request、某项功能或某个外部客户；一旦每个请求都带有该标签，你就可以按需据此汇总支出。
客户情绪的这种转变是真实存在的。六个月前，最令人担忧的是在 AI 采用上落后。现在则恰恰相反：AI 常被用于无聊的事情，成本增长快于收入，领导者们在问如何在这条成本曲线侵蚀盈利能力之前将其扭转。这不是假设。这几乎是我们交谈过的每家组织董事会层面的议题，包括 在 Databricks 内部.
遏制上下文膨胀
token 使用量和上下文窗口大小常被归咎，却很少得到很好的解释。上下文膨胀在生产系统中实际是什么样子，切实可行的解决办法又是什么？
Kevin Stumpf： 上下文膨胀意味着向智能体投入远超其做出良好决策所需的信息。这带来两个问题。第一，它烧掉不必要的 token。第二，它会分散注意力：智能体必须处理这些额外信息并判断其是否相关，这本身就是一种开销。这就像递给一个人一叠无关文件，让他在甚至还没开始任务之前就先弄清楚哪些重要。
最好的解决办法不是事后裁剪或缓存，而是一开始就不产生膨胀。一种常见且有效的模式是让智能体通过工具、MCP server 或技能按需拉取相关上下文，而不是预先主动推送它可能需要的所有内容。只有当你有 90% 或更高把握某内容对当前任务确实重要时，才应默认将上下文推送给智能体。否则，让智能体知道有哪些可用内容，并允许它在需要时获取所需内容。
动态模型与 harness 路由
模型选择往往是一个“一次选定”的决定。为什么它应该是动态的？智能路由又是如何实时判断一项任务是需要一个前沿模型，还是用更便宜、更快的模型就够了？同样的思路是否也适用于在不同智能体 harness 之间做选择？
Kevin Stumpf： AI 成本优化并不是要始终选择最便宜的模型，团队应当转向选择能够达到任务所需质量的最低成本模型或 harness。当前的现实是，前沿模型能力极强但价格昂贵，而非前沿模型依然相当有能力，只是更便宜。大约 5% 到 10% 的任务确实需要前沿模型，要么是因为风险足够高、你希望得到尽可能好的结果，要么是因为问题太复杂，其他模型无法胜任。其余 90% 的任务都可以由较弱的模型解决，无论是你自行托管开源模型，还是主要实验室提供的更便宜的模型系列。
如果任由员工按自身动机行事，大多数人会默认选择最昂贵的可用模型，因为他们的目标只是把问题解决掉，而没有人会去关注这给他们个人带来了多少成本。 智能路由 通过插入一个层来解决这个问题：该层实时评估任务复杂度，并决定一个请求应该发往前沿模型还是成本更低的模型，目标是以更低的成本维持相同的输出质量。
Harness 路由是超越模型路由的下一层。新兴研究表明，完全相同的模型，在不同的 harness 中运行，可能产生显著不同的成本。这很合理，因为 harness 决定了模型如何与其环境交互：它遵循哪些规则、何时压缩上下文窗口、哪些业务逻辑支配其行为。所有这些都直接影响 token 的消耗量。Harness 路由是成本优化“爬-走-跑”演进过程中的下一步，我们通过 Unity Gateway 和我们的元 harness Omnigent来实现这一点。
设计支出护栏
我们来谈谈支出本身的护栏，比如硬性上限、预算和速率限制。应该如何设计这些护栏，才能既阻止成本失控，又不损害开发者生产力或破坏生产工作流？
Kevin Stumpf： 有些规则适用于每个组织，另一些则取决于用例或公司。每个组织都应该设置硬性支出上限，以捕捉失控的使用。如果你的典型重度用户每天在 AI 上最多花费约 300 美元，就把硬性上限设得稍高一些，比如 500 美元。这个差额为你留出空间，去捕捉真正的错误，比如某个智能体意外陷入循环一直运行，同时又不会把合法的高用量日子一刀切掉。
在这个基线之上，按团队或项目设置差异化预算非常合理。一个为 CEO 处理关键事务的团队，可能值得比处理较低优先级工作的团队高得多的预算，而这个决定应当权衡该团队产出之物的价值与给予他们更多余量所付出的成本。
预算还应该能够触发不同类型的响应，而不只是硬性停止。例如，它们可以发送告警、施加硬性上限或减少可用的模型容量——比如某个团队用掉 70% 的预算后，就切断其对前沿模型的默认访问，并把其余请求改路由到开源模型。适用于所有地方的核心原则是：防止支出失控、按群组或项目设置差异化限制、在上限之前先告警，并内置智能的容量削减，而不是突然关停。
报告企业智能体 AI 实战手册
立即阅读
衡量 AI 实际交付了什么
哪些平台能同时提供智能体监控和成本追踪，这种可见性又能带你走多远，去衡量真正的 ROI，而不只是支出？
Kevin Stumpf： 衡量成本比把成本与投资回报联系起来要容易得多，而后者是每个人都想得到答案、却几乎没有人完全解决的问题。会话级或请求级标签是实现这一点的关键。如果一个智能体正在处理某个具体的 pull request，它可以把自己生成的会话或特定请求打上该 pull request 标识符的标签。这种归因会回流到成本仪表盘，于是你可以看到，例如，某个 pull request 的完成成本是 300 美元。这是我们在 Databricks 内部已经在做的事情。
在理想状态下——这也是我们正在构建进 Unity Gateway 产品的东西——你可以更进一步，把那个 pull request 关联到某个具体功能，再把该功能关联到可衡量的结果，比如它在给定时期内产生了多少收入或销售管道。这才是圣杯：不仅知道 AI 花了多少钱，还知道它带来了什么回报。借助 Unity Gateway，我们已经拥有了一个高度可定制的平台来构建这一切，并且我们正在投入，让这种成本到回报的视图开箱即用，而不是需要团队自己搭建。
支出可见性需要集中式系统
对于一家在多个团队中运行多种模型、智能体和工具的公司来说，良好的支出可见性实际上需要什么？这是一个仪表盘问题、治理问题，还是 FinOps 问题？
Kevin Stumpf： 良好的支出可见性要求每一次 AI 交互都流经一个集中式系统。正是这一点让你能够一致地锁定正确的信息，从而在其之上构建可靠的仪表盘和告警。AI gateway 为跨模型、智能体、工具和团队的 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 资产中集中成本归因、智能路由和支出护栏的信息。
在收件箱中获取最新文章
订阅我们的博客，将最新文章发送到你的收件箱。