Zu welchem Dienst die Limits gehören
Die Namen sind leicht zu verwechseln. Groq ist ein Unternehmen, das Modelle auf seiner eigenen Hardware hostet. Grok ist die Modellfamilie von xAI. Diese Seite ist beides nicht: Sie ist eine OpenAI-kompatible API für ein Open-Weight-Modell (Modell-ID uncensored), betrieben von einem unabhängigen Anbieter. Für das Ratenlimit der Groq-API selbst, wie Anfragen oder Token pro Minute bei einem bestimmten Plan, öffne die Konsole oder Dokumentation von Groq und lies die Zahlen für dein Konto. Diese ändern sich, und ich werde nicht raten.
Das Folgende gilt exakt für unsere API, und die Gewohnheiten lassen sich auf jeden Anbieter übertragen: Respektiere die Limit-Header, wiederhole nur bei den richtigen Fehlern und begrenze deine eigene Parallelität, bevor der Server dies für dich tut. Wenn du hierher gekommen bist, um Grok NSFW einzurichten, behandelt unser Integrationsleitfaden auch die umgebenden Fehler.
Die Limits auf einen Blick
| Grenzwert | Voller Schlüssel | Test-Schlüssel |
|---|---|---|
| Parallele Anfragen | 8 | 2 |
| Anfragen pro Minute | 300 | 60 |
| Anfragekörper | 8 MB | 8 MB |
| Kontextfenster (Prompt plus Vervollständigung) | 100.000 Token | 100.000 Token |
Zwei davon sind Ratenlimits im engeren Sinne: Anfragen pro Minute und Parallelität. Die anderen zwei sind Größengrenzen für eine einzelne Anfrage und sind unabhängig von den Ratenlimits. Eine Anfrage mit einem 90.000-Token-Prompt zählt als eine Anfrage gegen die 300 pro Minute, genau wie ein einzeiliger Prompt, obwohl sie länger dauert und ihren Platz länger belegt.
Das Testguthaben von $0.50 wird mit einem Klick auf der API-Schlüssel-Seite nach der Anmeldung beansprucht und verwendet die Testlimits. Die Limits des vollständigen Schlüssels gelten, sobald du dein Guthaben aufgeladen hast.
Die drei Arten von 429
Alle Limit-Fehler kommen als HTTP 429, bedeuten aber unterschiedliche Dinge und erfordern unterschiedliche Reaktionen.
rate_limited: Du hast mehr Anfragen gesendet als dein Minutenkontingent. Drossle das Tempo; das Fenster beträgt eine Minute, daher hilft es mehr, Anfragen gleichmäßig zu verteilen, als lange zu pausieren.concurrency: Zu viele Anfragen waren gleichzeitig in Bearbeitung. Warte, bis eine frühere Anfrage abgeschlossen ist. Dies ist bei Streaming häufig, da jede Anfrage während der gesamten Generierung aktiv bleibt.- Temporäre Überlastung: ebenfalls ein 429, mit einem
Retry-After: 5-Header. Es ist nicht deine Schuld und nicht an die Limits deines Schlüssels gebunden. Warte die angegebenen 5 Sekunden und wiederhole die Anfrage.
Fehlgeschlagene Anfragen werden nicht berechnet, daher kostet eine Wiederholungsschleife nur die eine Anfrage, die schließlich erfolgreich ist. Antworten enthalten auch X-RateLimit-Limit-Requests und X-RateLimit-Limit-Concurrency, damit dein Client seine eigenen Obergrenzen lesen kann, anstatt sie hart zu codieren, sowie X-Balance-USD für das verbleibende Guthaben und X-Request-Id, das du protokollieren und zitieren solltest, wenn du Support kontaktierst.
Durchsatzberechnung: Warum 300 pro Minute schwer zu erreichen sind
Die beiden Limits interagieren. Mit 8 parallelen Slots kannst du pro Minute maximal 8 x 60 geteilt durch die durchschnittliche Dauer einer Anfrage in Sekunden abschließen. Um tatsächlich 300 Anfragen pro Minute zu erreichen, müssen Anfragen durchschnittlich in 8 x 60 / 300 = 1,6 Sekunden abgeschlossen werden. Langsamere Anfragen werden zuerst durch die Parallelität begrenzt.
| Durchschnittliche Anfragedauer | Maximal pro Minute, vollständiger Schlüssel (8 Slots) | Maximal pro Minute, Test (2 Slots) |
|---|---|---|
| 2 Sekunden | 240 | 60 |
| 10 Sekunden | 48 | 12 |
| 20 Sekunden | 24 | 6 |
Dies sind arithmetische Obergrenzen für eine hypothetische Anfragedauer, keine Messungen unseres Dienstes; miss deine eigenen Anfragen. Die Erkenntnis ist, dass eine lange kreative Generierung von 20 Sekunden bei einem vollständigen Schlüssel bei 24 Anfragen pro Minute endet, weit unter den erlaubten 300. Wenn du mehr Durchsatz benötigst, kürze die Antworten mit max_tokens oder fordere weniger Text pro Aufruf an, anstatt auf ein höheres Ratenlimit zu hoffen.
Ein Client, der alle drei Fälle verarbeitet
Dieser Python-Client begrenzt seine eigene Parallelität mit einem Semaphore, liest Retry-After, wenn vorhanden, und verzögert andernfalls mit Backoff und etwas Jitter. Er verwendet das offizielle openai-Paket.
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))Die gleiche Idee in Node ist eine kleine Warteschlange, die maximal 8 ausstehende Promises erlaubt, und die curl-Prüfung unten druckt die Limit-Header aus, damit du die Obergrenzen deines Schlüssels bestätigen kannst:
curl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
-H "Authorization: Bearer YOUR_KEY" | grep -i "x-"Streaming, lange Prompts und Kontext
Eine gestreamte Anfrage mit stream: true behält ihren Parallelitätsplatz bis zum Eintreffen des letzten Ereignisses. Das bedeutet, dass ein langsamer Leser gegen dich zählt: Wenn dein Code beim Verarbeiten jedes Chunks pausiert, bleibt der Slot belegt. Konsumiere den Stream zeitnah.
Lange Prompts interagieren auf zwei Arten mit den Limits. Erstens benötigen sie mehr Verarbeitungszeit, wodurch sie deinen Durchsatz nach der obigen Formel senken. Zweitens müssen sie zusammen mit der Antwort in das 100.000-Token-Fenster passen, also halte einen Puffer ein. Das Kürzen alter Chat-Verläufe hilft bei beiden Problemen, und dasselbe Kürzen reduziert deine Rechnung: Bei $0,15 pro 1M Input-Token kostet ein 20.000-Token-Verlauf jedes Mal, wenn du ihn erneut sendest, $0,003.
Details zum Anfrageformat findest du im Schnellstart, und die Preise stehen auf der Preisseite.
Limits für deine eigenen Benutzer anzeigen
Ein Ratenlimit ist auch eine Produktentscheidung. Wenn deine App zwischen Endbenutzern und der API sitzt, sollte ein roher 429-Fehler sie niemals erreichen. Entscheide im Voraus, was sie stattdessen sehen.
- Für Chat-Apps: Zeige einen kurzen „Schreibt…“-Status an und stelle die Nachricht in eine Warteschlange. Eine Wartezeit von einigen Sekunden ist für die meisten Benutzer unsichtbar, wenn etwas auf dem Bildschirm passiert.
- Für Batch-Tools: Zeige den Fortschritt als Anzahl abgeschlossener Elemente an und lasse den Job im Hintergrund laufen. Wiederholungen sind intern und sollten nicht als Fehler erscheinen.
- Für gemeinsam genutzte Bereitstellungen: Weise jedem Benutzer in deinem eigenen Code ein kleines pro-Benutzer-Limit zu, damit ein intensiver Benutzer nicht alle 8 Slots von den anderen belegt.
Protokolliere drei Dinge für jeden Fehler: die X-Request-Id, den Fehlercode und wie viele Anfragen deine App in diesem Moment gleichzeitig in Bearbeitung hatte. Damit kannst du einen fehlerhaften Client von echter Last in wenigen Minuten unterscheiden. Wenn ein Problem serverseitig zu sein scheint, ist die Request-ID das Erste, was Support fragen wird.
Teste schließlich den Fehlerpfad absichtlich. Führe deinen Client mit einem bewusst niedrigen Semaphore und dann mit einem hohen aus und beobachte, was die Logs anzeigen. Eine Retry-Schleife, die noch nie ausgelöst wurde, ist eine Retry-Schleife, der du nicht vertrauen kannst. Der Test-Schlüssel ist dafür ein praktischer Ort, da du bei nur 2 parallelen Anfragen mit einem kurzen Skript leicht den concurrency-Fehler auslösen und sehen kannst, wie dein Code reagiert, und das für den Bruchteil eines Cents pro Anfrage.
Häufige Fehler
Einige Muster verursachen den Großteil der 429-Probleme, die Benutzer melden.
- Sofortige Wiederholung. Eine Schleife, die bei jedem Fehler erneut sendet, verwandelt einen Moment der Limitüberschreitung in einen Sturm. Warte, füge Jitter hinzu und begrenze die Anzahl der Versuche.
- Alles wiederholen. Nur 429 und vorübergehende Serverfehler verdienen eine Wiederholung. Eine fehlerhafte Anfrage oder ein falscher Schlüssel wird jedes Mal auf die gleiche Weise fehlschlagen.
- Streams in der Zählung vergessen. Zehn offene Chat-Fenster bei einem vollständigen Schlüssel können zehn Streams sein, und das sind zwei mehr als die 8 Slots.
- Keine Zeitüberschreitung festlegen. Eine hängende Verbindung belegt einen Slot. Gib jeder Anfrage eine sinnvolle Zeitüberschreitung in deinem HTTP-Client.
- Für den Durchschnitt dimensionieren. Der Verkehr kommt in Bursts. Plane für deine intensivste Minute, nicht für deinen täglichen Durchschnitt.
Kapazitätsplanung vor dem Launch
Gehe von deinem Peak aus rückwärts. Wenn du erwartest, dass 30 Benutzer gleichzeitig chatten und jede Antwort etwa 15 Sekunden streamt, benötigst du 30 Slots in dem Moment, in dem alle senden, und ein vollständiger Schlüssel hat 8. Stelle den Rest in deiner eigenen App in eine Warteschlange, zeige eine kurze Wartezeit an und verarbeite sie, wenn Slots frei werden. Mit 8 Slots und 15-Sekunden-Antworten kannst du 8 x 60 / 15 = 32 Antworten pro Minute abschließen.
Für Batch-Jobs führe einen festen Worker-Pool gleich deiner Parallelitätsgrenze aus und lasse die Wiederholungslogik gelegentliche Überlastungen behandeln. Anstatt die Limits zu umgehen, baue die Warteschlange: Sie bietet vorhersehbares Verhalten und ermöglicht es dir, echte Wartezeiten für deine Benutzer anzuzeigen.
