LLM API 速率限制：比較 13 家供應商，2 個 SDK 不重試 429
目錄
本文調查 13 個 LLM API，包括 10 家供應商，以及 Bedrock、Vertex AI 和 Azure OpenAI。其中 4 個 API 會在每次回應中告知剩餘額度，Mistral 只提供一個剩餘計數，另外 8 個則要等到請求失敗才會透露任何資訊。「429」其實可能代表 4 種不同情況：可以重試的節流、需要降低增長速度的加速限制、完全不該重試的配額或支出上限，以及供應商依情況回傳為 429、503 或 529 的過載。用戶端的行為往往比供應商規則影響更大：OpenAI、Anthropic 和 Groq SDK 遇到 429 會重試兩次，但 Retry-After 超過 60 或 120 秒時就會放棄；Google GenAI 和 Mistral SDK 則預設關閉重試。本文根據各官方 SDK 原始碼，整理不同供應商的限制維度、權杖計算方式、標頭、429 語意，以及 SDK 的實際行為。
TL;DR
- LLM API 通常依每分鐘請求數與權杖數節流；Anthropic 分開計算輸入與輸出，DeepSeek 則只限制並行數。
- OpenAI、Azure 和 Bedrock 會先按
max_tokens扣除額度；Anthropic 不計快取讀取；xAI 會計入推理權杖；Bedrock 中 Claude 5 每個輸出權杖會消耗 10 個配額權杖。 - OpenAI、Anthropic、Groq 和 Azure 會在每個 200 回應中提供剩餘額度與重設標頭；另外 8 個 API 沒有記載任何相關標頭。
- google-genai 和 Mistral SDK 預設不重試 429；OpenAI、Anthropic 和 Groq 會重試兩次，並將 Retry-After 上限設為 60 或 120 秒。
RPM、TPM 與其他限制代表什麼？
這些指標都代表特定時間窗內可傳送用量的上限，各供應商採用的組合不同：
| 類別 | 名稱 | 含義與採用者 |
|---|---|---|
| 請求計量 | RPM、RPD、RPS、並行數 | 每分鐘或每天的請求數，不論請求大小，每次呼叫都算一次。RPS 通常是 RPM 除以 60，作為突發流量防護機制（xAI、Alibaba、Mistral、Azure）。並行數計算的是處理中的請求，而不是單一時間窗內的總數，也是 DeepSeek 唯一的限制 |
| 權杖計量 | TPM、TPD、ITPM、OTPM、扣減倍率 | 每分鐘或每天的權杖數。部分供應商會分成輸入（ITPM）與輸出（OTPM）。扣減倍率會在輸出權杖計入配額前乘上係數（Bedrock）。哪些權杖需要計入，則由各供應商決定，下一節會詳細說明 |
| 其他單位的計量 | IPM、音訊秒數、OCR 頁數 | 圖像模型每分鐘可處理的圖片數（OpenAI、Gemini）、每小時或每天可處理的音訊秒數（Groq、Mistral），以及文件 OCR 每分鐘可處理的頁數（Mistral） |
| 時間窗的執行方式 | 權杖桶、加速限制 | 權杖桶會持續補充，而不是每分鐘整批重設，因此即使每分鐘總量未超標，突發流量仍可能耗盡權杖桶（Anthropic；Alibaba 和 Azure 也描述了相同效果）。加速限制會另外檢查用量的增長速度，即使用量仍低於限制，突然拉高流量也可能觸發（Anthropic、OpenAI 的 slow_down） |
| 數值的決定方式 | 層級、支出上限或配額、佈建容量 | 層級決定上述各項限制，通常依付費用量或歷史記錄升級，而不是依儲值金額。支出上限或每日配額限制的是金額或用量總數，不是速率，因此等待一分鐘不會有幫助。佈建容量是按單位、按小時計費的預留吞吐量（Bedrock 和 Vertex AI Provisioned Throughput、Azure PTU）；此時 429 代表預留容量已滿，而不是配額耗盡 |
頁面上的數值是時間窗上限，不是可任意使用的額度。Anthropic 指出，60 RPM「可能會按每秒 1 個請求執行」；Azure 也說明，「即使每分鐘總量仍在限制內，1 秒或 10 秒時間窗內的突發流量仍可能觸發 429」。
LLM API 會限制哪些項目？
幾乎所有供應商都限制每分鐘請求數與權杖數，而三大雲端平台並不只是轉送模型供應商的規則。下表定義均來自各供應商頁面，以 2026-09-03 和 2026-09-04 查閱時的內容為準。
| 供應商 | 限制維度 | 限制如何提高 | 來源 |
|---|---|---|---|
| OpenAI | RPM、RPD、TPM、TPD、IPM、每分鐘音訊分鐘數；Batch API 依排隊中的輸入權杖限制佇列 | 依累計付款分為第 1 至第 5 層 | 速率限制 |
| Anthropic | 依模型類別設定 RPM、ITPM、OTPM；權杖桶；加速限制 | 依使用記錄分為 Start、Build、Scale 層級 | 速率限制 |
| Google Gemini | RPM、TPM（輸入）、RPD；圖像模型另有 IPM | 免費層，之後依每 10 分鐘支出限制分為第 1 至第 3 層 | 速率限制 |
| xAI | 各模型分別設定 RPS（RPM / 60）與 TPM | 第 0 至第 4 層，另有 Enterprise | 速率限制 |
| Alibaba Model Studio | 各模型分別設定 RPM 與 TPM，並以 RPS = RPM / 60、TPS = TPM / 60 防止突發流量 | 依模型設定；部分模型的批次作業不受限制 | 速率限制 |
| DeepSeek | 只限制並行數：V4 Pro 為 500 個連線，V4 Flash 為 2,500 個連線 | 各模型固定 | 速率限制 |
| Mistral | 依模型與工作區設定 RPS、每分鐘權杖數、每月權杖數 | 依累計帳單分為第 1 至第 4 層；「新增點數不會提高速率限制」 | 用量與限制、說明中心 |
| MiniMax | 各模型分別設定 RPM 與 TPM；MiniMax M3 為 200 RPM、10M TPM | 洽詢業務 | 速率限制 |
| Moonshot Kimi | 並行數、RPM、TPM、TPD；第 0 層為 1 個並行請求與 3 RPM，第 5 層為 100 個並行請求與 300 RPM | 依累計儲值分為 6 層，從 $1 到 $3,000 | 限制 |
| Groq | RPM、RPD、TPM、TPD、ITPM、OTPM、每小時與每天的音訊秒數 | 依模型設定 | 速率限制 |
| Amazon Bedrock | 各模型、各區域分別設定 RPM、TPM、TPD；TPD 預設為 TPM x 1,440 | 透過 Service Quotas 申請提高；新帳號起始限制較低 | 配額 |
| Google Vertex AI | 隨用隨付沒有固定的專案數值，而是共用資源池，「貴組織的歷史支出會決定 Usage Tier 與基準吞吐量（TPM）」，並以盡力而為方式處理突發流量 | 依支出決定使用層級；Provisioned Throughput「可與共用 PayGo 資源池隔離」 | Google Cloud 部落格 |
| Azure OpenAI | 每個部署分配 TPM，再由 TPM 推算 RPM（舊模型每 1,000 TPM 對應 6 RPM，現行模型每 1,000 TPM 對應 1 RPM）；PTU 部署受使用率限制 | 配額分為第 0 至第 6 層，自動升級 | 配額與限制、配額管理 |
其中兩項根本不是分鐘時間窗。DeepSeek 限制的是開啟中的連線數；系統負載高時，它不會拒絕請求，而是透過空白行（串流則使用 : keep-alive 註解）維持連線，最長可達 10 分鐘。Vertex AI 隨用隨付則沒有可讀取的配額數值，429 只代表共用資源池在當下容量不足。
哪些權杖會計入限制？
計入速率限制的權杖不一定等同計費權杖。這項差異會直接決定實際容量只是頁面數值的一小部分，還是它的數倍：
| 供應商 | 計入權杖限制的項目 | 結果 |
|---|---|---|
| OpenAI | 在請求抵達時，從 max_tokens 與根據 prompt 估算的數值中取較大者扣除：「如果將 max_tokens 設得太高，即使實際回應短得多，用量仍可能被高估」（cookbook） | 回答只有 50 個權杖，但 max_tokens 設為 4,000，仍會消耗 4,000 TPM |
| Azure OpenAI | 根據「prompt 文字與數量、max_tokens 參數設定、best_of 參數設定」估算，部分依據字元數；PTU 部署中「快取權杖享有 100% 折扣」（配額指南） | 「速率限制可能比預期更早觸發」；未設定 max_tokens 時，系統會自行估算 |
| Amazon Bedrock | 開始時扣除「輸入權杖總數 + max_tokens」，結束時修正為 InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)，快取讀取不計。Claude 4.7 與更早版本的扣減倍率為 5x；Sonnet 5、Opus 5、Fable 5.1 和 GPT-5.6 模型為 10x；Claude 4.8 為 15x（權杖計算） | 官方範例中，5x 模型使用 1,000 個輸入權杖與 100 個輸出權杖，會消耗 1,500 個配額權杖，但只按 1,100 個權杖計費 |
| Anthropic | ITPM 計入 input_tokens 與 cache_creation_input_tokens；cache_read_input_tokens「不計入 ITPM」。OTPM 按實際輸出計算；「max_tokens 不影響 OTPM」（文件） | 官方範例中，2M ITPM 在快取命中率 80% 時，每分鐘可處理 10M 個輸入權杖 |
| xAI | 「請求消耗的所有權杖都會計入 TPM 限制：prompt 權杖（文字、圖片與音訊）、完成權杖、推理權杖（推理模型）、快取 prompt 權杖」 | 推理會對使用者看不到的權杖消耗 TPM；快取無法提高吞吐量 |
| Google Gemini | 輸入權杖 | 輸出長度不會消耗限制額度 |
| Alibaba、Mistral、MiniMax | 輸入加輸出 | |
| Kimi、Groq、DeepSeek、Vertex AI | 未說明 | Groq 分開計量 ITPM 與 OTPM；DeepSeek 沒有權杖限制；Vertex AI 只公布使用層級的基準值 |
同一個請求在各家限制中可能代表完全不同的大小，上例從 800 到 6,000 個權杖不等。因此，把同一工作負載分散到不同供應商的路由器，必須為每家供應商分別計量。
各供應商會回傳哪些標頭？
4 個 API 會在每次回應中提供限制狀態，Mistral 提供一個欄位，另外 8 個則必須自行計數。
| 供應商 | 一般回應中的標頭 | 格式說明 |
|---|---|---|
| OpenAI | x-ratelimit-limit-requests、x-ratelimit-limit-tokens、x-ratelimit-remaining-requests、x-ratelimit-remaining-tokens、x-ratelimit-reset-requests、x-ratelimit-reset-tokens，以及 -project-tokens 三個欄位 | Reset 表示「距離速率限制重設的時間」；429 會附上 Retry-After |
| Azure OpenAI | 每次呼叫都會提供相同的 6 個 x-ratelimit-* 名稱；429 另有 retry-after-ms 與 retry-after | 如果 x-ratelimit-limit-tokens 低於設定的 TPM，表示目前正套用「暫時性速率限制調整」 |
| Anthropic | anthropic-ratelimit-requests-{limit,remaining,reset}，以及 tokens、input-tokens、output-tokens 各自相同的三個欄位；適用相關層級時，另有 anthropic-priority-* 與 anthropic-fast-* | Reset 採 RFC 3339 格式；剩餘數量四捨五入至最接近的千位；tokens-* 三個欄位顯示「目前生效的最嚴格限制」 |
| Groq | x-ratelimit-limit-requests（每日）、x-ratelimit-limit-tokens（每分鐘）、x-ratelimit-remaining-*、x-ratelimit-reset-*；「一律包含」 | Reset 採持續時間格式，例如 "2m59.56s"、"7.66s"；retry-after 單位為秒，只在 429 出現 |
| Mistral | X-RateLimit-Remaining | |
| Gemini、xAI、Alibaba、DeepSeek、MiniMax、Kimi、Bedrock、Vertex AI | 沒有文件記載 | Gemini、Alibaba 和 Bedrock 會在錯誤本文中指出原因；Kimi 記載過載時會提供 Retry-After；若服務有傳送，AWS SDK 會讀取以毫秒表示的 x-amz-retry-after |
實務上的問題是，同一欄位有 3 種格式：OpenAI 的持續時間、Anthropic 的時間戳記，以及 Groq 的 2m59.56s，需要 3 套解析器。這也是 SDK 通常只讀取 retry-after 的原因之一。2026-09-03 針對兩個中介服務各發送一次請求進行測量。一個大型多供應商彙整平台在 200 回應中完全不提供速率限制標頭，只在 429 回應中提供；Synthorai 閘道則會回傳 x-ratelimit-remaining-requests、x-ratelimit-reset-requests，以及該請求的成本。
429 代表什麼？該重試嗎？
429 可能代表 4 種不同情況，其中只有 2 種適合重試：
| 含義 | 是否重試？ | 各供應商的表示方式 |
|---|---|---|
| 節流：超過限制 | 是，等待 Retry-After 或退避後重試 | OpenAI 與 Anthropic 的 429 rate_limit_error，Anthropic 另附 retry-after；Gemini 與 Vertex AI 的 429 RESOURCE_EXHAUSTED，在 Vertex AI 代表共用資源池容量不足；Kimi 的 rate_limit_reached_error；Bedrock 的 ThrottlingException，以及 SDK 最多重試 5 次的 ModelNotReadyException；Azure 的「Rate limit is exceeded」；xAI 的 RateLimitError；Alibaba 的「Requests rate limit exceeded」；DeepSeek 與 Mistral 的 429 |
| 加速限制：流量增長過快 | 降低增長速度，再重試 | OpenAI 的 slow_down；Anthropic 的「acceleration limits」；Alibaba 的「Request rate increased too quickly」；Azure 的 1 秒或 10 秒時間窗內突發流量 |
| 配額或支出上限：等待不會釋放額度 | 否，修正帳務問題或等待重設日期 | OpenAI 的 insufficient_quota、credit_balance_exhausted、organization_spend_limit_exceeded；Anthropic 的 enforced_spend_limit_reached 不含 retry-after，而自行設定的支出上限會回傳 400；Gemini 的 quota_exceeded（每日）；Kimi 的 exceeded_current_quota_error；Bedrock 的 400 ServiceQuotaExceededException；彙整平台與 DeepSeek 的 402。Azure 的配額在部署時分配，因此用盡配額不會回傳 429 |
| 過載：不足的是供應商容量，不是你的額度 | 是，退避後重試 | OpenAI 的 503 server_is_overloaded；Anthropic 的 529 overloaded_error；Gemini 的 503 UNAVAILABLE；Kimi 的 429 engine_overloaded_error，並附 Retry-After；Bedrock 的 503 ServiceUnavailableException 與 529 overloaded_error；Azure 的「System is experiencing high demand」、共用資源池的「temporary rate limit adjustment」，或 PTU 使用率達 100% 並附 retry-after-ms；DeepSeek 的 503 |
陷阱在第三列。Anthropic 的支出上限 429 與節流使用相同的 rate_limit_error 類型，文件明確指出：「在存取權恢復前，所有重試都會失敗，包括 SDK 的自動重試。」OpenAI 的 insufficient_quota 同樣也是 429。只根據狀態碼判斷的用戶端會重試這兩種錯誤，而下一節列出的所有官方 SDK 都會這麼做。應根據錯誤碼分流；如果 429 沒有 Retry-After，通常代表等待也無法解決。
第四列顯示了各雲端平台的差異。Azure 的疑難排解指南說得很直接：「許多客戶把容量相關的 429 誤判為配額問題，導致採取錯誤的處理方式。」在 Azure 上，如果 429 的 x-ratelimit-limit-tokens 低於設定值，代表共用資源池正在保護自身；Vertex AI 的每一個隨用隨付 429 都是這種情況；Bedrock 則會將相同狀況回傳為 503 或 529，絕不會是 ThrottlingException。經過彙整平台時，原因會出現在錯誤本文中：測量標頭時收到的一個 429，被包裝為 provider_error_code: insufficient_quota、limit_source: upstream_provider_shared_pool。狀態碼表示節流，本文卻顯示是別人的配額。
SDK 遇到 429 時會怎麼做？
行為取決於 SDK，其中兩個最常用的 SDK 預設完全不處理。下表直接取自各官方用戶端在 2026-09-04 的原始碼，而不是文件：
| SDK | 預設重試 | 會重試的狀態 | 退避 | Retry-After 處理方式 |
|---|---|---|---|---|
| openai-python（也包含 Azure OpenAI） | 2 次 | 408、409、429、5xx，或依 x-should-retry 決定 | min(0.5 × 2^n, 8) 秒並加入 jitter | 先讀取 retry-after-ms，再將 retry-after 解析為秒數或日期；超過 120 秒時完全不重試 |
| anthropic-sdk-python、groq-python | 2 次 | 相同 | 相同 | 解析方式相同；超過 60 秒時忽略標頭，改用退避公式 |
| openai-node、anthropic-sdk-typescript | 2 次 | 相同 | 相同 | 相同；超過 60 秒時改用預設退避 |
| google-genai（Python，Gemini API 與 Vertex AI） | 0 次：retry_options 預設為 None，因此只嘗試一次 | 啟用時：408、429、500、502、503、504 | 啟用時：嘗試 5 次，從 1 秒開始倍增，最高 60 秒，並加入 jitter | 不讀取 Retry-After |
| mistralai（Python） | 0 次：retry_config 預設未設定 | 設定後：429、500、502、503、504 | 設定後：500 毫秒 × 1.5^n，最高 60 秒，總時間最多 1 小時 | 遵循任何 Retry-After，支援秒數或日期 |
| boto3（Bedrock） | 舊版模式：共嘗試 5 次，包含第一次；標準模式：3 次 | ThrottlingException 與同類錯誤、429、5xx | 標準模式的基數為 2，上限 20 秒。2026 年行為需透過 AWS_NEW_RETRIES_2026=true 啟用，採 full jitter，節流的基準值為 1,000 毫秒，並使用重試權杖桶 | 不處理 Retry-After；2026 年行為會讀取以毫秒表示的 x-amz-retry-after，上限為退避時間加 5 秒 |
| xai-sdk（Python、gRPC） | 嘗試 5 次，但只針對 UNAVAILABLE | 不重試相當於 gRPC 429 的 RESOURCE_EXHAUSTED | 從 0.1 秒開始倍增，最高 1 秒 | 不適用 |
| dashscope（Alibaba） | HTTP 狀態碼預設不重試；如果連線池中的連線在收到任何位元組前中斷，會重新傳送一次 | |||
| DeepSeek、Kimi、MiniMax | 沒有第一方聊天 SDK；DeepSeek 文件建議使用不同 base URL 的 OpenAI/Anthropic SDK |
可得出 3 個結論。第一，Gemini、Vertex AI 或 Mistral 的 429 第一次出現就會直接傳到應用程式，除非明確傳入重試選項。google-genai 原始碼中「will retry 4 times」的註解描述的是啟用後的設定，不是預設行為。第二，Retry-After 上限反而不利於供應商要求的長時間等待：Anthropic SDK 收到等待 90 秒的指示時會忽略標頭，並在不到 8 秒內再次送出請求；OpenAI SDK 收到等待 150 秒的指示時則直接停止重試。第三，由 Stainless 產生的 SDK，也就是 OpenAI、Anthropic 和 Groq 用戶端背後的程式碼產生器，會先遵循未公開記載的 x-should-retry 標頭，再檢查狀態碼；也會先讀取 retry-after-ms，再讀取 retry-after。供應商或閘道不需要修改狀態碼，就能控制重試行為。
這些 SDK 都不會區分支出上限 429 與節流。單次 insufficient_quota 回應只會浪費幾秒鐘進行兩次重試，但整個服務叢集大規模這麼做，就會製造額外的突發流量。
閘道會帶來哪些改變？
閘道是唯一能集中處理這些差異的地方。面向上游時，它負責讀取各供應商提供的標頭，處理 3 種重設格式與 4 種 429 語意，不必讓每個用戶端各自實作；面向下游時，則提供統一的標頭與錯誤格式，前文實測的 Synthorai 標頭就是這種做法。閘道無法改變供應商的計量方式：連到 OpenAI 時，用戶端的 max_tokens 仍會預先扣除 TPM；連到 Bedrock 時，每個 Claude 輸出權杖仍會消耗 10 個配額權杖。如果閘道把許多用戶端集中到同一把供應商金鑰，也會比任何單一用戶端更快觸發供應商的加速限制。因此需要按金鑰建立權杖桶，而不是只使用一個共用計數器。
FAQ
max_tokens 會計入速率限制嗎？
OpenAI、Azure OpenAI 和 Bedrock 會。請求抵達時就會按 max_tokens 扣除，因此設定過大時，即使回答很短也會浪費 TPM；Bedrock 會在回應完成後修正扣除量。Anthropic 不會，OTPM 只計算實際產生的權杖，max_tokens「不影響」計算。
快取權杖會計入速率限制嗎？
Anthropic、Bedrock 和 Azure PTU 部署不會，這些平台都排除快取讀取。xAI 則會完整計入。OpenAI 和 Gemini 沒有說明。
429 一定會附上 Retry-After 嗎？
不一定。OpenAI、Azure（使用 retry-after-ms）和 Groq 會在節流時提供；Anthropic 在節流時提供，但支出上限不會；Kimi 和 Bedrock 只在過載時提供。Gemini、Vertex AI、xAI、Alibaba、DeepSeek 和 MiniMax 都沒有相關文件，因此用戶端必須自行實作退避。
為什麼我的 SDK 沒有重試 429？
如果使用 Google GenAI 或 Mistral Python SDK，重試預設關閉，必須傳入 retry_options 或 RetryConfig。如果使用 OpenAI Python SDK，而伺服器要求等待超過 120 秒，SDK 會刻意不重試。如果 429 代表配額或支出上限，而不是節流，那麼不重試才是正確行為。