一个平台团队签署了一份为期数个季度的预留吞吐量合约。在承诺容量内按固定的 token 费率计费，超过上限的部分则按更高的超额费率计费。财务部门根据六个月的历史流量对消耗进行了建模，而这些流量很少触及上限。合约中规定“溢出”是指超过承诺上限的每分钟字节数，基于这个定义，这笔交易看起来很稳健。
六周后，在流量形态、路由配置和产品界面均未改变的情况下，账单飙升了 2.4 倍。供应商在季度中期悄悄修改了计量定义。现在，“溢出”还包括自动路由器发送到高于预留层级的模型请求——因此，即使总吞吐量完全在承诺范围内，一次在复杂提示词上选择 Sonnet 的操作也会被计入超额桶中。原本按预留费率结算的 30% 流量，现在改按超额费率计费。财务部门通过仪表板追踪了三周的突发增长，最后才有人读到季度中期的定价补充协议，并在脚注中发现了这一重新定义。
合约并未被违反。但计价所使用的单位被重新定义了。
预留容量交易是基于计量定义的衍生品
当你签署预留吞吐量合约时——无论是 Azure Foundry PTU、Bedrock 预置吞吐量、OpenAI 企业承诺，还是 Anthropic 的定制合约——你买的并不是固定金额的算力。你买的是供应商定义的单位价格。由于合约中的措辞没有改变，这个单位看起来很稳定。“每分钟 Token 数”在 3 月和 9 月读起来是一样的。
但这个单位在操作上是由供应商运行的计量管道定义的。该管道决定了哪些请求落入哪个桶中，哪个模型层级算作预留层级，长上下文请求是否要乘以 token 权重系数，通过“优先”路径路由的请求是否按标准费率的 1.75 倍计费，或者溢出到标准部署是否回退到标准 token 计费。Azure 明确记录了优先层级比标准层级溢价 75%，而 Flex 层级则有 50% 的折扣；同一个词“token”，根据请求采取的路由路径，映射到三个不同的实际价格。
计量管道是供应商的。其中的定义也是供应商的。在大多数企业条款中，修改这些定义的权利也属于供应商——仅受通知期（通常为 30 天）和客户终止合同权利的限制。如果预留容量合约的计量定义是被引用而非锁定的，那么它就是一份基于交易对手方所控制数字的衍生品。那不是合同，那是一个头寸。
偏差发生在两个团队停止沟通的地方
这种失败模式并不是恶意的调价，而是负责账单建模的团队与负责流量运行的团队之间，对单位定义产生了无声的漂移。
财务部门根据历史 token 吞吐量对消耗率进行建模，因为历史发票就是这么显示的。工程部门运行自动路由器，因为路由器能在可行时选择更便宜的模型，在必要时选择更强大的模型，这是正确的产品决策。两个团队都没有掌握“路由器的决策”与“请求落入哪个结算桶”之间的映射关系。这种映射存在于供应商的计量层中，路由分布的转变——例如，提示词工程的更改触发了更多复杂提示词，或者一个新功能要求 JSON 模式响应导致路由器转向 Sonnet——会立即在结算桶之间重新分配流量，而不会在任何一个团队观察的仪表板上体现出来。
团队花了三周时间寻找不存在的代码变更。账单的形式改变了，流量的形态却没变。唯一变动的是供应商在两者之间应用的计算函数。
在合约中锁定计量定义，而非引用政策
第一道防线是合约层面的。如今大多数企业 AI 合约都引用供应商的定价页面或操作指南，而不是将计量定义嵌入合约正文。那个被引用的页面是供应商可以按照自己的节奏修改的单方面文件。30 天的通知期无法保护为期数个季度的承诺——这仅意味着团队在重新定义生效前 30 天得知消息，而此时唯一的补救措施要么是付钱，要么是提前终止合约并放弃承诺本应带来的折扣。
保护措施是将计量定义列为合同的实质性条款。具体包括：
- 将“溢出”定义为针对特定单位的数值阈值，并将该单位的定义嵌入合约中，而非引用外部文档。
- 通过稳定的标识符明确哪些模型层级包含在预留桶中，哪些不包含，而不是引用政策。
- 规定计量定义的变更需要签订合同补充协议，而不是发布补充通告。
- 包含价格保护条款，在承诺期限内保持计量定义不变，即使供应商修改了其公开政策。
这比谈判费率更难。供应商会抵制，因为计量定义正是他们想要保留的杠杆。能在这一点上谈成的交易，要么来自大客户，要么来自争夺客户业务的二线供应商。如果供应商不愿在计量定义上让步，这个信号说明该交易潜藏着未被建模的尾部风险。
每日核对供应商的分桶归因
第二道防线是操作层面的，而且构建成本为零。每个向你收费的 LLM 供应商都会在发票或使用情况导出报告中告诉你，每个请求落在了哪个分桶（bucket）中。Bedrock 的成本和使用报告（Cost and Usage Reports）将预置（provisioned）与按需（on-demand）进行了区分。Azure Foundry 将 PTU 小时数与标准部署的 Token 支出分开导出，溢出请求按标准费率计费，并显示为独立的细目。大多数供应商已采用的 FOCUS 1.2 规范包含一个 InvoiceID 列，将每一行直接链接到发票，并新增了四个用于 Token 和额度核算的列。
每日核对任务会提取两样东西：你的网关已经记录的客户端 Token 账目，以及来自使用情况导出的供应商分桶归因。它通过请求 ID 将两者关联，计算每个分桶中的请求比例，并每天写入一行记录。它监控的不是绝对支出，而是比例的变化。一旦落入超额分桶（overage bucket）的请求比例超出某个范围——例如，高于过去 30 天均值的两个标准差——该任务就会触发告警。
运行这种核对的团队可以在反映该变化的第一个账单周期后的 24 小时内发现“重新计价（redenomination）”。而没有运行核对的团队则要等到季度末财务结账时才会发现。核对并不能阻止调价，它只是将发现窗口期从几周缩短到了几小时。在这个窗口期内，团队可以重新谈判、限制受影响的路由，或缩小自动路由器进入更昂贵层级的权限。
构建按层级消耗的仪表盘，而非总支出仪表盘
第三道防线是可见性。大多数 LLM 成本仪表盘都汇总为总支出或单个模型支出，这两者都掩盖了分桶归因。团队可以看到整体成本正在上升，但仪表盘不会告诉他们这种上升是由于流量增加、提示词（prompt）变贵、路由决策变贵，还是供应商的计量方式发生了变化。
能够捕捉到计量偏差的仪表盘按层级和路由决策（而非模型）来拆分账单：
- 落在每个计费分桶（预留、标准、优先级、批处理）中的请求比例。
- 对于每个分桶，计算每个 Token 的边际成本和当前的账单归因。
- 每天每个分桶中，客户端 Token 计数与供应商发票 Token 计数之间的差异（diff）。
- 一个独立的面板，展示自动路由器在不同模型层级间的分布，并配有迷你图（sparkline）以显示分布情况如何周环比变化。
当账单上升而路由器的分布迷你图没有变动时，变化的源头就在供应商侧。当路由器分布发生了偏移但每 Token 费率稳定时，源头则在工程侧。仪表盘将这两种原因分开，这样团队的第一反应就不再总是“有人发了一个糟糕的提示词”。
定期审查供应商的计量策略
第四道防线是流程。供应商的公开定价和计量策略是一个动态变化的文件。大多数团队只在签署合同时阅读它，之后便再也不看。仅 Azure Foundry 的预置吞吐量文档变更日志，就在 2025 年和 2026 年大约每季度发布一次实质性更新——包括新的层级定义、溢出行为的变更、预留可移植性规则、模型路由语义等。Bedrock 的文档也以类似的频率演进。这些更新大都不会触发发给企业客户的电子邮件，因为它们都不构成合同变更。它们仅仅构成了计量方式的变更。
设立一个固定的日历审查机制（每季度一次是合理的），重新阅读供应商的计量策略，并将其与合同签署时生效的版本进行比对，就能在供应商记录“重新计价”的瞬间捕捉到它，而不是等到账单寄达。对于熟悉合同的人来说，这项复审工作只需 30 分钟。这是 FinOps 职能所能购买的最便宜的保险，但几乎没有团队会去执行。
架构层面的认知
预留容量合约感觉像是一种对冲：你用灵活性换取固定价格。这种心理模型是正确的，但价格是针对某个单位固定的，而这个单位在操作上是由交易对手定义的。供应商可以在不违反你签署的任何字面合同条款的情况下更改单位。从供应商的角度来看，重新定义“溢出（overflow）”的价格附录是对其一直控制的定义进行的操作性优化。而从你的角度来看，这是对你认为已经锁定的容量进行的单方面重新定价。
能够在这种失效中幸存的团队，会将计量定义视为合同的核心组成部分，在客户端账目与供应商分桶归因之间进行每日核对，构建按分桶和路由决策而非仅按模型分解支出的仪表盘，并按日历周期审查供应商的计量策略，而不是等待账单给他们带来惊喜。这些防御措施在技术上都不复杂。复杂之处在于认识到：单位即合同，而合同的持久性取决于团队对单位的掌控力。
那些锁定了费率但没锁定计量定义的团队，得到了他们谈好的价格稳定性，只是这种稳定性是以一种供应商可以随意“重新计价”的货币表现出来的。隔壁的团队则同时锁定了两者，运行着核对机制，并每周一查看按层级划分的仪表盘。当供应商的价格附录寄到收件箱时，他们在当天就会阅读，并在几小时内建模评估影响，在下一个账单周期结束前与客户经理进行沟通。同样的合同，同样的供应商，同样的模型——结果却迥然不同——因为其中一个团队理解预留容量交易是基于计量定义的衍生品，而另一个团队则认为它仅仅是一个价格。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
