迁到推理模型，不能只凭模型名做容量规划

为什么要重新测量，而不是复用旧规模

复用的反射假设模型名携带了规模——只要把管用的 gpt-4o 数值乘上一个家族 乘数，对 GPT-5.x 仍然合身。在接受这个假设之前，值得把两件事并排放一下。第一件是文档 规定的：Microsoft Learn 把流量换算成归一化 TPM，输入是峰值 RPM、平均提示与输出 token、 缓存率、模型的输出对输入比，以及每 PTU 的 Input TPM，并把缓存的提示 token 从利用率里 扣掉。OpenAI 把推理 token 记录为不显示的输出侧 token，报告在 output_tokens_details.reasoning_tokens 里。第二件是本仓库的示例计算：把那条 有文档记载的公式跑在一个调用形态的示例上，并排展示驱动规模的各个因素——它不是对任何 部署的测量。

值得停下来的，正是那个"成对"的部分。只看可见输出，迁移显得很好对付——同样的提示、 同样的可见答案，在新模型上大体同档，甚至可能略微更轻。但可见的答案不是请求的全部。 一旦隐藏的推理输出出现，同样的答案就可能需要多得多的归一化 TPM。而本仓库的工作假设 ——这是一个需要验证的准入风险，而不是有文档记载的平台行为——是：过大的 max_output_tokens 上限，无论那些 token 是否真的被生成，都可能预留下准入 权重。所以运维上的问题不是"新模型重不重"，而是"我测得的请求形态——可见输出、推理 输出、缓存率、响应上限——实际预留了什么"。归一化 TPM 公式、逐模型的表、缓存扣减、 推理 token 的记账，是 Microsoft Learn 与 OpenAI 记录的；把过大的 max_output_tokens 当成一个需要验证的 PTU 准入风险，则是本仓库愿意为之背书的 运维推断。下面的图，是一份在建模工作负载上、配着固定价格快照的合成计算示例——不是测得的 容量，不是在线 PTU 吞吐量，也不是 SLA。下面的示例图把驱动规模的因素明示出来。

官方行为 · 归一化 TPM

容量规划公式，讲的是 token 的形态

Microsoft Learn 通过把流量换算成归一化 TPM 来给 PTU 需求做容量规划。输入是峰值 RPM、 平均提示 token、平均生成输出 token、缓存率、模型的输出对输入比，以及模型每 PTU 的 Input TPM 值。

正因为有这条公式，家族级的捷径才会误导人。某个模型即便输出比更重，也可能拥有比前一个 模型更高的每 PTU Input TPM。答案取决于你工作负载实际的提示、输出、缓存画像。

运维视角 · 迁移中会变化的因素

决定迁移是否合身的，是四个因素

示例性计算 · 相同的可见工作负载

隐藏的输出可能改变答案

运维者清单 · 在购买容量前先重新测量

把迁移当成一次测量来做，而不是一次改名

1. 固定任务构成。让提示、工具、模式、检索摆放、样本分布在各模型配置之间逐字节稳定。
2. 测量可见输出。比较迁移前后可见输出 token 的均值与 p95。
3. 测量推理输出。取 reasoning_tokens，不要从最终答案文本去猜。
4. 测量缓存率。尤其在 ReAct 或工具模式变更之后，按缓存键分桶记录 cached_tokens / prompt_tokens。
5. 把上限调到合适。从有代表性的"可见 + 推理"分位数设定 max_output_tokens，对罕见的长答案用按调用的覆盖。
6. 然后才做 PTU 容量规划。用当前的模型表和实测的工作负载形态，套用归一化 TPM 公式。

来源与证据边界

Tier 1 — 服务契约（Microsoft Learn 与 OpenAI）。归一化 TPM 的容量 规划公式、逐模型的每 PTU Input TPM 与输出对输入比、GPT-4.1 及以后的输出 token 权重、 利用率里 100% 的缓存扣减，以及推理 token 的记账，都记录在这里。

• [1] Determine PTU sizing for a workload — 定义了归一化 TPM 的计算 （Input TPM = 峰值 RPM × 提示大小，Output TPM = 峰值 RPM × 响应大小，Normalized TPM = input TPM × (1 − 缓存率) + 输出对输入比 × output TPM，PTU = normalized TPM ÷ 每 PTU Input TPM）、逐模型的每 PTU Input TPM 与输出对输入比取值，以及缓存 token 从利用率计算中 100% 扣减。来源：Microsoft Learn 文档（2026-06-05 访问）· 存档。
• [2] What is provisioned throughput for Foundry Models? — 记录了 PTU 的 利用率模型，以及请求形态如何消耗预留容量。来源：Microsoft Learn 文档（2026-06-04 访问）· 存档。
• [3] Prompt caching with Azure OpenAI — 记录了缓存的提示 token 会从 利用率里扣除，因此前缀形态的变化会改变容量规划结果。来源：Microsoft Learn 文档（2026-06-04 访问）· 存档。
• [4] OpenAI reasoning models guide — 把推理 token 记录为不显示的、报告在 output_tokens_details.reasoning_tokens 里的输出侧 token。来源：OpenAI 文档（2026-06-04 访问）· 存档。

Tier 2 — 运维推断（本仓库）。把过大的 max_output_tokens 当成一个需要验证的 PTU 准入风险假设，以及对推理 token 与缓存 token 的测量约定，是本 仓库的运维推断，而非 Learn 规范。

• [5] 本仓库，docs/13-ptu-vs-payg-decision-runbook.md — 记录 mean_max_output_tokens，并把较大的 max_output_tokens 解释为一个需要验证的预留准入权重，而不是一个靠猜的值。来源。
• [6] 本仓库，docs/14-observability-schema.md — PTU 记录的规范契约，把 reasoning_tokens、cached_tokens、 max_output_tokens_sent 各自对应到原始的 usage 字段。来源。

本文证明了什么、又没证明什么。它记录了截至访问日期 Microsoft Learn 明示的 PTU 容量规划契约——归一化 TPM 公式、逐模型的每 PTU Input TPM 与输出对输入比、 GPT-4.1 及以后的输出 token 权重、100% 的缓存扣减——以及 OpenAI 的推理 token 记账，还有 本仓库的经验法则——在做容量规划之前，把输出、推理、缓存、上限都重新测一遍。示例图是把 有文档记载的公式套在一个调用形态示例上的结果。它是计算示例，而不是容量保证，也不证明 某个具体的 GPT-5.x 工作负载在所有区域、模型版本、流量形态下，比它的 GPT-4o 前任更重 还是更轻。