Limite di richieste API Groq e come funzionano i limiti 429

A quale servizio appartengono i limiti

I nomi sono facili da confondere. Groq è un'azienda che ospita modelli su hardware proprietario. Grok è la famiglia di modelli di xAI. Questo sito non è nessuna delle due: è un'API compatibile con OpenAI per un singolo modello a pesi aperti (ID del modello uncensored), gestita da un provider indipendente. Quindi per il limite di richieste dell'API Groq stesso, come le richieste o i token al minuto su un piano specifico, apri la console o la documentazione di Groq e leggi i valori per il tuo account. I valori cambiano e non farò supposizioni.

Quanto segue è esatto per la nostra API, e le abitudini si applicano a qualsiasi provider: rispetta gli header dei limiti, riprova solo per gli errori corretti e limita la tua concorrenza prima che il server lo faccia per te. Se sei qui per una configurazione Grok NSFW, la nostra guida all'integrazione copre anche gli errori correlati.

I limiti a colpo d'occhio

Due di questi sono limiti di richieste in senso stretto, richieste al minuto e concorrenza. Gli altri due sono limiti di dimensione su una singola richiesta e sono indipendenti dai limiti di frequenza. Una richiesta con un prompt da 90.000 token conta come una sola richiesta contro le 300 al minuto, proprio come un prompt di una riga, anche se richiederà più tempo e manterrà il suo slot più a lungo.

Il credito di prova di $0.50 si ottiene con un clic sulla pagina chiave API dopo la registrazione, e utilizza i limiti della prova. I limiti della chiave completa si applicano dopo aver ricaricato il credito.

I tre tipi di 429

Tutti gli errori di limite arrivano come HTTP 429, ma hanno significati diversi e richiedono reazioni diverse.

• rate_limited: hai inviato più richieste del tuo limite di richieste al minuto. Rallenta; la finestra è di un minuto, quindi distribuire le richieste uniformemente aiuta più di una lunga pausa.
• concurrency: troppe richieste erano in corso simultaneamente. Attendi che una precedente termini. Questo è comune con lo streaming, dove ogni richiesta vive per tutta la generazione.
• Sovraccarico temporaneo: è anche un 429, con un header Retry-After: 5. Non è colpa tua e non è legato ai limiti della tua chiave. Attendi i 5 secondi indicati e riprova.

Le richieste fallite non vengono addebitate, quindi un ciclo di retry costa solo la richiesta che alla fine va a buon fine. Le risposte riportano anche X-RateLimit-Limit-Requests e X-RateLimit-Limit-Concurrency così che il tuo client possa leggere i propri massimali invece di scriverli nel codice, oltre a X-Balance-USD per il credito residuo e X-Request-Id, che dovresti registrare e citare se contatti supporto.

Calcolo del throughput: perché 300 al minuto è difficile da raggiungere

I due limiti interagiscono. Con 8 slot concorrenti, il massimo che puoi completare al minuto è 8 x 60 diviso la durata media di una richiesta in secondi. Per raggiungere effettivamente 300 richieste al minuto hai bisogno di richieste che terminino in 8 x 60 / 300 = 1,6 secondi in media. Le richieste più lente sono limitate prima dalla concorrenza.

Questi sono massimali aritmetici per un tempo di richiesta ipotetico, non misurazioni del nostro servizio; cronometra le tue richieste. La conclusione è che una generazione creativa lunga di 20 secondi su una chiave completa si ferma a 24 richieste al minuto, ben al di sotto delle 300 consentite. Se hai bisogno di più throughput, accorcia le risposte con max_tokens o chiedi meno testo per chiamata invece di sperare in un limite di richieste più alto.

Un client che gestisce tutti e tre i casi

Questo client Python limita la propria concorrenza con un semaforo, legge Retry-After quando presente, e usa un backoff con un piccolo jitter altrimenti. Usa il pacchetto ufficiale openai.

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 stessa idea in Node è una piccola coda che permette al massimo 8 promesse in sospeso, e il controllo curl sotto stampa gli header dei limiti così che tu possa confermare i massimali della tua chiave:

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

Streaming, prompt lunghi e contesto

Una richiesta in streaming con stream: true mantiene il suo slot di concorrenza fino all'arrivo dell'ultimo evento. Questo significa che un lettore lento conta contro di te: se il tuo codice si ferma mentre gestisce ogni chunk, lo slot rimane occupata. Consuma lo streaming prontamente.

I prompt lunghi interagiscono con i limiti in due modi. Primo, richiedono più tempo per essere elaborati, quindi riducono il tuo throughput secondo la formula sopra. Secondo, devono adattarsi alla finestra da 100.000 token insieme alla risposta, quindi mantieni un margine. Tagliare i vecchi turni della chat aiuta entrambi i problemi, e lo stesso taglio riduce la tua bolletta: a $0,15 per 1M di token di input, una cronologia da 20.000 token costa $0,003 ogni volta che la invii.

I dettagli del formato della richiesta sono nella guida rapida, e i prezzi sono nella pagina dei prezzi.

Mostrare i limiti ai tuoi utenti

Un limite di richieste è anche una decisione di prodotto. Se la tua app si trova tra gli utenti finali e l'API, un 429 grezzo non dovrebbe mai raggiungerli. Decidi in anticipo cosa vedranno.

• Per le app di chat, mostra un breve stato "scrittura" e accoda il messaggio. Un'attesa di pochi secondi è invisibile alla maggior parte degli utenti se c'è qualcosa che accade sullo schermo.
• Per gli strumenti batch, mostra il progresso come conteggio degli elementi completati e lascia che il lavoro venga eseguito in background. I retry sono interni e non dovrebbero apparire come errori.
• Per le distribuzioni condivise, assegna a ogni utente un piccolo limite per utente nel tuo codice in modo che un utente molto attivo non possa occupare gli 8 slot degli altri.

Registra tre cose per ogni fallimento: l'X-Request-Id, il codice di errore e quante richieste la tua app aveva in corso in quel momento. Con quelli, puoi distinguere un client malfunzionante da un carico reale in pochi minuti. Se un problema sembra essere lato server, l'ID della richiesta è ciò che supporto chiederà per primo.

Infine, testa intenzionalmente il percorso di errore. Esegui il tuo client con un semaforo deliberatamente basso e poi con uno alto, e osserva cosa mostrano i log. Un ciclo di ritentativi che non è mai partito è un ciclo di ritentativi in cui non puoi fidarti. La chiave di prova è un luogo conveniente per questo, poiché con sole 2 richieste concorrenti è facile incontrare l'errore concurrency con uno script breve e vedere come reagisce il tuo codice, al costo di pochi decimi di centesimo per richiesta.

Errori comuni

Alcuni pattern causano la maggior parte dei problemi 429 segnalati dalle persone.

1. Ritentare istantaneamente. Un ciclo che ritenta ogni errore trasforma un singolo momento di superamento del limite in una tempesta. Attendi, aggiungi jitter e limita il numero di tentativi.
2. Ritentare tutto. Solo i 429 e gli errori transienti del server meritano un ritentativo. Una richiesta malformata o una chiave errata falliranno allo stesso modo ogni volta.
3. Dimenticare lo streaming nel conteggio. Dieci finestre di chat aperte con una chiave completa possono essere dieci stream, e sono due in più rispetto agli 8 slot.
4. Non impostare un timeout. Una connessione bloccata mantiene occupata uno slot. Imposta un timeout ragionevole per ogni richiesta nel tuo client HTTP.
5. Dimensionare per la media. Il traffico arriva a raffiche. Pianifica per il tuo minuto più intenso, non per la media giornaliera.

Pianificare la capacità prima del lancio

Parti dal picco. Se prevedi 30 utenti che chattano contemporaneamente e ogni risposta fa streaming per circa 15 secondi, ti servono 30 slot nel momento in cui tutti inviano, e una chiave completa ne ha 8. Accoda il resto nella tua app, mostra una breve attesa e processali quando gli slot si liberano. Con 8 slot e risposte da 15 secondi puoi completare 8 x 60 / 15 = 32 risposte al minuto.

Per i lavori batch, esegui un pool di worker fisso pari al tuo limite di concorrenza e lascia che la logica di ritentativo gestisca i sovraccarichi occasionali. Invece di aggirare i limiti, costruisci la coda: ti dà un comportamento prevedibile e ti permette di mostrare tempi di attesa reali ai tuoi utenti.

Altre guide

• Guida all'integrazione LLM NSFW Uncensored Grok API