LLM 429 レート制限 & ワーカー並列数計算ツール
稼働中の2026年モデル60件を対象に、必要なRPM・入力TPM(ITPM)・出力TPM(OTPM)を算出し、本番リリース前にクォータ上限のボトルネックを検知してフルジッター付きリトライ設定をコピーできます。
本番クォータ & ワーカー並列数サイジング・ワークベンチ
安全 (84% 最大バケット: ITPM)
必要RPM
240
必要入力TPM
840,000
必要出力TPM
144,000
安全な最大ワーカー並列数
16
推奨キュー深さ
48
クォータ使用率 & ボトルネック診断
// Full-jitter exponential backoff + Retry-After guard (google/gemini-4-hydrogen)
export async function callWithRateLimitGuard<T>(
fn: () => Promise<Response>,
maxRetries = 5,
baseDelayMs = 500,
maxDelayMs = 30_000
): Promise<T> {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
const res = await fn();
if (res.status !== 429 && res.status < 500) {
return (await res.json()) as T;
}
if (attempt === maxRetries) {
throw new Error(`LLM quota exhausted (HTTP ${res.status}) after ${maxRetries} retries`);
}
const retryAfterSec = Number(res.headers.get('retry-after'));
const ceiling = Math.min(maxDelayMs, baseDelayMs * 2 ** attempt);
const sleepMs = Number.isFinite(retryAfterSec) && retryAfterSec > 0
? retryAfterSec * 1000
: Math.floor(Math.random() * ceiling);
await new Promise((r) => setTimeout(r, sleepMs));
}
throw new Error('Unreachable');
}
LLMの 429 レート制限ボトルネックが発生する仕組み
エンタープライズ向けLLM APIゲートウェイは、RPM(毎分リクエスト数)、ITPM(RAGチャンクを含む毎分入力トークン数)、OTPM(毎分出力トークン数)の3つのトークンバケット上限を同時に適用します。他の2つが使用率20%未満でも、いずれか1つを超過するとHTTP 429 が返されます。クォータ設計とあわせて30日間APIコストを試算し、LLMEOLでモデルのEOLスケジュールも確認してください。
本番キューイング & リトライ設計ガードレール
- 実行中ワーカー並列数の上限設定: リトルの法則(
Concurrency = Safe_RPM × Avg_Latency_Sec ÷ 60)に15%の安全マージンを加えてワーカープールを制御します。 Retry-Afterヘッダーを最優先で尊重: 複数エージェントが一斉に再試行してクォータ枠を踏み潰さないよう、フルランダムジッター付きの指数バックオフへフォールバックします。- 非対話ジョブをBatch APIへオフロード: 夜間評価や文書抽出バッチを24時間非同期キューへ移すことで、リアルタイムRPM制限を回避しつつLLMトークン費用を50%削減できます。
よくある質問
リクエスト数がRPM上限よりはるかに少ないのにHTTP 429エラーが出るのはなぜですか?
長大なRAGプロンプトやマルチターンのエージェント履歴により、毎分リクエスト数(RPM)に達するずっと前に入力TPM(ITPM)または出力TPM(OTPM)のトークンバケットが枯渇するためです。
プロンプトキャッシュを使うと入力TPMレート制限も緩和されますか?
プロンプトキャッシュは入力トークン課金を90%〜95%削減し、多くのプロバイダーではキャッシュヒット分を非キャッシュITPM枠から除外します。具体的なコスト削減額はLLMコスト計算ツールで試算できます。
固定間隔のリトライではなくフルジッター指数バックオフを使う理由は何ですか?
固定待機時間では同じ秒に制限された並列ワーカーが一斉に再試行して再び制限を引き起こしますが、フルランダムジッターを使えばTypeScriptやPythonのSDKで再試行タイミングを回復ウィンドウ全体に分散できます。