LLM レート制限: 1 分あたりのトークン数、1 分あたりの要求数、制限に達したときに何が起こるか

言語モデル API では、1 分あたりに送信する要求の数 (RPM) と 1 分あたりに使用するトークンの数 (TPM) という 2 つの方法でトラフィックが制限されます。 いくつかの長いプロンプトがトークンの予算を使い切ったため、リクエスト上限を大幅に下回っていても、それでもスロットリングされる可能性があります。 いずれかの制限に達すると、API は 429 Too Many Requests を返し、アプリは待機する必要があります。

OpenAI、Azure OpenAI、Anthropic でのカウント方法

Provider 制限される項目 知っておくべきこと
OpenAI RPM、1日あたりのリクエスト数、TPM、1日あたりのトークン数など(組織ごと、プロジェクトごと、モデルごと) 先に上限に達した方の制限に引っかかります。 トークン制限の場合、リクエストは max_tokens とその文字数に基づく見積もりのうち大きい方でカウントされます。 失敗したリクエストも件数に含まれます。
Azure OpenAI 各デプロイに割り当てる TPM に加えて、それに比例して設定された RPM 制限 RPM は 1 秒または 10 秒のウィンドウでチェックされるため、1 分あたりの合計が問題ない場合でもバーストは 429 になります。 トークンの見積もりには max_tokensが含まれます。
Anthropic RPM、1 分あたりの入力トークン (ITPM)、出力トークン/分 (OTPM)、モデルごと 容量の補充が継続的に行われ、1 秒あたり 1 要求として 60 RPM が適用される場合があります。 ほとんどのモデルでは、キャッシュされた入力トークンは ITPM の対象になりません。また、max_tokens は OTPM の対象になりません。

max_tokensを 4,000 に設定し、200 個のトークンを取得すると、OpenAI と Azure OpenAI は引き続き制限に対して 4,000 をカウントします。 これが、使用量メトリックがクォータを十分に下回っている場合でも 429 が返されることがある理由です。

429 が各プロバイダーにとって何を意味するか

待てば解消する429ばかりではありません。

Provider 待機して再試行する 停止して誰かに伝える
OpenAI リクエスト数またはトークン数に対しては 429、429 slow_down(制限内であってもトラフィックが急速に増加しました)、503 server_is_overloaded。 Retry-Afterが存在する場合は待機します。 organization_usage_limit_exceeded 内の error.code、credit_balance_exhausted、organization_spend_limit_exceeded、または project_spend_limit_exceeded を含む 429。 再試行してもアクセスは復元されません。
Azure OpenAI デプロイのTPMまたはRPM、システム容量、またはレート制限の一時的な引き下げが原因で429が返されます。 retry-after-msを待ってください。 承認されたクォータを下回っているにもかかわらず、運用環境で 429 エラーが継続して発生している。 展開の TPM 割り当てを確認し、サポート リクエストを作成します。
Anthropic 429 rate_limit_errorretry-afterヘッダー付きの(使用量が急激に増加した後のレート制限を含む)、529 overloaded_error。 毎月の支出上限は429です。 retry-after ヘッダーがなく、error.details.error_codeはenforced_spend_limit_reachedで、アクセスが再開されるまで失敗し続けます。

LLM レート制限を処理する方法

  1. 表示された429を確認してください。 課金、支出、クォータのエラーには、再試行ではなく人が必要です。
  2. API が要求する限り待ちます。 OpenAI と Anthropic が retry-afterを秒単位で送信します。 Azure OpenAI は、応答をミリ秒単位で送信しますretry-after-ms。 ヒントがない場合は、ランダムジッターで指数関数的にバックオフし、試行回数と合計時間の両方を制限します。
  3. SDK が既に行うことを把握しましょう。 OpenAI と Anthropic の Python SDKs は、接続エラー、および 408、409、429、5xx の各応答について、既定で 2 回再試行します。 独自の再試行ループを追加する場合は、たとえば Python では max_retries=0 を使用して、Azure OpenAI が推奨するように SDK の再試行を無効にします。そうしないと、再試行回数が増えてしまいます。
  4. 重要なものを絞り込みます。 OpenAI と Azure OpenAI で、max_tokensを、予想される応答サイズに近い値に設定します。 Anthropicでは、システム命令などの繰り返しコンテンツをキャッシュします。
  5. 徐々に増やしてください。 トラフィックの急激な増加は、制限内であっても、OpenAIのslow_downとAnthropicのレート制限に達することがあります。 OpenAI は、1 分あたり 100 万個の入力トークンに達したら、15 分ごとの増加率を 50% 以下に抑えることを推奨しています。
  6. 既に消費したストリームを再生しないでください。 ストリームの開始後にエラーがストリーム イベントとして到着する可能性があり、出力を使用した後に要求を自動的に再生しないよう OpenAI は推奨 しています。
  7. スピナーを表示するのではなく、要求が 429 でストールしたときにユーザーに知らせます。

アプリが LLM レート制限を処理することをテストする方法

Approach 見つけたもの 見逃した項目
テストで SDK クライアントをモックするか、コーディング エージェントにモックを記述させる エラー ブランチが実行されるかどうか プロバイダーの実際の状態コード、エラー コード、ヘッダー、およびお使いの SDK 自体の再試行。 アプリでは、モックに到達するためにテスト専用のスイッチも必要です。
スロットリングされるまで実際の API を呼び出す 実際の動作 すべてのトークンに対して支払いを行い、slow_down、オーバーロード、または支出上限を任意にトリガーすることはできません
アプリの実際のトラフィックをインターセプトしてプロバイダーのエラーを返すか、アプリで使用するトークンに基づいてスロットルする 実際の URL、SDK の再試行ポリシー、プロバイダーのエラー本文(選択した上限で) 単体のコード。 このためには単体テストを使ってください。

アプリで試す

Dev Proxy は、アプリからの言語モデル API へのリクエストを傍受し、プロバイダー独自のエラーを返しますが、アプリは実際の URL を引き続き呼び出し続けます。 OpenAI の場合は、プリセットをダウンロードし、それを使用して開発プロキシを起動します。

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

openai-throttling プリセットでは、slow_down へのリクエストの 90% が、TPM または RPM の場合は credit_balance_exhausted、server_is_overloaded、rate_limit_exceeded、または 503 https://api.openai.com/* というランダムなエラーで失敗します。 anthropic-throttling プリセットは、RPM、入力トークン、出力トークン、アクセラレーション関連の 429 エラー、および 529 エラー https://api.anthropic.com/* について、overloaded_error に対しても同様です。 どちらのプリセットにも RetryAfterPlugin が含まれています。これは、429 の retry-after 時間が切れる前にアプリが API を再び呼び出すタイミングを示します。 503 と 529 の応答を確認しません。

アプリが実際に使用するトークンに基づいてスロットルするには、LanguageModelRateLimitingPlugin を使用します。 各応答が報告するプロンプト トークンと完了トークンをカウントし、アプリが設定した制限を超えると retry-after を付けて 429 を返します。 Azure OpenAI とローカル モデルを含む、OpenAI と互換性のある API で動作します。

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "LanguageModelRateLimitingPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "languageModelRateLimitingPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.openai.com/*",
    "https://*.openai.azure.com/openai/deployments/*/chat/completions*"
  ],
  "languageModelRateLimitingPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/languagemodelratelimitingplugin.schema.json",
    "promptTokenLimit": 1000,
    "completionTokenLimit": 500,
    "resetTimeWindowSeconds": 60
  }
}

プラグインは、 max_tokens 見積もりを再現しません。 既定の 429 レスポンス本文では、insufficient_quota コードが使用されます。 アプリが想定するレート制限のエラー本文を返すには、 whenLimitExceeded を Custom に設定し、 customResponseFile を独自の応答にポイントします。 Dev Proxy をインストールするには、「Dev Proxy のセットアップ」を参照してください。

次のステップ

参照