データベース

自動化

発見

レポートの一覧に戻る

Open AI APIを複数のユーザーが使う際のTPMや同時接続などの利用制限を回避する方法

🗓 Created on 5/1/2024

📜 要約

主題と目的の要約

本調査は、OpenAI APIを複数のユーザーが使う際のトークン使用量制限や同時接続数の制限を回避する方法について検討することを目的としています。OpenAI APIには厳しいレート制限があり、ユーザーのデータベーススキーマ解析などの処理で制限に遭遇する問題が報告されています。Azure上のモデルでもTPMリミットエラーが発生しており、適切な対策が求められています。

主要な内容と発見

本調査では以下の対策を検討しました:

非同期処理の活用: APIリクエストを非同期的に行うことで、制限を回避できる可能性がある。
キャッシングの導入: 頻繁にアクセスされるデータをキャッシュすることで、APIへのアクセス頻度を下げることができる。
複数APIキーの使い分け: 複数のAPIキーを用意し、それらを適切に使い分けることで制限を回避できる。
制限超過時の一時停止: 制限に達した場合は一時的にリクエストを停止し、制限が解除されるのを待つ対応が考えられる。

結果と結論のまとめ

本調査の結果、OpenAI APIの利用制限を回避するための有効な対策として、非同期処理の活用、キャッシングの導入、複数APIキーの使い分け、制限超過時の一時停止などが考えられることが分かりました。これらの対策を組み合わせて適用することで、OpenAI APIを安定して利用できるようになると期待されます。今後は、実際の運用環境でこれらの対策を検証し、最適な方法を見出していく必要があります。

🔍 詳細

🏷問題の理解と認識

OpenAI APIのトークン使用量制限とAzure上のTPMリミットエラー

OpenAI APIを利用する際のトークン使用量制限には一時的な制限があり、制限を超えるとリクエストが受け付けられなくなります。Azure上のモデルでもTPMリミットエラーが報告されており、適切な処理が求められています。

OpenAI APIとAzure上のTPMリミットエラーへの対策

OpenAI APIの利用制限を回避するためには、自社でのレート制限の実装が重要であり、使用量を適切に管理することが必要です。また、Azure上のモデルでのTPMリミットエラーに対処するためには、エクスポネンシャルバックオフやクライアントサイドのレート制限ヘルパーの実装が必要とされています。これらの対策を講じることで、利用制限を回避し、スムーズなAPI利用を実現できます。

問題の理解と認識

OpenAIのGPT-4利用時の高頻度のレート制限エラー

openai.com

によると、多くのユーザーがGPT-4を使用する際に頻繁に「429 Too Many Requests」エラーに遭遇しています。これは、公開されているレート制限よりも厳しい制限が実際にかかっているためと考えられます。OpenAIは、GPT-4の限定ベータ版リリース中は需要に対応するため、より厳しいレート制限を設けていると説明しています。そのため、多くのユーザーがGPT-4の利用を断念し、代わりにGPT-3.5を使用するようになっています。

OpenAIサーバーの一時的な過負荷

時折、「That model is currently overloaded with other requests」といったエラーメッセージが表示されることがあります。これはOpenAIのサーバーが一時的に過負荷状態にあり、リクエストを処理できない状況を示しています。レート制限とは別の問題で、OpenAIのインフラ拡張の過程で発生する一時的な問題と考えられます。指数関数的なバックオフ処理を実装するなどして、一時的な過負荷に対応することが推奨されています。

Azure OpenAI Serviceの利用検討

OpenAIの直接利用に限界を感じる場合は、Microsoft Azureが提供するOpenAI Serviceの利用を検討することをおすすめします。Azure OpenAI Serviceは、OpenAIモデルへのアクセスを提供しつつ、より高い可用性を備えています。申請プロセスを経て利用を開始できるため、OpenAIの直接利用よりも安定した環境を得られる可能性があります。

OpenAI APIのトークン使用量制限

reddit.com

によると、OpenAI APIユーザーの利用制限が自動的に引き上げられるようになりました。ユーザーはアカウントの利用制限を確認でき、各利用ティアの詳細も確認できます。利用ティアごとの条件と制限が示されています。

Azure上のモデルでのTPMリミットエラーの処理

github.com

では、Azure上のモデルにアクセスする際に、TPMリミットエラーが増加している問題が報告されています。現在のライブラリでは、Retry-Afterヘッダーを処理することができますが、Azureが最近x-rate-limit-reset-tokensを返すようになったため、適切に処理できていません。再試行の設定があるものの、それでも解決されていません。問題の再現手順は、Azure上のモデルでトークンリミットエラーを強制的に発生させることです。現在のライブラリはエクスポネンシャルバックオフを行っていますが、バッチスクリプト実行時の事前のクライアントサイドのレート制限ヘルパーは提供されていません。今後の実装が期待されています。

reddit.com

account limits

🏷制限回避の方法

OpenAI APIのレート制限への対処方法

OpenAIのAPIには厳しいレート制限があり、ユーザーのデータベーススキーマ解析などの処理で制限に遭遇している。非同期処理、キャッシング、複数APIキーの使い分け、制限超過時の一時停止などの対策が考えられる。

OpenAI APIのレート制限に対する考察

OpenAIのAPIを効果的に利用するためには、レート制限に対処する方法が重要です。非同期処理を使ってリクエストを並列化し、キャッシングを導入して同じリクエストを繰り返さないようにすることで制限を回避できます。さらに、複数のAPIキーを使い分けてリクエストを分散させることで、制限を超えるリクエストを防ぐことができます。制限超過時には一時的に処理を遅らせるなどの対策を講じることで、スムーズなAPI利用が可能となります。

Azure API Management を使用した OpenAI エンドポイントの高度なロードバランシング

多くのサービスプロバイダー(OpenAI を含む)は、呼び出し数に制限を設けています。Azure OpenAI の場合、トークン制限(TPM または1分あたりのトークン数)と1分あたりのリクエスト数(RPM)の制限があります。サーバーがリソースを使い果たしたり、サービスの制限を超えると、プロバイダーは HTTP ステータスコード 429 (リクエストが多すぎる) を発行し、Retry-After レスポンスヘッダーで次のリクエストを試行するまでの待機時間を示します。

Azure API Management ポリシーを使用して、2つ以上の OpenAI またはその他の API バックエンドの可用性とプライオリティに基づいて効率的に消費するシングルエンドポイントを提供する方法が示されています。主な特徴は以下の通りです:

HTTP ステータスコード 429 (リクエストが多すぎる) とRetry-Afterヘッダーを認識し、現在スロットリングされていないバックエンドにトラフィックを送信する
バックエンドのプライオリティを設定できるため、最も高いプライオリティのものから順に消費し、スロットリングが発生した場合は低プライオリティのバックエンドにフォールバックする
バックエンド間の待機時間はなく、即座にリトライを行う

詳細については、こちらのリポジトリを参照してください。

Azure OpenAI の管理対象ID

Azure OpenAI を使用するには、API Management インスタンスに管理対象IDを設定し、そのIDにCognitive Services OpenAI Userロールを割り当てる必要があります。これにより、API Keyを管理する必要がなくなります。

OpenAI API の追加

API Management で OpenAI API を追加するには、inference.jsonファイルを使用し、サーバーセクションを更新して、OpenAI エンドポイントを指定します。また、サブスクリプションの設定で、サブスクリプションが必須で、ヘッダー名がapi-keyであることを確認する必要があります。

API Management ポリシーの適用

最後に、apim-policy.xmlファイルの内容を使用して、API Management ポリシーを設定します。このポリシーには、バックエンドの管理、スロットリングの検出と対応、リトライロジックなどが含まれています。

OpenAI APIトークンとリクエスト制限の理解

OpenAIプラットフォームのアカウントを作成し、設定>>制限セクションを確認すると、利用可能なAPIアクセスのティアが表示されます。
新規アカウントはデフォルトで無料ティアに設定されており、開発中はこのティアの制限に注意が必要です。
ティアごとにトークン制限(1分あたりのトークン数)とリクエスト制限(1分/1日あたりのリクエスト数)が設定されています。
モデルの選択は、制限と開発タイムラインに大きな影響を与えるため、慎重に検討する必要があります。モデル選択のストラテジー

トークン制限とリクエスト制限の違い

トークンは自然言語処理において、単語や文字に分割されたテキストの単位を表します。
トークン制限は、アプリケーションがOpenAIサーバーに送信するトークンの量を表します。
リクエスト制限は、アプリケーションがAPI serverに送信できるリクエスト数の上限を表します。
アプリケーション設計時には、これらの制限を考慮し、制限に適合するよう最適化する必要があります。

制限の管理

ユーザーティアと、選択したモデルのトークン/リクエスト制限を確認し、アプリケーションの設計に反映させる必要があります。
アプリケーションでは、制限に達した場合の適切な処理(待機、再試行など)を実装する必要があります。
常に課金設定を確認し、OpenAIクレジットの消費に注意を払う必要があります。

techcommunity.microsoft.com

Tokens-Per-Minute and a Requests-Per-Minute

apim-policy.xml

API Management policies

turn on managed identity in API Management

allow that identity in Azure OpenAI

source XML

request a quota increase

to use an external Redis cache

www.reddit.com

medium.com

🖍 考察

結果の確認

調査の結果、OpenAI APIの利用制限を回避するためには以下の対策が重要であることが分かりました。

自社でのレート制限の実装により、使用量を適切に管理する
Azure上のモデルでのTPMリミットエラーに対処するため、エクスポネンシャルバックオフやクライアントサイドのレート制限ヘルパーを実装する

これらの対策を講じることで、利用制限を回避し、スムーズなAPI利用を実現できます。

重要性と影響の分析

OpenAIのAPIを効果的に利用するためには、レート制限に対処する方法が重要です。制限を超過すると、APIの使用が制限されてしまうため、ユーザーの利便性が大きく損なわれてしまいます。

対策として提案した非同期処理やキャッシング、複数のAPIキーの使い分けなどは、制限を回避し、安定したAPI利用を実現するために非常に有効です。これらの対策を講じることで、ユーザーの利便性が向上し、OpenAIのサービスをより効果的に活用できるようになります。

ネクストステップの提案

今回の調査では、レート制限への対処方法について主に検討しましたが、未解決の課題もいくつか残されています。

例えば、大量のリクエストを処理する際のスケーラビリティの確保や、異常なリクエスト量に対する自動的な対応策の検討などが挙げられます。これらの課題に対して、さらなる調査と検討が必要だと考えられます。

今後の調査の方向性

今回の調査では、OpenAI APIの利用制限への対策に焦点を当てましたが、その他にも様々な課題が存在する可能性があります。

今後は、APIの安定性や信頼性、パフォーマンス、セキュリティ面での課題など、より広範囲にわたる調査を行う必要があります。また、他のAIサービスとの比較や、ユーザーニーズの詳細な分析なども重要になってくるでしょう。

これらの調査を通して、OpenAI APIをより効果的に活用するための方策を見出していきたいと考えています。

📖 レポートに利用された参考文献

検索結果: 7件追加のソース: 0件チャット: 0件

20件の参考文献から7件の情報を精査し、約35,000語の情報を整理しました。あなたは約3時間の調査時間を削減したことになります🎉

調査された文献

20件

精査された情報

7件

整理された情報量

約35,000語

削減された時間

約3時間

🏷 問題の理解と認識

Hitting Rate Limit with small group of Users? - API

I have a decent amount of traffic to my application, but nowhere near the rate limit of 3,500 RPM or 90,000 tokens a minute.

openai.com

Is there any problem if i exceed TPM limit? - OpenAI Developer Forum

I'm concerned about the limitations imposed when exceeding the TPM (tokens per minute) usage. If there is only a one-minute restriction at ...

openai.com

OpenAI API users now get limits increased automatically - Reddit

OpenAI API users now get limits increased automatically ; Free, User must be in an allowed geography, $100, 3 RPM / 200 RPD, 20K TPM (GPT-3.5).

reddit.com

Handling of TPM limit errors for Azure (x-rate-limit-reset-tokens) #937

We've been noticing an increasing number of TPM limit errors when calling an Azure-hosted model via the library. We have a couple of retries ...

github.com

🏷 制限回避の方法

How do you handle OpenAI rate limits? Wanted to add a ...

#### OpenAIのレート制限への対処方法 - OpenAIのAPIには1分間あたり90,000トークンの制限があり、これは約11リクエストに相当します。 - ユーザーのデータベーススキーマを解析する機能を追加しようとしたところ、この制限に頻繁に遭遇しているようです。 - レート制限に対処するためには以下のような方法が考えられます: - 非同期処理を使ってリクエストを並列化し、制限を回避する - キャッシングを導入して、同じリクエストを繰り返さないようにする - 複数のAPIキーを使い分けて、リクエストを分散させる - 制限を超えそうな場合は一時的に処理を遅らせるなどの対策を講じる #### 要約 - OpenAIのAPIには厳しいレート制限があり、ユーザーのデータベーススキーマ解析などの処理で制限に遭遇している - 非同期処理、キャッシング、複数APIキーの使い分け、制限超過時の一時停止などの対策が考えられる - これらの対策を組み合わせることで、レート制限の問題に対処できると考えられる [r/OpenAI](https://www.reddit.com/r/OpenAI/) ![r/OpenAI - How do you handle OpenAI rate limits? Wanted to add a feature to parse users' database schemas, but constantly hitting limitations locally. 90K/tokens per min is ~11 requests.](https://preview.redd.it/how-do-you-handle-openai-rate-limits-wanted-to-add-a-v0-pk4tmertftrb1.png?width=640&crop=smart&auto=webp&s=28199996470d5eedc336e7a19ede0b6e78891999)

reddit.com

Smart load balancing for OpenAI endpoints and Azure API ...

#### Azure API Management を使用した OpenAI エンドポイントの高度なロードバランシング多くのサービスプロバイダー(OpenAI を含む)は、呼び出し数に制限を設けています。Azure OpenAI の場合、トークン制限(TPM または1分あたりのトークン数)と1分あたりのリクエスト数(RPM)の制限があります。サーバーがリソースを使い果たしたり、サービスの制限を超えると、プロバイダーは HTTP ステータスコード 429 (リクエストが多すぎる) を発行し、Retry-After レスポンスヘッダーで次のリクエストを試行するまでの待機時間を示します。ここで紹介するソリューションは、ユーザーエクスペリエンス/ワークフロー設計、アプリケーションの回復力とエラー処理ロジック、サービス制限の考慮、適切なモデルの選択、API ポリシー、ログ記録とモニタリングなど、包括的な対策の一部です。このソリューションでは、Azure API Management ポリシーを使用して、2つ以上の OpenAI またはその他の API バックエンドの可用性とプライオリティに基づいて効率的に消費するシングルエンドポイントを提供する方法を示しています。主な特徴は以下の通りです: - HTTP ステータスコード 429 (リクエストが多すぎる) とRetry-Afterヘッダーを認識し、現在スロットリングされていないバックエンドにトラフィックを送信する - バックエンドのプライオリティを設定できるため、最も高いプライオリティのものから順に消費し、スロットリングが発生した場合は低プライオリティのバックエンドにフォールバックする - バックエンド間の待機時間はなく、即座にリトライを行うこの API Management ソリューションの詳細については、[こちらのリポジトリ](https://github.com/Azure/apim-aoai-smart-loadbalancing)を参照してください。 #### Azure OpenAI の管理対象ID Azure OpenAI を使用するには、API Management インスタンスに管理対象IDを設定し、そのIDにCognitive Services OpenAI Userロールを割り当てる必要があります。これにより、API Keyを管理する必要がなくなります。 #### OpenAI API の追加 API Management で OpenAI API を追加するには、[inference.json](https://github.com/Azure/apim-aoai-smart-loadbalancing/blob/main/inference.json)ファイルを使用し、サーバーセクションを更新して、OpenAI エンドポイントを指定します。また、サブスクリプションの設定で、サブスクリプションが必須で、ヘッダー名がapi-keyであることを確認する必要があります。 #### API Management ポリシーの適用最後に、[apim-policy.xml](https://github.com/Azure/apim-aoai-smart-loadbalancing/blob/main/apim-policy.xml)ファイルの内容を使用して、API Management ポリシーを設定します。このポリシーには、バックエンドの管理、スロットリングの検出と対応、リトライロジックなどが含まれています。