当供应商重新定义 Bucket 时，那份让你溢出流量成本暴增的预留容量合同

一个平台团队签署了一份为期数个季度的预留吞吐量合约。在承诺容量内按固定的 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 天得知消息，而此时唯一的补救措施要么是付钱，要么是提前终止合约并放弃承诺本应带来的折扣。

保护措施是将计量定义列为合同的实质性条款。具体包括：

• 将“溢出”定义为针对特定单位的数值阈值，并将该单位的定义嵌入合约中，而非引用外部文档。
• 通过稳定的标识符明确哪些模型层级包含在预留桶中，哪些不包含，而不是引用政策。
• 规定计量定义的变更需要签订合同补充协议，而不是发布补充通告。
• 包含价格保护条款，在承诺期限内保持计量定义不变，即使供应商修改了其公开政策。

加载中…