Token 预留容量：被人们忽略的、尚未从云时代迁移过来的预留实例决策

大多数团队购买推理资源的方式，就像他们的前辈在 2010 年购买 EC2 时一样：全部按需（on-demand），按 token 计费，且在两个维度上同时让人措手不及。账单是一个意外。速率限制（rate limit）是另一个——在发布的中途出现的 429 错误，就在你从未预留的按需资源池被其他同样选择支付零售价的人争抢时。然后有人打开定价页面，发现供应商一直都在悄悄销售预留容量：预置吞吐量（provisioned throughput）、承诺使用折扣（committed-use discounts）、按单位小时计费而不是按百万 token 计费。云计算行业花了十年时间才内化的预留实例决策，现在就摆在 token 面前，但几乎没有人移植这一套玩法。

这种现象的原因并非无知。而是你为计算资源学习的预留实例数学模型无法直接迁移，而它失效的方式恰恰是在惩罚那种天真的承诺。预留一个 EC2 实例是在赌你一年后仍然需要那种实例类型。预留一块 token 吞吐量则是在赌你一年后仍然需要 那个模型——而模型的生命周期是以月计算的，而不是以十年计算。承诺的结构很熟悉，但你所承诺的对象却并非如此。

这篇文章讨论的是决策，而非供应商。虽然 Azure 的预置吞吐量单位（PTU）、AWS Bedrock 的预置吞吐量以及其他供应商提供的承诺使用层级的机制各不相同，但其形式大体一致：你牺牲灵活性，换取更低的单价和有保障的容量底线。有趣的问题在于，经典的“预留 vs 按需”分析中，哪些部分在迁移到 token 时依然成立，哪些部分发生了反转，以及在做出明智而非昂贵的承诺之前，你需要建立什么样的 FinOps 能力。

你究竟在买什么

首先从计费模型开始，因为这是最容易被误读的地方。按需推理是按消耗量计费的：你为每个输入和输出 token 付费，完全闲置的一小时不产生任何费用。预留容量则相反。你购买固定数量的吞吐量单位——Azure 称之为 PTU，Bedrock 称之为模型单位（model units）——无论是否有请求流过，你都按小时付费。Azure 自己的文档说得很直白：“无论实际利用率如何，你都要为部署的完整 PTU 数量付费”，且预置部署“无法暂停。只有在删除部署时才会停止计费。”

这一句话重新定义了整个决策。在按需模式下，你的成本随流量而动。在预留模式下，你的成本随 预留量 而动，而你的任务是让这些预留资源保持忙碌。只有当你购买的容量确实在运作时，单位经济效益才成立。这就是为推理资源重申的预留实例契约：你获得了更低的 token 实际单价和容量保证，但你将可变成本转化为了固定成本，而固定成本只有在利用率高时才是划算的。

这种折扣是真实的，且在大规模应用时值得投入。在持续负载下，预置层级的价格通常比按需低 20–40%，如果在其上叠加期限预留（Azure 的一个月或一年承诺，Bedrock 的一个月或六个月期限），实际费率会进一步降低，年度承诺的价格大约比月度定价低 30%。不过，入门门槛并不低。Azure 的全球（Global）和数据区（Data Zone）预置部署起步为 15 个 PTU；区域部署则需要 25 到 50 个。Bedrock 的预置吞吐量每小时每个模型单位的费用在几十到几百美元不等。这些不是你为业余项目随便开启的开关。它们是为已经明确的工作负载而准备的承诺。

盈亏平衡点比你的直觉预估更高

每个人都想要一个明确的数字，所以这里有一个诚实的版本：盈亏平衡点（break-even）大约在你预留容量的 60–80% 持续利用率之间。低于这个水平，即使按需的 token 单价更高，它也更便宜，因为你不需要为闲置单位付费。高于这个水平，预留模式就开始胜出，并且随着你将利用率推向上限，优势会越来越大。

将其转化为具体的量级取决于模型，但门槛很高。对于像 GPT-4o 这样的主流模型，公开的盈亏平衡估算大约在每月 1.5 亿到 2 亿 token 左右，超过这个数，PTU 部署才优于按量计费。这个数字让大多数团队望而却步：如果你的工作负载每月还没有达到数亿个 token，且没有一个 平坦 的曲线，那么这种承诺就是亏损的。而在那句话中，“平坦”这个词承载了很多信息。

利用率的计算在特定方面非常无情。预留容量是按 24/7 的小时数计费的，但几乎没有产品能产生 24/7 的流量。一个具有工作日工作时间负载模式的 B2B 工具，每周大约有三分之二的时间是闲置的——夜晚、周末、节假日。如果你根据峰值小时来确定预留规模，那么在全天候计费下的 平均 利用率可能只有 25%，你其实是在为容量保证支付高于零售价的溢价。这就是为什么适合预留的候选对象是那些需求真正平稳的工作负载：全球规模的稳定工作日聊天产品、并发会话数可预测的语音助手、以及你可以安排在谷峰期运行的批处理流水线。不太适合的候选对象则是波动的内部工具、实验性流量，以及任何负载图表看起来像连绵山脉的应用。

由此得出的推论是一种策略，而非单纯的购买：预留保底，按需爆发（reserve the floor, burst on-demand）。 根据你确信总会消耗的基准线（流量图表的平坦底部）来确定预留规模，并让高峰流量溢出到按需资源或更便宜的备用模型。Azure 和 Bedrock 都会对超出预留单位的使用部分按标准的每小时或每 token 费率计费，因此混合部署并非投机取巧，而是设计初衷。你在可预测的基准上获得了折扣，同时在需求真正多变的地方保留了灵活性。

加载中…