58.7% de interrupciones inesperadas se debieron a GPUs, tres incidentes requirieron intervención humana significativa
Según se informa, durante los 54 días de pre-entrenamiento, hubo un total de 466 interrupciones de trabajo. De estas, 47 fueron interrupciones planificadas debido a mantenimiento automatizado, como actualizaciones de firmware o actualizaciones de configuración o conjunto de datos iniciadas por operadores; 419 fueron interrupciones inesperadas, principalmente debido a problemas de hardware confirmados, incluyendo fallas de GPU, componentes de host o problemas sospechosos relacionados con hardware, como corrupción silenciosa de datos y eventos de mantenimiento de host único no planificados.
Los problemas de GPU fueron la categoría principal de interrupciones inesperadas, representando el 58.7% de todos los problemas inesperados, incluyendo varias fallas de GPU como NVLink y fallas de memoria HBM3. Esto no es sorprendente, ya que las GPU H100 de Nvidia consumen alrededor de 700W y soportan mucho estrés térmico. A pesar de la gran cantidad de fallas, solo tres incidentes requirieron intervención humana significativa, el resto de los problemas pudieron ser manejados por automatización.
El 41.3% restante de las interrupciones inesperadas se debió a una combinación de errores de software, cables de red y adaptadores de red. Curiosamente, solo dos CPUs fallaron durante este período.
Durante los 54 días de pre-entrenamiento de Llama 3 405B, se clasificaron las causas raíz de las interrupciones inesperadas.
Otro desafío que enfrentó el equipo de entrenamiento del modelo grande Llama 3 405B fue la fluctuación de consumo de energía de decenas de miles de GPUs simultáneamente, lo que ejerció presión sobre la red eléctrica del centro de datos.
Durante el entrenamiento, miles de GPUs pueden aumentar o disminuir su consumo de energía simultáneamente, por ejemplo, al esperar que se complete un punto de control o que finalice una comunicación colectiva, o al iniciar o apagar toda la tarea de entrenamiento. Cuando esto ocurre, puede causar fluctuaciones instantáneas en el consumo de energía del centro de datos del orden de decenas de megavatios, lo que podría sobrecargar la red eléctrica.
Este es un desafío continuo, lo que significa que Meta debe asegurarse de que sus centros de datos tengan suficiente energía para mantener el funcionamiento normal del modelo de 405B y futuros modelos Llama de mayor escala. A medida que la complejidad de los modelos de IA continúa creciendo, también aumentan los recursos computacionales necesarios.
Esfuerzos detrás de lograr un 90% de tiempo de entrenamiento efectivo
Para mejorar la eficiencia, Meta desarrolló varias herramientas y estrategias de optimización, incluyendo la reducción de los tiempos de inicio de tareas y puntos de control, el uso extensivo del registrador de vuelo NCCL incorporado en PyTorch, y la identificación de GPUs rezagadas. Entre estos, NCCLX jugó un papel crucial en la detección y localización de fallas, especialmente para problemas relacionados con NVLink y RoCE, y su integración con PyTorch permitió el monitoreo y el tiempo de espera automático de las pausas de comunicación causadas por fallas de NVLink.
Se entiende que el registrador de vuelo NCCL de PyTorch puede registrar metadatos colectivos y seguimientos de pila en un búfer circular, lo que permite un diagnóstico y resolución rápidos de problemas de bloqueo y rendimiento a gran escala, especialmente aquellos relacionados con NCCLX. Además, debido a que Meta utiliza una mezcla de NVLink y RoCE en su red, la depuración de problemas en el entrenamiento a gran escala se vuelve más compleja. Las transferencias de datos a través de NVLink generalmente se realizan mediante operaciones de carga/almacenamiento emitidas por kernels CUDA, y las fallas de GPU remotas o conexiones NVLink generalmente se manifiestan como operaciones de carga/almacenamiento estancadas dentro de los kernels CUDA, sin devolver códigos de error explícitos.
NCCLX mejoró la velocidad y precisión de la detección y localización de fallas a través de un diseño colaborativo cercano con PyTorch, permitiendo que PyTorch acceda al estado interno de NCCLX y rastree información relevante. Aunque no puede prevenir completamente los bloqueos causados por fallas de NVLink, el sistema monitorea el estado de la biblioteca de comunicación y automáticamente agota el tiempo de espera cuando detecta tales bloqueos. Además, NCCLX también rastrea la actividad del kernel y la red para cada comunicación NCCLX y proporciona instantáneas del estado interno de los colectivos NCCLX fallidos, incluyendo las transferencias de datos completadas y pendientes entre todos los rangos.
A veces, los problemas de hardware pueden resultar en "rezagados" que aún funcionan pero son lentos y difíciles de detectar. Incluso un solo "rezagado" puede ralentizar el funcionamiento de miles de otras GPUs, a menudo manifestándose como comunicaciones normales pero lentas. Para abordar esto, Meta desarrolló herramientas para priorizar las comunicaciones potencialmente problemáticas de grupos de procesos seleccionados, detectando y resolviendo efectivamente a los rezagados de manera oportuna, asegurando que la desaceleración se minimice y manteniendo la eficiencia general del entrenamiento.
Otra observación interesante es el impacto de los factores ambientales en el rendimiento del entrenamiento a gran escala. Para Llama 3 405B, Meta notó una variación de 1-2% en el rendimiento en cierto momento del día, una fluctuación causada por las temperaturas más altas al mediodía que afectaban el ajuste dinámico de voltaje y frecuencia de las GPUs, influyendo así en el rendimiento del entrenamiento. Sin embargo, esto no es un gran problema, ya que el escalado dinámico de voltaje y frecuencia de las GPUs suele verse afectado por los cambios de temperatura.
Conclusión
Considerando que un clúster de 16384 GPUs H100 experimentó 419 fallas inesperadas en 54 días, 7.76 veces cada 24 horas, no podemos evitar preguntarnos, ¿con qué frecuencia ocurrirán fallas en el superclúster Memphis de xAI equipado con 100000 GPUs H100?
La semana pasada, Elon Musk se jactó en la plataforma social X de haber lanzado "el clúster de entrenamiento de IA más poderoso del mundo", afirmando que creará "la IA más poderosa del mundo en todos los indicadores" antes de diciembre de este año. Se informa que el superclúster Memphis ha comenzado el entrenamiento, utilizando refrigeración líquida y una arquitectura de interconexión de red RDMA única.
En términos de escala de GPU, el superclúster Memphis de xAI probablemente enfrentará una tasa de fallas exponencialmente más alta, con un número de componentes fallidos que podría aumentar seis veces, lo que presenta un desafío aún mayor para su futuro entrenamiento de IA.
Enlaces de referencia:
https://www.inspire2rise.com/meta-faces-frequent-gpu-failures-llama-3-training.html
https://ai.meta.com/research/publications/the-llama-3-herd-of-models/