Estado y fiabilidad
Cómo gestiona la pasarela los fallos de los proveedores y qué hacer cuando algún servicio funciona de forma degradada.
Cómo funciona la conmutación por error
Las solicitudes se distribuyen entre la capacidad disponible de los proveedores de origen. Cuando uno devuelve un error o está sobrecargado, el tráfico se traslada a otro en lugar de provocar un fallo definitivo; por eso un 529 es menos frecuente aquí que al llamar directamente a un único proveedor.
Qué significa cada fallo para usted
| Ves | Dónde está el fallo | Qué hacer |
|---|---|---|
529 sobrecargado | Capacidad del proveedor de origen | Reintente con intervalos de espera crecientes; suele resolverse en segundos |
500 | Pasarela | Reintente una vez y luego informe del problema con el identificador de la solicitud |
429 | Concurrencia de su cuenta | Reduzca el paralelismo — Límites de solicitudes |
| Primer token lento | Colas en el proveedor de origen bajo carga | Es previsible durante los picos; la transmisión en tiempo real permite detectarlo antes |
Diseño para afrontar la degradación del servicio
- Reintento
429,500,502,503y529con espera exponencial y variación aleatoria. - Mantenga configurado un modelo de respaldo: pasar de Opus a Sonnet es preferible a devolver un error.
- Establezca tiempos de espera para que una solicitud bloqueada no pueda ocupar un proceso de trabajo indefinidamente.
- Ejecute la
/v1/modelscomprobación de estado en CI para detectar una credencial que no funciona antes del despliegue.
Si una incidencia afecta a su cuenta, contacte con support@aiprimetech.io e incluya marcas de tiempo y un identificador de solicitud.