Mantener los flujos de agentes activos cuando un proveedor de LLM cae

El proveedor es una dependencia frágil

Tu flujo de agentes está llamando a un proveedor de LLM y el proveedor ha caído. ChatGPT, Claude, Gemini y Grok sufrieron interrupciones de servicio que afectaron a miles de usuarios durante varios minutos. Los problemas con cuatro chatbots populares comenzaron por la tarde, alrededor de las 15:00 hora peninsular española. El Mundo informó que Downdetector mostró que el incidente se extendió a Groq, descrita como la IA de Elon Musk, y a Amazon Web Services, y que las primeras hipótesis culpaban a un tráfico repentino que colapsó una ruta de Cloudflare.

La página de estado oficial de OpenAI indicó que estaba experimentando problemas y errores graves en ChatGPT y Codex. El 77% de los problemas reportados de ChatGPT estaban directamente relacionados con el chatbot, el 10% con el asistente de código de OpenAI, Codex, y el 7% con la aplicación. Se informó que la caída de Claude afectaba a Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8 y Opus 4.6. ChatGPT fue el primer servicio en recuperar su operación normal.

Para un flujo de agentes, el incidente es una falla de dependencia. Las llamadas al modelo pueden fallar, agotar el tiempo de espera o devolver una salida degradada mientras el resto del flujo aún espera una respuesta limpia. El trabajo del operador es mantener el sistema útil, no fingir que el proveedor está sano.

Prepara el respaldo antes de la caída

Elige un proveedor secundario que pueda manejar la carga máxima. Pruébalo con los mismos prompts, herramientas y salvaguardas. Mantén las claves API, los límites de tasa, las alertas de facturación y un responsable designado en el mismo canal de incidente. Si el flujo depende de un formato de salida o un comportamiento de herramienta específico, verifica que el respaldo soporte el mismo contrato. Los respaldos que solo funcionan para chat simple fallan en producción.

Asocia cada flujo a una respuesta mínima viable. Los agentes pueden ejecutarse con un modelo más pequeño, devolver una respuesta en caché o detenerse y pedir ayuda a un humano. Decide eso antes del incidente, no durante.

Controla la tarifa del proveedor de respaldo en el canal de incidente. Los respaldos que agotan el presupuesto pueden desencadenar otro incidente. Establece un límite de gasto y un camino de aprobación para un uso prolongado.

El runbook de dependencia de LLM mantiene el flujo activo

El runbook tiene cuatro pasos: detectar, degradar, enrutar, notificar.

• Detecta la falla antes de que los usuarios la descubran. Instrumenta cada llamada de LLM con latencia, tasa de error, recuento de tokens y comprobaciones de validez de salida. Los agotamientos de tiempo, los errores de servidor, las completaciones vacías y la salida que no coincide con el formato esperado son señales. Alerta cuando la tasa de error supere un umbral y muestra la salud del proveedor por modelo, región y flujo.
• Degrada el flujo a un estado seguro. Detén los bucles de agentes de larga ejecución que dependen del proveedor fallido. Encola el trabajo entrante, reduce la concurrencia y desactiva los pasos opcionales. Mantén las solicitudes principales respondiendo, incluso con menos fuentes, resúmenes más cortos o una bandera de revisión manual.
• Enruta el tráfico a un proveedor de respaldo o a una respuesta en caché. El respaldo debe estar preaprobado, probado y mapeado al mismo contrato de entrada/salida. Si no existe un respaldo, sirve un modo limitado. No cambies de modelo en silencio. Los usuarios pueden notar un tono diferente, una calidad de razonamiento alterada o un comportamiento de rechazo distinto. Diles qué cambió. La respuesta de respaldo debe coincidir con el contrato original y mostrar una nota visible de que el modelo cambió.
• Notifica a las personas que deben actuar. Envía un mensaje interno de incidente con el proveedor afectado, los modelos, los flujos y el impacto en usuarios. Envía una nota de estado para el usuario cuando el cambio afecte su salida. Deja un canal de incidente con marca de tiempo, una actualización de estado para el cliente y un responsable claro para cada tarea de recuperación.

La recuperación no es silencio

Después de que el proveedor regrese, no devuelvas todo el tráfico de golpe. Verifica las rutas de respaldo y principales con la misma suite de pruebas. Revisa el uso de tokens, la latencia y la calidad de la salida antes de aumentar la carga. Cuando el incidente cambie un comportamiento visible para el usuario, dilo en la nota post-incidente. Los operadores deben registrar qué falló, qué se degradó, qué se enrutó y qué se dijo a los usuarios.

Mantén el runbook lo suficientemente corto para que un ingeniero cansado pueda usarlo a altas horas de la noche. Imprime los pasos. Pon los umbrales de alerta, el responsable del respaldo y la plantilla de mensaje para el usuario en una sola página. La próxima falla del proveedor no esperará a una revisión de diseño.

Usa el incidente para mejorar el sistema. Si la detección fue lenta, añade una sonda sintética que llame al proveedor regularmente. El enrutamiento manual de respaldo necesita automatización para los patrones de falla conocidos. Las quejas de usuarios sobre la salida cambiada necesitan una insignia de modelo visible o una línea de estado. Programa la corrección ahora, antes de la próxima caída.