El incidente principal es la dificultad inherente de mantener la fiabilidad de la infraestructura de GPU a escala de hyperscaler, donde los fallos de hardware son una ocurrencia común y no trivial de detectar. Los checks de estado estándar de la nube y los checks básicos a nivel de GPU resultaron insuficientes porque no podían detectar fallos sutiles en la memoria on-chip, adaptadores de red de alta velocidad degradados o problemas de firmware que solo se manifestaban bajo carga de trabajo. Además, las propias herramientas de diagnóstico podían fallar o colgarse, dando una falsa sensación de salud.
La causa raíz es la naturaleza distribuida y de "gang" de las cargas de trabajo de ML, donde el fallo o la degradación de un solo componente (GPU, interconexión, red) en una máquina puede ralentizar o detener todo un job que se ejecuta durante semanas. Las salvaguardas existentes fallaron porque no eran lo suficientemente profundas ni resistentes a los fallos de las propias herramientas de diagnóstico. La falta de un mapa de errores fatales actualizado y la dependencia de binarios que podían desaparecer tras una actualización también contribuyeron a la invisibilidad de los problemas.
La cascada de fallos se manifestaba en jobs de ML que se ralentizaban o fallaban, lo que resultaba en una baja utilización de GPU, retrasos en el entrenamiento de modelos y un impacto directo en la experiencia del usuario final (recomendaciones, activos promocionales). La falta de atribución clara de fallos llevaba a reintentos ineficaces o al reemplazo de hardware sano. La solución implicó un enfoque de defensa en profundidad, con múltiples capas de detección y remediación, y un cambio de paradigma para asumir que el hardware puede mentir y las herramientas pueden fallar.