8.0
热点
AI SCORE
编程提效2026-08-23 22:16
Azure OpenAI PTU vs 按量付费：真实盈亏平衡表
dev.to · AI#Azure OpenAI#成本优化#GPT-5
Editor brief · 编辑速览
基于微软官方 PTU 吞吐量和 2026 年定价，拆解 GPT-5 两种计费模式实际月费差异，指出通用计算器因假设 100% 利用率导致错误结论。
网上所有 Azure OpenAI 成本计算器给你的建议都一样：GPT-5 的 PTU 盈亏平衡点大约在每月 1.5 亿至 2 亿 token。低于这个量，按量付费（PAYG）更划算；高于这个量，PTU 预留更合算。选个数，签个预留合同，搞定。
这个算法是错的，或者至少是不完整的。计算器假设 PTU 部署的利用率是 100% 持续运行。许多生产工作负载的实际持续利用率远低于 100%；你需要根据自己的遥测数据来校准。下面这个实际案例中，15 个 PTU 的年度预留费用可能会比同等的 PAYG 账单更贵。
我查阅了微软官方发布的每个 PTU 吞吐量数据、当前的 2026 年定价，并跑出了 GPT-5 及同类模型的真实成本表。以下是你在签任何合同前应该了解的内容。
GPT-5 Global PAYG 的价格是每百万输入 token 1.25 美元，每百万输出 token 10 美元。GPT-5 Global PTU 大约是每 PTU 每小时 1 美元，按月预留每 PTU 每月 260 美元，按年预留每 PTU 每月 221 美元。最小部署规模是 15 个 PTU（即按小时付费每月 10,800 美元，按月预留每月 3,900 美元，按年预留每月 3,315 美元）。每个 PTU 提供 4,750 输入 TPM，输出 token 的利用率消耗相当于 8 个输入 token。在典型的 8K 输入/1K 输出工作负载下，100% 持续利用率 24/7 运行，PAYG 和按年预留 PTU 的盈亏平衡点大约在每月 3,800 美元。在 40% 持续利用率下（更接近大多数生产工作负载的实际状态），按年预留 PTU 仍需 3,315 美元，而 PAYG 降至 1,540 美元。PTU 只有在能完全饱和部署且承诺按年付费的情况下才是划算的；在无法饱和的情况下就是一个陷阱。
计算器隐藏的盈亏平衡曲线：在大多数生产工作负载的实际运行利用率下，PAYG 始终比按年 PTU 预留更便宜。
PTU（Provisioned Throughput Unit）是一种微软按固定小时费率销售的模型处理能力单位。你以 PTU 模式部署模型，预留一定数量的 PTU，无论用与不用都要付费。模型的 TPM（每分钟 token 数）容量取决于你购买了多少个 PTU。
Global Provisioned：最便宜，请求在全球容量池中路由
Data Zone Provisioned：中间档，请求保持在大陆数据区域内
Regional Provisioned：最贵，请求保持在特定区域内
大多数架构师会选择 Global。Data zone 和 Regional 主要用于合规场景，成本更高。
最小部署规模：Global 和 Data Zone 最少 15 个 PTU，按 5 的倍数递增。Regional 大多数模型最少 50 个 PTU。你无法"部署 1 个 PTU 的 GPT-5 来测试"。GPT-5 PTU 部署的最小规模就是 15 个 PTU。
PTU 预留有三种计费模式：
按小时计费：灵活，无需承诺，但价格最贵
按月预留：折扣可观，需承诺 1 个月
按年预留：折扣最大，需承诺 1 年
预留是一种财务手段，不是部署手段。你通过 Azure 门户的"预留"页面购买预留，合同会自动应用到同一范围、区域和部署类型的任何匹配部署。微软的官方指引：
预留确保在所选期限内的折扣价格。它们不保留服务容量，也不保证在创建部署时容量可用。强烈建议客户在购买预留前先创建部署，以防止过度购买。
所以安全的顺序是：先部署（按小时付费），确认容量可用，再购买预留。你至少需要按小时付费几天来确认规模。
Azure OpenAI / Foundry 上 GPT-5 家族的确认定价：
PTU 按小时费率因模型和区域而异。Azure 定价计算器是权威来源。GPT-5 Global 每 PTU 每小时 1 美元的数字基于 2026 年 Azure OpenAI GPT-5 Global PTU 定价，按月预留约 260 美元/PTU/月，按年预留约 221 美元/PTU/月。
还有几个额外的计费杠杆：
按小时到按年预留的差距是巨大的。15 个 PTU 的 GPT-5 部署，按小时付费每月 10,800 美元，按月预留每月 3,900 美元，按年预留每月 3,315 美元。同样的容量，70% 的成本差异，仅仅是承诺期限不同。
微软公布了每个模型的每个 PTU 输入 TPM。这个数字决定了你的 PTU 部署能承接多少等效 PAYG 的流量。
从这个表里有几点值得注意：
输出与输入的比率很关键，因为它决定了典型混合形状请求如何消耗利用率。对于 GPT-5，一个输出 token 在你的每 PTU TPM 预算中"权重"是输入 token 的 8 倍。因此，一个 8K 输入和 1K 输出的请求，每分钟消耗 8,000 + (1,000 × 8) = 16,000 个加权 token，占用你 4,750-per-PTU 预算的一部分。
以 15 个 PTU GPT-5 Global 部署（最小可能规模）来算账。工作负载假设：每个请求 8K 输入 token、1K 输出 token。
吞吐量上限：15 个 PTU × 4,750 输入 TPM = 71,250 有效输入 TPM。每个请求消耗 16K 加权（8K 输入 + 8 × 1K 输出）。因此部署上限为 71,250 / 16,000 = 每分钟 4.45 个请求，即每天 6,400 个请求，或在 100% 利用率下每月约 192,000 个请求。
100% 利用率下的 token 量：192,000 个请求 × 8K 输入 = 15.4 亿输入 token，外加 192,000 × 1K 输出 = 1.925 亿输出 token。
100% 利用率下的 PAYG 成本：
同 15 个 PTU 的 PTU 成本：
现在在不同利用率下跑这张表。计算基于微软发布的每 PTU TPM 规格和 2026 年 Azure OpenAI 公开定价。在承诺前用你自己的工作负载遥测数据校准。
按年预留 PTU 与 PAYG 的盈亏平衡利用率大约是 86% 持续运行。在这个利用率下，PAYG 和按年预留 PTU 成本相同。低于这个利用率，PAYG 胜出；高于它，PTU 胜出。
86% 持续利用率 24/7 运行是很难做到的。这意味着你每分钟有约 6.4 个 GPT-5 请求，每分钟、每小时、每天都如此，包括凌晨 4 点的周日。真实的生产工作负载几乎从不会维持这种曲线。它们有高峰、有低谷、有季节性模式，周末流量可能降至工作日的 10%。
按小时 PTU 永远不会比 PAYG 便宜。按月预留大约在 100% 利用率才能盈亏平衡，这意味着实际上它从来赢不了 PAYG。唯一能在成本上真正胜出的 PTU 计费模式是按年预留，而且只有在你能够饱和部署的情况下。
PTU 在三种工作负载下是真划算的。如果你的工作负载符合其中之一，签按年预留。如果不符合，就用 PAYG。
1. 大规模面向客户的聊天机器人。为峰值清醒时段服务的消费级聊天机器人，如果 PTU 部署规模合理，可以达到 70-90% 的持续利用率。流量曲线可预测，负载是稳态的，PTU（相对于 PAYG 排队）的延迟底限对用户体验很重要。按年预留是正确的选择。
2. 重型批处理流水线。一个持续处理数百万文档队列的文档处理流水线，可以主动饱和 PTU 部署。你按 PTU 上限来设计吞吐量。每个 worker 按部署能服务的速率从队列中拉取任务。利用率通过架构设计保持在 95%+。
不过话说回来，如果流水线对延迟不敏感，5 折的 Batch API 通常比这个方案更划算。在签合同前，始终要将 Batch + PAYG 与 PTU + 饱和方案做成本对比。
3. 具有可预测流量的延迟关键型实时应用。PTU 提供有保障的延迟。PAYG 在峰值时可能遇到排队延迟。交易大厅副驾驶、紧急调度助手、实时欺诈决策系统有业务理由为有保障的延迟付费，这是成本计算器无法捕获的。当慢响应的代价高于未使用容量的代价时，PTU 胜出。
大多数生产团队应该考虑的架构模式：
基线流量享受 PTU 价格（饱和时便宜，延迟可预测）。峰值流量享受 PAYG 价格（无承诺，随负载扩展）。你只需要为你能 24/7 充分利用的 PTU 规模做承诺。缓存放在 PTU 侧，免费利用，是最有价值的成本杠杆。
大多数团队做错的是 PTU 基线的规模规划。看你的历史每分钟流量，找到第 30 百分位（没错，就是偏低）。这是成本最优混合的 PTU 基线。高于这个值意味着你在安静时段为未使用的 PTU 过度付费。
缓存输入 token 100% 从 PTU 利用率中扣除，在 PAYG 上只收标准输入费率约 10% 的费用。这是整个模型中最大的成本杠杆。
如果 70% 的输入是缓存的（典型带系统 prompt + RAG 上下文的聊天机器人）：
当缓存介入时，PAYG 到 PTU 的盈亏平衡会发生剧烈偏移。具有重度前缀缓存的工作负载可以在更低的请求量下饱和 PTU 部署，因为每个请求消耗更少的利用率。
如果你以 70% 缓存命中率和 8K/1K 请求形状运行，在同样的 192K 请求量下，有效 PAYG 成本降至约 2,200 美元/月。PTU 按年预留 3,315 美元/月，除非利用率保持在 100%，否则永远不会比它划算——而缓存使得达到 100% 利用率变得更难，因为每个缓存请求需要更长时间才能填满 PTU 预算。
换句话说：缓存使 PAYG 的竞争力大幅提升。先调优缓存，再重新审视 PTU 问题。
签任何合同前运行这个检查。
从 Azure Monitor 拉取历史 TPM 数据。看过去 30 天的输入 + 输出 TPM 的 p50 / p90 / p99，按星期几和钟点看的模式。
计算持续利用率。平均 TPM 除以部署上限。如果结果低于 70%，你不需要 PTU。
映射工作负载类型。是面向客户延迟关键的？是重型批处理？还是有变化的 RAG agent？PTU 对前两种胜出，对第三种输。
对任何异步工作测试 5 折的 Batch API。如果 batch 能覆盖你的任务，PTU 很少是正确的答案。
估算缓存命中率。如果你能够达到 50%+ 的前缀缓存命中，用缓存定价来跑计算——PAYG 看起来会好很多。
检查容量可用性。配额不等于容量。先部署，确认容量，再预留。微软明确说了这一点。
选择正确的预留期限。按小时是用于基准测试的。按月预留很少能赢 PAYG。按年预留才是真正的 PTU 价值，但只适用于你确信会运行一年的工作负载。
规划溢出。在上线前配置 PAYG 溢出，这样峰值流量不会排队或被拒绝。
同样的计算适用于 GPT-5-mini、gpt-4.1、gpt-4o 以及其他系列。不同的每 PTU TPM 和不同的 PAYG 费率给出不同的盈亏平衡点，但结构性结论是一样的：
对于 gpt-4o-mini 这样每 PTU 37,000 TPM 的 mini 模型，每美元吞吐量要高得多，所以 PTU 盈亏平衡会偏移。但同样的利用率警告仍然适用。你仍然需要真正使用那个容量。
如果你想跳过电子表格，对于 GPT-5 系列有一个经验法则：
如果你的持续利用率低于 70%，用缓存留在 PAYG。如果你能用按年预留在 85% 以上饱和，PTU 胜出；幅度取决于持续利用率（见上面的盈亏平衡计算）。两者之间是五五开，取决于工作负载特定因素。
为 2026 年设计 AI 成本模型的架构师有两个要点。
第一：成本计算器是销售工具。它们优化的是"PTU 听起来不错"而不是"你的实际工作负载"。每个公开的盈亏平衡对比都假设 100% 利用率，因为那是能卖出预留的图表。用你自己的流量数据建立你自己的模型，否则你就是默认接受了乐观情形。
第二：缓存、批处理和路由比部署模式更重要。大多数团队在实施前缀缓存之前就花了几周时间纠结 PTU vs PAYG。先实施缓存。为异步工作实施批处理路由。然后看残余成本曲线，决定 PTU 是否带来价值。在许多情况下，一旦有了缓存，答案就变成了"不"。
高级架构师在这里的角色是回绝"采购优先"的答案。微软卖预留是因为他们对收入预测有益。有时候对你的成本结构也有益。经常不是。你需要用来判断的数据在你的 Azure Monitor 日志里，不在计算器里。