トークン サイズにおける RPM と TPM の上限
小さいバーは実際に速度を低下させるものです。
| 限界 | 価値 | 最大要求/分 | バインド？ |
|---|
なぜ 2 つの制限があるのか、そしてなぜそれが重要なのか
OpenAI、Anthropic、Google、Mistral などの主要な LLM プロバイダーはすべて、あなたを測定します。 1分あたりのリクエスト数 そして 1分あたりのトークン数 同時に。問題は、トークンの制限はほとんどの人が忘れていることです。 4,000 トークンのプロンプトを送信するまでは、30,000 TPM の予算は大きく見えます。これは、トークンを取得し始めるまでに 1 分間にわずか 7 リクエスト程度です。 429 Too Many Requestsたとえ RPM 制限により数百が許容される場合でも。修正が「より速く送信」されることはほとんどありません。コンテキストをトリミングしたり、出力の長さを制限したり、使用レベルを引き上げたりすることです。
この計算機はあなたの代わりに割り算をしてくれます。リクエストごとに制限とトークンの両方を取得し、より小さい上限を見つけて、それを計画できるものに変換します。 同時アクティブユーザー。各ユーザーが 1 分間におよそ 2 件のリクエストを発行することがわかっている場合、ユーザー番号から、リクエストがキューに入るまでに 1 つのキーが何人のユーザーにサービスを提供するかがわかります。壁にぶつかったときの正直な選択肢は次のとおりです。プロンプトを縮小する (多くの場合、最大の手段)、短くする max_tokens、緊急でない作業をバッチ処理します。 非同期バッチAPI、または、より多くの金額を費やすことで、より高いレベルの資格を得ることができます。
スループットの規模を決定したら、価格を設定します。 LLM トークンコスト計算ツール それらのトークンをドルに変換し、 AI アプリのコスト見積りツール ユーザー数に応じて請求書全体をモデル化します。チャット製品を構築していますか?の チャットボットのコスト計算ツール 会話量をコストとスループットの両方に結び付けます。
使い方
1. プリセット層を選択するか、プロバイダー ダッシュボードから RPM および TPM 制限を入力します。
2. 一般的なリクエストで使用される入力トークンと出力トークンを入力します (出力も TPM にカウントされます)。
3. 1 人のアクティブ ユーザーが 1 分間に送信するリクエストの数を設定します。
4. 1 分あたりの有効なリクエスト数、同時ユーザー数、ボトルネックとなっている制限を確認します。
よくある間違い
入力トークンのみをカウントします。 出力トークンも課金され、レート制限されます。応答が長いおしゃべりなモデルは、TPM を高速に消費します。 RPM 制限に合わせてサイジングします。 プロンプトが大きい場合は、TPM によって最初に制限がかかります。回転数は関係ありません。 制限が固定されていると仮定します。 支出が増えるとティアが自動的に上がるので、今日の壁は来月にはなくなるかもしれません。 バーストは無視します。 制限は 1 分あたりの平均ですが、短い時間枠で適用されるため、トラフィックの急増は平均より 429 秒低くなります。
よくある質問
TPM 制限を 1 分あたりのリクエストに変換するにはどうすればよいですか?
TPM をリクエストごとのトークンで除算します (入力 + 出力)。その結果が、トークン側のリクエストの上限となります。本当の上限は、それと RPM 制限の小さい方です。
RPM 制限を下回ると 429 エラーが発生するのはなぜですか?
代わりに、1 分あたりのトークン制限が拘束されるためです。長いプロンプトまたは出力は、リクエスト数に達する前に TPM を使い果たします。プロンプトを縮小するか、出力の長さを制限します。
1 つの API キーで何人のユーザーに対応できますか?
1 分あたりの有効リクエスト数 ÷ ユーザーあたり 1 分あたりのリクエスト数。トークンのトリミング、バッチ処理、階層を上げたり、キー間で負荷を分散したりすることで、値を上げます。
バッチ エンドポイントはこれらの制限を共有しますか?
いいえ、非同期バッチ API には、レイテンシーを犠牲にして、独自のはるかに高い制限と割引があります。非対話型の一括ジョブに使用します。
見積もりのみ。レート制限は参考値であり、プロバイダー、モデル、アカウント層によって異なります。ダッシュボードで確認してください。