Fiabilidad, reintentos y tiempos de espera

Cada solicitud se supervisa desde el inicio hasta el primer token. Si una ruta hacia el modelo se bloquea o falla, la solicitud pasa a otra antes de que nada llegue a ti.

Autorreparación

• La mayoría de los modelos se sirven a través de varias rutas. Cada solicitud empieza por la más saludable.
• Una ruta que da error o no se puede alcanzar se descarta para esa solicitud y se reintenta en otra. Una ruta que funciona se espera, por largo que sea el tiempo que tarde una solicitud grande; una que permanece completamente en silencio durante 3 minutos (5 con un esfuerzo de razonamiento alto) cuenta como fallida.
• Las rutas que fallan repetidamente pasan al final de la cola para todos. Una que se queda en silencio en una quinta parte o más de sus solicitudes queda por detrás de una ruta que responde sin problemas. Cada una se vuelve a probar en cuanto se recupera.
• Nada llega a ti hasta que ha llegado un token real, así que todo esto es invisible: ves una respuesta algo más lenta, no un error.

La página de modelos muestra el estado en directo de cada modelo (operativo, degradado o caído), a partir de solicitudes reales y de nuestras propias comprobaciones: cada modelo de chat se prueba al menos cada 10 minutos.

Tiempos de espera

Un flujo no envía nada durante sus primeros 20 segundos sin un primer token y luego abre con comentarios de keep-alive hasta que empieza la respuesta. Una solicitud sin streaming no envía nada hasta que termina, así que el streaming conviene a los clientes que abandonan cuando las cabeceras tardan (el fetch de Node las espera 5 minutos). Configura el tiempo de espera de tu cliente en al menos 10 minutos para razonamientos largos, salidas largas e imágenes. Los SDK de OpenAI usan 10 minutos por defecto; algunos clientes HTTP usan 30 o 60 segundos por defecto.

Límites de velocidad

No hay un límite de velocidad global en tu cuenta: las claves solo se limitan si les pones un límite de velocidad. Un workspace puede ejecutar 32 solicitudes a la vez; una más recibe 429 concurrency_limit_exceeded con retry-after. Un modelo sobrecargado se reintenta en sus otras rutas; si ninguna responde, recibes 503 model_unavailable con retry-after. Reduce el ritmo y reintenta, o activa el enrutamiento inteligente.

Cuando un modelo está caído

En raras ocasiones, fallan todas las rutas hacia un modelo. Sin enrutamiento inteligente, la solicitud termina con 503 model_unavailable y retry-after. Cuando las rutas dan error mientras el modelo sigue respondiendo a otras solicitudes, se trata de un fallo pasajero que suele resolverse en segundos, así que seguimos reintentándolas durante un máximo de 2 minutos. Cuando el modelo está caído para todos, el error llega de inmediato, y cuando las rutas permanecen en silencio, en un plazo de 10 minutos. Con enrutamiento inteligente, responde en su lugar una alternativa cercana.