LLM API のレート制限 13 社比較、2 SDK は 429 を再試行しない
目次
ここでは 13 の LLM API、ベンダー 10 社に Bedrock、Vertex AI、Azure OpenAI を加えて調査した。すべてのレスポンスで残り枠を返すのは 4 つ、残数を 1 つだけ返すのが Mistral、残る 8 つはリクエストが失敗するまで何も返さない。「429」が示す状態は 4 種類ある。再試行すべきスロットリング、送信ペースを落とすべき加速制限、再試行しても解消しない quota または利用額上限、ベンダーによって 429、503、529 のいずれかで返される過負荷だ。挙動はベンダーだけでなくクライアントにも左右される。OpenAI、Anthropic、Groq の SDK は 429 を 2 回再試行するが、Retry-After が 60 秒または 120 秒を超えると打ち切る。Google GenAI と Mistral の SDK は、デフォルトで再試行しない。本稿ではベンダー横断のリファレンスとして、制限の軸、算入される token、header、429 の意味、公式 SDK の挙動をソースコードから確認する。
TL;DR
- ほぼすべての LLM API は、1 分あたりのリクエスト数と token 数を制限する。Anthropic は入力と出力を分け、DeepSeek は同時実行数だけを制限する。
- OpenAI、Azure、Bedrock は
max_tokensを先に消費枠から差し引く。Anthropic は cache read を除外し、xAI は reasoning token も算入する。Bedrock では Claude 5 の出力 token 1 個につき quota token を 10 個消費する。 - OpenAI、Anthropic、Groq、Azure は、すべての 200 レスポンスで残量と reset の header を返す。8 つの API は何も文書化していない。
- google-genai と Mistral の SDK は、デフォルトでは 429 を再試行しない。OpenAI、Anthropic、Groq は 2 回再試行し、Retry-After の上限を 60 秒または 120 秒としている。
RPM、TPM、その他の制限は何を意味するのか
いずれも一定の window 内で送信できる量の上限だ。採用する指標は provider ごとに異なる。
| 分類 | 用語 | 意味と採用 provider |
|---|---|---|
| リクエスト単位の指標 | RPM、RPD、RPS、同時実行数 | 1 分または 1 日あたりのリクエスト数。サイズに関係なく 1 call を 1 件として数える。RPS は通常 RPM を 60 で割った値で、burst を抑えるために適用される。採用例は xAI、Alibaba、Mistral、Azure。同時実行数は window ごとの件数ではなく処理中のリクエスト数を数える。DeepSeek が設けている制限はこれだけ |
| token 単位の指標 | TPM、TPD、ITPM、OTPM、burndown rate | 1 分または 1 日あたりの token 数。一部の provider は入力の ITPM と出力の OTPM に分ける。burndown rate は出力 token を quota に計上する前に一定倍率で増やす仕組みで、Bedrock が採用している。どの token を算入するかも provider ごとに異なり、次節で扱う |
| その他の単位 | IPM、音声秒数、OCR ページ数 | 画像モデルの 1 分あたりの画像数で、OpenAI と Gemini が採用。1 時間または 1 日あたりの音声秒数は Groq と Mistral、文書 OCR の 1 分あたりのページ数は Mistral が採用 |
| window の適用方式 | Token bucket、加速制限 | Token bucket は毎分リセットされず継続的に補充される。このため 1 分あたりの合計が上限内でも、burst で bucket が空になる。Anthropic が採用し、Alibaba と Azure も同じ挙動を説明している。加速制限は利用量の増加速度に対する別のチェックで、上限内でも急激に増やすと抵触する。Anthropic と OpenAI の slow_down が該当 |
| 上限値の決まり方 | Tier、利用額上限または quota、provisioned capacity | Tier は上記の各上限を決める区分で、credit の追加購入ではなく、有料利用額や利用履歴に応じて上がる。利用額上限や日次 quota は金額または量の上限であり、rate ではない。1 分待っても解消しない。Provisioned capacity は unit 単位の時間課金で予約する throughput で、Bedrock、Vertex AI Provisioned Throughput、Azure PTU が採用する。この場合の 429 は quota の枯渇ではなく、予約容量が埋まったことを意味する |
画面に表示される値は window の上限であり、均等に使える割当量ではない。Anthropic は 60 RPM でも「1 秒あたり 1 リクエストとして適用される場合がある」と説明している。Azure も「1 秒または 10 秒の window 内で burst が起きると、1 分あたりの合計が上限内でも 429 が発生し得る」としている。
LLM API は何をレート制限するのか
ほぼすべてが 1 分あたりのリクエスト数と token 数を制限する。3 つの cloud は、各ベンダーのルールをそのまま中継しているわけではない。以下は 2026-09-03 と 2026-09-04 時点でリンク先に記載されていた provider 自身の定義だ。
| Provider | 制限軸 | 上限の拡張方法 | 出典 |
|---|---|---|---|
| OpenAI | RPM、RPD、TPM、TPD、IPM、1 分あたりの音声分数。Batch API の queue は待機中の入力 token 数で制限 | 累計支払額に応じて Tier 1 から 5 | レート制限 |
| Anthropic | model class ごとの RPM、ITPM、OTPM。token bucket と加速制限 | 利用履歴に応じて Start、Build、Scale tier | レート制限 |
| Google Gemini | RPM、TPM（入力）、RPD。画像モデルでは IPM | Free の後、10 分あたりの利用額上限に応じて Tier 1 から 3 | レート制限 |
| xAI | model ごとの RPS（RPM / 60）と TPM | Tier 0 から 4 と Enterprise | レート制限 |
| Alibaba Model Studio | model ごとの RPM と TPM。burst 制限として RPS = RPM / 60、TPS = TPM / 60 | model ごと。一部の model は batch を除外 | レート制限 |
| DeepSeek | 同時実行数のみ。V4 Pro は 500 connection、V4 Flash は 2,500 connection | model ごとに固定 | レート制限 |
| Mistral | workspace と model ごとの RPS、1 分あたりの token 数、1 か月あたりの token 数 | 累計請求額に応じて Tier 1 から 4。「credit を追加してもレート制限は増えない」 | 利用量と上限、ヘルプセンター |
| MiniMax | model ごとの RPM と TPM。MiniMax M3 は 200 RPM、10M TPM | sales に問い合わせ | レート制限 |
| Moonshot Kimi | 同時実行数、RPM、TPM、TPD。Tier 0 は同時実行 1、3 RPM。Tier 5 は同時実行 100、300 RPM | 累計入金額に応じた 6 tier。$1 から $3,000 | 上限 |
| Groq | RPM、RPD、TPM、TPD、ITPM、OTPM、1 時間と 1 日あたりの音声秒数 | model ごと | レート制限 |
| Amazon Bedrock | region と model ごとの RPM、TPM、TPD。TPD のデフォルトは TPM x 1,440 | Service Quotas で申請して引き上げ。新規 account は低い上限から開始 | quota |
| Google Vertex AI | pay-as-you-go には project ごとの固定値がない。共有 pool を使い、「組織の過去の支出額によって Usage Tier と baseline throughput（TPM）が決まり」、best-effort の bursting が可能 | 支出額に応じた Usage Tier。Provisioned Throughput は「共有 PayGo pool から分離された容量を提供」 | Google Cloud blog |
| Azure OpenAI | deployment ごとに TPM を割り当て、そこから RPM を算出。旧 model は 1,000 TPM あたり 6 RPM、現行 model は 1,000 TPM あたり 1 RPM。PTU deployment は使用率で制限 | quota Tier 0 から 6。自動で昇格 | quota と上限、quota 管理 |
このうち 2 つは 1 分単位の window ではない。DeepSeek は開いている connection 数を制限する。負荷が高い場合は拒否せず、空行を返し続ける。stream では : keep-alive comment を返し、最大 10 分間リクエストを維持する。Vertex AI の pay-as-you-go には参照できる quota 値がない。429 は、その時点で共有 pool の容量が足りなかったことを示す。
レート制限にはどの token が算入されるのか
課金対象の token と同じとは限らない。この差により、実際に使える容量は画面上の値の数分の 1 にも数倍にもなる。
| Provider | token 上限に算入されるもの | 影響 |
|---|---|---|
| OpenAI | max_tokens と prompt から推定した値の大きい方を、到着時に差し引く。「max_tokens を高く設定しすぎると、実際のレスポンスがかなり短くても利用量が過大に見積もられることがある」（cookbook） | 50 token の回答でも max_tokens が 4,000 なら、TPM を 4,000 消費する |
| Azure OpenAI | 「prompt の text と件数、max_tokens parameter の設定、best_of parameter の設定」から推定し、一部は文字数に基づく。PTU deployment では「cached token は 100% 割引」（quota guide） | 「予想より早くレート制限が発生する場合がある」。max_tokens を設定しない場合は自動で推定される |
| Amazon Bedrock | 開始時に「入力 token 合計 + max_tokens」を差し引き、終了時に InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate) へ補正する。cache read は除外。burndown は Claude 4.7 以前で 5x、Sonnet 5、Opus 5、Fable 5.1、GPT-5.6 model で 10x、Claude 4.8 で 15x（token の計数） | 文書にある例では、5x model で入力 1,000 token、出力 100 token の場合、quota token を 1,500 消費し、課金対象は 1,100 token |
| Anthropic | ITPM は input_tokens と cache_creation_input_tokens を算入する。cache_read_input_tokens は「ITPM に算入されない」。OTPM は実際の出力を算入し、「max_tokens は OTPM に影響しない」（docs） | 文書にある例では、cache hit 率 80% なら 2M ITPM で 1 分あたり 10M input token を処理できる |
| xAI | 「リクエストが消費するすべての token が TPM 上限に算入される。prompt token（text、image、audio）、completion token、reasoning model の reasoning token、cached prompt token」 | 画面に出ない reasoning token も TPM を消費する。cache を使っても throughput は増えない |
| Google Gemini | 入力 token | 出力長は上限を消費しない |
| Alibaba、Mistral、MiniMax | 入力と出力 | |
| Kimi、Groq、DeepSeek、Vertex AI | 記載なし | Groq は ITPM と OTPM を別々に計測する。DeepSeek に token 上限はない。Vertex AI は Usage Tier の baseline しか公開していない |
同じリクエストでも、各上限に対するサイズは異なる。上の例では 800 から 6,000 token まで差がある。1 つの workload を複数ベンダーへ振り分ける router には、ベンダーごとの meter が必要だ。
各 provider はどの header を返すのか
4 つの API はすべてのレスポンスに上限の状態を含める。Mistral は 1 field だけ返し、残る 8 つではクライアント側で数える必要がある。
| Provider | 通常レスポンスの header | 形式に関する注記 |
|---|---|---|
| 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 の 3 項目 | Reset は「レート制限がリセットされるまでの時間」。429 では Retry-After |
| Azure OpenAI | すべての call で同じ 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 にも同じ 3 項目。該当する tier では anthropic-priority-* と anthropic-fast-* も返す | Reset は RFC 3339。remaining は最も近い 1,000 単位に丸める。tokens-* の 3 項目は「現在有効な制限のうち最も厳しいもの」を示す |
| Groq | x-ratelimit-limit-requests（日次）、x-ratelimit-limit-tokens（分単位）、x-ratelimit-remaining-*、x-ratelimit-reset-*。「常に含まれる」 | Reset は duration 形式で、"2m59.56s"、"7.66s"。秒単位の retry-after は 429 のみ |
| Mistral | X-RateLimit-Remaining | |
| Gemini、xAI、Alibaba、DeepSeek、MiniMax、Kimi、Bedrock、Vertex AI | 文書化なし | Gemini、Alibaba、Bedrock は error body に理由を記載する。Kimi は過負荷時の Retry-After を文書化している。AWS SDK は service が送信した場合、ミリ秒単位の x-amz-retry-after を読む |
実装上の問題は、同じ field に 3 種類の形式があることだ。OpenAI の duration、Anthropic の timestamp、Groq の 2m59.56s には、それぞれ別の parser が必要になる。SDK が retry-after しか読まない理由の 1 つでもある。2026-09-03 に 2 つの中継サービスへそれぞれ 1 回ずつリクエストを送り、挙動を確認した。ある大手 multi-provider aggregator は 200 で rate-limit header を一切返さず、429 の場合だけ返していた。Synthorai gateway は、リクエストの cost とともに x-ratelimit-remaining-requests と x-ratelimit-reset-requests を返した。
429 は何を意味し、再試行すべきか
429 が示す状態は 4 種類あり、再試行すべきなのは 2 種類だけだ。
| 意味 | 再試行 | provider ごとの表現 |
|---|---|---|
| スロットリング。上限を超えた | Retry-After または backoff の後に再試行 | OpenAI と Anthropic は 429 rate_limit_error。Anthropic は retry-after も返す。Gemini と Vertex AI は 429 RESOURCE_EXHAUSTED。Vertex AI では共有 pool の容量不足を意味する。Kimi は rate_limit_reached_error。Bedrock は ThrottlingException で、ModelNotReadyException は SDK が最大 5 回再試行する。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 秒の window 内の burst |
| quota または利用額上限。待っても枠が空かない | 再試行しない。billing を修正するか、reset 日まで待つ | OpenAI は insufficient_quota、credit_balance_exhausted、organization_spend_limit_exceeded。Anthropic は retry-after なしの enforced_spend_limit_reached。ユーザー自身が設定した利用額上限では 400。Gemini は日次の quota_exceeded。Kimi は exceeded_current_quota_error。Bedrock は 400 ServiceQuotaExceededException。aggregator と DeepSeek は 402。Azure は quota を deployment 時に割り当てるため、その枯渇は 429 ではない |
| 過負荷。利用者側ではなく provider 側の容量不足 | backoff して再試行 | OpenAI は 503 server_is_overloaded。Anthropic は 529 overloaded_error。Gemini は 503 UNAVAILABLE。Kimi は Retry-After 付きの 429 engine_overloaded_error。Bedrock は 503 ServiceUnavailableException と 529 overloaded_error。Azure は「System is experiencing high demand」、共有 pool の「一時的なレート制限調整」、または PTU の使用率が 100% に達した状態で retry-after-ms を返す。DeepSeek は 503 |
注意すべきなのは 3 行目だ。Anthropic の利用額上限による 429 は、スロットリングと同じ rate_limit_error type を返す。文書には「SDK の自動再試行を含め、アクセスが再開するまで再試行は失敗する」とある。OpenAI の insufficient_quota も 429 だ。status code だけで分岐するクライアントは、どちらも再試行する。次節で示すとおり、公式 SDK はすべてそう動く。error code で分岐し、Retry-After のない 429 は、待っても解消しない可能性を示すものとして扱うべきだ。
4 行目は cloud ごとの差が大きい。Azure の troubleshooting guide には「多くの顧客が容量不足による 429 を quota の問題と誤認し、誤った対処をしている」と明記されている。Azure では、x-ratelimit-limit-tokens が設定済みの上限より小さい 429 は、共有 pool が自身を保護している状態だ。Vertex AI では pay-as-you-go の 429 がすべてこれに該当する。Bedrock では同じ状態を ThrottlingException ではなく、必ず 503 または 529 で返す。aggregator 経由では body に現れる。header 計測中に届いた 429 の 1 件は、provider_error_code: insufficient_quota、limit_source: upstream_provider_shared_pool として wrap されていた。status はスロットリングを示していたが、body は別の利用者の quota が原因だと示していた。
SDK は 429 をどう処理するのか
挙動は SDK ごとに異なり、広く使われている 2 つの SDK は何もしない。文書ではなく、2026-09-04 時点の各公式 client のソースコードを確認した。
| SDK | デフォルトの再試行 | 再試行する status | Backoff | Retry-After の扱い |
|---|---|---|---|---|
| openai-python（Azure OpenAI を含む） | 2 | 408、409、429、5xx、または x-should-retry が指示したもの | jitter 付きの min(0.5 × 2^n, 8) 秒 | retry-after-ms、次に秒または日付形式の retry-after を読む。120 秒を超える場合は一切再試行しない |
| anthropic-sdk-python、groq-python | 2 | 同上 | 同上 | parser は同じ。60 秒を超える header は無視し、backoff 式を使う |
| openai-node、anthropic-sdk-typescript | 2 | 同上 | 同上 | 同上。60 秒を超える場合はデフォルトの backoff に戻る |
| google-genai（Python、Gemini API、Vertex AI） | 0。retry_options のデフォルトは None で、1 回の試行に解決される | 有効時は 408、429、500、502、503、504 | 有効時は 5 回。1 秒から倍増し、最大 60 秒。jitter あり | Retry-After を読まない |
| mistralai（Python） | 0。retry_config のデフォルトは未設定 | 設定時は 429、500、502、503、504 | 設定時は 500 ms × 1.5^n。最大 60 秒、合計 1 h | 秒または日付形式のすべての Retry-After に従う |
| boto3（Bedrock） | legacy mode は初回を含め 5 回。standard mode は 3 回 | ThrottlingException とその関連 error、429、5xx | standard mode では base factor 2、上限 20 秒。2026 年版の挙動は AWS_NEW_RETRIES_2026=true で opt-in し、full jitter、スロットリング時の base は 1,000 ms、retry token bucket を使う | Retry-After は読まない。2026 年版はミリ秒単位の x-amz-retry-after を読み、backoff に 5 秒を加えた値までに制限する |
| xai-sdk（Python、gRPC） | UNAVAILABLE に対してのみ 5 回 | gRPC の 429 に相当する RESOURCE_EXHAUSTED は再試行しない | 0.1 秒から倍増し、最大 1 秒 | n/a |
| dashscope（Alibaba） | HTTP status による再試行は 0。pool した connection が 1 byte も受信せず切断された場合のみ 1 回再送 | |||
| DeepSeek、Kimi、MiniMax | first-party の chat SDK はない。DeepSeek の文書は base URL を変更して「OpenAI/Anthropic SDK を使う」よう案内している |
ここから 3 つのことが分かる。第一に、Gemini、Vertex AI、Mistral の 429 は、retry option を渡さなければ初回からアプリケーション側へ返る。google-genai のソースコメントには client が「4 回再試行する」とあるが、これは有効化した場合の設定であり、デフォルトではない。第二に、Retry-After の上限は、ベンダーが実際に要求する長い待機時間と噛み合わない。Anthropic の SDK は 90 秒待つよう求められても header を無視し、8 秒未満で再試行する。OpenAI の SDK は 150 秒を指定されると再試行を打ち切る。第三に、Stainless が生成した SDK、つまり OpenAI、Anthropic、Groq の client は、status code より先に未文書化の x-should-retry header を確認する。また retry-after より先に retry-after-ms を読む。ベンダーや gateway は status code を変えずに再試行を制御できる。
どの SDK も、利用額上限による 429 とスロットリングを区別しない。insufficient_quota を 2 回再試行しても、1 client あたりの損失は数秒で済む。しかし fleet 全体が大規模に同じ動きをすれば、自ら burst を引き起こす。
gateway を入れると何が変わるのか
gateway を使えば、これらの差異を 1 か所で処理できる。upstream 側では各ベンダーの header を読み、3 種類の reset 形式と 4 種類の 429 を gateway 側で吸収する。downstream 側では統一した header と error 形式を返せる。前述の Synthorai で計測した header がその例だ。ただし gateway でも、ベンダーの計上方法は変えられない。OpenAI の背後ではクライアントの max_tokens が引き続き TPM から先に差し引かれ、Bedrock の背後では Claude の出力 token 1 個が 10 token 分を消費する。また、多数のクライアントを 1 つのベンダー key に集約する gateway は、個々のクライアントより早くベンダーの加速制限に達する。対策には共有 counter を 1 つ置くのではなく、key ごとの bucket が必要だ。
FAQ
max_tokens はレート制限に算入されるか
OpenAI、Azure OpenAI、Bedrock では算入される。リクエスト到着時に max_tokens が差し引かれるため、回答が短くても過大な値を設定すると TPM を無駄にする。Bedrock はレスポンス完了時に差し引き量を補正する。Anthropic では算入されない。OTPM は実際に生成された token を数え、max_tokens は「影響しない」。
cached token はレート制限に算入されるか
Anthropic、Bedrock、Azure PTU deployment では算入されず、cache read は除外される。xAI では全量が算入される。OpenAI と Gemini は明記していない。
429 では必ず Retry-After が返るか
返らない。OpenAI、Azure（retry-after-ms）、Groq はスロットリング時に返す。Anthropic もスロットリング時には返すが、利用額上限では返さない。Kimi と Bedrock は過負荷時だけ返す。Gemini、Vertex AI、xAI、Alibaba、DeepSeek、MiniMax は文書化していないため、クライアント側で独自の backoff が必要になる。
SDK が 429 を再試行しなかったのはなぜか
Google GenAI または Mistral の Python SDK では、デフォルトで再試行が無効になっている。retry_options または RetryConfig を渡す必要がある。OpenAI Python SDK では、server が 120 秒を超える待機を要求すると、意図的に再試行しない。429 がスロットリングではなく quota または利用額上限によるものなら、再試行しないのが正しい。
関連記事：課金単位フィールドガイド、長いコンテキストの料金 tier、token 使用量の内訳、gateway cache 監査。