Toda IA en producción tiene un secreto incómodo: depende de un proveedor de LLM que no está bajo tu control. Y los proveedores se caen. Se ponen lentos un martes por la mañana. Retornan error 529 de sobrecarga en el peor momento. Si tu agente depende de un único proveedor, entonces la disponibilidad de tu producto es, en realidad, la disponibilidad del eslabón más débil de la cadena — y le tercerizaste tu uptime a una empresa que no te debe nada.
En producción seria, esto es inaceptable. La solución es fallback de LLM, y es una de las primeras cosas que pongo de pie en cualquier agente.
El problema, en concreto
Imagina un agente atendiendo en WhatsApp o en una llamada en vivo. El cliente manda el mensaje, el agente llama al LLM primario y... timeout. O error 500. O una latencia de 15 segundos. Sin fallback, lo que el cliente ve es: silencio. La atención murió a la mitad. En una llamada de voz, es aún peor — no existe el "intenta de nuevo en un rato", la conversación es ahora.
La causa no siempre es una caída total. Muchas veces es degradación: el proveedor está de pie, pero lento o inestable. Desde el punto de vista del cliente, demasiado lento es lo mismo que fuera de servicio.
La arquitectura: fallback en cascada
El principio es simple: ningún punto único de falla en la respuesta. En la práctica, monto una cascada de modelos:
Petición
→ LLM primario (rápido, bueno, costo-beneficio)
¿falló/timeout? ↓
→ LLM secundario (otro proveedor, capacidad equivalente)
¿falló/timeout? ↓
→ LLM terciario (último recurso, solo para no morir)
Reglas que lo hacen funcionar:
Proveedores diferentes en cada nivel. Si el primario y el secundario son del mismo proveedor, una caída derriba a los dos. La resiliencia viene de la diversidad — modelos de empresas diferentes, infraestructuras diferentes.
Timeout agresivo antes de rendirse. No esperes 30 segundos a que el primario responda. Si en X segundos no llegó, considéralo falla y cae al siguiente. La latencia alta es falla.
Retry con sentido común. Un retry rápido en el mismo proveedor puede resolver un hipo momentáneo. Pero no te quedes intentando con el eslabón roto — cae al siguiente pronto.
Transparencia total para el cliente. Nunca debe saber que el primario se cayó. El cambio ocurre en milisegundos, entre bastidores. El éxito es que el cliente no note nada.
Bonus: el fallback también es optimización de costo
Una vez que tienes la infraestructura para enrutar entre modelos, sirve para más que resiliencia. La misma capa permite elegir el modelo correcto por tipo de mensaje: el modelo barato para intenciones simples ("¿cuál es mi factura?"), el modelo caro solo cuando la conversación exige razonamiento. La mayoría de los mensajes son simples — y esa elección reduce drásticamente el costo por conversación.
Es decir: la arquitectura que te salva cuando un proveedor se cae es la misma que ahorra dinero todos los días. Dos problemas, una solución.
Qué observar (si no, no sabes que está roto)
El fallback silencioso es genial para el cliente y peligroso para ti: si el primario se está cayendo todo el tiempo y el secundario aguantando, todo parece bien — hasta que el secundario se cae también. Por eso, mide: tasa de fallback por proveedor, latencia de cada nivel, cuántas peticiones llegaron al último recurso. Si tu primario empezó a fallar el 30% de las veces, quieres saberlo antes de que falle el 100%.
El principio
La resiliencia no es una funcionalidad que agregas después. Es una decisión de arquitectura que tomas al principio: mi producto no puede tener la disponibilidad de terceros que no controlo. El fallback de LLM es cómo recuperas ese control — transformando la caída inevitable de un proveedor en un no-evento que nadie nota.
Un agente sin fallback funciona lindamente en la demo. En producción, es una bomba esperando el día en que el proveedor tiene un mal día. Y el proveedor siempre lo tiene.
Construyo IA resiliente para producción — con fallback, observabilidad y la ingeniería que aguanta el mundo real. Si tienes una IA que no puede caerse, conversemos.