Notas de ingeniería
Enrutamiento de respaldo para una latencia predecible
Por qué un gateway de modelos necesita una ruta de respaldo explícita y qué debe ocultar o mostrar a tu aplicación.
Qué aprenderás
- Retry only transient upstream failures; never replay invalid or unauthorized requests.
- Choose fallbacks by endpoint and workload, not by name alone.
- Log the selected route, retry count, and final upstream result.
Antes de empezar
- Basic HTTP and API knowledge
Leave with a concrete implementation checklist and a testable starting point.
Conclusiones clave
- Reintenta solo fallos transitorios explícitos.
- Selecciona alternativas compatibles con el endpoint y la carga.
- Registra ruta final, reintentos y resultado del proveedor.
El problema de un único proveedor
Una función de producción puede depender de un proveedor mientras este afronta saturación regional, timeouts o límites temporales de capacidad. Con un único destino, ese incidente se convierte también en tu incidente.
Un gateway mantiene una dirección estable y concentra las decisiones específicas del proveedor en el borde.
Qué debe hacer el respaldo
La ruta de respaldo debe actuar después de clasificar endpoint, modelo, grupo de cuenta y política. Los fallos transitorios seguros pueden reintentarse; las solicitudes inválidas y los errores de autenticación no deben repetirse a ciegas.
La aplicación sigue recibiendo una respuesta compatible con OpenAI.
Diseñar para la visibilidad
Registra el modelo elegido, el resultado del proveedor, los reintentos y la ruta final. Combina esos datos con tu propio request ID y mediciones de latencia.
Consulta el catálogo y los precios actuales de EasyAI antes de convertir una alternativa en política de producción.
Cómo elegir
| Criterio | Opción A | Opción B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Pasos de implementación
- 1
Clasifica endpoint, modelo, grupo y timeout.
- 2
Define una lista corta de modelos compatibles.
- 3
Haz como máximo un reintento controlado.
- 4
Mide p50, p95, p99 y tasa de fallback.
Ejemplo para copiar
const candidates = ["deepseek-chat", "deepseek-reasoner"];
const retryable = new Set([429, 500, 502, 503, 504]);
for (const model of candidates) {
try {
return await client.chat.completions.create({ model, messages });
} catch (error) {
const status = error instanceof OpenAI.APIError ? error.status : undefined;
if (!status || !retryable.has(status) || model === candidates.at(-1)) throw error;
}
}Preguntas frecuentes
¿Todo timeout debe activar el fallback?
No. Distingue timeout del proveedor, cancelación del cliente y saturación de tu aplicación.
¿Puede cambiar la calidad?
Sí. Registra el modelo final y limita el fallback a casos donde la diferencia sea aceptable.
Fuentes
- EasyAI documentationFuente verificada 2026-08-27