概要
目標: アプリが OpenAI のレート制限と過負荷エラーをどのように処理するかをテストする
時間: 10 分
Plugins:GenericRandomErrorPlugin、 RetryAfterPlugin
前提条件:開発プロキシを設定する
このアプリは開発環境では正常に動作しますが、運用環境では 429 Too Many Requests の理由でエラーが発生します。 OpenAI のレート制限は、組織の使用状況レベル、モデル、および同じ組織を使用している他のすべてのユーザーによって異なります。そのため、意図的に確実に上限に達することはできません。 Dev Proxy は OpenAI API が返すのと同じエラーを返すため、ユーザーが利用する前に、アプリがどのような動作をするかを確認することができます。
OpenAI が返す内容を理解する
すべてのOpenAIエラーが「再試行してください」を意味するわけではありません。 アプリでは、それらを区別する必要があります。
| Status | error.code |
意味 | アプリで実行する必要がある操作 |
|---|---|---|---|
| 429 | rate_limit_exceeded |
1 分あたりのリクエスト数 (RPM) または 1 分あたりのトークン数 (TPM) の制限に達しました。 |
Retry-After ヘッダーに記載されている時間が経過するまで待ってから、再試行してください。 |
| 429 | slow_down |
上限内であっても、リクエストレートの増加が急激すぎます。 |
Retry-After を待ち、要求頻度を下げ、徐々に上げていきます。 |
| 429 | credit_balance_exhausted |
組織の前払いクレジットが残っていません。 | 再試行しないでください。 再試行してもアクセスは回復しません。 ユーザーに通知するか、管理者に通知します。 |
| 503 | server_is_overloaded |
現時点では、このモデルには十分なキャパシティがありません。 |
Retry-Afterが存在する場合は待ってから、遅延を増やして再試行してください。 |
完全な一覧については、OpenAI ドキュメントの エラー コード を参照してください。
Important
429 行の 3 つのエラーはすべて、同じ状態コードを使用します。 アプリがすべての 429 応答で再試行すると、回復しない課金エラーを再試行し続けます。
error.codeを確認して、何を行うかを決定してください。
OpenAI SDK でできることを知る
Python および JavaScript 用の公式 OpenAI SDK は、既定では、指数バックオフを使用して、408、409、429、5xx 応答、および接続エラーを 2 回再試行します。 これは、Python では maxRetries オプション、JavaScript では max_retries で変更できます。
SDK の再試行は、短時間のバーストに対応します。 再試行回数を使い切ったときに何が起こるか、再試行しても解決しないエラーを処理する方法をアプリで決定する必要があります。 Pythonでは、429 がRateLimitErrorを発生させ、503 がInternalServerErrorを発生させるので、両方に対処してください。
Tip
エラー処理コードが受け取る内容を正確に確認するには、テスト中に max_retries=0 (Python) または maxRetries: 0 (JavaScript) を設定してください。 後で SDK の再試行をオンに戻してください。
OpenAI レート制限をシミュレートする
Dev Proxy には、表にある OpenAI エラー用のプリセットがあります。 ダウンロードします:
devproxy config get openai-throttling
プリセットを使用して Dev Proxy を起動します:
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"
このプリセットは、https://api.openai.com/* への要求の 90% を、テーブルからランダムに抽出したエラーで失敗させます。 調整への対応として、Retry-After ヘッダーを設定し、RetryAfterPlugin を使用して、アプリが API を再度呼び出す前にその時間だけ待機することを確認します。
アプリが Dev Proxy 経由で要求を送信し、Dev Proxy 証明書を信頼していることを確認してください。 Node.jsについては、「Use Dev Proxy with Node.js applications」を参照してください。 その他のランタイムについては、「 開発プロキシのトラブルシューティング」を参照してください。
アプリを実行し、次のことを確認してください:
-
rate_limit_exceededまたはslow_downエラーが発生した後、アプリはRetry-After時間待機します。 API の呼び出しが早すぎる場合、開発プロキシはそれを報告し、要求のレート調整を行います。 -
credit_balance_exhaustedエラーが発生すると、アプリは API の呼び出しを停止し、明確なメッセージを表示します。 -
server_is_overloadedエラーが発生した後、アプリは遅延を伴って再試行し、再試行回数を使い果たしたら、スタック トレースの代わりにフォールバックするか、クリア メッセージを表示します。 - アプリで作業が失われることはありません。 たとえば、長いチャット会話やバッチ ジョブは、エラーの後も続行されます。
要求が失敗する頻度を変更するには、--failure-rate オプションを使用してください。 たとえば、すべてのリクエストを失敗させるには:
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json" --failure-rate 100
Azure OpenAI およびその他のプロバイダーのトークン制限をシミュレートする
プリセットは、アプリが使用するトークンの数に関係なく、ランダムにエラーを返します。 実際のトークンの使用に基づいて要求を調整する (たとえば、長い会話が TPM の制限を超えたときに何が起こるかを確認する) には、 LanguageModelRateLimitingPlugin を使用します。 Azure OpenAI モデルやローカル モデルなど、OpenAI と互換性のある API で動作します。 詳細については、「テスト言語モデルのトークン制限」を参照してください。
次のステップ
トークンベースの制限をシミュレートする方法について説明します。
参照
- 言語モデルの失敗でアプリをテストする - 予期しない言語モデルの応答をシミュレートする
- OpenAI API のエラーをシミュレートする - 独自の OpenAI エラー ファイルを作成する
- アプリケーションがスロットリングを適切に処理できることをテストする - 任意の API でのスロットリング
- プリセットの構成を使用する - プリセットを使用て作業します
- RetryAfterPlugin - リトライ動作を確認する
Dev Proxy