最終更新: 2026-06-22

LLMレート制限の計画とは

LLMレート制限の計画とは、あるワークロードに対してプロバイダーのAPI制限が許す持続可能なリクエストレートと、それが含意する処理中の並行実行数を求める作業です。ホスト型の推論APIは処理能力を2つの独立した軸で制限します。1つは1分あたりトークン数（TPM）で、アカウントが1分間に処理できる入力と出力を合わせたトークン数です。もう1つは1分あたりリクエスト数（RPM）で、規模にかかわらず1分間に許されるAPI呼び出しの回数です。先に到達した方が上限を定めます。

制約となるのはどちらか

呼び出しあたりの平均トークンコストを持つワークロードは、TPM上限を同等のリクエスト上限へと換算します。1分あたりのトークン予算をリクエストあたりの消費トークン数で割ると、トークン制限のみが許す1分あたりリクエスト数が求まります。

ここで $L_t$ はTPM上限、$n$ はリクエストあたりトークン数です。持続可能なレートは、このトークンから導かれる上限と明示的なRPM上限 $L_r$ のうち小さい方です。

$R_t < L_r$ ならトークン制限が、$R_t \ge L_r$ ならリクエスト制限が制約となります。トークン量の多い作業（長いコンテキスト、大きな応答）はトークン制約になりがちで、高頻度の小さな呼び出しはリクエスト制約になりがちです。

リトルの法則による並行実行数

1秒あたりの持続可能なレートは $R_s = R / 60$ です。リトルの法則は、システム内の項目の平均数が到着率と各項目がそこに滞在する平均時間の積に等しいことを示すキューイングの結果であり、このレートと平均リクエスト遅延 $t_L$ から、パイプラインを満たし続けるために並行して実行すべき並行実行数 $C$ を求めます。

計算例

TPM上限 $L_t = 2{,}000{,}000$、RPM上限 $L_r = 10{,}000$、リクエストあたり平均 n = 2{,}000 トークンの場合を考えます。トークンから導かれる上限は次のとおりです。

1{,}000 < 10{,}000 であるため、トークン制限が制約となります。処理能力は見出しの10,000ではなく、1分あたり1,000リクエストに制限されます。平均遅延が $t_L = 20$ 秒のとき、1秒あたりのレートは $R_s = 1{,}000 / 60 \approx 16.7$ となるため、必要な並行実行数は次のとおりです。

したがってレートを維持するには、およそ333件のリクエストを同時に処理中に保つことになります。ワークロードがトークン制約であるため、RPM上限を引き上げても効果はありません。リクエストあたりのトークン数を減らす（短いプロンプト、小さな応答、または プロンプトキャッシュの節約額の計算 による）か、より高いTPMの割り当てを申請することが有効です。

変動要因と活用

リクエスト制約の場合は、1回の呼び出しで複数の項目をまとめて処理すると実効的な処理能力が上がる一方、トークンを削っても効果はありません。遅延はリトルの法則を通じてのみ関与します。$t_L$ を2倍にすると一定のレートが要求する並行実行数も2倍になるため、応答の速いモデルは接続プールやキューの規模を緩めます。並行実行数はクライアントの構成（ワーカー数、セマフォの上限、接続プール）に反映され、持続可能なレートは LLM月額コストの計算 を介してコストの試算に反映されます。トークン数はリクエストごとに変動し、プロバイダーがキューイングやバーストを行うことがあるため、定常状態の数値は実際のトラフィックと照合して検証すべき計画の基準です。