2026年GPT Image 2速率限制详解：开发者须知
了解2026年GPT Image 2速率限制的运作方式，以及它们对吞吐量、队列设计和生产环境部署规划的影响。
嘿，大家好。我是 Dora。一位在三人产品团队工作的朋友在五月初上线了一个 GPT Image 2 功能。软上线，邀请了约 200 名用户。90 分钟内，功能就崩了——不是因为模型出了问题，而是因为他们在 Tier 2，那些用户（平均每人生成 3–5 张图片）的突发请求在第一个下午就触达了 20 IPM 的上限。
这就是 GPT Image 2 速率限制的特点：它们感觉不像限制，直到真的成为限制。文档表格里的 Tier 数字看起来很抽象，但当你的队列深度超过该 Tier 每分钟能处理的量时，就变得无比具体。这篇文章写给那些把 GPT Image 2 集成到真实产品中的团队，而不是跑单个提示词基准测试的人——OpenAI 图像 API 速率限制在负载测试和开发环境中的表现截然不同。
免责声明：我为 WaveSpeedAI 撰写关于 Agent 和图像基础设施的文章。我在早前的一篇文章中讨论了模型评估问题——GPT Image 2 是否适合你的工作流。这篇文章假设你已经决定它适合，现在要弄清楚它能否在真实流量下撑住。
2026 年 GPT Image 2 速率限制概览
根据 OpenAI 速率限制文档和 GPT Image 2 模型页面，该模型按两个维度计量：TPM（每分钟 Token 数，包含图像输入/输出和文本 Token）和 IPM（每分钟图像数，对大多数工作流来说是更硬的上限）。
基于 Tier 的 IPM 和 TPM 结构
以下是截至 2026 年 4 月公布的 GPT Image 2 限制。免费 Tier：不支持。
| Tier | TPM | IPM | 大致资格消费 |
|---|---|---|---|
| Tier 1 | 100,000 | 5 | 已支付 $5 |
| Tier 2 | 250,000 | 20 | 已支付 $50 + 7 天 |
| Tier 3 | 800,000 | 50 | 已支付 $100 + 7 天 |
| Tier 4 | 3,000,000 | 150 | 已支付 $250 + 14 天 |
| Tier 5 | 8,000,000 | 250 | 已支付 $1,000 + 30 天 |
有两点需要注意。Tier 是组织级别的，不是按项目或 API Key 划分的——每个项目共享同一个 GPT Image 2 IPM 预算。OpenAI 可能随时修改这些数字，因此上表仅作规划基准。在做出架构决策前，请在你的账户限制面板中确认。
这些限制在实践中意味着什么
Tier 1 的 5 IPM 上限意味着每 12 秒一张图，持续稳定。这足以支撑个人开发和小型原型，但无法支撑有少量并发的面向公众的功能。Tier 5 的 250 IPM 上限听起来很高，但算一下：250 张/分钟 × 60 分钟 = 每小时 15,000 张。如果你的上线推文在第一小时带来 5,000 次注册，每个用户生成一张图，假设完美分布（现实中从不发生），你已经用掉了 33% 的容量。
更难处理的失败模式是突发流量。OpenAI 的文档指出，限制是在不足一分钟的窗口内强制执行的。20 IPM 并不意味着你可以在第一秒发送 20 个请求然后休息 59 秒。在 2 秒内发送 5 个请求就会被限流，即使你的每分钟平均值远低于上限。
速率限制如何影响生产规划
模型评估花了两周。而让它在真实负载下持续运行的基础设施，至少还需要两周。大多数团队低估了这一点。
队列设计、批处理和重试决策
这里有三层需要叠加。大多数团队只建了两层。
第一层：客户端速率限制。将并发进行中的请求上限设置为你所在 Tier IPM 的约 80%，均匀分布在每分钟内。如果你在 Tier 3（50 IPM），那就是持续约 40 张并发图像，后面排队。
第二层：指数退避重试。OpenAI cookbook 建议对 429 错误使用带抖动的指数退避。标准模式：等待 1 秒、2 秒、4 秒、8 秒，加随机抖动，6 次后停止。这是不可妥协的。对 429 进行紧密循环重试会让你的账号被标记。
第三层——团队经常跳过的——是请求形态控制。不是每张图都需要 quality: high，不是每个工作流都需要同步响应。OpenAI 的 Batch API 有独立的配额池和 50% 的定价，SLA 为 24 小时。对于夜间缩略图重新生成，批处理是正确的工具；对于面向用户的单次生成，则不是。大多数团队两者兼有，却把它们当成一回事来路由。“速率限制是个问题”和”速率限制只是背景”之间的区别，在于你是否将异步工作从同步 IPM 池中剥离出去。
团队对周转时间和流量峰值的预期
这是没人写进文档的部分。这是与产品和运营的对话，而不是关于模型的。
在 Tier 2（20 IPM）下，p50 延迟大致受模型本身约束——根据质量和推理模式，在 8–25 秒之间。但在持续负载下，p99 包含队列等待。第 21 个在一分钟内提交请求的用户要等 60 秒，而不是 12 秒。“图像在 15 秒内生成”只有在没有其他人同时生成时才成立。
对于营销活动和上线，规划问题不是平均吞吐量，而是峰值分钟吞吐量。如果你预期活动上线后的 4 小时内流量是平时的 3 倍，你的 Tier 需要能吸收这 3 倍而不崩溃，否则你需要预先生成，或者需要降级方案。在上线前确定其中一个。在上线过程中才做决定，结果从来都不好。
速率限制何时变成产品问题
有一个阈值，在此之后 GPT Image 2 的吞吐量不再是基础设施问题，而变成了产品问题。信号很一致：当你的重试队列深到用户可以感知时，你面临的是产品问题，而不是基础设施问题。
已经越过这条线的迹象：
- 面向用户的延迟方差超出你的容忍范围（例如，80% 的请求在 20 秒内完成，5% 因为排在突发流量后面而需要 90 秒以上）
- 你为了保持在 Tier 内而削减功能范围——“UI 中不提供批量生成”是个信号
- 一个恶意用户或一个爆款分享链接就能占满你的分钟配额，拖慢其他所有人
- 你的 Tier 5 申请耗时超过 30 天，但你的上线计划在 14 天后
当你遇到这种情况时，诚实的答案是：单一提供商有运营上限。即使是 Tier 5 也是上限。运行大规模业务的团队开始考虑预先生成和缓存、对非关键路径使用压力较低的替代模型，或通过跨提供商池化容量的聚合/降级层。每一种方案都增加工程面，但每一种都比公开的延迟事故代价更低。
写这一节时我停顿了一会儿，因为很容易滑入 WaveSpeed 的框架。诚实地说：聚合只是多种选项之一。预先生成和缓存解决的问题往往比人们认为的更多，成本也更低。是否需要多提供商层，取决于你的工作负载是否真的超过了 Tier 5，或者你是否还没有优化。先诊断，再做架构设计。
扩容前构建者应该监控什么
按以下顺序关注三件事。
峰值时的实际 IPM，而不是平均值。 在每次响应中记录 x-ratelimit-remaining-images 和 x-ratelimit-remaining-tokens 头。观察最小值，而不是均值。如果峰值分钟剩余量降到 Tier 的 20% 以下，你距离 429 只差一次流量峰值。
失败模式分布。 将 429 作为总请求的百分比跟踪，按小时分组。0.5% 的 429 率听起来还好，直到你发现在营销邮件发送窗口期间是 8%。按时间分桶的指标能发现这一点，聚合指标则不行。
升级到下一个 Tier 的时间。 Tier 5 需要 $1,000 的消费加上 30 天的账号年龄。如果你的预测在 2 个月内触及 Tier 5 需求，现在就开始消费，或者接受你大规模运营的前 30 天将受到容量限制。
这是我数据的边界——我在 Tier 2 和 Tier 3 运营过 GPT Image 2，而不是 Tier 5。Tier 5 的团队反映动态再次发生变化，上限不再是 IPM，而是请求形态效率。
常见问题
GPT Image 2 各 Tier 的速率限制是什么？
根据 OpenAI 截至 2026 年 4 月的文档：Tier 1 是 100,000 TPM / 5 IPM，Tier 2 是 250,000 / 20，Tier 3 是 800,000 / 50，Tier 4 是 3,000,000 / 150，Tier 5 是 8,000,000 / 250。不支持免费 Tier。限制是组织级别的，所有项目共享。OpenAI 可能修改这些数字，请在你的账户面板中确认。
速率限制如何影响大规模图像工作流？
三件事：队列设计（你需要在 OpenAI 之前做客户端限速）、延迟分布（p99 包含队列等待，而不只是模型时间）、以及路线图（你可能会推迟那些会产生你无法吸收的峰值的功能）。常见模式：团队按平均负载构建，然后发现峰值负载决定了用户体验。
团队在上线高并发功能前应该做什么？
四个步骤。估算峰值分钟生成量，而不是日均量。确认你的 Tier 覆盖它并有约 30% 的余量。实现带抖动的指数退避和熔断器。为容量耗尽的情况确定降级方案——预先生成、替代模型或优雅降级。上线当天你无法修复的失败模式，是你没有提前规划的那个。
什么时候单一提供商在运营上不够用？
当峰值分钟需求持续超过单一提供商 Tier 5 容量时，当你的 SLA 无法承受单一提供商的中断窗口时，或者当队列等待导致的延迟方差在优化后仍对用户可见时。大多数团队不会遇到这种情况。遇到的团队——通常是有病毒式传播模式的消费产品或有严格 SLA 的企业流水线——会增加预先生成、多提供商路由，或两者兼用。这个决定应该来自你的峰值负载日志，而不是某个供应商的营销页面。
结论
GPT Image 2 速率限制的快速总结：Tier 1 从 5 IPM 开始，Tier 5 上限为 250 IPM，突发流量触达这些上限的速度远比稳态数学估算的快得多。慢版总结：速率限制是一个运营设计约束，而不是文档里的一个注脚。它决定了你的队列、SLA、功能范围和上线计划。
对于构建者来说，正确的问题不是”我在哪个 Tier”——而是”我的峰值分钟是什么样的，我的 Tier 能否有余量地吸收它”。大多数团队用错误的方式发现答案，在上线之后。
等我在 Tier 5 运营 GPT Image 2 之后会有更多内容分享。以上数字来自 OpenAI，框架是我的，容量政策更新速度比博客文章快。
往期文章：
