Databricks 推出 AI 支出控制功能，但覆盖缺口令其承诺更复杂

Databricks 推出 AI 支出控制功能，是对失控的代理成本作出的直接回应；但其广泛执行的承诺，立刻就与文档内容产生了冲突。

该功能于 2026 年 7 月 23 日发布，为用户、工作区、用例以及整个 Databricks 账户增加了预算警报。Databricks 还表示，客户可以设置硬性上限，在预算耗尽后阻止新的请求。

这一组合让 AI 成本管理更接近模型请求本身。传统云预算通常是在基础设施已经消耗资源后才报告支出。AI 网关则可以在将工作路由至供应商前，检查请求、身份、模型和使用情况。

这一时机反映出一个新的运营问题。代理并非只是回答孤立的提示词。它们会制定计划、调用工具、委派工作、重试失败任务，并在无需持续人工监督的情况下继续运行。

因此，一个有缺陷的工作流可能在财务仪表板暴露损失前，就生成数千次模型调用。Microsoft、Amazon Web Services 和 Google Cloud 已经提供成本报告、配额或网关控制功能。Databricks 则希望针对模型和供应商提供统一的策略层。

关键问题并不在于企业是否需要更好的警报——显然需要。问题在于，Databricks 能否将成本可见性转化为可靠的执行机制，并覆盖其公告中列出的每一种工作负载。

Databricks 在网关层推出控制功能

此次发布将 AI 预算从财务报告移入模型消耗开始的请求路径。

Unity AI Gateway 是 Databricks 用于访问和治理大语言模型、代理及 Model Context Protocol 服务器的集中式层。AI 网关位于应用程序和模型端点之间，让管理员能够在一个位置应用路由和访问策略。

根据支出控制公告，组织可以创建共享或个人月度阈值。管理员可以按账户、工作区、用户或带标签的用例来界定这些阈值。

账户范围让 FinOps 团队能够为参与的工作负载设置统一上限。工作区阈值可将生产环境消耗与实验活动区分开来。按用户设置的阈值则可暴露异常昂贵的个人行为。

资源标签提供了另一层控制。团队可以按应用程序、环境、部门或用例为网关模型添加标签。随后，预算可仅纳入与所选标签匹配的计费记录。

这一点很重要，因为单个工作区往往服务于互不相关的工作负载。客户支持助手和夜间文档处理管道可能使用同一个模型端点，但它们的负责人、风险状况和可接受的消耗模式各不相同。

Databricks 表示，这些控制功能支持警报和硬性上限。警报会在支出越过设定阈值时发送电子邮件。硬性上限则会阻止后续请求，直至管理员提高限额或计费周期重置。

这一区别是此次发布的核心。警报告诉组织某件事已经发生；执行机制则会中断导致进一步消耗的行为。

管理员通过账户控制台配置这些控制功能。他们选择 Unity AI Gateway 作为资源类型，选定工作区，并可选择应用资源标签。随后，他们可以设置共享阈值和按用户划分的阈值。

成本部分展示活跃预算和支出趋势。按用户划分的视图会显示已超过分配阈值的个人。管理员可在合理需求需要更多容量时编辑预算。

Databricks 还将网关记录与 Unity Catalog 系统表连接起来。Unity Catalog 是该平台面向数据和 AI 资产的治理层，涵盖权限、审计记录和使用元数据。

该公司表示，每个网关请求都会记录计算得出的 Databricks Unit 成本，而不仅是原始 token 数量。这些记录可以按身份、工作区、端点、模型、供应商或请求标签进行分组。

这一设计解决了常见的归因问题。仅有 token 总数无法说明是哪个产品、客户或团队产生了账单。请求身份和标签提供了问责所需的组织背景。

这些控制功能的目标也不止于交互式聊天。Databricks 将编程代理、生产代理和定时批处理工作列为相关工作负载。每一种模式都可能在无人批准每次模型调用的情况下产生消耗。

夜间处理管道说明了其中的风险。如果作业的一部分失败，重试逻辑可能反复处理相同的输入。应用程序在技术上可能依然健康，但其模型使用量却会成倍增长。

多代理实验也带来类似风险。一个代理可以为多个其他代理创建子任务，而它们随后可能独立调用模型和工具。一个小请求可能扩展为昂贵的执行图。

因此，此次发布改变了预算策略所处的位置。策略不再只位于云账户之上，而可以跟随网关身份和带标签的 AI 工作负载。这也形成了本文的核心张力：广泛控制依赖于广泛计量。

代理工作负载正在打破传统预算假设

AI 代理让支出从可预测的流量函数，转变为由重试、委派和模型选择塑造的执行风险。

云成本管理最初围绕团队可以盘点的资源发展。财务团队跟踪虚拟机、存储、数据库和网络流量。工程师可以将大多数费用关联到某个账户、项目或带标签的资源。

生成式 AI 让这一模式变得复杂。一个应用程序可以在多种计费结构差异巨大的模型之间路由请求。它可以结合按 token 付费的推理、预留容量、外部供应商和配套云服务。

请求数量同样难以预测。传统 API 通常将一次用户操作映射为一个有边界的操作。代理则可能将相同行动解释为一连串规划、检索、模型和工具调用。

重试让问题进一步恶化。短暂的服务错误可能触发应用程序逻辑，再次发送请求。边界控制不佳的恢复逻辑，可能在原始用户离开很久后仍持续运行。

模型选择又增加了一个变量。开发人员可以在不改变应用程序可见界面的前提下，用能力更强的模型替换较小的模型。这一选择可能改变整个工作流中的成本和延迟。

提示词长度也会变化。代理往往会累积对话历史、检索到的文档、工具结果和中间推理。随着任务推进，应用程序可能在每一轮发送更多上下文。

这些行为削弱了建立在延迟计费记录之上的预算系统。基于昨日账户总额的警报无法阻止此刻正在生成请求的代理。等到人工响应时，问题运行可能已经结束。

Databricks 将网关定位为自然的执行点。每一项受治理的请求都会在到达受支持模型前经过网关。网关已经能够看到调用方、端点、模型和请求元数据。

这一位置使 Databricks 相比只分析账单的工具更具优势。网关可以将身份控制与支出规则结合起来，也可以在云计费系统完成记录处理前对消耗进行归因。

不过，成本上限并不等同于容量配额。速率限制会限制短时间内的请求或 token；预算则限制更长周期内累积的货币消耗。

这一区别对企业买家至关重要。速率限制可以防止一个应用程序垄断吞吐量，但无法保证每月支出上限。即使请求速率较低，长期下来仍可能产生高成本。

Microsoft 的 AI 网关使用 API Management 在项目层面应用 token 限制和配额。其文档描述了可将团队和模型的使用量控制在范围内的机制。

然而，Microsoft 另行表示 Azure OpenAI 不具备原生硬性预算限制。其成本管理指南建议使用预算、警报、筛选器，以及面向更高级响应的可选自动化功能。

Google 的方法也说明，吞吐量与支出不应混为一谈。Vertex AI 对许多按量付费模型采用动态共享配额。Google 表示，这种安排没有预先定义的使用上限。

Vertex AI 配额用于管理对可用处理容量的访问。它本身并不会为单个开发人员或带标签的实验设定业务预算。

因此，Databricks 正在解决一个真实的缺口。该公司希望让同一个治理层回答三个不同的问题：谁可以调用模型、他们可以访问什么，以及他们可以花费多少。

这种整合给云服务提供商和独立网关供应商带来压力。企业不希望为每个模型供应商部署独立的执行系统，也不希望应用程序切换模型时成本归因随之消失。

这种压力对支持内部 AI 采用的平台团队最为显著。他们必须在给开发人员探索空间的同时保护生产预算。全面限制会拖慢有价值的工作，而不受限制的访问则会带来财务风险。

按用户控制提供了一种更精确的折中方案。公司可以提供个人实验额度，而无需禁用整个工作区。共享阈值仍可保护更大的组织。

按用例划分的预算提供了另一道边界。即便共享基础设施，编程代理、面向客户的助手和文档处理管道也可以获得不同策略。这让成本治理更接近应用程序治理。

该功能的价值最终将取决于实际有多少请求经过 Unity AI Gateway。在网关之外调用的模型仍处于其直接策略路径之外。访问方式碎片化，就会导致控制碎片化。

这一现实让采用成为一项技术和组织挑战。团队必须先标准化模型访问、身份和标签，集中式预算才能实现完整的问责。

该机制仅在计量完整时才有效

只有当计量器能看见每一项覆盖请求，并且足够快地阻止下一项请求时，硬性支出限制才具备可信度。

Databricks 的机制结合了计费筛选器、近实时跟踪、请求身份和网关执行。每个组成部分分别解决成本控制问题的不同环节。

计费筛选器定义范围。共享预算可以纳入选定工作区，以及带有匹配资源标签的模型。随后，按用户设置的阈值会在该范围内评估每位已识别调用方的消耗。

近实时跟踪会将记录的消耗与设定阈值进行比较。当越过警报阈值时，平台会发送通知。启用阻断后，执行层会拒绝后续符合条件的请求。

身份数据用于明确责任归属。网关请求可以携带用户身份或服务主体，后者代表工作负载而非个人。这使同一系统能够区分人工试验与自动化生产流量。

系统表支持在告警发生后开展调查。团队可以按模型、提供商、端点、工作区或请求标签对使用情况进行分组。他们可以识别峰值是由流量增长、更长的提示词、重试还是模型变更引起的。

这比单一账户总额更有力。总额只能告诉财务支出增加了。详细的请求轨迹则能为工程团队提供修正应用程序的路径。

这一机制也有助于为客户代理模型调用的 SaaS 企业。请求标签可以将使用量与最终客户或功能关联起来。团队无需为每个账户单独创建模型端点，就能比较客户活动。

不过，归因依赖于一致的元数据。未加标签的请求无法按用例可靠地分组。共享服务主体可能掩盖究竟是哪个人员或产品发起了工作。

Amazon Bedrock 也记录了类似限制。其请求元数据支持详细日志分析，但 AWS 表示这些值不会被自动强制执行。

AWS 还指出，没有元数据的请求依然会成功。组织若希望获得可靠覆盖，必须通过共享客户端或网关添加元数据。这一教训并不局限于某一家云服务提供商。

治理政策需要强制性的上下文信息。如果开发者可以绕过网关、遗漏标签或复用宽泛的身份，报告层就会变得不够准确。与不完整归因绑定的上限，可能保护的是错误的边界。

计费延迟带来了另一项挑战。Databricks 表示，预算执行采用近实时跟踪。其文档还说明，由于刷新频率不同，电子邮件告警、预算页面和系统表可能显示不同金额。

这种差异并不自动意味着执行无效。运营系统通常会为策略决策维护更快的计数器，并为分析维护较慢的报告存储。买方仍需了解这些计数器如何对账。

已经进行中的请求会造成不可避免的超额。系统在检测到阈值后可以拒绝下一次请求，但并不总能追回已经完成的模型处理。并行请求可能几乎同时越过边界。

Databricks 在有关使用量阻断的预算文档中承认了这一行为。该公司表示，活跃请求不会被中断，短暂的执行延迟可能允许产生有限的额外消耗。

实际目标是控制损失，而非数学上的精确。网关上限应能足够迅速地阻止陷入循环的代理，避免小错误演变成巨额账单。它不需要像预付卡一样运作。

尽管如此，企业仍应在真实并发条件下测试这一边界。单个交互式用户构成简单场景。数百个并行代理调用则会带来更棘手的执行问题。

预置容量带来了不同的困难。即使很少有请求通过网关，组织仍可能为预留吞吐量付费。阻断请求并不一定会消除底层的容量费用。

外部提供商进一步增加了计量复杂度。Databricks 可以路由至 Anthropic 和 OpenAI 等公司的模型。网关必须将提供商的使用量转换为一致的成本表示。

提供商计费可能包括输入 token、输出 token、缓存 token、批处理以及预留服务。统一计量器必须考虑这些差异，同时不能制造虚假的精确感。

这正是 Databricks 对计算成本的关注比单独 token 计数更有用的原因。一百万个 token 并不具有普遍一致的经济含义。模型、token 类型、路由方式和商业安排都会产生影响。

更广泛的机制颇具吸引力：集中请求、附加身份、计算成本、执行阈值，并保留记录以供分析。其最薄弱之处，是任何处于这条链路之外的流量或费用。

文档缺口令硬上限主张承压

Databricks 的公告描述了广泛的硬上限，而当前产品文档列出的阻断与跟踪覆盖范围更为有限。

公告称，Unity AI Gateway 可以在预算超支后阻止后续请求。它将硬上限定位为告警不足时的解决方案。

当前的网关预算文档需要更审慎地解读。文档称，共享阈值和按用户阈值可以发送告警，而使用量阻断仅适用于 Genie 预算。

Genie 是 Databricks 的对话式分析产品。如果该文档仍然有效，这一限制将把通用网关工作负载排除在所宣传的阻断行为之外。

对此存在一种合理的时间差解释。该文档页面更新于 7 月 23 日公告之前。Databricks 可能正在以快于各参考页面更新速度的节奏推出更广泛的执行能力。

这种解释仍属推断，并非确认。企业买方应在自己的账户、云环境和区域中验证功能可用性。他们不应假定博客公告凌驾于运营文档之上。

跟踪覆盖范围构成第二项差异。公告描述了对模型、代理、MCP 服务器和提供商的可见性。它还讨论了分析层中的外部模型成本和预置吞吐量。

预算文档称，Unity AI Gateway 预算目前跟踪通过 ai_query 产生的按 token 计费和批量推理。文档表示，预置吞吐量和外部模型推理目前尚未被跟踪。

分析与预算执行可能使用不同的数据路径。Databricks 或许能在系统表中显示某些外部成本，却不将其计入预算阈值。公开材料并未完全解释这一边界。

这一差异至关重要。可见性回答的是组织花了多少钱。执行决定未来哪些请求应被拒绝。某项工作负载可以出现在分析中，同时仍处于硬上限之外。

一家多提供商公司需要在两个层面都获得清晰说明。如果网关预算涵盖 Databricks 托管推理，却排除外部模型，团队可能会在无意中将支出转移到受控计量器之外。

同样的担忧也适用于预置吞吐量。公司可能看到与预留容量相关的使用量，但停止请求并不会消除预留本身。预算政策必须区分消耗与承诺成本。

模型服务路径也存在疑问。文档列出了具体支持的计费类别。买方应验证每个 SDK、端点类型、批处理路径和代理运行时是否都接入同一个预算计量器。

执行身份同样需要测试。按用户限制在调用携带个人用户身份时效果最佳。服务端应用通常使用由许多最终用户共享的服务主体。

共享身份可能导致某一客户的活动阻断该主体背后所有人的服务。请求标签可能改善分析，但公开文档并未证明每个标签都支持硬性执行。

阈值时序也值得直接验证。Databricks 表示执行接近实时，而系统计费表每隔数小时刷新一次。团队需要了解哪个计数器控制阻断，以及它将提供商使用量纳入其中的速度。

这些问题都不会令此次发布失去意义。它们界定了一个有吸引力的控制平面与可靠财务保障之间的区别。

早期企业软件发布往往从较窄的覆盖范围开始。Databricks 可以随时间扩展受支持的计费类型和执行目标。清晰的文档必须同步跟进，因为财务控制需要可预测的行为。

最负责任的部署模式是分层防护。团队可以将网关预算与云账户告警、提供商限制、应用速率限制和代理级迭代控制结合使用。

应用程序防护仍然至关重要。代理应具备最大步骤数、有限重试、超时和取消逻辑。财务上限是最后一道断路器，而不是第一道防线。

云成本报告也仍不可或缺。网关可能治理模型调用，但周边基础设施会产生独立费用。即使模型访问停止，向量数据库、存储、网络和计算仍可能继续消耗资源。

团队应在启用上限前记录预期的执行范围。该记录应列明模型、端点类型、身份、标签和被排除的费用。随后即可通过测试验证每条路径。

一次受控的故障演练可以提供有用证据。工程师可以让低风险工作负载针对较小的内部阈值运行，提高并发度，并观察告警和拒绝响应何时出现。

他们还应将网关仪表板与系统表及提供商记录进行比较。轻微的时序差异在预期之内。持续的覆盖缺口则需要采用不同的控制措施或修订策略边界。

因此，应根据已验证的覆盖范围而非预算页面的存在来评价此次发布。仪表板很容易理解。在异构 AI 计费系统中实现可靠执行，才是更艰难的工程成就。

三个信号将显示这些控制措施是否奏效

下一项考验不是又一次公告；而是 Databricks 是否能统一文档表述、扩展计量能力，并证明其在真实代理工作负载中的采用情况。

第一个信号是文档趋同。Databricks 需要让其产品公告和运营参考资料描述相同的阻断行为。

买方应关注网关文档是否会移除仅限 Genie 的使用量阻断限制。他们还应寻找关于账户设置、权限、云环境和支持区域的明确要求。

清晰的错误行为也同样重要。文档应说明被阻断的请求会返回什么结果、访问会多快恢复，以及管理员是否可以授予例外。生产应用需要可预测的故障处理。

如果这些细节出现，广泛硬上限的主张会更可信。如果这一限制持续存在，客户应将通用网关预算主要视为告警，直到 Databricks 另行确认。

第二个信号是扩展计费覆盖范围。外部模型推理和预置吞吐量是重要的企业支出类别。排除其中任一类别，都会削弱组织范围内的成本上限。

Databricks 应说明哪些费用进入阈值执行，哪些仅出现在分析中。它还应解释，当定价结构不同时，提供商成本如何计算。

批量操作的覆盖也值得关注。定时文档处理可能产生高额、无人值守的消耗。这正是财务断路器最具价值的工作负载。

该公司的文档目前将按 token 计费和 ai_query 批量推理列为被跟踪的类别。扩展到这些路径之外，将强化统一 AI 成本治理的主张。

第三个信号是真实的运营采用情况。产品团队应寻找涉及多个工作区、提供商、身份和代理框架的客户证据。简单的仪表板演示无法检验困难场景。

有价值的案例研究应报告团队多快发现失控重试、哪些策略阻断了请求，以及工程师如何恢复合法工作负载。它们还应披露哪些内容仍处于网关之外。

采用情况将取决于开发者行为。只有当团队持续通过网关路由模型时，网关才能实现完整治理。组织需要受支持的 SDK、低路由开销，以及不会妨碍日常实验的政策。

独立网关和云原生控制能力将继续完善。Microsoft 已将项目配额与 API 管理层相结合。AWS 则通过身份、推理配置文件、日志和账单导出提供详细的成本归因。

Databricks 的差异化优势在于连接数据治理、模型访问和财务政策。Unity Catalog 已为许多客户保存权限和审计信息。加入支出决策能力，可减少它们需要运行的控制系统数量。

当智能体使用受治理的企业数据时，这一优势会进一步扩大。同一平台可以决定智能体访问哪些信息、调用哪些工具，以及消耗多少推理资源。

这也带来了集中化风险。共享网关中的一个错误可能同时影响许多应用。管理员需要变更控制、政策测试、审计追踪和紧急覆盖机制。

知识工作者可能不会直接与这些预算设置交互，但他们会感受到结果。额度耗尽可能中断编码会话、研究工作流或支持流程。

因此，团队应将支出控制与清晰的责任归属结合起来。用户需要知道请求失败是因为权限、提供商容量、速率限制，还是预算阈值。

他们还需要一条轻量级的升级路径。一个正当项目不应在多个部门讨论谁能调整其额度期间始终被阻塞。

对于正在评估此次发布的组织，最佳下一步是开展范围明确的试点。选择一个经由网关路由的智能体，附加专用身份，应用一致的标签，并记录每一项预期费用。

随后测试告警、阻断、并发和重置行为。将 Databricks 记录与提供商或云端账单数据进行比较。在更换模型或将工作负载迁移至批量执行后，重复测试。

在执行边界明确之前，应将试点与关键生产流量隔离。搭配有限重试和智能体最大步骤数。记录任何仍超出已配置预算的费用。

管理这些发现的团队可以维护一个可搜索的工程知识库。当工程师在部署决策期间能够检索到政策测试、账单说明和事故复盘时，这些资料会更有价值。

Databricks 推出 AI 支出控制功能，是对智能体需要在执行路径内设置财务护栏的重要认可。该公司现在必须证明，其执行覆盖范围与这一雄心相匹配。

关注文档、受支持的计费类别以及真实客户部署。这些信号将揭示 Unity AI Gateway 是否会成为有效的断路器，还是又一层延迟的成本可见性。