AI 功能的闲置成本该由谁承担

按 token 付费的心智模型训练了一代工程师，让他们认为 AI 成本是使用量的函数。没有请求，就没有账单。这是一个令人慰藉的模型，对于 API 调用本身而言，这基本属实。但它只描述了生产级 AI 功能的一个层面，而并非那个悄悄吞噬预算的层面。

预置吞吐量、预留 GPU 容量、预热向量索引以及待机微调端点都是按时长计费，而不是按计数器计费。无论流量是否到来，它们都为你提供服务流量的权利而收费。即便周六没人碰某个功能，计费表依然在转动。在办公时间内由 12 个人使用的内部工具，每周 168 小时都在计费。你为了 3 月份发布而准备的资源预置，在 5 月份流量洪峰平息很久之后，依然占据着预留额度。

这就是闲置成本。它之所以野蛮生长，原因并非技术层面，而是组织层面：没有一个单一的角色能看到它，也没有一个单一的角色负责它。

闲置损耗的四种常见形式

闲置成本不是单一的账单条目。它隐藏在至少四个地方，每个地方都有其独特的计费逻辑。

预置吞吐量（Provisioned throughput）。 像 Amazon Bedrock 和 Microsoft Foundry 这样的平台允许你以固定的每小时费率预留固定水平的模型吞吐量。无论你使用多少，你都要为预置单元付费，而更长的承诺期限（一个月、六个月）则通过锁定你来降低费率。Bedrock 的六个月承诺在到期前无法删除；在你手动停止之前，计费将一直持续。从业者的经验法则是，当利用率在大约 50–70% 以上时，预置容量才是划算的。低于这个比例，你就在补贴平台。

预留 GPU 容量（Reserved GPU capacity）。 在专用 GPU 上进行自托管推理是闲置损耗最纯粹的形式。在云端，单个 H100 每小时运行成本为 2–3 美元；一个服务生产流量的推理集群每月支出可能超过 50,000 美元。这些实例在凌晨 3 点的计费与峰值时段完全相同。FinOps 团队报告称，推理集群的平均利用率仅为 22%，在晚上 7 点到次日早上 8 点以及整个周末基本处于闲置状态 —— 但每一小时都在计费。

预热向量索引（Warm vector indexes）。 检索（Retrieval）也有其自身的闲置层。基于 Pod 的向量数据库会持续为分配的容量计费。即使是能将读取缩减至零的无服务器向量数据库也有“预热”层：为了保持命名空间的响应速度，你需要每分钟发送一次心跳查询，每一次都是一次可计费的读取。支撑一个极少使用的 RAG 功能的索引仍必须保持足够的预热度，以便在没有数秒冷启动的情况下回答偶尔的查询。

待机微调端点（Standby fine-tuned endpoints）。 自定义或微调模型通常无法共享通用的按需池。它需要专门的托管，而无论该模型是每天调用一次还是每秒调用一次，托管都会计费。团队为特定功能启动这些端点，结果功能表现不及预期，而端点却一直留存，因为没人确定删除它是否安全。

这四者的共同点是：成本源于预留（reservation），而非请求（request）。而预留很容易创建，也很容易被遗忘。

闲置成本存在的组织缝隙

这是结构性问题所在。三个不同的角色各自掌握着闲置成本拼图的一块，却没人掌握全局。

产品负责采用率。 产品经理（PM）知道有多少人使用该功能、使用频率如何，以及周末的低谷是否属实。但 PM 看到的是使用量仪表盘，而不是账单控制台。对 PM 来说，周末低使用量是关于用户的事实，而不是关于钱的事实。预留对他们来说是不可见的。

基础设施负责预留。 平台或基础设施工程师预置了吞吐量、确定了 GPU 集群规模并配置了索引层级。他们清楚地知道预留了什么。但他们不知道该功能是否成功，不知道他们为之设定规模的发布高峰是否真正出现过，也不知道在政治上缩减规模是否安全。对基础设施团队来说，预留只是某人要求的设置，而且没人要求更改。

财务负责发票。 财务看到的是总额。他们看到 AI 支出上升了。但发票是汇总的 —— 它不会分解为“已预置但已消耗”与“已预置但闲置”。财务无法区分繁忙的功能和被遗弃的预留，因为两者的账单看起来一模一样。

预置与消耗之间的差距就是闲置成本。产品能看到消耗，基础设施能看到预置，财务能看到账单。没人能看到这个差距，因为看到它需要整合来自三个组织、具有三种不同更新节奏且没有共享键（shared key）的数据集。闲置成本之所以被隐藏，并非因为它微不足道，而是因为它掉进了那些各自只能看到一半成本的人员之间的缝隙里。

这就是为什么闲置损耗表现得像个棘轮。预置是一个有明确负责人的刻意行为 —— 有人提交工单，有人批准发布容量。而取消预置是一个没有负责人的判断行为。它需要有人断言这些容量确实不再需要，而这种断言带有风险：如果他们错了，功能性能就会下降，指责是具体的。而无所作为不会招致指责，只会产生费用，而费用是没有名字的。因此，容量上升容易，下降却极其罕见。

使用率是没人在仪表板上标注的指标

解决问题的关键在于将使用率（实际消耗除以预置资源）视为一等指标，并像延迟或错误率一样显著地展示出来。

大多数 AI 可观测性栈追踪请求量、Token 计数、P95 延迟和错误率。这些都是 需求侧 指标。使用率则是 供给与需求 的比例，是让闲置成本可见的唯一数字。一个功能模块可以在预留集群上以 18% 的使用率运行，同时拥有完美的延迟仪表板和完美的错误预算。每个需求侧指标都显示健康，但该功能在每个闲置的小时里都在悄悄亏钱。

使用率还重塑了关于单位经济效益的讨论。对于一个 AI 功能来说，最真实的分母不是总支出，而是每活跃用户成本，而每活跃用户成本对于采用率低的功能来说是残酷的。5,000 美元的月账单分摊到 5,000 名用户身上是每人 1 美元。同样的 5,000 美元分摊到 50 名用户身上则是每人 100 美元 —— 如果这 5,000 美元大部分是资源预留而非实际使用，那么当这 50 名用户周末回家休息时，人均成本几乎不会变动。闲置成本是一个功能的单位经济效益即使在每 Token 成本看起来不错的情况下依然入不敷出的原因。

实际的目标是存在的。FinOps 从业者的目标是在推理负载上实现超过 50% 的 GPU 使用率，在训练负载上则更高。低于这条线，预留模式就是错误的模式 —— 你正在按独占价格支付按需流量。使用率指标不仅揭示了浪费；它还告诉你何时该彻底切换计费模式。

你为发布预留的流量峰值再也不会回来了

一种特定且昂贵的模式值得拥有自己的名字：为发布而预置资源，且从未撤销。

发布时的逻辑是合理的。你预期会有流量激增，你不希望功能在用户面前崩溃，所以你慷慨地预置了资源。高峰如期而至，资源预留扛住了压力，发布圆满成功。然后高峰逐渐消退 —— 正如发布峰值总是那样 —— 回落到仅为峰值一小部分的稳态。而按峰值规模预置的资源却留了下来。

没人去重新审视它，因为重新审视它不是任何人的工作。发布已经结束；发布团队已经转移到下一个项目。预置资源已成为基线的一部分，而基线被认为是正确的，恰恰是因为它们已经存在了一段时间。六个月后，它变成了“该功能一直以来的预置方式”，质疑它感觉就像在质疑一面承重墙。

防御措施是让每一个由发布驱动的资源预留从创建之日起就带有一个明确的审查日期。不是一个模糊的复查意向 —— 而是挂在日历上的负责人和日期，被视为一种承诺。预置工单应该写着：为 3 月发布预置，按预期峰值定型，5 月 1 日根据实际稳态进行审查。这一行字将一个沉默的棘轮转化为一个预定的决策。审查结果仍然可以是“保留它” —— 但现在保留它是一个人做出的选择，而不是一个没人注意到的疏忽。

缩减至零切实可行，但代价是延迟

解决闲置成本的显而易见的方法是停止预置：缩减至零，只为你使用的部分付费。这行之有效，且主流平台现在都支持 —— SageMaker 可以将端点缩减至零，无服务器向量数据库会删除闲置的命名空间，无服务器推理会按需启动。

但缩减至零并非免费。它用闲置成本交换了冷启动延迟，而且这笔交易代价不菲。生产环境中的无服务器 LLM 推理从冷启动到产出第一个 Token 可能需要 40 多秒，而热启动后每 Token 大约只需 30 毫秒 —— 冷热状态之间存在千倍的差距。一个无服务器向量索引在闲置后回答第一个查询可能需要 300–500 毫秒，而不是几十毫秒。

这种权衡对某些工作负载非常划算，但对另一些则是不可接受的。批处理作业、内部工具、开发和测试环境，以及那些极少被调用的长尾模型，几乎总是应该缩减至零 —— 每日报告中 40 秒的冷启动是感知不到的。面向用户的聊天、语音代理和实时编程助手则无法承受；对于它们来说，缩减至零会使每个静默期后的第一次请求变成一次显而易见的糟糕体验。

这个决策是针对每个功能的，且应该是深思熟虑的。中间地带也存在缓解措施 —— 预测性预热（读取历史流量并在已知高峰前预置）、容器和检查点缓存（大幅缩短冷启动时间）、保留单个热副本而其余缩减至零。重点并不是说缩减至零永远是正确的。重点是，对于流量明显有每日和每周节律的功能，“始终预置”绝不应成为未经审视的默认选项。

让这个差距成为某人的指标

闲置成本并非罕见的失败。它是一种计费模式下的必然结果，即这种模式对资源预留收费，却恰好碰上了一个资源预留没有负责人的组织架构。容量被预置时有明确的理由和负责人；它从未被撤销，因为撤销它是一种没人被指派去承担的风险。

三个动作可以弥补这一缝隙。首先，将使用率（实际消耗除以预置资源）与延迟和错误率放在同一个仪表板上，让能够采取行动的人看到这个差距。其次，给每个资源预留，尤其是由发布驱动的资源预留，分配一个明确的负责人和日历上的审查日期，让容量决策到期失效，而不是利滚利。第三，根据每个功能在闲置损耗和冷启动延迟之间的真实权衡来决定是否缩减至零，而不是因为“始终开启”是阻力最小的路径就将其设为默认。

这些都不是困难的工程问题。这是一种纪律，即让一个数字 —— 你预置的资源与你使用的资源之间的差距 —— 在它出现在没有任何名字的季度发票上之前，先带着负责人的名字出现在仪表板上。