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 放進真實產品的團隊，而不是在測試單一 prompt 的人——OpenAI image 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 金鑰——每個專案共享相同的 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 的批次 API 有獨立的配額池和 50% 的定價，附帶 24 小時 SLA。對於夜間縮圖重新生成，批次是正確的工具；對於用戶端的單次生成，它就不是了。大多數團隊兩者都有，卻當作同一種處理。「速率限制是個問題」和「速率限制只是背景因素」之間的差異，在於你是否已將非同步工作從同步 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 也是上限。運行大規模流量的團隊會開始考慮預先生成和快取、將非關鍵路徑路由到對 Tier 壓力較小的替代模型，或透過在多個提供商之間匯聚容量的層級進行聚合/備援。每種方案都增加工程面。每種方案都比公開的延遲事故便宜。
在撰寫這個部分時，我停頓了一下，因為這裡很容易陷入 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，框架是我自己的，容量政策的更新速度比部落格文章還快。
往期文章：
