FinOps 鸿沟：为什么没有人批准你那 4 万美元的 AI 账单

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

数据让这一鸿沟变得具体。目前大约 37% 的企业每年在 LLM API 上的支出超过 25 万美元，且 72% 的企业预计这一数字还会攀升。那个著名的警示案例是一个智能体系统在 11 天内悄悄烧掉了 4.7 万美元：四个协调智能体中，有两个陷入了澄清循环，全天候交换验证请求。系统没有崩溃。它以每天约 4,700 美元的成本，完美地完成了没人想要的工作，直到发票让这一切变成了现实。Gartner 在 2026 年 3 月报告称，只有 44% 的组织对这项支出设置了财务护栏。

为什么 Token 支出具有独特的不可见性

云端 FinOps 之所以有效，是因为它将成本与持久存在的事物挂钩。服务器有寿命、有标签、有所有者。你可以查看资源清单，找到未标记的 EC2 实例，并询问那是谁的。整个学科——打标签、规格优化、预留实例规划——都假设成本是与你可以指出的持久资产绑定的。

LLM API 调用没有可以指出的资产。它是一次交易，而不是一种资源。它存在两秒钟后就消失了，只留下一个 Token 计数。事后没有什么可以标记的，没有可以优化的实例，也没有可以购买并产生实质性折扣的预留。使云成本治理成为可能的原始要素根本不存在。

三个特性让 AI 支出躲过了那些能捕捉到其他所有支出的控制措施：

• 它没有席位数量。 SaaS 随人员数量扩展；你开通用户，成本遵循一个你可以推理的方案。Token 支出随 for 循环扩展。一个工程师上线了一个频繁重试的代码路径，就可以在不增加一个用户的情况下让账单翻倍，而任何基于席位的心理模型都无法预测这一点。
• 它通过密钥而不是采购订单进入。 模型 API 通过环境变量中的密钥进行授权。没有采购步骤，没有预算负责人的签字，没有容量审查——在演示中花费不足一美分的同一个调用，在上线后每天可能花费五位数，而这两种情况下的授权机制看起来完全相同。
• 它的成本曲线是非线性的，且与基础设施脱钩。 提示词设计的更改、更大的上下文窗口或模型切换，都可以在不触动一台服务器的情况下让成本倍增。财务部门习惯于成本随基础设施变动而变动。在这里，成本随提示词变动而变动，而提示词不会出现在容量计划中。

还有一层支出是大多数团队根本看不到的。他们追踪可见的聊天补全，却遗漏了嵌入生成调用、向量数据库操作、重排序过程以及偶尔的微调运行。模型仪表板上的标题数字只是该功能真实成本的一小部分。

归因是成败的关键

令人不安的部分在这里：大多数团队无法回答财务部门会问的第一个问题。哪个功能让我们花了钱？哪个客户？哪个团队？ 发票是一个巨大的、无差别的数字，如果没有归因，就没有责任制，没有单位经济效益，也没有办法在预算会议上为这些支出辩护。

AI 的归因不能事后补救，因为没有持久的资源可以用来在以后进行对账。你必须在调用的那一刻捕获上下文——用户 ID、客户 ID、功能名称、环境——并将这些元数据传递到账单数据中。如果你不在交易发生时打上标记，信息就消失了。没有类似于下个季度通过检查资源清单来理清账单的方法。

一旦你捕获了这些元数据，两件以前不可能的事情就变得可能了。

加载中…