你的推理内部结算正在悄悄侵蚀评估纪律

FinOps 团队在一年前推出了 AI 内部计费（Chargeback）。仪表盘非常华丽。每个功能团队都能精确到分地看到上个月的推理账单，平台 PM 的幻灯片展示了 SKU 级别的业务线归因。相比一年前，组织拥有了更多的 AI 功能，但 AI 的质量却变差了。目前还没有人将这两个事实联系起来，但它们其实是同一件事。

用一句话概括这种失败模式：内部计费为推理 Token 定价，却悄无声息地忽略了评估 Token 的定价。因此，组织架构中的每一位 PM 都面临着一个奖励模型升级、惩罚评估规范的激励结构。12 个月后，评估覆盖率在萎缩，而账单却在增长——这与 FinOps 项目最初设想的激励效果完全背道而驰。这并不是仪表盘的漏洞，而是内部计费模型在严格执行其设计逻辑，只是在 AI 领域，源自云成本 FinOps 的设计假设已不再适用。

《2026 年 FinOps 现状调查》报告显示，98% 的从业者目前管理着某种形式的 AI 支出，高于前一年的 63%，而 “AI 成本管理” 是团队计划增加的首要能力。云内部计费的成熟曲线花了十年时间才攀升。而团队正试图将其压缩到 18 个月内，用于一种单位经济效益仍在波动的工作负载，且其衡量标准（Token 支出）与核心价值（每次正确答案的成本）之间的脱节方式，是传统的云计算模拟从未遇到过的。

吞噬评估覆盖率的不对称性

内部计费的工作原理是将支出激励与支出团队对齐。这是云 FinOps 中比较纯粹的想法之一，因为计费单位（CPU 秒、GB/月）也大致是工程师优化的单位。让消耗 CPU 秒的团队付费，团队就会编写更高效的代码。优化梯度和会计梯度指向同一个方向。

在 LLM 工作负载中，这两个梯度发生了分歧。计费单位是 Token。团队应该优化的单位是“单次正确成本（cost per correctness）”——即达到可接受质量的每个任务的 Token 支出。Token 易于计算且在每张发票上清晰可见。而正确性衡量起来成本高昂，需要标注数据，且只有在团队构建并维护了评估体系（eval harness）时才会显现。内部计费只对易于衡量的部分定价，而忽略了衡量成本高昂的部分。

于是，PM 层级的激励机制便如期上演：

• 投入评估：成本是工程师的时间和标注预算，由团队账本预先支付。收益是“我们在发布前发现了一个回归（regression）”——这是一个没人会庆祝的非事件，不会出现在获胜报告的幻灯片中，也不会让发票金额下降。
• 升级到更大的模型：成本是按 Token 支付的美金，可归因，分摊到全年的团队账本中。收益是“功能变得更好了”——这是获胜报告中的一页幻灯片，是面向客户的变化，也是在下次绩效评审时会波动的指标。

一个理性的 PM 在看到这种激励结构后，会选择升级到更大的模型，并推迟评估投入。下一个 PM 也是如此。乘以组织中的每个功能团队，六个月后，评估覆盖率曲线就会下降，而推理曲线则会上扬。内部计费模型正在做 FinOps 一贯做的事情——将支出归因于产生支出的团队——而这正是问题所在。FinOps 想要的行为（效率）与内部计费奖励的行为（容量提升）并不是同一种行为，因为“工程师会根据他们支付的指标进行优化”这一隐含假设，必须通过一个内部计费从未定价的“质量关卡”才能成立。

为什么“单次正确成本”才是仪表盘上应有的数字

FinOps 社区已开始讨论将“按功能成本归因”作为超越“按团队归因”的下一个成熟阶段。这固然正确，但还不够。按功能的成本归因仍然只衡量了“单次正确成本”的分子，而没有分母。一个推理账单增长了 40% 的功能，可能是使用量增长了 40% 且质量稳定，也可能是使用量持平但质量悄悄下降——在账单条目上，这两者表现完全一致，但背后的故事却截然不同。

真实的单位应该是“每个正确任务的成本”，这需要典型的内部计费仪表盘所不具备的三样东西：

• 一个对生产流量进行评分的实时评估集，而不仅仅是每晚的批处理。
• 一个根据当前用户意图（而非上季度的黄金标准集）计算的正确率。
• 一张图表，横轴为时间，纵轴为“每个完成任务所花费的美元”，并将评估覆盖率百分比叠加在同一轴线上，这样 PM 在查看其中一个指标时就无法忽视另一个。

当这张图表存在时，成本审查中的对话就会发生改变。对话不再是“功能 X 本月支出增加了，我们能把它移到更便宜的层级吗”，而是变成“功能 X 的单次正确任务成本上升了，同时其评估覆盖率下降了，我们无法判断支出增长是因为使用量增加，还是因为模型现在的错误率更高了”。这是完全不同的对话，也正是内部计费最初应该促成的对话。

团队之所以没有这张图表，并不是因为计算困难。而是因为比例中的“评估投入”一侧作为纯成本记录在功能团队的账本上，而“推理”一侧则同时作为成本和归因记录在同一账本上。不对称的账本导致了不对称的行为。解决办法不是惩罚 PM，而是让账本变得对称。

四种重新平衡账目的机制

一个既想激励质量又想控制成本的分摊（Chargeback）模型，必须将评估覆盖率（eval coverage）视为一种非管理费用（overhead）的指标。这些机制并不罕见，但它们要求 FinOps 团队放弃“推理账单是唯一值得归因的数字”这一假设。

利用评估额度抵销推理账单。 对评估不足的功能收取比评估充分的功能更高的每 Token 费率。这种溢价不是一种税收——它是评估不足的功能所携带的更高运营风险的体现，就像没有监控的服务具有更高的可靠性风险一样。在生产权重分布上拥有 80% 评估覆盖率的团队支付基础费率。而只有 20% 覆盖率的团队则需要支付倍数费率。这个倍数是可收回的：投资评估，就能获得额度。这使得评估投资从沉没成本转变为产品经理在规划会议上可以辩护的预算项目，因为它出现在首席财务官（CFO）阅读的同一个仪表板上。

平台资助的评估工具补贴。 评估最初出现在功能团队账目上的原因是，其他人的账目中没有它的位置。如果平台团队拥有评估框架、标注流水线、追踪捕获基础设施以及评测模型（judge-model）调用，并将这些成本吸收进平台自身的预算中，就能将每个团队的构建成本转化为共享的基础设施成本。这正是十年前在可观测性领域奏效的做法：当每个团队都必须建立自己的指标流水线时，可观测性是零散的；当平台团队支付指标流水线费用时，可观测性就成了默认选项。现在的评估（Eval）正处于 2014 年可观测性所处的发展阶段。

评估新鲜度的 SLO，与成本显示在同一个仪表板上。 “单次正确成本”这个数字的真实性取决于其背后的评估集（eval set）。评估集会发生漂移。一个六个月前的黄金集（gold set）是在针对一个已经不复存在的流程分布进行校准。将 SLO 定义为“评估集相对于生产流量偏移的新鲜度”——即处于评估集分布范围内的近期流量百分比——可以将评估新鲜度转变为一个带有告警阈值的跟踪指标。当违反 SLO 时，分摊率会向上浮动，直到评估集更新。产品经理在同一个地方、同一次评审中，能在看到成本数字的同时看到新鲜度数字。

带有评估指令的季度“单次正确成本”评审。 目前的对话听起来像是“你的功能太贵了，能不能降级到更便宜的模型”，而它应该听起来像是“你的单次正确任务成本增加了 30%——在讨论模型降级之前，你用来衡量降级的评估覆盖率是多少？因为在能够对切换进行评分之前，我们不会批准模型切换。”讨论更便宜的模型层级是正确且必要的；但如果没有到位的评估来捕捉回归，这种讨论也最有可能导致功能倒退。强制先进行评估投资对话，并附带预算，将模型切换挂钩在质量衡量之后。

这些机制在概念上都不是全新的。云端 FinOps 对每一项都有类似的对应——预留容量折扣、平台拥有的共享服务、可观测性 SLO、季度架构评审。这项工作不是发明。这项工作是认识到 AI 工作负载具有云工作负载所没有的质量维度，并且分摊模型必须在这个维度上产生价格，否则组织将继续围绕它进行盲目优化。

分摊模型体现了组织的真实价值观

在这些机制背后隐藏着一个更隐蔽的问题，即分摊模型反映了组织如何看待 AI。一个只对推理定价的分摊模型，隐含地表达了这样一种观点：推理是 AI 功能的主要成本。从金钱的角度来看，这可能是真的。但在风险价值（value-at-risk）方面，这很少是真的。模型回归对客户可见的影响范围——例如发布了一个自信的错误答案、在应该采取行动时拒绝、或者对陈旧状态进行工具调用——并不受限于推理 Token 账单。它受限于与用户的信任契约，而修复信任契约的成本比支付推理账单要高出好几个数量级。

一个只对推理定价的分摊模型每季度都在告诉每位产品经理，组织认为账单就是风险。领导层的全员大会可以随口说质量是头等大事。但仪表板才是组织真实的价值观，它以数字的形式呈现，每位产品经理在每次规划会议前都会阅读它。如果该仪表板上的评估列显示“覆盖率：未跟踪”，而推理列显示“支出：$48,213.41”，那么组织传达优先级的方式比任何全员大会都要清晰，且这种影响是无法消除的。

这里有一个很有用的古德哈特定律（Goodhart's Law）视角。当一个指标变成目标时，它就不再是一个好指标了——而作为分摊目标的推理账单，已经不再是衡量功能健康状况的好指标。它现在成了一个优化目标，组织将针对它进行优化，方式既有诚实的（团队构建 Prompt 缓存），也有扭曲的（团队推迟评估）。云指标文献中趋于一致的解决方法是同时测量多个特征，因为操纵五个数字比操纵一个数字要困难得多。这种修复方案的 AI 版本是将评估覆盖率、评估新鲜度和单次正确任务成本数字放在与推理账单相同的仪表板上，具有相同的显著性，并拒绝平台产品经理发布仅显示账单的分摊仪表板。

证明内部结算机制价值的年终回顾

从现在起十二个月后，FinOps 团队将对内部结算计划（Chargeback Program）进行年终回顾。可能会有两种结果。第一种情况是，回顾发现推理支出归属明确，评估不足的功能支付了溢价，从而推动了整个组织的评估（Eval）覆盖率提升；大多数功能的“单次正确任务成本”曲线已趋于平缓或下降；内部结算模型已成为 AI 质量投入和成本规约的中流砥柱。仪表盘讲述了一个 CFO 和 AI 负责人双双认可的故事，因为那是同一个故事。

另一种情况是，回顾发现推理支出归属明确，组织在能降级的地方降了级，在必须升级的地方升了级，账单大致符合预期，但 AI 功能的用户感知质量却以一种无人能定位的方式退化了，因为没有团队资助过本能捕捉到这一点的评估（Eval）。仪表盘是准确的。功能变差了。内部结算计划达成了数字，却错失了目的。

这两种结果的区别在于，内部结算模型是将评估 Token（Eval Token）与推理 Token 共同定价，还是仅为推理 Token 定价。这是 FinOps 团队本季度正在做出的设计选择——体现在代码中，体现在仪表盘模式中，也体现在某个必须有人为一个尚未有清晰单位的指标而据理力争的会议上。获胜的团队是那些在年终回顾迫使他们这样做之前，就将“评估”列放入仪表盘的团队。而今天没有这样做的人，其实是选择了在下一次年终回顾时才发现：即便预算完全达标、内部结算模型运行完美，组织的 AI 功能产品组合也已在悄悄退化。