绑定到你不再符合条件的定价层级的成本预测

使用曲线几乎没变。账单却上涨了 38%。

这是某中型金融科技公司的财务主管在季度第一个周一收到的邮件。三个月前，工程部门重新谈判了他们的 LLM 推理合同，通过承诺最低使用量，从谈判后的单价中又削减了相当大的一部分。财务模型将新的单价纳入了财年预测。没有人留意到定价表中的脚注：如果月度使用量连续三个月低于底线，折扣将失效。4 月至 5 月的季节性流量下降正好触发了这一条款。供应商将账户重新分档回原价。工程部门没有收到任何通知，因为通知发到了采购部门的收件箱，而自合同签署以来，那里就没人读过邮件。

预测并没有算错产品会消耗多少 token。预测错的是这些 token 的成本，因为它假设了一个该账户不再符合资格的价格分档。这种区别——“我们预测错了使用量”与“我们准确预测了使用量，但该单价已不再适用于我们”——是大多数财务模型默默搞反的地方。单价在电子表格中被视为常量，而实际上它是账户的一个有状态属性，取决于账户最近的行为。

供应商定价分档是运行时状态，而非合同常量

当合同从采购部门移交给财务部门时，谈判达成的单价会被誊写到电子表格的一个单元格中。从那时起，它表现得就像一个常量。预测将预期的 token 数乘以该常量，预算根据得出的数字进行设定，而差异报告则将实际支出与假设该常量依然成立的基准进行比较。

但谈判达成的单价并不是常量。它是一个函数的稳态值，其输入包括你过去 12 个月的支出、月度承诺完成情况、你是否处于数量阶梯折扣区间内，在某些合同中，还包括你是否在嵌入（embeddings）、推理和批处理中达到了特定的产品组合。单价是供应商针对你的账户运行的一个小型状态机的输出。这个状态机具有你可以在无人告知的情况下跨越的转换条件，因为这些转换是在你的使用量达到你几个月前在文档中设定并早已不再查看的阈值时触发的。

如果你编写的生产代码从远程服务读取配置值，且在启动后从未重新读取，你会称之为 Bug。成本预测正是这么做的。它在签署合同时读取一次单价，然后将该值视为固定值，直到下一次合同谈判。与此同时，供应商的计费系统在每个计费周期评估资格谓词（eligibility predicates），并输出计算出的价格。预测与现实注定会在谓词触发发生变化的那一刻产生分歧——而这种情况必然会发生，因为输入包括你自己的使用量，而你自己的使用量并不是持平的。

隐藏在定价表脚注中的降级条款

阅读一份典型的 AI 供应商企业定价表，降级条款几乎从不在主要条款清单中。它们位于定义分档结构的附录中，通常以一段开头为“客户对 [分档名称] 单价的资格应予维持，只要……”的话开始，后接一系列条件。这些条件通常写成一个底线——最低月度 token 数、最低月度支出、最低活跃工作负载数。接着会有一个子条款描述未达到底线时会发生什么：重新分档到下一级较低的分档，有时有一两个月的宽限期，有时则没有。

脚注通常会规定重新分档是自动的，供应商将提供合理的通知，且对于降级前的折扣期不欠任何退款或差额补缴。最后一点很重要。一旦你被重新分档，想要回到折扣价通常需要你在新的追溯窗口内重新获得资格——连续三到六个月高于底线——而不仅仅是一个月的恢复。因此，账单的跳升不是单月的峰值。它是一个会持续存在的新基准，直到你能证明持续的恢复，而在你正试图针对错误的预测进行规划的季度里，你无法证明持续的恢复。

这里的结构性问题在于，在采购期间阅读此脚注的人并不是拥有预测的人。采购人员阅读它是为了在谈判期间划掉风险。他们成功地删除了一些最糟糕的条款，接受了那些看起来可以管理的条款，然后签了字。财务人员阅读了采购人员为他们总结的条款清单。工程人员阅读了采购人员要求他们验证的任何内容——通常是速率限制表，而不是使用量底线表。到合同生效时，记录降级条件的唯一地方是合同库中的 PDF，而每月查阅它的唯一系统是供应商的计费引擎。

分层感知预测模型关注的是跌破保底额的概率，而不是保底额本身

预测层面的修复方案并非是在 Excel 表格中每当单价变动时就去更新它。真正的修复方案是停止将单价视为一个死数字，而是将其视为相对于合同阈值的预期用量的函数。

这一方案的最小可行版本是在每个周期生成两个数字：预期 Token 数量，以及该数量低于合同保底额（floor）的概率。预期成本随后变为一个分段函数——当高于保底额时，按折扣单价乘以用量；当低于保底额时，按原价单价乘以用量。预测应该报告的是这两种情况的概率加权混合值，而不是基于其中某一种情况计算出的单一值点估计。

对于季节性强的产品，跌破保底额的概率在一年中差异巨大。零售相关的业务负载在 11 月至 12 月会远超保底额，而在 2 月至 3 月则会跌破保底额。采用每周发布节奏的消费级产品会在发布日出现峰值，并在周中回落。具有美国办公时间特征的 B2B 业务负载在重大节日以及圣诞节到元旦之间的淡季会下降。这些情况中的每一种在每月都有不同的跌破保底额概率，而如果预测模型只是将它们平均化，就会产生一个足够窄的置信区间，让财务部门误以为折扣费率是结构性的，而实际上它是有条件的。

接下来的工作是在预测中增加一行“层级转换成本”：即在降级发生的月份会解锁多少额外支出。这一行能让任何阅读预测报告的人直观地看到问题，因为它是一个与特定风险挂钩的具体数值。如果没有这一行，降级情景就会被埋没在更宽的误差线中，永远不会在预算审查中被讨论。

监控阈值，而非绝对支出

能捕获这类问题的用量监控告警，可能并不是你的 AI 基础设施团队现有的那种。团队通常设置的是“月度支出超出计划 X%”的告警。这种告警只有在降级已经发生后才会触发，因为正是降级导致了支出超出计划。到那时，除了接受更高的费率外，已经无能为力了。

真正有帮助的告警应针对先行指标：在判定窗口的第一个月，月度 Token 消耗量低于合同保底额。这应该是一个基于租户或基于产品的告警，由负责推动账户超过阈值的业务负载的团队拥有。该信号是明确的：“在你的折扣费率面临风险前你有一个月的时间，在它失效前你有两个月的时间。”应对措施要么是在窗口关闭前加速符合条件的业务负载进入合同，要么是将即将发生的层级变动告知财务，以便在账单到达前调整预测。

与阈值挂钩的告警必须以人类可读的形式记录在某处。合同库不是个好地方，因为没人会根据 PDF 文件来运行告警。正确的地方应该是与速率限制（rate limits）和 SLO 相同的单一事实源：供应商账户的服务目录条目，将合同的结构化参数（保底额、窗口期、转换价格）作为监控系统读取的字段。当合同续约时，目录条目随之更改，告警会自动调整。当团队成员为了排查成本问题检查条目时，合同条件就直接显示在速率限制和延迟目标旁边，这正是它们所属的地方。

合同结构：棘轮机制、宽限期和季度审查

合同层面的修复方案是在下次续约时增加一个降级棘轮（downgrade ratchet）。棘轮是一种条款，即使跌破了保底额，也能在特定的宽限期内（通常是一个或两个季度）防止层级自动调整。供应商并不喜欢这个条款，因为它将风险转嫁给了他们，但这是企业级合同的标配要求，通常可以用来交换略高一点的保底额或更长的初始期限。这种交换是合理的。你获得了应对季节性和突发事件导致用量下降的缓冲，供应商则获得了稍微更强的承诺。

下一个要求是增加通知条款，指名你方的一个特定角色（而不仅仅是“客户”）在即将降级前 30 天接收预警。该角色应与职能挂钩，而非个人：应是“平台工程总监”而不是 “Jane Smith”。供应商的客户成功职能部门通常无需上报即可满足这一要求，因为在续约时失去你的业务之前，给你时间纠偏符合他们的利益。

闭环的采购端实践是由财务和工程团队共同负责的季度合同审查。议程很短：阅读过去 12 个月的用量曲线，将其与合同的保底额和上限进行比较，识别下一季度任何可能的层级转换，并据此调整预测。会议很枯燥，但这正是目的所在。合同是稳定的，曲线大多是可预测的，每 90 天进行一次 15 分钟的审查，可以捕捉到那些原本只能在首席财务官询问 38% 偏差的邮件中才会发现的慢性问题。

将合同视为生产基础设施

领导层的思维重塑是，采购合同是一项生产基础设施。它不仅仅是在交易完成后归档的一次性法律文件。它是一个配置文档，其状态驱动着利润表上的成本项，其脚注是你必须监控的 SLO，其续约周期是你必须规划的部署。那些以这种方式对待合同的人，在应对季节性波动时不会感到意外。而那些将其视为静态电子表格输入的人，则会不断地被账单“偷袭”——尽管这些账单在他们技术上同意的条款下是准确无误的。

在实践中，这意味着合同在工程侧也有一个负责人——而不仅仅是在采购侧——并且该负责人是签署成本预测的人。预测本身编码的是合同的状态机，而不是其稳态值。监控栈针对合同阈值而非产生的支出进行告警。续约日程表驱动季度审查，参会者包括负责工作负载的人，而不仅仅是负责预算项的人。这一切都不是什么英雄主义的工程壮举。这是成本工程领域的“配置即代码”实践，将带有部署计划的配置文件视为代码，大多数团队已经在处理其他生产状态时这样做过了。合同也是同类对象。是时候像治理其他生产对象一样来治理它了。