人工智能现在是一个金融运营问题
FinOps 基金会的 2024-2025 年 FinOps 状况报告以简单的数字说明了这一转变：“管理人工智能成本”和“管理基于承诺的折扣”已成为从业者优先考虑的重点，取代了定义早期企业云成本纪律周期的长期规模调整担忧。独立的云行业调查报告了相同的方向——人工智能和机器学习基础设施是连续多年增长最快的云支出类别。
这种转变破坏了现有的 FinOps 的许多力量。大多数工程组织所依赖的工具和仪表板是为稳定计算的世界而设计的，该计算可归因于通过标签提供的服务，并通过实例大小和承诺折扣进行优化。人工智能工作负载违反了所有这些假设。它们是突发性的而不是稳定的。它们每单位时间都很昂贵。它们涵盖 GPU 计算、矢量数据库、推理端点、托管模型 API 和第三方生成 AI 服务。而且它们越来越多地由不直接拥有云发票的产品团队运营。
接下来的框架将介绍特定于人工智能工作负载的三个结构性成本泄漏、驱动每个工作负载的经济性、人工智能的 FinOps 操作手册的操作细节、区分受控程序和反应性程序的治理节奏，以及解决企业 FinOps 从业者在 2026 年提出的反复出现的问题的常见问题解答。
漏洞 1 – GPU 利用率不足
企业人工智能中最常见和最昂贵的成本泄漏是仪表板上看起来最便宜的成本泄漏。 GPU 实例按小时定价 - 无论它们是在主动训练模型、等待缓慢的数据加载器、在陈旧的 Jupyter 内核上闲置，还是运行被遗忘的开发实验。已发布的行业基准一致认为，从 2023 年到 2025 年，企业 ML 集群中的 GPU 利用率中位数在 30% 到 40% 的范围内，许多生产环境的运行情况远低于该水平。
成本计算是无情的。在云按需定价上运行的单个高端训练 GPU 的价格约为每小时 4-6 美元。在任何模型投入生产之前，十名数据科学用户的笔记本电脑会产生闲置的 GPU 时间，这会导致中型 ML 团队每年损失六位数的成本。
该修复并不是对工程师的道德讲座。它是嵌入在代码中的策略：具有记录的 TTL 策略的空闲内核自动关闭、笔记本实例和开发端点上的强制生存时间、每个环境中每个团队的 GPU 配额、调度程序管理的作业放置（Kueue、Volcano、Slurm 类调度程序）（将作业打包到共享 GPU 池而不是将每个用户固定到专用容量）以及每个团队的显示仪表板，使空闲 GPU 模式对拥有它的团队可见。
漏洞 2 – 代币蔓延和模型蔓延
LLM API 重新引入了可变的、按请求定价的堆栈，该堆栈基本上已经适应了统一费率计算。对前沿模型提供商的每个 API 调用都会产生输入令牌和输出令牌费用，并且成本以触发它们的团队通常看不到的不明显方式复合：在没有相应预算审查的情况下从 4k 上下文大小增长到 32k 上下文大小的 RAG 管道、在 A/B 测试中将输出长度加倍的思想链提示、在瞬态故障时默默触发 3 次的重试循环、在每个查询上处理相同大型文档的长上下文方法而不是缓存。
更糟糕的是，触发这些成本的团队很少能看到这些成本。以笔记本形式运行 A/B 的产品经理、使用内部助理的客户成功代理、重新索引知识库的后台作业 – 每个人都可以增加相同的共享 API 账单，而无需每个团队归因。解决方案是将每个功能令牌计量推到产品层：输入令牌、输出令牌和估计成本的请求级日志记录，按功能和用户群体标记，以与产品分析已经汇总每次获取成本或每次请求成本相同的方式进行汇总。
模型蔓延加剧了代币问题。现在，每个主要模型提供商都提供分层目录（旗舰推理模型、中层通用模型、低成本快速模型、微调的较小变体）。团队在发布时选择旗舰产品，不再重访，并为查询支付比所需费用高出 5 至 10 倍的费用，而较小或经过微调的模型将无法区分地提供服务。每季度的“模型规模调整”审查（AI 相当于经典实例规模调整）通常可以收回 30-50% 的 LLM 支出，且不会出现用户可见的质量变化。
漏洞 3 – 承诺和现货实例策略不一致
对于自托管训练和推理工作负载，底层的云经济看起来与任何其他计算支出一样，但适用于稳定网络服务的承诺策略却打破了人工智能。主要云平台的三个定价层对于 AI 工作负载的工作方式有所不同：
- 按需 GPU 实例。最昂贵的选择。适用于不可预测、小批量或一次性工作负载。
- 预留/储蓄计划/承诺使用折扣。 30-60% 的折扣可换取 1 年或 3 年的承诺。适用于连续运行的推理层。
- 现货/抢占式实例。高达 90% 的折扣，但可以在短时间内收回。适用于容忍检查点中断的工作负载。
每个工作负载的承诺策略
培训工作负载是现货定价的理想选择，因为它们可以进行检查点和恢复。很多企业团队从来没有设置过这个；他们按需支付能够承受 5 到 10 分钟检查点开销的现场中断的工作。培训项目的成本差异通常为 70-90%。
推理工作负载则相反。他们需要可预测的延迟来提供面向用户的服务，而点通常不适合，因为抢占会导致用户可见的事件。推理层应在承诺容量（预留/节省计划/CUD）上运行；仅地板上方的弹性溢出需要按需。成熟的 AI FinOps 实践会明确分解生产组合：致力于推理、现货培训以及仅按需提供真正无法规划的突发容量。
同样的计算也适用于托管推理端点（用于模型服务的云供应商托管服务）。它们的定价既方便又节省工程时间，而且每 GPU 小时的价格比同等原始实例贵 2-3 倍。当托管服务真正节省了工程能力时，这一溢价是值得的，而当团队具备在原始基础设施上运行推理并捕获成本差异的运营成熟度时，这一溢价就不值得了。
人工智能 FinOps 手册
人工智能的最低限度可行的 FinOps 实践如下所示，按运营杠杆的顺序排列：
- 按团队、产品和堆栈每一层的环境标记每个资源：计算、存储、矢量数据库、托管推理端点、第三方模型 API 消耗。未标记的支出是任何 FinOps 审计所利用的第一个弱点。
- 在 LLM 和生成工作负载的请求级别（而不是实例级别）进行计量。将输入令牌、输出令牌、延迟和估计成本与标准应用程序指标一起推入可观察性堆栈，按功能和每个用户群组进行归因。
- 将策略放在代码中，而不是策略文档中。空闲内核自动关闭、开发端点上的强制 TTL、每个团队 GPU 配额、自动挂起笔记本实例、按需成本超过阈值时安排的现货层回退。
- 每季度进行一次模型规模调整审查。对于每个 LLM 支持的功能，根据当前生产模型重新评估通过评估集的最小模型。记录降级决定或保留更大型号的明确原因。
- 按工作负载形状单独的承诺策略：承诺推理层、训练点、仅针对真正的突发溢出按需分配。将托管推理端点视为具有记录的溢价的可选性，而不是默认选择。
- 在“退款”之前先建立“展示”。为团队提供每周一次的人工智能支出仪表板以及归因；在将财务责任纳入损益表之前，让这种可见性驱动整个季度的行为。跳过展示并直接进行退款始终会产生怨恨，而不会产生推动实际成本降低的可见性。
- 限制每个请求的成本和每个功能的每月支出，并设置无法关闭的硬性限制。每个请求的成本上限模式可以防止失控的代理循环产生意外的账单，而每个功能的每月上限可以防止 A/B 测试悄悄地将行项目加倍。
向量数据库和检索成本维度
2026 年，FinOps 的一个维度经常让团队感到惊讶：矢量数据库和检索基础设施成本。 As RAG pipelines scale to production volume, the vector index, the retrieval queries, the re-embedding cost when models change, and the storage cost for embeddings all become meaningful line items separate from the LLM API spend.
务实的操作方法：计量矢量 DB 成本与计量 LLM 成本的方式相同 - 每个查询、每个功能归因、暴露给产品负责人，由产品负责人决定检索模式是否合理。在任何嵌入模型交换之前，应专门对重新嵌入成本进行建模和预算；重新嵌入大型语料库的成本是不小的，并且让没有计划的团队感到惊讶。
对于在边缘和云两层模式上运行的程序，成本算术会以有趣的方式发生变化。 Frontier API 查询每次调用的成本为几美分，但不需要嵌入基础设施；在本地硬件上微调的小型模型每次查询的成本仅为一美分，但需要前期微调投资加上检索基础设施来保持它们的最新状态。总成本比较取决于数量、刷新频率和基础设施开销。
让 FinOps 坚持下去的治理部分
我们见过的针对人工智能工作负载的最佳 FinOps 计划将上述工程控制与轻量级治理节奏相结合，从而保持可见性循环闭合，而不会产生官僚开销。
- 每月人工智能成本审查会议。工程、产品和财务领导层参加了 45 分钟的跨团队审查。常设议程：十大成本驱动因素、每周趋势、异常调查、即将发生的影响成本的变化。
- 十大成本驱动因素的常设名单及其所有者。该清单是 FinOps 计划的运营支柱。如果没有指定每个驱动程序的所有权，讨论只是理论上的；有了它，生产每条成本线的团队就有责任捍卫或减少它。
- 季度模型和承诺规模调整审查。模型规模调整带来的 30-50% 的 LLM 成本降低是经常性的，而不是一次性的；每季度的节奏抓住了这一点。
- 每个事件的成本回顾。当人工智能功能发布并显着优于或低于其成本预测时，请对预测方法进行回顾，而不仅仅是绝对数字。
- 年度容量和承诺规划。推理层的 1-3 年云承诺决策每年根据产品路线图、工程能力和财务预测的输入做出。
人工智能的 FinOps 成熟度进程
大多数企业 AI FinOps 计划都会经历三个阶段，每个阶段都会解锁下一组功能：
- 第一阶段——可见性。标记、计量、仪表板。团队可以回答“人工智能支出去哪儿了？”。到 2026 年，大多数企业的人工智能工作负载都处于这个阶段，即使它们在传统云支出上的 FinOps 成熟度较高。
- 第 2 阶段 – 优化。代码中的政策、规模调整、承诺策略、治理节奏。团队可以在不影响用户可见质量的情况下减少支出。 30-50% 的成本降低就在这里。
- 第 3 阶段 – 预测和与产品相关的支出。向产品经理公开的每个人工智能功能的成本、人工智能功能的每次获取成本风格指标、与产品路线图一致的预算分配、与产品发布相关的容量规划。这就是人工智能成本从“工程团队的问题”转变为“企业故意做出的产品经济决策”的地方。
常见问题
企业 FinOps 从业者在确定 2026 年人工智能工作负载范围时提出的常见问题：
- 我应该为 AI FinOps 工具和流程预算多少？通常占 AI 基础设施支出的 3-8%，具体取决于项目规模。通过第一季度的成本优化和随后几个季度的预测准确性，投资可以自行回收。
- 我应该为人工智能构建内部 FinOps 工具还是使用商业平台？在现有可观测性基础设施之上构建计量和显示仪表板；使用商业 FinOps 平台进行跨云成本分析和承诺规划，以增加价值。纯构建方法需要很长的时间；纯购买方法在人工智能特定维度上举步维艰，其中商业工具仍处于成熟阶段。
- 如何处理可变成本供应商发票？在应用程序层按供应商进行成本归因，而不是依赖供应商发票。发票每月寄达；每个功能的归因应该每天进行，以便团队可以在发票让任何人感到惊讶之前对其采取行动。
- 与云相比，本地 GPU 何时具有经济意义？当相同工作负载上的持续推理量连续 12 个月以上超过专用 GPU 容量的大约 60-80% 时，本地 TCO 通常会击败云。低于这个阈值，云弹性就值得付出代价。
- 当一个用户操作触发 30-80 个 LLM 呼叫时，我该如何处理代理工作负载？在失控成本事件累积之前失败的每个请求成本上限已关闭。加上每个代理的成本分布监控（不仅仅是平均）——长轨迹的尾部是成本意外发生的地方。
