The new economics of AI cost management
TL;DR · AI 摘要
The new economics of AI cost management Databricks Blog Skip to main content Data + AI Foundations The new economics of...
核心要点
- 主题聚焦:The new economics of AI cost management
- 来源:Databricks,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
AI成本管理的新经济模式 | Databricks博客
跳至主要内容
数据与AI基础
AI成本管理的新经济模式
如何衡量和管理AI成本。
作者:Databricks团队
摘要
- 企业正从"tokenmaxxing"转向"valuemaxxing",即衡量每美元投入AI所产生的影响。
- 衡量AI投资回报率需要足够精细的归因能力,能够追溯到具体用户、团队、项目甚至单个代码提交请求
- 花费防护机制、端到端可观测性以及所有AI流量必须经过的中央枢纽,是当前团队需要构建的基础架构
过去两年,企业AI采用的故事主要集中在如何让更多人使用AI。但最近几个月,这个故事在许多组织中正在迅速发生变化。曾经以token数量衡量成功的AI可观测性,现在开始转向以投资回报率衡量成功。那些率先掌握成本管理的企业,将能够实现AI规模化而不让支出超过收入。
从根本上说,AI成本管理是在模型、代理、应用和团队之间,对AI支出进行衡量、归因、控制和优化的实践。目标不仅仅是减少token使用量,而是最大化每美元投入所产生的业务价值。随着AI代理承担更多自主工作,这一学科的范畴也逐渐扩展到管理代理推理、工具调用及其驱动模型的成本。
我们与Databricks高级工程师Kevin Stumpf进行了对话,他是Unity Gateway的技术负责人,他分享了团队应该如何真正实践这一学科:不是将AI成本视为需要最小化的单项支出,而是需要管理的系统。
从tokenmaxxing到valuemaxxing
社交媒体上充斥着领导者争论"tokenmaxxing"(尽可能频繁地运行AI)是加速创新的正确方式。除了显而易见的成本影响,为什么这种思维方式是错误的?
Kevin Stumpf:行业正在从tokenmaxxing转向valuemaxxing。在早期阶段,公共排行榜显示人们消耗了多少token,这在当时作为策略是有意义的。当时很多人对使用AI持犹豫态度,所以展示那些受人尊敬的领导者都是重度AI用户,给了其他人跟随的理由。如果我看到受尊敬的人大量使用AI,我也想效仿。
但系统被利用了。当排行榜顶端成为身份象征后,人们发现最快到达顶端的方式不是做好工作,而是通过数量。启动一个简单的代理程序让它循环运行,反复询问天气情况,实质上什么也不做却消耗大量token。这种结果是奖励原始使用量而非成果的激励结构的必然产物。
现在当组织普遍接受AI后,讨论重点已转向负责任且有效的使用方式。我们真正应该构建的是另一种排行榜:按AI产生的影响除以生成该影响的成本来对人进行排名。这就是投资回报率,虽然比原始token数量更难量化,但这才是真正重要的数字。相关内容:推动企业AI采用的关键因素是什么?
Kevin Stumpf:AI成本归因最终归结为回答两个问题:我的支出从何而来?我从中获得了什么?在最基础的层面,这意味着将成本归因到某个具体用户或团队,比如数据科学团队或软件工程团队。它也可以映射到特定项目,或组织架构图中的某个节点,例如理解AI副总裁与工程执行副总裁之间的支出分布差异。
目标是实现足够细致的可见性,使你能够对数据进行多维度分析,明确成本的实际来源,因为无法管理无法衡量的事物。Databricks默认支持按用户、组、代理、AI网关端点、模型、提供商和时间段进行成本归因。但组织也可以通过请求级别的标签进行高度定制化。标签可以代表任何组织关心的内容,比如特定的拉取请求、功能或外部客户。一旦每个请求都携带了该标签,你就可以根据需要按任意方式汇总支出。
客户情绪的转变是真实存在的。六个月前,最大的担忧是人工智能采用落后。现在情况正好相反:AI经常被用于一些无意义的事情,成本增长速度超过了收入增长,领导者们正在询问如何在成本侵蚀盈利能力之前扭转这一趋势。这不是假设性的问题。在我们接触的几乎所有组织中,包括Databricks内部,这都是董事会层面的讨论。
应对上下文膨胀
令牌使用量和上下文窗口大小经常被归咎,但很少有清晰的解释。在生产系统中,上下文膨胀实际表现为何种形态?实际可行的解决方案是什么?
Kevin Stumpf:上下文膨胀意味着向代理提供远超其决策所需的信息。这带来两个问题。首先,会消耗不必要的令牌。其次,会产生干扰:代理必须处理这些额外信息并判断其相关性,这本身是一种开销。这就像给某人一堆无关文件,要求他们在开始任务前先找出重要信息。
最佳解决方案不是事后进行裁剪或缓存,更不是一开始就生成冗余信息。一个常见且有效的方法是让代理通过工具、MCP服务器或技能按需获取相关上下文,而不是提前主动推送所有可能需要的信息。只有在90%以上确定某信息对当前任务确实重要时,才应默认推送上下文给代理。否则,应告知代理可用信息,并允许其在需要时自行获取所需内容。
动态模型与Harness路由
模型选择通常是"一次性决策"。为什么应该采用动态方式?智能路由如何实时判断任务是否需要前沿模型还是更便宜快速的替代方案?这种思路是否也适用于不同代理Harness的选择?
Kevin Stumpf:AI成本优化并不是一味选择最便宜的模型,团队应转向选择成本最低或能够满足任务质量需求的模型。当前的现实是,前沿模型能力强大但成本高昂,而非前沿模型虽然能力稍逊但成本更低。大约5%到10%的任务确实需要使用前沿模型,要么因为任务重要性极高需要最佳结果,要么因为问题复杂度超出了其他模型的处理能力。其余90%的任务都可以通过能力较低的模型解决,无论是自行托管的开源模型还是各大实验室提供的更经济的模型家族。
在缺乏监管的情况下,大多数员工会默认选择最昂贵的模型,因为他们的目标仅仅是解决问题,而无人关注这会带来多少个人成本。智能路由通过插入一个实时评估任务复杂度的中间层来解决这个问题,根据任务复杂度决定请求是发送给前沿模型还是低成本模型,目标是在保证输出质量的同时降低成本。
Harness路由是模型路由之外的又一层优化。有新兴研究表明,完全相同的模型通过不同的Harness运行会产生显著不同的成本。这合乎逻辑,因为Harness决定了模型与环境的交互方式:遵循的规则、何时压缩上下文窗口、由什么业务逻辑主导行为。所有这些都会直接影响消耗的token数量。Harness路由是成本优化从爬行、行走到奔跑的演进过程中的下一步,我们通过Unity Gateway和Omnigent(我们的元Harness)来实现这一优化。
设计支出防护机制
让我们讨论针对支出本身的防护机制,如硬性上限、预算和速率限制。如何设计这些机制才能在防止支出失控的同时不损害开发人员效率或破坏生产流程?
Kevin Stumpf:一些规则适用于所有组织,而另一些则取决于使用场景或公司特性。每个组织都应设置硬性支出上限以防止使用失控。如果典型高使用率用户每天最多在AI上花费300美元,可将硬性上限设为略高于该值(例如500美元)。这个差距可以为识别真正的错误提供空间,例如某个代理意外陷入循环运行的情况,而不会误伤真正需要高使用额度的合理场景。
在这一基准之上,按团队或项目划分的差异化预算非常有意义。负责CEO关键项目的团队可能需要远高于处理低优先级任务团队的预算,这种决策应权衡该团队产出价值与提供更多预算空间的成本。
预算机制还应能触发不同类型的响应,而不仅仅是硬性停止。例如可以发送警报、应用硬性上限或减少可用模型容量——当团队消耗了70%预算后,可以切断对前沿模型的默认访问,将后续请求路由到开源模型。普适的核心原则:防止支出失控、按团队或项目设置差异化限制、在触发上限前发出预警,并通过智能容量缩减而非突兀切断来实现控制。
REPORT
企业级智能体AI实践指南
立即阅读
评估AI实际交付效果
Which platforms offer agent monitoring and cost tracking together, and how far can that visibility take you toward measuring actual ROI, not just spend?
Kevin Stumpf: Measuring cost is a lot easier than connecting that cost to return on investment, and that's the question everyone wants answered and almost nobody has fully solved yet. Session or request-level tagging is what makes this possible. If an agent is working on a specific pull request, it can tag its session or specific requests it generates with that pull request's identifier. That attribution flows back into a cost dashboard, so you can see, for example, that a given pull request cost $300 to complete. This is something we’re already doing internally at Databricks.
In an ideal state, and this is something we're building into the Unity Gateway product. You can go a step further and connect that pull request to a specific feature, and that feature to a measurable outcome, like how much revenue or pipeline it generated in a given period. That's the holy grail: not just knowing what AI cost, but knowing what it returned. With Unity Gateway , we already have a highly customizable platform to build this on, and we're investing in making that cost-to-return view available out of the box rather than something teams have to construct themselves.
Spend visibility requires a centralized system
For a company running multiple models, agents and tools across many teams, what does good spend visibility actually require? Is it a dashboard problem, a governance problem or a FinOps problem?
Kevin Stumpf: Good spend visibility requires that every AI interaction flows through a centralized system. That's what allows you to lock down the right information consistently, so you can build reliable dashboards and alerts on top of it. An AI gateway provides a centralized control point for AI cost management across models, agents, tools and teams. Databricks Unity Gateway is designed to provide that centralized control point across models, agents, tools and coding agents. When AI interactions flow through a common control point, organizations can observe usage, attribute costs, enforce budgets and optimize spend in one place.
But having the centralized system isn't enough on its own. You also need a way to enforce that everyone actually routes their AI traffic through it. Visibility only works if adoption is universal, not optional.
Balancing cost optimization and output quality
Cost control can't come at the expense of quality or reliability. How do you know when an optimization has gone too far and started hurting output?
Kevin Stumpf: That's genuinely use case specific. You need a feedback mechanism, and it can be either subjective or objective. Subjective feedback is anecdotal, someone on the team telling you they can't get the job done within the current budget. That's fast to get but easy to dismiss as one person's complaint. Objective feedback comes from automated evaluations, which are harder to set up but far more reliable.
对于编码代理等常见用例,这可能意味着定义一个质量代理指标,例如在两周内未被回滚的合并拉取请求。从这里开始,你可以进行实验:将预算减半,观察这个关键指标是上升、保持稳定还是甚至改善,因为约束有时会激发创造力。通过在不同预算、模型和工具链的团队之间并行实验,或在几周内进行时间限定的对比,你可以推断特定预算究竟是创造了价值还是破坏了价值,而不是凭猜测。
端到端追踪的价值
端到端追踪和监控在此过程中扮演什么角色?当你能够看到整个代理工作流中的提示、工具调用和令牌使用情况时,这会解锁哪些之前无法实现的能力?
Kevin Stumpf:追踪的核心是收集代理行为的完整轨迹:它们在思考什么、调用哪些工具、获取哪些数据、提示内容是好是坏。这些原始数据正是挖掘洞察的关键,无论是识别滥用行为、资源浪费、安全漏洞,还是发现从未想过要寻找的模式。
这与更广泛的数据行业的发展轨迹如出一辙。早期我们只有数据库中干净的结构化数据。随后出现的数据湖一度沦为数据沼泽,因为人们将非结构化数据随意丢弃其中却无法提取价值。最终这些沼泽重新转变为可用的数据湖,如今我们比以往任何时候都更有能力从非结构化和半结构化数据中提取洞察,这主要得益于大型语言模型(LLMs)处理这类数据的灵活性。代理追踪数据也属于这一类别。收集的数据越多,可提取的洞察就越丰富,而且提取难度也比以往任何时候都更低。
扩展到代理舰队
许多企业正在从单个AI应用转向代理舰队。与运行单一应用背后的单一模型相比,这种转变是否改变了成本方程(新的成本驱动因素?新的盲点?)?
Kevin Stumpf:这并没有改变成本方程本身,而是将其复杂度呈指数级放大。代理群体将成为新的常态,每个代理都会消耗需要归因、监控和管理的令牌。现在正是建立正确的成本可视性与管理基础架构的关键时刻,因为生产环境中的代理数量预计会迅速增长。
目前消耗令牌的主要代理类型是编码代理,但未来将扩展到许多其他类型的代理,这些代理会全天候自主运行,代理会调用其他代理,而其他代理还会继续调用更多代理。那些等到复杂性出现后再构建集中式AI可观测性和成本管理基础设施的企业,将不得不在压力下仓促建设,而非按照自己的节奏进行规划。
如果必须让企业AI领导者在明年成本管理方面转变一种思维方式,你希望他们转变的是什么?
Kevin Stumpf:我不会等到明年。这迫在眉睫,现在就应该以这样的方式来对待。如果非要浓缩成一个核心观点,那就是:你无法管理你无法衡量的事物。这适用于原材料,适用于人员,同样也适用于人工智能。人工智能正迅速成为企业现金流量表上最重要的条目之一,必须进行全面监控,以便衡量并进而实现管理。它只是生产组织产品或服务系统中的另一种原材料,理应受到同样的严谨对待。
现在刻度已经开始转动 跨团队使用多种模型和工具控制人工智能成本的问题,无法通过单一仪表盘或一次性模型选择来解决。这是一项运营层面的学科:需要足够精细的归因机制,能够将支出追溯到具体个人或项目;需要能够实时适应任务需求的路由机制;需要设置防护措施,在支出失控成为头条新闻前及时拦截;还需要足够详细的追踪能力,将原始使用数据转化为真正的洞察。那些率先掌握这一趋势的组织,并不是在人工智能上投入最少的公司。而是那些能够自信明确说明"为这笔支出获得了什么成果"的组织。
了解更多关于Unity Gateway如何在你的AI资产中集中管理成本归因、智能路由和支出防护措施的信息。
订阅最新文章
订阅我们的博客,将最新文章直接发送到你的邮箱。
立即订阅
查看所有博客
slice-start id="_gatsby-scripts-1"
slice-end id="_gatsby-scripts-1"