A qué servicio pertenecen los límites
Los nombres son fáciles de confundir. Groq es una empresa que aloja modelos en su propio hardware. Grok es la familia de modelos de xAI. Este sitio no es ninguno de los dos: es una API compatible con OpenAI para un único modelo de pesos abiertos (ID de modelo uncensored), gestionada por un proveedor independiente. Así que para el límite de peticiones de la API de groq en sí, como peticiones o tokens por minuto en un plan dado, abre la consola o documentación de Groq y lee las cifras para tu cuenta. Cambian, y no voy a adivinar.
Lo que sigue es exacto para nuestra API, y los hábitos se trasladan a cualquier proveedor: respeta los encabezados de límite, reintenta solo en los errores correctos y limita tu propia concurrencia antes de que el servidor lo haga por ti. Si viniste aquí para una configuración de Grok NSFW, nuestra guía de integración cubre también los errores relacionados.
Los límites de un vistazo
| Límite | Clave completa | Clave de prueba |
|---|---|---|
| Peticiones simultáneas | 8 | 2 |
| Peticiones por minuto | 300 | 60 |
| Cuerpo de petición | 8 MB | 8 MB |
| Ventana de contexto (prompt más respuesta) | 100.000 tokens | 100.000 tokens |
Dos de estos son límites de peticiones en sentido estricto, peticiones por minuto y concurrencia. Los otros dos son límites de tamaño en una única petición, y son independientes de los límites de peticiones. Una petición con un prompt de 90.000 tokens cuenta como una petición contra las 300 por minuto, igual que un prompt de una línea, aunque tardará más y mantendrá su slot más tiempo.
El crédito de prueba de $0.50 se reclama con un clic en la página de clave de API tras registrarte, y usa los límites de prueba. Los límites de clave completa se aplican una vez que hayas recargado.
Los tres tipos de 429
Todos los errores de límite llegan como HTTP 429, pero significan cosas distintas y requieren reacciones distintas.
rate_limited: enviaste más peticiones de tu cuota por minuto. Ralentiza; la ventana es de un minuto, así que espaciar las peticiones uniformemente ayuda más que una pausa larga.concurrency: había demasiadas peticiones en vuelo a la vez. Espera a que termine una anterior. Esto es común con streaming, donde cada petición vive durante toda la generación.- Sobrecarga temporal: también es un 429, con un encabezado
Retry-After: 5. No es culpa tuya ni está ligado a los límites de tu clave. Espera los 5 segundos indicados y reintenta.
Las peticiones fallidas no se cobran, así que un bucle de reintento solo cuesta la petición que finalmente tiene éxito. Las respuestas también llevan X-RateLimit-Limit-Requests y X-RateLimit-Limit-Concurrency para que tu cliente pueda leer sus propios límites en lugar de codificarlos en duro, además de X-Balance-USD para el crédito restante y X-Request-Id, que deberías registrar y citar si contactas con soporte.
Matemáticas de throughput: por qué es difícil alcanzar 300 por minuto
Los dos límites interactúan. Con 8 slots concurrentes, lo máximo que puedes completar por minuto es 8 x 60 dividido por la duración media de una petición en segundos. Para alcanzar realmente 300 peticiones por minuto necesitas peticiones que terminen en 8 x 60 / 300 = 1,6 segundos de media. Las peticiones más lentas están limitadas primero por concurrencia.
| Tiempo medio de petición | Máximo por minuto, clave completa (8 slots) | Máximo por minuto, prueba (2 slots) |
|---|---|---|
| 2 segundos | 240 | 60 |
| 10 segundos | 48 | 12 |
| 20 segundos | 24 | 6 |
Estos son techos aritméticos para un tiempo de petición hipotético, no medidas de nuestro servicio; cronometra tus propias peticiones. La conclusión es que una generación creativa larga de 20 segundos en una clave completa alcanza un máximo de 24 peticiones por minuto, muy por debajo de las 300 permitidas. Si necesitas más capacidad de procesamiento, acorta las respuestas con max_tokens o pide menos texto por llamada en lugar de esperar un límite de peticiones más alto.
Un cliente que gestiona los tres casos
Este cliente Python limita su propia concurrencia con un semáforo, lee Retry-After cuando está presente, y retrocede con una pequeña variación aleatoria en caso contrario. Usa el paquete oficial 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))La misma idea en Node es una cola pequeña que permite como máximo 8 promesas pendientes, y la comprobación con curl que imprime los encabezados de límite para que puedas confirmar los techos de tu clave:
curl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
-H "Authorization: Bearer YOUR_KEY" | grep -i "x-"Streaming, prompts largos y contexto
Una petición en streaming con stream: true mantiene su plaza de concurrencia hasta que llega el último evento. Eso significa que un lector lento cuenta contra ti: si tu código se pausa al manejar cada fragmento, la plaza se mantiene ocupada. Consume el streaming rápidamente.
Los prompts largos interactúan con los límites de dos formas. Primero, tardan más tiempo en procesarse, así que reducen tu capacidad de procesamiento con la fórmula anterior. Segundo, deben caber en la ventana de 100.000 tokens junto con la respuesta, así que mantén un margen. Recortar los turnos antiguos del chat ayuda a ambos problemas, y el mismo recorte reduce tu factura: a $0.15 por 1M de tokens de entrada, un historial de 20.000 tokens cuesta $0.003 cada vez que lo reenvías.
Los detalles del formato de la petición están en el guía de inicio rápido, y las tarifas están en la página de precios.
Mostrando límites a tus propios usuarios
Un límite de peticiones también es una decisión de producto. Si tu app se sitúa entre usuarios finales y la API, un 429 crudo nunca debería llegarles. Decide de antemano qué ven en su lugar.
- Para apps de chat, muestra un estado corto de "escribiendo" y coloca el mensaje en cola. Una espera de unos segundos es invisible para la mayoría de usuarios si algo está pasando en pantalla.
- Para herramientas por lotes, muestra el progreso como un recuento de elementos terminados y deja que el trabajo corra en segundo plano. Los reintentos son internos y no deberían aparecer como errores.
- Para despliegues compartidos, da a cada usuario una pequeña cuota por usuario en tu propio código para que un usuario pesado no se lleve los 8 slots de los demás.
Registra tres cosas para cada fallo: el X-Request-Id, el código de error y cuántas peticiones tenía tu app en vuelo en ese momento. Con eso, puedes distinguir un cliente que se comporta mal de una carga real en unos minutos. Si un problema parece estar en el lado del servidor, el ID de petición es lo primero que pedirá soporte.
Por último, prueba a propósito la ruta de error. Ejecuta tu cliente con un semáforo deliberadamente bajo y luego con uno alto, y observa qué muestran los registros. Un bucle de reintento que nunca se ha activado es un bucle de reintento en el que no puedes confiar. La clave de prueba es un lugar conveniente para esto, ya que con solo 2 peticiones simultáneas es fácil provocar el error de concurrency con un script corto y ver cómo reacciona tu código, con un coste de unas décimas de céntimo por petición.
Errores comunes
Algunos patrones causan la mayoría de los problemas 429 que la gente reporta.
- Reintentar al instante. Un bucle que reenvía en cada fallo convierte un momento de exceso de límite en una tormenta. Espera, añade jitter y limita el número de intentos.
- Reintentar todo. Solo 429 y errores transitorios del servidor merecen un reintento. Una petición mal formada o una clave incorrecta fallarán igual cada vez.
- Olvidar las transmisiones en el recuento. Diez ventanas de chat abiertas en una clave completa pueden ser diez transmisiones, y eso son dos más que las 8 plazas.
- No configurar un tiempo de espera. Una conexión colgada mantiene una plaza ocupada. Asigna a cada petición un tiempo de espera sensato en tu cliente HTTP.
- Dimensionar para el promedio. El tráfico llega en ráfagas. Planifica para tu minuto más intenso, no para tu media diaria.
Planificando capacidad antes del lanzamiento
Trabaja hacia atrás desde tu pico. Si esperas 30 usuarios chateando a la vez y cada respuesta se transmite durante unos 15 segundos, necesitas 30 plazas en el instante en que todos envían, y una clave completa tiene 8. Pon el resto en cola en tu propia aplicación, muestra una espera breve y procésalos a medida que se libran plazas. Con 8 plazas y respuestas de 15 segundos puedes terminar 8 x 60 / 15 = 32 respuestas por minuto.
Para trabajos por lotes, ejecuta un grupo de trabajadores fijo igual a tu límite de concurrencia y deja que la lógica de reintento gestione la sobrecarga ocasional. En lugar de rodear los límites, construye la cola: te da un comportamiento predecible y te permite mostrar tiempos de espera reales a tus usuarios.
