直接回答
すべての 429 が短時間の rate limit とは限りません。再試行前に本文とヘッダーを読み、通信量制限と quota・残高不足を分けます。
このガイドで解決できること
retry storm や処理重複を起こさず API rate limit と quota エラーを解決する。
OpenAI 互換 APIPython / Node.js SDKcurlリバースプロキシと API ゲートウェイworker と batch job
01
症状
burst、長い context、並列 worker で 429 が発生し、Retry-After や rate-limit header が付くことがあります。
残高、project budget、account quota、model 権限が尽きた場合は単一リクエストも継続的に失敗します。
02
主な原因
- 毎分 request、毎分 token、同時 request が上限を超えている。
- 残高、前払い quota、project budget、account credit が不足している。
- 独立 worker が共通 limiter なしで同時に再試行している。
- 長い prompt と大きい output budget が token capacity を急速に消費する。
03
診断手順
- 01境界を確定本文を throttling、quota、budget、balance、access に分類します。
- 02基準を作成RPM、TPM、同時実行数、入力量、output budget、retry 回数を記録します。
- 03一項目を比較Retry-After と reset header があれば優先します。
- 04決定的な証拠を記録worker を停止し、単一 request で account の基準状態を確認します。
最小診断コマンド言語：bash
date -u
curl -sS -D /tmp/rate-headers.txt -o /tmp/rate-body.json 'https://<your-api-host>/v1/models' -H "Authorization: Bearer ${API_KEY:?set API_KEY first}"
sed -n '1,30p' /tmp/rate-headers.txt
04
修正
- 01障害レイヤーを修正process ごとではなく worker 全体で共有する queue・limiter を使います。
- 02必要な動作を復元jitter、最大回数、総 deadline 付き exponential backoff を適用します。
- 03一時回避策を除去context と同時実行数を減らすか、必要な残高・予算・権限を回復します。
修正例言語：text
for attempt in 0..4:
response = request()
if response.status != 429: return response
if response.error is quota_or_billing: stop_and_alert()
wait = retry_after ?? min(30s, 2^attempt + random_jitter)
sleep(wait)
raise rate_limit_exhausted05
検証
- 全 worker が実効的な同時実行・rate budget を共有する。
- retry に jitter、回数上限、総時間上限がある。
- 残高、project budget、model access を個別に確認した。
- 段階的な増量で latency と 429 率が再上昇しない。
06
機密情報の扱い
- token 負荷測定で完全な prompt を記録しない。
- billing failure を一時エラーとして再試行しない。
- idempotency と task state で副作用の重複を防ぐ。
- 機密除去した limit header、負荷指標、UTC 時刻、request ID で共有する。
公式情報と検証範囲
本ガイドはプロトコル仕様とクライアント公式文書を根拠にしています。エラー文、再試行ヘッダー、設定項目はサービスやバージョンで変わるため、参照元を確認し、ログとリクエスト例を秘匿してから共有してください。
ドキュメントの適用範囲を見る