Por qué falla el failover entre LLM en producción y qué hace Bifrost

Un análisis técnico publicado por Maxim AI repasa los modos de fallo más comunes del failover entre proveedores de LLM y presenta Bifrost, un gateway de IA de código abierto escrito en Go que propone resolverlos en la capa de infraestructura.

El texto parte de una premisa: cambiar de modelo no es como cambiar de réplica en un microservicio. Dos instancias detrás de un NGINX ejecutan el mismo código y devuelven respuestas idénticas; dos proveedores de LLM no. OpenAI, Anthropic, Google o AWS difieren en tokenizers, formatos de respuesta, esquemas de herramientas y límites de contexto. Las peticiones a un modelo duran segundos y son stateful: el estado de tokens, el historial conversacional o las tool calls se pierden si el reintento parte de cero. Y los errores no son códigos HTTP claros: hay límites de tasa opacos, streams que se cortan a mitad y degradaciones silenciosas de calidad.

Los fallos concretos

El artículo identifica varios patrones de fallo. El más común es la caída de una conexión de streaming a mitad de respuesta. Si el cliente ya recibió los primeros tokens de una generación larga y el gateway decide fallback a otro proveedor, el backup reinicia la respuesta desde el principio: el cliente ve texto duplicado o corrupto, o cuelga si el proveedor primario se queda en silencio sin cerrar el socket. El resultado es una doble facturación y, a menudo, una interrupción visible para el usuario.

Otro punto delicado son las llamadas a herramientas. Cuando un modelo decide invocar una función, el formato de los argumentos depende de su esquema de tool calling. Hacer fallback a un modelo que usa otro esquema produce argumentos malformados o funciones fallidas. Además, los límites de tasa pueden heredarse entre llamadas: si el proveedor primario devuelve 429, el secundario puede estar igualmente saturado, y un bucle de reintentos amplifica el problema en cascada.

Qué propone Bifrost

Bifrost no es un proxy HTTP más. Aplica políticas de enrutamiento atómicas, health checks activos y normalización de payload en la capa de puerta de enlace. El resultado es una sobrecarga media de 11 microsegundos por petición, según los autores. La documentación oficial incluye ejemplos de configuración para proveedores como OpenAI, Anthropic o Vertex AI.

El artículo insiste en que el problema no es solo técnico: saltar entre modelos puede violar requisitos de soberanía de datos, cumplimiento normativo o fronteras de seguridad. Por eso, una solución de failover debe decidir no solo cuándo cambia de proveedor, sino cuál es compatible con la política corporativa. Que un cambio así funcione en un test unitario no significa que aguante una tarde con un pico de tráfico.