速率限制（Rate Limit）是什麼：API 為什麼回你 429

速率限制（rate limit）是服務在一段時間內允許你送出的請求數或 token 數上限，超過時 API 通常回 HTTP 429 Too Many Requests。它管的是速度。Anthropic 與 Microsoft 的繁中文件寫「速率限制」，Google 繁中頁標題作「頻率限制」、內文兩者混用；這裡用「速率限制」，較貼近 rate「單位時間內的量」的本意。Gemini API 查額度、分類錯誤的操作步驟見API 額度與錯誤：費用、重試與成本控制。

以下整理 RFC 與各家官方文件寫的機制，不列任何方案的數字，實際額度以自己的主控台為準；資料截至 2026 年 10 月。

它算的是一段時間內的量

常見單位是每分鐘請求數（RPM）與每分鐘 token 數（TPM），也有每日請求數（RPD）與每日 token 數（TPD）。OpenAI 說明哪一項先到就先觸發，很多短請求可能先用完請求數。各家算 token 的方式也不同：Anthropic 把輸入與輸出分開，算成每分鐘輸入 token（ITPM）與輸出 token（OTPM）；Google 的 Gemini API 文件則把 TPM 標為輸入 token。

限制也有層級。OpenAI 定在組織與專案，Google 定在專案而不是 API 金鑰，Anthropic 定在組織、可再替工作區設較低上限；同一個專案多開幾把金鑰，額度不會變多。

時間窗未必是整分鐘。Anthropic 用權杖桶（token bucket）演算法：額度像桶裡的籌碼，用掉後持續補回到上限，不是每隔固定時間一次重設；它也提醒每分鐘上限可能拆成更短區間執行。所以這一分鐘的額度還沒用完，短時間送太密仍可能被擋。

429 與 Retry-After：規範怎麼寫

429 出自 2012 年的 RFC 6585，定義是使用者在一段時間內送出太多請求。回應應該說明原因，並可以附上 Retry-After 告知要等多久。規範沒有定義怎麼辨識使用者、怎麼計數，所以各家計算方式不同，都合乎標準。

Retry-After 的格式寫在 RFC 9110：可以是 HTTP 日期，也可以是秒數，例如 120 代表兩分鐘，也能搭配 503 Service Unavailable 使用。OpenAI 建議把它當成最少等待時間，再加一點隨機延遲。

不是每個 429 都該重試

429 底下不只一種原因。OpenAI 的預付額度、花費上限或使用上限用完也回 429，並寫明重試不會恢復；Anthropic 方案等級的每月花費上限用完也回 429，但不附 retry-after，自設的較低上限則回 400；Google 的 Interactions API 錯誤表把每日配額用完另列一個代碼，建議等重設，依花費計算的速率限制則是短時間窗，可稍等再試。另一種是加速太快：OpenAI 的 slow_down 與 Anthropic 的加速限制都因用量急升而觸發，OpenAI 註明沒到每分鐘上限也會發生；解法是逐步加量。

退避加抖動：示例流程

指數退避（exponential backoff）是每失敗一次就把等待時間加倍，直到上限。AWS 的 Marc Brooker 在 2015 年用模擬說明：只有退避，重試仍會成群擠在同一時間；加上隨機抖動（jitter）才會分散。他模擬 100 個客戶端搶著更新同一筆資料，加抖動後總呼叫數少了一半以上。

示例（未實測），程式收到 429 之後：

1. 讀錯誤內容；若是花費上限或配額用完，記錄後停止。
2. 附有 Retry-After: 20 時，至少等 20 秒，再加 0 到 1 秒的隨機延遲。
3. 沒有 Retry-After 時，以 1 秒為基準、8 秒為上限，第 1 到第 5 次重試的上界依序是 1、2、4、8、8 秒，每次在 0 到上界間隨機取值。
4. 最多重試 5 次、總等待不超過 2 分鐘，用完就把工作放回佇列。
5. 預期結果：多個工作的重送時間會錯開，較少擠在同一秒。若 5 次都失敗，多半代表平均速度本身超標，該降低並行數量，而不是加大重試次數。

重試只留一層。OpenAI 提醒官方 SDK 已會自動重試，自己再包一層時要關掉它或算進上限；AWS 舉例，五層服務呼叫各自試 3 次，最底層資料庫的負載會放大到 243 倍。RFC 9110 也提醒，非冪等（重送可能多生效一次）的請求除非能確認重送無害或原請求沒有生效，否則不應自動重試；會寄信或付款的工具呼叫要先做好防重複。

速率限制、配額、花費上限與上下文視窗

配額（quota）的用法各家不一：Google 指每日上限，在太平洋時間午夜重設；Microsoft 的 Azure OpenAI 指分給訂閱、再由各部署瓜分的每分鐘 token 總量；OpenAI 的帳務類錯誤，錯誤類型可能標成 insufficient_quota。

花費上限算的是金額，Anthropic 文件就把限制分成花費上限與速率限制兩類。上下文視窗是單次請求能放的 token 數：在 Anthropic，輸入超過上下文視窗會回 400，等多久都沒用。聊天產品的使用量上限又是另一回事：Claude 說明中心把訂閱方案的上限分成使用量上限與長度上限（受上下文視窗限制），並說明付費訂閱不含 API。

代理迴圈與批次工作的節流設計

代理迴圈（Agent Loop）每一輪都是一次模型呼叫。Anthropic 的 Messages API 是無狀態的，每次都送完整對話歷史，輪數越多、輸入越長，輸入 token 容易比請求數先用完。多個子代理共用同一個組織或專案的額度，工具一起回傳、下一輪一起送出，就是短時間爆量。批次工作也類似：AWS 提到，多台機器的定時工作可能在每分鐘頭幾秒或午夜剛過時撞在一起，建議也加抖動。

• 所有工作者共用一個限速器，因為額度算在組織或專案上，不是各算各的。
• 限制同時進行的請求數，其餘排進佇列。
• 讀回應標頭的剩餘量，接近上限就先放慢，不等 429。
• 不急的大量工作改用批次 API；三家文件都把批次的限制和即時呼叫分開列。
• OpenAI 以輸出上限 max_tokens 與估計 token 數的較大者計入，宜設得接近預期長度；Anthropic 的 max_tokens 不計入 OTPM。

重複的系統指示與長文件，可以用提示詞快取（Prompt Caching）：Anthropic 大多數模型從快取讀取的 token 不計入 ITPM。撞到限制時，代理任務應記成「等待中」，而不是失敗後從頭重跑。

更多相關詞彙見AI 名詞總索引。

• AI 工具
• 教學
• AI 名詞解釋