Inicio → Ayuda

Timeout 524 en peticiones largas a la API

Un 524 lo genera un proxy inverso o una CDN situada delante de la API, no el modelo. Salta cuando el origen no ha enviado el primer byte de la respuesta dentro de un plazo fijo, habitualmente 100 segundos.

Lo que ves

Por qué ocurre

El detalle importante es que el reloj mide el tiempo hasta el primer byte, no la duración total. Una respuesta con streaming empieza a emitir casi de inmediato, así que puede durar muchos minutos sin llegar nunca al límite. Una petición sin streaming con una fase de razonamiento larga no envía nada hasta terminar del todo, y esa es exactamente la forma que se corta.

Por eso el fallo parece aleatorio. El mismo prompt funciona cuando termina rápido y falla cuando el modelo piensa más tiempo, y se correlaciona con la profundidad del razonamiento, no con nada que hayas cambiado.

Comprueba si es esta la causa

Ejecuta la misma petición con streaming activado y desactivado. Si una sobrevive y la otra no, lo has encontrado:

# non-streaming — vulnerable to the time-to-first-byte limit
curl -sS -X POST 'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL","stream":false,"messages":[...]}'

# streaming — first byte arrives in well under a second
  -d '{"model":"MODEL","stream":true,"messages":[...]}'

El streaming además te da un modo de fallo mucho mejor: si algo va mal a mitad, conservas la salida parcial en lugar de perder toda la llamada.

Cómo solucionarlo

  1. Activa el streamingEsto resuelve el problema de raíz en casi cualquier carga de trabajo, y es un cambio de una línea. La mayoría de los SDK y herramientas de agentes ya usan streaming por defecto.
  2. Usa un endpoint directo si el proveedor lo ofreceAlgunos proveedores publican un host de API que evita su CDN precisamente para esquivar este límite. Si las llamadas largas sin streaming son inevitables, para eso existe.
  3. Divide el trabajoSi una sola llamada necesita de verdad minutos de razonamiento antes de producir nada, suele ser más barato y fiable dividirla en etapas con puntos de control.
En APICLAN las peticiones con streaming nunca se almacenan en búfer, así que no se ven afectadas. Para llamadas largas sin streaming hay un endpoint directo en https://api.apiclan.us/v1 sin ese límite.

Relacionado

Unexpected token '<' al llamar a una API compatible con OpenAI401 invalid API key: cuando la clave parece correcta pero sigue fallando

Revisado por última vez el 2026-10-01. Escrito a partir de problemas diagnosticados en una pasarela compatible con OpenAI en producción, no recopilado de otras webs.