Limite de débit de l'API Groq et fonctionnement de nos limites 429

À quel service appartiennent les limites

Les noms sont faciles à confondre. Groq est une entreprise qui héberge des modèles sur son propre matériel. Grok est la famille de modèles d'xAI. Ce site n'est ni l'un ni l'autre : c'est une API compatible OpenAI pour un seul modèle à poids ouverts (ID du modèle uncensored), gérée par un fournisseur indépendant. Pour la limite de débit de l'API Groq proprement dite, comme le nombre de requêtes ou de tokens par minute sur un plan donné, ouvrez la console de Groq ou sa documentation et lisez les chiffres pour votre compte. Ils changent, et je ne devinerai pas.

Ce qui suit est exact pour notre API, et les habitudes se transmettent à tout fournisseur : respectez les en-têtes de limite, ne réessayez qu'en cas d'erreurs appropriées, et plafonnez votre propre concurrence avant que le serveur ne le fasse pour vous. Si vous êtes venu ici pour une configuration Grok NSFW, notre guide d'intégration couvre également les erreurs associées.

Les limites en un coup d'œil

Deux de ces limites sont des limites de débit strictes : requêtes par minute et concurrence. Les deux autres sont des limites de taille sur une seule requête, indépendantes des limites de débit. Une requête avec un prompt de 90 000 tokens compte comme une seule requête face aux 300 par minute, comme un prompt d'une ligne, bien qu'elle prenne plus de temps et occupe sa place plus longtemps.

Le crédit d'essai de 0,50 $ est réclamé en un clic sur la page clé API après l'inscription, et il utilise les limites d'essai. Les limites de la clé complète s'appliquent une fois que vous avez rechargé votre compte.

Les trois types d'erreur 429

Toutes les erreurs de limite arrivent sous forme de HTTP 429, mais elles signifient des choses différentes et appellent à des réactions différentes.

• rate_limited : vous avez envoyé plus de requêtes que votre quota par minute. Ralentissez ; la fenêtre est d'une minute, donc espacer les requêtes uniformément aide plus qu'une longue pause.
• concurrency : trop de requêtes étaient en cours en même temps. Attendez qu'une requête précédente se termine. C'est courant avec le streaming, où chaque requête dure toute la génération.
• Surcharge temporaire : également un 429, avec un en-tête Retry-After: 5. Ce n'est pas de votre faute et cela n'est pas lié aux limites de votre clé. Attendez les 5 secondes indiquées et réessayez.

Les requêtes échouées ne sont pas facturées, donc une boucle de réessai ne coûte que la requête qui réussit enfin. Les réponses portent également les en-têtes X-RateLimit-Limit-Requests et X-RateLimit-Limit-Concurrency pour que votre client puisse lire ses propres plafonds au lieu de les coder en dur, plus X-Balance-USD pour le crédit restant et X-Request-Id, que vous devez journaliser et citer si vous contactez le support.

Mathématiques du débit : pourquoi 300 par minute est difficile à atteindre

Les deux limites interagissent. Avec 8 slots de concurrence, le plus que vous pouvez terminer par minute est 8 x 60 divisé par la durée moyenne d'une requête en secondes. Pour atteindre réellement 300 requêtes par minute, vous avez besoin de requêtes qui se terminent en 8 x 60 / 300 = 1,6 seconde en moyenne. Les requêtes plus lentes sont limitées par la concurrence en premier.

Ce sont des plafonds arithmétiques pour une durée de requête hypothétique, pas des mesures de notre service ; chronométrez vos propres requêtes. La conclusion est qu'une génération créative longue de 20 secondes sur une clé complète plafonne à 24 requêtes par minute, bien en dessous des 300 autorisés. Si vous avez besoin de plus de débit, réduisez les réponses avec max_tokens ou demandez moins de texte par appel plutôt que d'espérer une limite de requête plus élevée.

Un client qui gère les trois cas

Ce client Python limite sa propre concurrence avec un sémaphore, lit Retry-After lorsqu'il est présent, et recule avec une petite variation aléatoire sinon. Il utilise le package openai officiel.

Copyimport 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))

La même idée en Node est une petite file d'attente qui permet au plus 8 promesses en attente, et la vérification curl ci-dessous imprime les en-têtes de limite pour que vous puissiez confirmer les plafonds de votre clé :

Copycurl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
  -H "Authorization: Bearer YOUR_KEY" | grep -i "x-"

Streaming, longs prompts et contexte

Une requête en streaming avec stream: true conserve son slot de concurrence jusqu'à l'arrivée du dernier événement. Cela signifie qu'un lecteur lent compte contre vous : si votre code fait une pause lors du traitement de chaque chunk, le slot reste occupé. Consommez le flux rapidement.

Les longs prompts interagissent avec les limites de deux manières. Premièrement, ils prennent plus de temps à traiter, ce qui réduit votre débit selon la formule ci-dessus. Deuxièmement, ils doivent tenir dans la fenêtre de 100 000 tokens avec la réponse, donc gardez une marge. Réduire les anciens tours de chat aide à ces deux problèmes, et la même réduction réduit votre facture : à 0,15 $ par 1M de tokens d'entrée, un historique de 20 000 tokens coûte 0,003 $ à chaque fois que vous le renvoyez.

Les détails du format de requête sont dans le guide de démarrage rapide, et les tarifs sont sur la page de tarification.

Afficher les limites à vos propres utilisateurs

Une limite de débit est aussi une décision produit. Si votre application se trouve entre les utilisateurs finaux et l'API, un 429 brut ne devrait jamais les atteindre. Décidez à l'avance ce qu'ils voient à la place.

• Pour les applications de chat, affichez un court état « en train d'écrire » et mettez le message en file d'attente. Une attente de quelques secondes est invisible pour la plupart des utilisateurs si quelque chose se passe à l'écran.
• Pour les outils par lots, affichez la progression comme un nombre d'éléments terminés et laissez le travail s'exécuter en arrière-plan. Les réessais sont internes et ne doivent pas apparaître comme des erreurs.
• Pour les déploiements partagés, donnez à chaque utilisateur une petite allocation par utilisateur dans votre propre code pour qu'un utilisateur intensif ne puisse pas prendre les 8 slots des autres.

Journalisez trois choses pour chaque échec : le X-Request-Id, le code d'erreur, et le nombre de requêtes que votre application avait en cours à ce moment-là. Avec cela, vous pouvez distinguer un client mal comporté d'une charge réelle en quelques minutes. Si un problème semble venir du côté serveur, l'ID de requête est ce que le support demandera en premier.

Enfin, testez le chemin d'échec intentionnellement. Exécutez votre client avec un sémaphore délibérément bas puis avec un haut, et observez ce que montrent les logs. Une boucle de réessai qui n'a jamais été déclenchée est une boucle de réessai en laquelle vous ne pouvez pas avoir confiance. La clé d'essai est un endroit pratique pour cela, car avec seulement 2 requêtes simultanées, il est facile de déclencher l'erreur concurrency avec un script court et de voir comment votre code réagit, au coût de quelques dixièmes de centime par requête.

Erreurs courantes

Quelques cas provoquent la plupart des problèmes 429 signalés par les utilisateurs.

1. Réessai immédiat. Une boucle qui réessaie à chaque échec transforme un dépassement de limite en tempête. Attendez, ajoutez un jitter et limitez le nombre de tentatives.
2. Réessayer tout. Seuls les 429 et les erreurs serveur transitoires méritent un réessai. Une requête malformée ou une clé incorrecte échouera de la même manière à chaque fois.
3. Oublier les flux dans le compte. Dix fenêtres de chat ouvertes sur une clé complète peuvent être dix flux, et c'est deux de plus que les 8 slots.
4. Ne pas définir de timeout. Une connexion bloquée garde un slot occupé. Donnez à chaque requête un timeout raisonnable dans votre client HTTP.
5. Dimensionner pour la moyenne. Le trafic arrive par rafales. Planifiez pour votre minute la plus chargée, pas votre moyenne quotidienne.

Planifier la capacité avant le lancement

Travaillez à rebours à partir de votre pic. Si vous attendez 30 utilisateurs en chat simultané et que chaque réponse est diffusée en streaming pendant environ 15 secondes, vous avez besoin de 30 slots à l'instant où ils envoient tous, et une clé complète en a 8. Mettez le reste en file d'attente dans votre application, affichez une courte attente, et traitez-les lorsque les slots se libèrent. Avec 8 slots et des réponses de 15 secondes, vous pouvez terminer 8 x 60 / 15 = 32 réponses par minute.

Pour les travaux par lots, exécutez un pool de workers fixe égal à votre limite de concurrence et laissez la logique de réessai gérer la surcharge occasionnelle. Au lieu de contourner les limites, construisez la file d'attente : cela vous donne un comportement prévisible et vous permet d'afficher des temps d'attente réels à vos utilisateurs.

Plus de guides

• API Grok sans censure : Guide d'intégration LLM NSFW