你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 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、功能名称、环境——并将这些元数据传递到账单数据中。如果你不在交易发生时打上标记，信息就消失了。没有类似于下个季度通过检查资源清单来理清账单的方法。
一旦你捕获了这些元数据，两件以前不可能的事情就变得可能了。
第一是单客户单位经济效益。如果每个请求都标记了客户 ID，你就可以汇总每个客户的 Token 成本，并最终回答你的基于用量的定价是否真正产生了利润——或者你那三个使用量最大的账户是否在悄悄亏损。对于许多 AI 产品来说，这就是一项业务与一个昂贵爱好之间的区别。
第二是单功能透明度。按能力打标签——聊天机器人 vs. 摘要生成 vs. 代码辅助功能——产品团队就可以看到他们上线的每项功能的真实成本。这是后续所有对话的基础，因为在你了解每个功能的实际成本之前，你无法决定削减什么、限制什么或重新定价什么。
在实行计费分摊（Chargeback）前先进行消费公示（Showback）
一旦你能归因支出，本能的反应就是立即将其分摊到各团队的预算中。请克制这种冲动。计费分摊（Chargeback）——即通过财务集成将成本实际转移到团队的成本中心——需要在每个工作负载上进行准确的打标签（Tagging）、就如何分摊共享开销达成一致，并获得财务部和每个团队负责人的认可。在标签还不可信之前就开启这项功能，接下来的一个季度你将忙于争论数据是否准确，而不是去降低账单。
从 消费公示（Showback） 开始：这是一种仅用于归因的报告，每个团队都能看到他们本应被收取的费用，但实际并没有资金流动。它是一面镜子，而不是一张发票。消费公示在不引发政治斗争的情况下建立了问责机制，并能在错误标签开始影响真实预算之前将其暴露出来。当各团队查看自己的数据几个月且无人提出异议时，计费分摊就变成了一项财务记账变更，而不是一场谈判。
顺序至关重要。归因赢得信任，消费公示培养习惯，然后计费分摊才有立足之本。跳过前面的步骤直接进入最后阶段，会让 FinOps 项目背负上“产生没人相信的数据”的名声。
告警并非执行手段
AI FinOps 中最惨痛的教训是：预算告警并不等于预算控制。当一个智能体（Agent）每天烧掉 4,700 美元时，1,000 美元的告警起不到任何作用——等到人类阅读通知、确认并找到关闭开关时，那些突破上限的会话早已运行结束。当数百个智能体会话以机器速度并发执行时，大多数会话在任何人采取行动之前就已经完成了。监控告诉你发生了什么，但它无法阻止正在发生的事情。
真正的控制存在于执行层，即在下一次调用发出之前。支出网关（Spend Gate） 会根据上限检查累计支出，并直接拒绝该 请求——它不会发出关于预算的警告，而是拒绝发起调用。这就是烟雾报警器与断路器之间的区别。报警器告诉你着火了，而断路器则直接切断电流。
在不重写每个服务的情况下安装这些网关的务实方法是，在代码与供应商之间架设一个代理（Proxy）或网关。这类工具——LiteLLM 是常见的开源示例——会分发虚拟密钥（Virtual keys），每个密钥都有自己的硬性 max_budget、重置周期以及每分钟请求数（RPM）和每分钟 Token 数（TPM）限制。当某个密钥超出预算时，代理将拒绝后续请求并返回明确的错误，直到窗口重置或有人调高上限。让每个功能、团队或客户都通过各自的密钥进行路由，你就能从同一个切入点实现归因和执行。一个值得压力测试的细节：从快速共享计数器读取支出的预算检查在负载下或缓存失效期间可能会出现偏差，因此如果上限必须是真正的硬上限，请确保你的设置在允许请求之前会向权威数据存储进行验证，而不是信任一个最终一致性的数字。
设计目标是给预算所有者一个他们真正能旋转的旋钮。不是一个让他们在计费表飞速转动时盯着看的仪表盘，也不是一个会让整个功能下线的自杀开关——而是一个真正的限制，它能优雅地拒绝单个请求、在超出限制时降级到更便宜的模型层级，或者将工作排队处理而非丢弃，同时让预算所有者在拥有完整上下文的情况下调整上限。
具体的实践建议
你不需要在第一天就拥有一个 FinOps 平台。你需要从一开始就接入四件事，因为对已经产生的支出进行事后补救是上述所有步骤中最困难的版本。
- 在调用点植入归因。 为每个模型请求标记功能、客户、团队和环境。这是你以后无法补救的一件事，因为交易在完成的那一刻就消失了。
- 通过具有硬性单密钥预算的网关进行路由。 执行应该发生在调用之前，而不是发生在事后送达的告警中。拒绝请求的上限远胜于解释超支的图表。
- 在尝试计费分摊前先发布消费公示。 让团队查看自己的数据，直到无人提出异议，然后再进行真实的账务核算。
- 以基于使用量而非价格的区间进行预测。 Token 单价在持续下降，这会让团队麻痹大意，从而忽视账单。但你的成本随使用量增长和上下文大小（Context size）而扩展，而非随标价扩展——请预测一个范围，而不是一个点，并在上线前针对该范围的上限进行压力测试，而不是等上线后被动应对。
让你感到意外的账单从来不真正关乎 Token 价格。它关乎那些通过你的变更管理流程从未被要求审查的代码路径进入生产环境的支出。弥补这一差距，那份 40,000 美元的发票就不再是事后需要解释的谜团——它变成了一个由某人选择、负责并可以调低的数字。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
