Picos de caída de ChatGPT: revisa tasa de error, p95, cola y coste

Un pico de búsquedas es un síntoma

Cuando las búsquedas por caídas se disparan, el dilema es velocidad frente a gasto: redirigir o escalar para reducir la latencia, o degradar y pagar menos. Las solicitudes fallidas equivalen a la tasa de error multiplicada por el tráfico, el tiempo de espera crece con la profundidad de cola y el gasto crece con los tokens multiplicados por el precio. La aritmética facilita la decisión.

Una observación aislada sin contexto puede llevar a un analista a error por lagunas o sesgo. Down Detector informó de problemas en cuatro chatbots populares a partir de aproximadamente las 15:00 hora peninsular española. La página de estado oficial de OpenAI indicó que estaba experimentando problemas y que había errores graves en ChatGPT y Codex. Se informó de que la caída comenzó alrededor de las 17:00 y no se restauró por completo hasta después de las 19:00, siendo el chatbot de Anthropic el más afectado. Se informó de que ChatGPT fue el primer servicio en volver a la operación normal.

Los informes de usuarios son ruidosos. Los datos de Down Detector atribuyeron el 77% de los problemas reportados de ChatGPT al chatbot, el 10% a Codex y el 7% a la aplicación. Esa distribución importa: una falla a nivel de modelo puede parecer una caída de producto. Se informó de que la caída de Claude afectó a Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8 y Opus 4.6.

La misma precaución aplica a las pruebas de capacidad. El 28 de febrero de 2022, las solicitudes HTTP desde Lviv, Ucrania aumentaron 3-4X, y Cloudflare reconoció que el aumento anómalo podría ser mal etiquetado como un ataque, pero otras señales ayudaron a evitar esa conclusión. En el mismo caso, los sistemas de defensa y mitigación DoS de Cloudflare no detectaron un ataque, lo que ayudó al equipo a evitar clasificar erróneamente el pico de tráfico. Dos pruebas de velocidad que comparten un cuello de botella pueden ver cada una solo la mitad del ancho de banda real, por lo que las estimaciones de capacidad requieren una medición consciente del método antes de escalar o redirigir.

El servicio de inferencia es una superficie operativa importante: AWS espera que hasta el 90% de las cargas de trabajo se conviertan en relacionadas con inferencia. La ruta de servicio es el primer lugar a revisar. Las páginas de estado son útiles, pero no sustituyen a tu propia telemetría. Un proveedor puede reconocer un problema mientras tus usuarios ya están viendo timeouts. Tu panel de control debería responder: ¿la ruta está fallando, está ralentizándose, y está costando más? Si la respuesta es solo coste, el incidente es un problema de presupuesto, no de fiabilidad.

Cuatro señales de servicio separan la caída del ruido

La revisión es para la ruta de servicio, no solo para el modelo. El modelo puede estar bien mientras la pasarela, la cola o la ruta de facturación de tokens esté rota. Usa la misma ventana de tiempo para las cuatro señales; una discrepancia puede hacer que una cola lenta parezca un problema de coste.

Ejecuta las cuatro comprobaciones en este orden; cada una es testeable en un minuto y apunta a un modo de fallo diferente. El orden separa el impacto en el usuario del impacto en el servicio.

• Tasa de error. Compara las fallas actuales con la línea base. Si los errores se disparan: la ruta de servicio está rota, no solo lenta.
• Latencia p95. Revisa la mayoría lenta, no la media. Un p95 en aumento significa que los usuarios sienten la cola antes de que suenen las alarmas.
• Profundidad de cola. Vigila las solicitudes pendientes y el margen de capacidad. Si la cola crece mientras la tasa de error se mantiene plana: estás cerca de la saturación.
• Coste por 1k de tokens. Multiplica el volumen de tokens por el precio unitario. Si el gasto sube con el tráfico: la solución puede ser enrutamiento, lotes o un modelo más pequeño.

Cuando la profundidad de cola no es directamente visible, infiérela a partir de la latencia y la tasa de solicitudes. Un p95 en aumento con errores planos es una cola que se forma. Cuando el coste no es visible en tiempo real, usa contadores de tokens y precio unitario. El objetivo es una tasa de gasto que puedas comparar con el tráfico.

La mitad de los despliegues de IA en producción tienen dificultades para mantener la latencia aceptable a escala. El coste de inferencia es la segunda línea presupuestaria más grande de la IA empresarial después del talento. Trata la latencia y el coste como señales de servicio fundamentales, no como añadidos de última hora.

La acción sigue a los números

Tasa de error alta y profundidad de cola alta: redirige primero. Tasa de error baja, p95 alto y profundidad de cola en aumento: escala o añade capacidad. P95 alto con profundidad de cola plana: degrada acortando el contexto, reduciendo los tokens máximos o usando un modelo más barato. Tasa de error, p95 y profundidad de cola estables, con solo el coste por 1k de tokens en aumento: paga o renegocia; no compres latencia que no necesitas.

Registra la decisión y la señal que la motivó. Redirigido: anota qué ruta asumió la carga. Degradado: anota qué ajuste de calidad cambió. Pagado: anota el coste por 1k de tokens antes y después. Un incidente posterior se vuelve más fácil cuando el anterior dejó un rastro.