预置吞吐量与容量承诺

两种工具，习惯性地被混为一谈。

"我们要做个承诺换个更好的价"这句话，把两份失效方式完全不同的合同压成了一份。在建任何模型之前先把它们分开，因为一份是容量预留，另一份是用量折扣，而只有前者会改变你的延迟。

• 预置容量为你预留专用的服务吞吐：Azure OpenAI 卖 Provisioned Throughput Units，AWS Bedrock 按一个月与六个月期限卖 Provisioned Throughput，Google Vertex AI 卖 Generative AI Scale Units。不管你用不用，这份预留你都得付。它是一次以吞吐单位计价的机器租赁，而这些单位是按模型定义的，其定义方式让跨厂商比较变得相当困难。
• 承诺消费是"承诺在一个期限内花掉某个金额"换来的折扣。它不预留任何东西，不改变你的限流额度，也不会把你的 p99 改善哪怕一毫秒。它是一件采购工具，而它的风险是消费不足，不是利用率不足。
• 它们的失效方式不同，所以要分开建模。预置容量用不满，是持续而无声地在浪费钱。承诺消费没花够，通常只在结算时集中浮现一次，表现为一张补差额的账单。前者是日常运营中的渗漏，后者是一次预测失误。
• 只有其中一件在事故的关键路径上。当共享池被打满时，预置容量是你的请求仍然能完成的原因。一份消费承诺是合同里的一行字，没人能呼它。

打平点是一个利用率数字，而它只是一次除法。

预留容量按时间计价；按需按令牌计价。所以这个比较不是"哪个费率更低"，而是"在什么利用率下，每小时的固定成本等于这些令牌按需要花的钱"。在任何人给你报一个百分比之前，先用你自己的令牌量把它算一遍。

• 经验法则是折扣的补数。如果预留容量在满载利用下被报为低于按需 30%，那你的打平点就是 70% 的持续利用率。四折优惠对应 60%。厂商目前公布的折扣大致落在这个带内、随期限长短而变，所以你的打平点住在 60–75% 这个区间的某处——对任何交互式负载来说这都是个苛刻的数字。
• 利用率指的是"对这份预留的、跨整个合约期的"。不是峰值，不是工作时间。如果你的流量一天跑十二小时、夜里归零，那么在你还没犯下任何其它错误之前，天花板就是 50%——而在那十二小时内做多少优化都补不回来。
• 单位是吞吐，所以输入和输出不能互换。预留容量是按某个假定的输入／输出比与上下文长度、以每分钟令牌数来定容量的。带着长 prefill、短补全的智能体负载，消耗一份预留的方式与聊天完全不同；而一份按聊天形态假设定下的预留，会在远低于标称数字的令牌量上被耗尽。
• 按"每个完成任务的成本"来算，不按每令牌。一份让你能把更多工作路由给更小模型的预留会同时改变分子和分母——能在这种改变下存活的指标，是单位经济性里的那个。
• 缓存会把打平点推向不利于预留的方向。提示词缓存往往是更大、也更可逆的那笔节省，而它削减的恰恰是你正打算去预留的那部分令牌量。先做它，再定容量。按未缓存的流量去定预留，正是团队们如何为自己即将停止做的工作买下容量的——见上下文缓存经济学。

智能体流量是最不适合预留的那种形态之一。

预留容量奖励平坦、可预测、被刻画清楚的负载。而智能体工作负载的每一项结构性特征都在把它往反方向推，而且它们是相乘而非相互抵消的。

• 一次用户操作会扇出成数量不可预测的模型调用。一个任务可能三步，也可能三十步，取决于工具返回了什么。因此你的负载并不是以任何稳定方式作为用户数的函数——而那正是容量规划通常所依赖的那条假设。
• 任务内部的令牌量呈超线性增长。每一步都会把累积的对话记录重发一遍，所以一个长任务的代价随步数增长的方式更接近平方而非线性——就是智能体成本控制里的那套算术。任务平均难度的一点点上升，就是吞吐需求的一大截上升。
• 峰值是相关的，不是独立的。批处理作业、工作时间负载与重试风暴会一起到来。决定你必须预留多少的那个峰均比，由相关的最坏情形设定；而决定它是否划算的那个利用率，由均值设定。
• 重试是你并不打算购买的需求。一个降级的上游会在容量最紧的那一刻产生一阵重试——正是在那里，与限流与厂商容量的相互作用，以及并发与扩缩里的排队纪律，比预留的大小更要紧。
• 对付突发性的诚实解法是一个队列，而且它几乎不要钱。如果你的负载里有任何一部分能容忍延迟——评测、批量富化、后台智能体、建索引——把它挪到一个能填平波谷的队列后面，会直接抬高利用率。在买容量去覆盖那些你本可以削平的峰值之前，先做这件事。

真正该买它的理由：一条你能承诺出去的尾巴。

上面的一切都在价格上反对预留容量。而在延迟上它们的结论正相反，也正是在这里这件工具真正对得起它的成本。共享的按需端点，其尾部由别人的流量决定；而一份预留把别人的吵闹邻居换成了你自己已知的负载。

• 当一条用户可见的 p99 写进了合同时，买它。如果一个客服智能体必须在几秒内作答，或者一个语音智能体必须在一个轮次预算内作答，那么风险来自共享池的方差，而不是它的均值。预留容量是你把那个数字变成自己可控之物的方式——取舍框架见成本、质量与延迟。
• 当被打满等同于一次可用性事故时，买它。如果在峰值被限流意味着一条你排不干的队列和一批离开的用户，那么这份预留就是保险，并且应该按保险来定价——对着那次故障的代价，而不是对着按需费率。
• 当你需要一个归自己掌握的准入控制点时，买它。有了专用容量，"在压力下哪些请求被服务"这个决定就挪进了你的系统内部：你可以卸掉批处理、降级到更小的模型、保护交互流量。而在共享端点上，这个决定由厂商替你做，而它并不知道你的哪些请求要紧。
• 不要为并不存在的合规理由去买它。专用吞吐通常并不等于专用硬件、数据驻留控制或隐私边界。如果有人拿这些理由在论证这笔采购，去看合同，而不是看营销页。
• 签字之前先把 SLO 写下来。"300 路并发会话下 p95 低于 4 秒"是一件你能买、且事后能验证的东西。"性能更好"不是，而它正是那种会毫无阻力地一路活到续约的理由。

没人写进模型的那项期限成本：它把你的模型选择冻住了。

这一项能把一笔勉强划算的交易变成一笔糟糕的交易，而它从不出现在表格里。预留容量是按模型购买的。一份为期十二个月、绑定某个具体模型的承诺，是在赌你第十一个月想跑的模型就是你第一个月选的那个——而这个市场的前沿一直以季度为节奏在移动，性价比也随之移动。

• 切换成本变成了财务成本，而不只是技术成本。没有承诺时，换到一个更好或更便宜的模型花的是一次重新验证。有了承诺，它还要再花掉剩余的那份预留，而那个数字大到足以赢下一些它本不该赢的争论。
• 留意那个悄悄不再被做出的决定。失败并不戏剧化。它是一个团队因为"反正我们在承诺期里"而跳过了一次评测，一年后跑着一个落后两代的模型，费率在第四个月就已经不再有竞争力了。
• 厂商侧的退役不尊重你的期限。模型会按厂商的时间表被退役、被静默更新；你的预留并不保护你免于一次你没计划过的重新验证。无论你承诺了什么，都照做模型退役与迁移里的那套演练。
• 优先选能买到那条 SLO 的最短期限。一份折扣小一些、但你能随时走开的一个月预留，在这个市场里通常是比六个月或十二个月、费率更好的那份更好的工具——因为你卖掉的那份选择权，比其中的价差更值钱。
• 预留地板，其余溢出。把预留的容量定到那部分真正一直都在的负载上，让峰值跑在按需上。它让出一些标称折扣，换回大部分利用率风险，而且它是那种在流量预测朝任一方向失准时都能活下来的配置。

决策流程，按顺序来。

按次序跑这些。大多数团队在第三步就会得到一个清楚的答案，往后都用不上——而这正是重点：最便宜的容量决策，通常是那个你避免去做的。

• 1. 先拿到按工作负载的令牌记账。如果你说不出哪个工作负载消耗了什么、以什么输入／输出比与上下文长度，你就没法给任何东西定容量。这是成本归因的用途，而它是前置条件，不是一件并行的事。
• 2. 把免费的杠杆用尽。缓存、上下文纪律、把便宜的步骤路由给更小的模型，以及把可延后的负载排队。这四件都能削减或削平你正打算预留的那份需求，而且都是可逆的。
• 3. 用一分钟的分辨率画出一周的真实负载。读出均值、p99 与两者之比。如果峰均比高于大约 2 而你又削不平它，那么按峰值定容量的预留达不到打平点，你已经有答案了。
• 4. 说出这份预留买到了哪条 SLO，否则就停。一条你真的愿意摆到客户面前的延迟或可用性承诺。没有 SLO，不买。
• 5. 买地板，用最短期限，开启溢出。然后每周测量实际利用率，并把持续低于打平点的数字当成一次活的事故来处理，而不是当成一条季度发现。
• 6. 在高且平坦的量级上，诚实地重开自建这个问题。到了一份预留能被全天候充分利用的那个点上，面向智能体的自建推理里的算术就开始有竞争力了——而它带着一份预留所没有的运维负担。

相关：自建还是采购讲这个决定的放大版，经济性失败模式讲模型出错的其它方式，推理提供商讲谁在卖什么。