公開 2026-06-28 · 参照制限、プロバイダー ダッシュボードで確認してください
ドキュメントを読みました。あなたのレベルで許可されているのは、 1 分あたり 500 リクエスト。おそらく 8 通送信します。それでもログはいっぱいです 429 Too Many Requests。コードには何も問題はありません。 他の 制限、ほとんどのチュートリアルがスキップするもの: 1 分あたりのトークン数 (TPM)。すべての主要な LLM プロバイダーは、RPM と TPM を同時に測定し、実際には、ほとんどの場合最初にトークン制限を要求します。
OpenAI の GPT-4o のエントリー層を見てみましょう: おおよそ 500RPM そして 30,000TPM (参考、2026 年 6 月)。 RPM 数値は余裕があるように見えます。しかし、いくつかのドキュメントが詰め込まれた検索拡張プロンプトは、簡単に実行できます。 4,000トークン と 500アウト — リクエストあたり 4,500 トークンとします。ここで、ドキュメントでは行われていない分割を実行します。
| 限界 | 価値 | 最大リクエスト/分 (4,500 トーク) |
|---|---|---|
| RPM (リクエスト/分) | 500 | 500 |
| TPM (トークン/分) | 30,000 | 6.7 ◀ バインド |
価格は参考見積り、2026 年 7 月。 古い価格を報告する →
つまり、あなたの本当の天井は 1 分間に 7 リクエスト未満トークン制限は、リクエスト制限が示す値の 1.3% に制限されます。これが、429 が 1 桁のトラフィックから始まる理由であり、「送信を遅くする」または「再試行を追加する」ことが原因ではなく症状を治療する理由です。
1 分あたりのリクエスト数は抽象的なものです。あなたが実際に知りたいのは、 一度に何人がアプリを使用できるか。各アクティブ ユーザーが 1 分あたりおよそ 2 つのリクエストを発行すると、その上限は 6.7 RPM になります。 3 人の同時ユーザー リクエストがキューイングを開始する前に。デモには問題ありません。打ち上げの壁。修正がより高速なループになることはほとんどありません。これは、次の 4 つの手段の 1 つです。
max_tokens burns the budget on rambling answers.同じ罠がどこにでも存在し、場合によってはより厳しい罠もあります。 Anthropic のエントリー、クロード層が登場 50 RPM / 40,000 TPM; Google の無料の Gemini 2.5 Flash レベルは、トークン (約 250,000 TPM) は寛大ですが、リクエスト (約 10 RPM) は控えめです。バインド制限は、プロンプトが大きいかトラフィックが急増しているかによって変わります。これがまさに、単一の経験則が失敗する理由です。プラグインする必要があります あなたの トークンのサイズ。
それが私たちの新しいものです レート制限計算機 行うこと: 層 (または実際の TPM/RPM)、入力トークンと出力トークン、各ユーザーの呼び出し頻度を入力すると、1 分あたりの有効なリクエスト数、処理できる同時ユーザー数、ボトルネックとなっている制限がわかります。これは、ユーザーが壁にぶつかる前に、ローンチが壁にぶつかるかどうかを確認する最も速い方法です。
RPM 制限を下回る 429 エラーはバグではありません。これは、1 分あたりのトークン制限が機能しているためです。サイズ容量オン トークン、リクエスト数ではありません。再試行する前にコンテキストをトリミングします。上限は支出に応じて上がることに注意してください。実際の上限がわかったら、トラフィックの価格を設定します。 LLM トークンコスト計算ツール そしてアプリ全体をモデル化します AI アプリのコスト見積りツール.
レート制限は参考値 (2026 年 6 月) であり、プロバイダー、モデル、アカウント層によって異なります。常にダッシュボードで確認してください。関連している： レート制限計算ツール ・ バッチ API の節約 ・ 最安の LLM API.