API レート制限とスループットの説明

レート制限とは実際には何ですか

あ レート制限 API を使用できる速度の上限です。プロバイダーは、サービスの公平性と安定性を維持するためにこれらの制限を課します。これがなければ、単一のバグのあるループや 1 人の顧客からのトラフィックの急増により、他のすべてのユーザーが飢えに陥る可能性があるため、制限によって容量を保護し、プラン層を強制し、露骨な悪用やサービス拒否攻撃を行います。制限を超えると、API は一時的にサービスを停止し、 HTTP 429「リクエストが多すぎます」 仕事をする代わりに応答する。

制限にはいくつかの一般的な単位があり、最初にそのいずれかに達する可能性があります。

LLM API で最も頻繁に食い込むのは次の 2 つです。 回転数 そして TPM、そしてそれらは独立しています。 50 個の小さな分類呼び出しは、TPM にほとんど触れずに RPM を超える可能性があります。 1 つの 100K トークンのドキュメントの要約は、1 回のリクエストで TPM を超える可能性があります。ワークロードが最初に到達する上限に合わせて設計します。

TPM 制限を「何人のユーザーに対応できるか」に変える

キャパシティプランニングは単なる算術です。トークンから始める 1つ ユーザーが 1 分あたりに消費する量を計算し、制限をそれで割ります。

• リクエストごとのトークン = 入力トークン (プロンプト + システム メッセージ + コンテキスト) プラス モデルが生成する出力トークン。どちらも TPM に対してカウントされます。
• ユーザーごとの 1 分あたりのリクエスト数 = アクティブ ユーザーのおしゃべり度。
• ユーザーあたりの 1 分あたりのトークン数 = リクエストあたりのトークン × ユーザーあたりの 1 分あたりのリクエスト。

例: 各チャット ターンは ~1,500 の入力 + ~500 の出力 = を使用します 2,000トークン、アクティブ ユーザーは 1 分あたり約 1.5 ターンを送信します → 3,000 トークン/ユーザー/分。と 300,000TPM おおよそ提供できる制限 300,000 ÷ 3,000 = 100 人の同時アクティブ ユーザー。 RPM 制限に対して同じ除算を行い、 小さい 2 つの答えのうち、それがあなたの本当の限界です。 「アクティブ」とは、アクティブに送信することを意味することに注意してください。同時ユーザーが 100 人の製品には、通常、数千のサインイン アカウントが存在します。

ティア: 支出額が増えると制限が上がります

ほとんどのプロバイダーが実行されます 使用レベル。新しいアカウントは低い RPM/TPM/RPD から始まります。支出額が増え、アカウントが古くなると、上限がはるかに高く、場合によっては開始時の数値の 10 倍または 100 倍の上位階層に自動的に昇格します。制限に達している場合、最初に疑問に思うのは、自分はどのレベルにいるのか、次のレベルに進む資格はあるのか、ということです。エンタープライズ契約と確約支出契約により、制限をさらに引き上げたり、専用の容量を追加したりできます。

実効スループットを拡張するテクニック

• バッチ処理 — RPM プレッシャーを軽減するために、多くのアイテムを少数の大きなリクエストに結合します。プロバイダーの専用バッチ API も、緊急でない作業に対して割引料金で実行されます。
• ストリーミング — トークンをストリーミングバックしてもトークンの予算は増加しませんが、体感的なレイテンシーが短縮され、クライアントのリソースがより早く解放されるため、重複するリクエストがより早くクリアされます。
• バックオフとペーシング — 通話を一度にすべて発信するのではなく、1 分間に均等に分散することで、つまずいてしまうような破裂天井に陥ることなく通話を続けることができます。
• トークンのトリミング — 短いプロンプト、プロンプトのキャッシュ、および厳しい出力制限により、固定 TPM 予算内に収まるリクエストの数が直接増加します。

429 の処理: バックオフ、再試行、キューイング

制限に達するのは正常です。問題は、アプリが正常に回復するかどうかです。標準的なパターンは、 ジッターを伴う指数関数的バックオフ: 429 では、少し待ってから再試行します。再度失敗した場合は、毎回遅延をおよそ 2 倍にし (例: 1 秒、2 秒、4 秒、8 秒)、小さなランダム オフセットを追加して、多くのクライアントがロックステップで再試行しないようにします。常に敬意を払います 再試行後 プロバイダーがヘッダーを送信する場合、それは待機時間を正確に示します。

ハードリミットとソフト/バーストリミット

あ ハードリミット は絶対的な上限です。これを超えると、ウィンドウがリセットされるまですべてのリクエストが拒否されます。あ ソフトまたはバースト制限 定常レートを超える短いスパイクが許可されるため (多くの場合、時間の経過とともに補充されるトークン バケットを介して)、短期間のバーストは通過しますが、持続的な過負荷は依然として抑制されます。どちらに直面するかを知ることで戦略が変わります。バースト制限はウィンドウ上のトラフィックをスムーズにすることに報酬を与えます。ハードリミットには実際の値が必要です 列 安全な速度でリクエストを測定します。

• 緊急ではない作業をキューに入れる そのため、API を大量に消費するのではなく、制御されたペースで排出されます。
• 分散荷重 毎分の先頭で爆発するのではなく、均一に。
• 合計再試行回数の制限 したがって、運命にあるリクエストは永久にループするのではなく、きれいに失敗します。

コストの観点: 法案ではなく、形状アーキテクチャを制限します

レート制限は直接的にお金がかかるわけではありません。429 に料金が請求されることはありません。しかし、レート制限は構築方法とその選択に大きく影響します。 する コストがかかります。単一のキーでは必要なスループットを提供できない場合、チームは通常、 フォールバックチェーン (プライマリ スロットル時に 2 番目のモデルまたはプロバイダーにフェールオーバーします)、 複数のキーまたはプロバイダー プール容量、および バッチAPI 緊急でない仕事を、より安価で上限の高いレーンに押し込むためです。それぞれが回復力とヘッドルームを追加しますが、統合が複雑になり、場合によってはフォールバックでのトークンごとの価格が高くなる場合もあります。最も健全なアプローチは、まずレベルを上げてトークンをトリミングし、次にハードリミットによって本当にブロックされる場合にのみ冗長性を追加することです。

よくある質問

RPMとTPMの違いは何ですか?

RPM (1 分あたりのリクエスト数) は 1 分間に実行できる API 呼び出しの数に上限を設定し、TPM (1 分あたりのトークン) はそれらの呼び出しで移動できるテキストの量に上限を設定します。最初にどちらの上限に達しても構いません。多くの小規模な呼び出しは RPM を消費しますが、少数の大きなコンテキストの呼び出しは TPM を消費します。

TPM 制限をサービスできるユーザー数に変換するにはどうすればよいですか?

1 ユーザーが 1 分あたりに消費するトークンを推定し (リクエストあたりのトークンとユーザーあたりの 1 分あたりのリクエストを掛け、入力と出力の両方をカウントします)、TPM 制限をその数値で割ります。ユーザーが 3,000 トークン/分を必要とし、制限が 300,000 TPM である場合、約 100 人の同時アクティブ ユーザーにサービスを提供できます。

429 Too Many Requests エラーはどのように処理すればよいですか?

指数バックオフとジッターを使用して再試行します。試行間の待機時間を徐々に長くし、プロバイダーが返す Retry-After ヘッダーを尊重します。緊急ではない作業をキューに入れ、負荷をバーストするのではなく均等に分散し、合計再試行に制限を設けて、リクエストが永久にループするのではなく最終的に正常に失敗するようにします。