摘要：FinOps Foundation《2026 State of FinOps》释放了一个被多数人忽略的信号：粗放式云浪费的“大石头”已基本清理完毕，剩下的是一大批“费力才能捡起来的小石头”。与此同时，Harness调查显示67%的企业每月AI支出超过25万美元，26%的AI花费被浪费，而73%的项目在超预算运行。当传统FinOps的边际收益递减撞上AI成本的结构性失控，继续拧同一颗螺丝已经不够了。本文给出一套五步进阶路径，从标签治理推进到预测性预算与IT财务治理对接，每一步附带可验证的工具链和指标。
引言：省钱的“容易模式”结束了，而AI账单不等人
过去五年，FinOps的绝大多数成果来自一类工作：找到闲置的虚拟机、关掉没人用的环境、清理废弃的存储卷、把长期运行的实例换成预留。这些就是CloudKeeper所称的“大石头”——肉眼可见、动刀即省、工程代价低。FinOps Foundation 2026年的调查覆盖了1192名从业者、代表超过830亿美元的年云支出，结论很直白：许多受访者表示“我们已经搬完了浪费的大石头，现在面对的是大量需要更多努力才能抓住的小机会”。
问题在于，恰恰在这个“容易钱赚完了”的节点，AI成本以完全不同的方式涌进来。Harness对700名企业工程负责人的调查显示，67%的企业每月AI支出不低于25万美元，五分之一的企业超过100万美元；组织自估26%的AI支出被浪费，对于月支出100万美元的企业，这意味着每月26万美元没有可衡量的回报。更棘手的是归因和治理的断裂：52%的企业没有明确的AI成本负责人，72%在过去一年经历过意外账单飙升，只有13%对AI支出有基本可见性。
当“砍大石头”的收益已经见顶，而AI账单正在成为一个传统FinOps手段系统性失效的新盲区，运维工程师和技术管理者应该按什么顺序推进，才能让优化投入的边际回报不继续下滑？五步进阶不是又一轮工具采购清单，而是一次从“清理已发生的浪费”到“在浪费发生之前干预”的范式转移。
第一步：标签治理——不是重做标签，而是先定义“谁该为哪一类成本负责”
核心观点：标签治理在AI时代的第一优先级不是覆盖更多资源，而是区分“可标签归因的成本”和“标签无法拆分的成本”——后者恰恰是AI支出的主体，承认这一点才能避免在错误的战场上投入工程时间。
传统标签治理的假设是：每一个资源都能被标记到团队、项目或成本中心。这在虚拟机、存储桶和数据库上大致成立。但AI成本打破了这个假设。一个共享GPU上同时运行多个模型和多个客户的推理请求，一张API Key背后混合了不同团队的调用，一个token计费账户的消耗无法用“打标签”的方式拆到功能粒度。DoiT在推出Attribute时对此有一段精准的表述：API Key或标签无法拆分一块跑着多个模型的GPU，SDK只能看到“有人记得包了一层”的调用，覆盖永远是局部的，数字永远偏离现实。
因此，标签治理在AI FinOps进阶中的正确角色是划定边界，而不是包揽一切。可标签的部分——云主机、Kubernetes命名空间、存储、网络——继续用标签和分配规则做归因，Datadog的Tag Pipelines和Custom Allocation Rules在这方面提供了成熟的能力。不可标签的部分——共享GPU、token支出、模型API调用——需要被明确标记为“需要运行时归因”的类别，交给第二步的工具来处理。
可验证的指标：标签覆盖率本身不再是有意义的成功度量。更有意义的指标是“可标签成本占总AI支出的比例”。如果这个比例低于50%，说明大部分AI支出根本不在标签体系的射程之内，此时继续投入工程时间提升标签覆盖率，是在优化一个已经不再是主要矛盾的问题。国内实践中，平安金算盘在1.0阶段做完资源效率优化后，2.0阶段转向“数据层—能力层—治理层”架构，本质上也是在承认：粗放清理之后，归因和核算的精细度才是瓶颈。
第二步：AI工作负载成本归因——从“打了什么标签”转向“实际跑了什么”
核心观点：AI成本归因的技术路线正在从“侵入式埋点”转向“内核级观测”，这对于标签覆盖不足、SDK改造代价高的国内环境是一个结构性利好；归因的粒度决定了后续每一步优化是否有可操作的对象。
传统归因靠两件事：标签和SDK。标签在共享资源面前失效，SDK在工程纪律松弛和覆盖不完整时失真。DoiT的Attribute选择了一条不同的路径：一个轻量eBPF传感器安装在操作系统内核，观测实际发生的GPU、CPU、API调用和I/O，将每一单位消耗映射回进程、容器、Pod和请求，同时识别对OpenAI、Anthropic、Gemini、Bedrock等托管模型API的出站调用，并与供应商成本数据拼接。它不需要标签策略，不需要代码改动，安装时间约15分钟。Datadog的路线则是在可观测性数据旁边追踪LLM和GPU成本，让工程师在日常使用的仪表板和软件目录中看到成本，同时支持按模型和服务构建单位成本。CloudHealth同样将能力延伸到token级tokenomics和GPU使用归因。
这两条路线指向同一个判断：AI成本归因的竞争壁垒不在“能不能打标签”，而在“能不能在不依赖工程纪律的前提下持续产出可审计的数字”。对于国内运维工程师而言，这意味着在评估归因工具时，应该优先追问三个问题：是否支持共享GPU的多租户拆分；是否覆盖主流国内模型API（阿里云百炼、火山方舟、百度千帆等）的用量归因；输出的单位成本（每token、每请求、每客户）是否可以被财务直接使用。MofCloud等国内平台已经开始将阿里云、腾讯云、华为云、火山引擎、百度智能云上的大模型用量归一化到同一张表中，这是国内AI FinOps工具链走向可用的一个信号。
可验证的指标：归因覆盖率，即被归因到具体团队/功能/客户的AI支出占总AI支出的比例。Harness调查中只有13%的企业对AI支出有基本可见性，这个数字本身就是第二步的基线。
第三步：预留+Spot+Serverless组合——把“省钱的顺序”搞对，比选对工具更重要
核心观点：AI工作负载的成本优化存在一个严格的顺序：先判断工作负载的可中断性，再选择计费形态；反过来先买承诺、再发现负载不适合，会把折扣变成负债。CloudKeeper提出的“先缩小、再承诺”原则，在GPU场景下比在传统云资源场景下更加致命。
MLflow的2026年企业指南给出了清晰的折扣区间：Spot实例用于训练任务可节省60%到90%的按需价格，预留实例和Savings Plans用于最大计算项可节省40%到72%，而综合运用闲置检测、Spot、right-sizing和基线承诺的团队可以在30天内实现50%到60%的成本下降。但这些折扣有一个共同的前提：工作负载的特性必须与计费形态匹配。
训练任务天然适合Spot——它是批处理式的、容错的、可中断的。推理任务则复杂得多。全天候满载、规格稳定的线上推理适合预留实例，因为利用率有保障；但周期在数小时到数周之间的微调任务，以及流量波动大的推理服务，需要Serverless GPU的按秒计费和scale-to-zero能力。DigitalOcean的定价示例提供了一个直观的量级：一张H100按需运行744小时约3281美元，如果利用率长期低于30%，预留承诺的折扣会被闲置成本吃掉。
CloudKeeper引用AWS对71000多个账户的分析给出了一个值得注意的佐证：将right-sizing与Savings Plans结合使用的客户，在成本效率指标上表现优于仅依赖Savings Plans的客户；Savings Plan覆盖率在95%到100%的客户，可见的非Savings Plan优化机会比覆盖率在0%到25%的客户少65%到80%。但高覆盖本身也可能掩盖问题——它让某些优化机会在指标中变得不可见。对于AI工作负载，正确的顺序是：先做归因，知道哪些负载在跑、跑了多久、能不能中断；再基于归因结果决定哪些负载进Spot、哪些进预留、哪些留在Serverless。跳过归因直接买承诺，等于在不知道负载画像的情况下签了一张长期支票。
国内实践中，腾讯云TKE的算力错峰是一个值得研究的案例：智能辅助驾驶场景中，白天在线脱敏业务消耗千张GPU卡，离线数据处理若独立运行需额外增加300多张卡；通过“白天推理、晚上训练”的动态资源池调度，用700多张卡完成了原本需要1600多TB/天的数据处理任务，总成本降低30%，集群整体利用率提升至65%。这个案例的本质不是买对了哪种计费形态，而是先看清了负载在时间轴上的分布，再让计费形态去适配它。
第四步：预测性预算——从“解释上个月为什么超了”到“在下个月超之前干预”
核心观点：AI支出的概率性特征使基于历史均值的预算方法系统性失效；预测性预算的价值不在于把预测做“准”，而在于把干预点前移到支出发生之前，让预算从一份事后解释文档变成一条事前控制线。
Harness的数据揭示了传统预算方法在AI场景下的窘境：56%的企业承认预测AI支出靠的是猜测而非数据，72%经历过意外账单，只有20%能在支出翻倍时于数小时内定位原因。原因不复杂。AI成本由token消耗驱动，而token消耗是概率性的——同样的提示词每次产生的响应长度不同，多模型路由使单价随请求动态变化，多级Agent的工作流让一次用户操作可能触发数十次模型调用。用上个月的账单均值乘以一个系数，在这种波动面前几乎没有预测力。
预测性预算的技术路线正在成形。IEEE 2026年发表的FISO系统使用Facebook Prophet做预测、Isolation Forest做异常检测，在AWS、Azure、GCP的真实生产数据上达到93.4%的预测准确率（MAPE 8.3%），异常检测时间从传统工具的24到48小时缩短到4分钟，使用该系统的组织将预算意外减少了64%。Datadog在其云成本管理模块中加入了budget forecasting，将前瞻性支出视图嵌入工程师和FinOps日常使用的预算工作流中。Kion和HCL MyXalytics同样将AI/ML驱动的异常检测和预测分析作为核心能力。
但需要保持清醒的是，预测准确率本身不应成为目标。一个MAPE为8%的预测如果只能月度更新一次，对于token支出日间波动的干预价值仍然有限。更有意义的指标是“异常检测到干预动作之间的时间差”，以及“预算阈值触发的自动动作比例”——比如当某个团队的AI支出在24小时内偏离预测区间超过设定幅度时，是只发一封告警邮件，还是自动触发模型路由降级、切换到更便宜的模型或暂停非关键实验。预测性预算的真正分界线，在于它是否接入了执行面。
第五步：FinOps与IT财务治理系统对接——让单位算力经济性进入技术选型的决策桌
核心观点：FinOps的成熟形态不是在月底出一份成本报告，而是在技术选型发生之前就把成本约束嵌入决策；这要求FinOps的数据和语言能够被IT财务治理系统直接消费，而不是停留在运维仪表盘里。
FinOps Foundation 2026报告中最值得注意的结构性变化之一是：78%的FinOps团队现在向CTO或CIO汇报，而向CFO汇报的比例降至8%。同时，与高管层（VP/SVP/EVP/C-suite）有对接的FinOps实践，在云服务选型上的影响力是从仅对接总监级的4倍以上（53%对12%），在云厂商选型上是近6倍（47%对8%）。报告还指出，FinOps与ITFM（IT财务管理）团队的协作频率最高，其次是ITAM/SAM和ITSM。
这条演进线索的含义是：FinOps正在从“成本优化职能”转变为“技术价值治理职能”。在AI场景下，这一步的紧迫性尤其突出。当一个团队要决定自建推理集群还是调用托管API、选择哪家模型供应商、在训练中投入多少GPU时，成本不应该是事后核算出来的数字，而应该是选型评估表里的一行。Harness调查中只有26%的企业有稳健的方法衡量AI支出的业务价值，这恰恰说明大多数组织还没有建立起“单位经济性→技术选型”的反馈回路。
可验证的指标：不是“FinOps团队产出了多少份报告”，而是“有多少项AI相关的技术选型在决策时引用了FinOps提供的单位成本数据”。平安金算盘的3.0阶段提供了一个国内参照：以“AI For FinOps”为核心，通过AI Agent打通“感知—决策—执行—反馈”闭环，从“平台”升级为“智能助手”，降低跨域协作门槛。这个方向的本质是让成本治理不再是财务和运维之间的拉锯，而是嵌入到技术和业务决策的默认流程中。
结论
“大石头”砍完之后，FinOps的边际收益递减不是失败信号，而是成熟信号。它意味着粗放清理的红利已经兑现，接下来的每一个百分点的优化都需要更精确的归因、更前置的干预和更深的组织嵌入。而AI成本恰好在这个节点涌入，用token的概率性、共享GPU的不可标签性和多供应商的计费碎片化，把传统FinOps的手段逼到了失效边缘。五步进阶的顺序不是随意的：没有归因的预留是盲目的承诺，没有预测的预算是一份事后讣告，没有接入财务治理的FinOps只是一张运维仪表盘。
对运维工程师：把“可归因的AI支出占比”和“异常检测到干预的时间差”作为当前阶段的核心KPI，而不是标签覆盖率和工具开启数量。在GPU共享环境中，优先验证内核级观测方案是否能产出可审计的单位成本，这比在标签体系上继续加码更有杠杆。
对技术管理者和企业IT决策者：在下一个AI项目立项时，要求团队在架构选型阶段就提交单位经济性测算——每token成本、每请求GPU秒数、按当前利用率假设的折旧覆盖率。把FinOps的参与点从“上线后优化”前移到“设计时约束”，这是阻止AI账单继续成为意外来源的最便宜的手段。
对投行分析者：AI FinOps工具链的竞争正在从“可见性”转向“归因粒度”和“预测到执行的闭环能力”。关注那些能把归因做到token/GPU周期级别、并把预测信号接入自动动作（模型路由、容量伸缩、承诺购买）的玩家，而不是只提供成本看板的厂商。企业AI支出的26%浪费率是一个可被产品化压缩的利润池，谁能让这个数字可测量、可干预，谁就站在下一轮企业软件价值重估的入口。