制限がどのサービスに属するか
名称は混同しやすいものです。Groqは、自前のハードウェア上でモデルをホストする企業です。GrokはxAIのモデルファミリーです。このサイトはそれらどちらでもなく、独立したプロバイダが運営するオープンウェイトモデル（モデルID uncensored）向けのOpenAI互換APIです。したがって、groq APIのレート制限そのもの（特定のプランにおける1分あたりのリクエスト数やトークン数など）については、Groqのコンソールまたはドキュメントを開き、アカウントの数字を確認してください。それらは変動し、私は推測しません。
以下に述べる内容は当APIにおいて正確であり、その習慣は他のプロバイダにも当てはまります：制限ヘッダを尊重し、適切なエラーのみで再試行し、サーバーがあなたに代わって制限する前に、ご自身の同時実行数を制限してください。Grok NSFWの設定についてお探しの場合は、統合ガイドで関連するエラーについても解説しています。
制限の概要
| 制限 | フルキー | トライアルキー |
|---|---|---|
| 同時リクエスト | 8 | 2 |
| 1分あたりのリクエスト数 | 300 | 60 |
| リクエストボディ | 8 MB | 8 MB |
| コンテキストウィンドウ（プロンプトと補完） | 100,000トークン | 100,000トークン |
このうち2つは厳密な意味でのレート制限（分間リクエスト数と同時実行数）です。残り2つは単一リクエストのサイズ制限であり、レート制限とは独立しています。90,000 トークンのプロンプトを持つリクエストは、1行のプロンプトと同じく分間 300 のカウントとして1回として扱われますが、処理には時間がかかり、枠をより長く占有します。
$0.50のトライアルクレジットは、サインアップ後にAPIキーページでワンクリックで取得でき、トライアル制限が適用されます。チャージが完了すると、フルキーの制限が適用されます。
3 種類の 429
すべての制限エラーは HTTP 429 として到着しますが、意味と対応する対応策が異なります。
rate_limited: リクエスト数の上限を超えました。速度を落としてください。ウィンドウは1分なので、リクエストを均等に間隔を空けて送る方が、長時間の一時停止よりも効果的です。concurrency：同時に実行中のリクエストが多すぎます。以前のものが完了するまで待ってください。ストリーミングでは各リクエストが生成全体にわたって存続するため、これが一般的です。- 一時的な過負荷：これも 429 で、
Retry-After: 5ヘッダーが付きます。これはあなたのせいでも、キーの制限に関連するものでもありません。指定された 5 秒待機してリトライしてください。
失敗したリクエストは課金されません。そのため、リトライループで実際に課金されるのは最後に成功した1回分のリクエストのみです。レスポンスには X-RateLimit-Limit-Requests および X-RateLimit-Limit-Concurrency が含まれるため、クライアントはこれをハードコードするのではなく、自身の上限値として読み取ることができます。さらに、残高クレジットを示す X-Balance-USD と、サポート へ連絡する際にログに記録し、参照すべき X-Request-Id も含まれています。
スループットの計算：分間 300 が難しい理由
2つの制限は相互作用します。8つの同時枠がある場合、1分あたりに完了できる最大数は、リクエストの平均秒数で 8 x 60 を割ったものです。実際に分間 300 リクエストに到達するには、平均して 8 x 60 / 300 = 1.6 秒で完了するリクエストが必要です。より遅いリクエストはまず同時実行数によって制限されます。
| 平均リクエスト時間 | フルキー（8枠）の分間最大 | トライアルキー（2枠）の分間最大 |
|---|---|---|
| 2 秒 | 240 | 60 |
| 10 秒 | 48 | 12 |
| 20秒 | 24 | 6 |
これらは仮想的なリクエスト時間の算術的な上限値であり、当サービスの測定値ではありません。ご自身のリクエストの時間を計測してください。重要な点は、フルキーで20秒かかる長いクリエイティブな生成の場合、1分あたりのリクエスト数は最大で24回となり、許容される300回を大幅に下回るということです。スループットをさらに上げたい場合は、max_tokens で応答を短くするか、リクエスト制限の引き上げを期待するのではなく、呼び出しごとに必要なテキスト量を抑えてください。
3つのケースすべてを処理するクライアント
このPythonクライアントはセマフォを使用して自身の同時実行数を制限し、存在する場合は Retry-After を読み取り、それ以外の場合はわずかなジッターを加えてバックオフします。公式の openai パッケージを使用しています。
import random
import threading
import time
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI, RateLimitError
client = OpenAI(
base_url="https://api.groknsfw.top/v1",
api_key="YOUR_KEY",
max_retries=0, # we handle retries ourselves
)
slots = threading.BoundedSemaphore(8) # use 2 on the trial key
def ask(prompt, tries=6):
for attempt in range(tries):
with slots:
try:
r = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": prompt}],
max_tokens=400,
)
return r.choices[0].message.content
except RateLimitError as e:
wait = e.response.headers.get("retry-after")
body = e.response.text
# sleep outside the slot so others can proceed
delay = float(wait) if wait else min(2 ** attempt, 30)
if "rate_limited" in body:
delay = max(delay, 5)
time.sleep(delay + random.random())
raise RuntimeError("still rate limited after retries")
with ThreadPoolExecutor(max_workers=8) as pool:
results = list(pool.map(ask, ["Write one line about the sea."] * 20))
print(len(results))Node での同じアイデアは、最大 8 の保留中の promise を許可する小さなキューであり、以下の curl チェックは制限ヘッダーを出力してキーの上限を確認できるようにします：
curl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
-H "Authorization: Bearer YOUR_KEY" | grep -i "x-"ストリーミング、長いプロンプト、コンテキスト
stream: true を持つストリーミングリクエストは、最後のイベントが届くまで同時実行数の枠を保持します。つまり、遅いリーダーはあなたにカウントされます：チャンクを処理する際にコードが一時停止すると、枠は使用中のままになります。ストリームを迅速に消費してください。
長いプロンプトは、2つの方法で制限と相互作用します。第一に、処理に時間がかかるため、上記の式によってスループットが低下します。第二に、応答と合わせて100,000トークンのウィンドウに収まる必要があるため、余裕を持たせてください。古いチャットのやり取りを削除すると両方の問題に役立ち、同じ削除により請求額も削減されます：1M入力トークンあたり$0.15の場合、20,000トークンの履歴を再送信するたびに$0.003かかります。
リクエスト形式の詳細は クイックスタート に、料金は 価格ページ に記載されています。
自身のユーザーへの制限の表示
レート制限は製品上の判断でもあります。もしアプリがエンドユーザーと API の間に位置する場合、生の 429 をユーザーに表示してはいけません。代わりに何を表示するかを事前に決定してください。
- チャットアプリの場合：短い「入力中」状態を表示し、メッセージをキューに入れます。画面に何かが起きている場合、数秒の待機はほとんどのユーザーには見えません。
- バッチツールの場合：完了したアイテムのカウントとして進捗を表示し、ジョブをバックグラウンドで実行させます。リトライは内部のものであり、エラーとして表示すべきではありません。
- 共有デプロイの場合：自身のコードで各ユーザーにユーザーごとの小さな割り当てを設け、一人の負荷の高いユーザーが他のユーザーの8枠すべてを占有できないようにしてください。
すべての失敗について3つのものをログに記録してください：X-Request-Id、エラーコード、およびその瞬間にアプリが同時に実行していたリクエスト数。これらがあれば、数分で問題のあるクライアントと実際の負荷を区別できます。問題がサーバー側にあるように見える場合、リクエスト ID が サポート が最初に求めるものです。
最後に、意図的に失敗パスをテストしてください。クライアントを意図的に低いセマフォで実行し、次に高いセマフォで実行し、ログに何が表示されるかを確認します。一度も発火したことがないリトライループは信頼できません。この目的にはトライアルキーが便利な場所です。並列リクエストが2つのみであるため、短いスクリプトでconcurrencyエラーに簡単に到達し、コードがどのように反応するかを確認でき、リクエストごとに1セントの数分の1程度のコストで済みます。
よくあるミス
報告される 429 トラブルの大部分は、いくつかのパターンによって引き起こされます。
- 即時リトライ。 失敗ごとに再送するループは、1回の制限超過を嵐に変えます。待機し、ジッターを追加し、試行回数を制限してください。
- すべてをリトライ。 429 と一時的なサーバーエラーのみがリトライに値します。不正な形式のリクエストや間違ったキーは、毎回同じ方法で失敗します。
- ストリームをカウントし忘れる。 フルキーで開かれたチャットウィンドウ10個は10ストリームであり、8枠を2つ超えます。
- タイムアウトを設定しない。 ハングした接続は枠を占有したままにします。HTTP クライアントに各リクエストに適切なタイムアウトを設定してください。
- 平均値に合わせてサイズ調整。 トラフィックはバーストで来ます。日平均ではなく、最も忙しい1分に合わせて計画してください。
ローンチ前のキャパシティ計画
ピークから逆算してください。同時に30人のユーザーがチャットし、各返信が約15秒ストリーミングすると予想される場合、全員が送信する瞬間に30枠が必要であり、フルキーには8枠しかありません。残りを自身のアプリでキューに入れ、短い待機を表示し、枠が空くたびに処理してください。8枠と15秒の返信では、分間 8 x 60 / 15 = 32 件の返信を完了できます。
バッチジョブの場合、同時実行数の制限に等しい固定ワーカープールを実行し、リトライロジックで時折発生する過負荷を処理してください。制限を回避するのではなく、キューを構築してください：それは予測可能な動作をもたらし、ユーザーに実際の待機時間を表示できます。
