直接回答
すべての 429 が短時間の rate limit とは限りません。再試行前に本文とヘッダーを読み、通信量制限と quota・残高不足を分けます。
このガイドで解決できること
retry storm や処理重複を起こさず API rate limit と quota エラーを解決する。
症状と影響範囲を確認する
burst、長い context、並列 worker で 429 が発生し、Retry-After や rate-limit header が付くことがあります。
残高、project budget、account quota、model 権限が尽きた場合は単一リクエストも継続的に失敗します。
- 設定を変更する前に、ステータスまたは例外、レスポンス本文、request ID、UTC 時刻、クライアント版、最終ホストを保存します。
- 最小リクエストと失敗するワークフローを比較し、全体障害、モデル固有、機能固有のどれかを切り分けます。
- 認証情報、完全なプロンプト、顧客データ、非公開ファイルをスクリーンショットやサポート資料に含めません。
主な原因と責任境界
エラーは一つのレイヤーから得た証拠であり、下流全体の故障を証明するものではありません。まず次の可能性を順に検証します。
- 毎分 request、毎分 token、同時 request が上限を超えている。
- 残高、前払い quota、project budget、account credit が不足している。
- 独立 worker が共通 limiter なしで同時に再試行している。
- 長い prompt と大きい output budget が token capacity を急速に消費する。
レイヤー別に最小診断を行う
可変要素が最も少ないリクエストから開始します。アカウント、API ホスト、対象モデルは維持し、任意機能だけを外します。
一度に一項目だけ変更し、元のステータス、ヘッダー、本文、所要時間を残します。これによりクライアントのシリアライズとゲートウェイ・上流の挙動を分離できます。
- 01境界を確定本文を throttling、quota、budget、balance、access に分類します。
- 02基準を作成RPM、TPM、同時実行数、入力量、output budget、retry 回数を記録します。
- 03一項目を比較Retry-After と reset header があれば優先します。
- 04決定的な証拠を記録worker を停止し、単一 request で account の基準状態を確認します。
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
確認した根本原因に修正を適用する
証拠で確定したレイヤーだけを最小限変更します。決定的な設定エラーを広範な再試行や検証無効化で隠さないでください。
- 01障害レイヤーを修正process ごとではなく worker 全体で共有する queue・limiter を使います。
- 02必要な動作を復元jitter、最大回数、総 deadline 付き exponential backoff を適用します。
- 03一時回避策を除去context と同時実行数を減らすか、必要な残高・予算・権限を回復します。
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_exhausted一度の成功ではなく修正結果を検証する
最小確認が成功したら元の経路を再実行し、通常のストリーミング、同時実行数、タイムアウト条件でも安定することを確認します。
- 全 worker が実効的な同時実行・rate budget を共有する。
- retry に jitter、回数上限、総時間上限がある。
- 残高、project budget、model access を個別に確認した。
- 段階的な増量で latency と 429 率が再上昇しない。
セキュリティ境界とエスカレーション資料
認証、通信、権限、検証を弱めず、かつ機密情報を公開しない範囲で、再現とエスカレーションに必要な証拠を収集します。
- token 負荷測定で完全な prompt を記録しない。
- billing failure を一時エラーとして再試行しない。
- idempotency と task state で副作用の重複を防ぐ。
- 機密除去した limit header、負荷指標、UTC 時刻、request ID で共有する。
公式情報と検証範囲
本ガイドはプロトコル仕様とクライアント公式文書を根拠にしています。エラー文、再試行ヘッダー、設定項目はサービスやバージョンで変わるため、参照元を確認し、ログとリクエスト例を秘匿してから共有してください。
技術検証方法を見る