Cómo mantenemos la confiabilidad de las GPU en todo Databricks AI

El entrenamiento distribuido de GPU se ha convertido en una rutina en toda la industria. Ahora, los equipos entrenan modelos fundacionales, realizan el ajuste fino de modelos a escala de frontera, crean grandes sistemas de visión y ejecutan redes de recomendación profundas a escalas que antes eran dominio exclusivo de los laboratorios de vanguardia.

Construir una infraestructura de GPU que pueda satisfacer la escala actual requiere hacer bien muchas cosas: detectar los fallos que interrumpen una ejecución, identificar las degradaciones lentas que nunca se anuncian, validar el estado de la red de interconexión (fabric) a través de miles de enlaces, programar tareas en torno a hardware que tarde o temprano fallará y recuperarse de forma limpia cuando esto ocurra. Muchos de estos aspectos son fundamentales, y los problemas más complejos que se encuentran más arriba en la pila dependen de ellos.

En Databricks AI, ejecutamos cargas de trabajo de entrenamiento a escala masiva cada semana, donde los fallos aparecen continuamente en el hardware, la red de interconexión y el software. Esta serie analiza lo que se necesita para mantener la fiabilidad de las GPU a esta escala, comenzando con los aspectos fundamentales en esta primera publicación: los modos de fallo que se encuentran al ejecutar GPU, las diversas cargas de trabajo que los revelan y el sistema de control de estado de varias etapas que los detecta. El entrenamiento es el tipo de carga de trabajo más exigente y el tema central aquí, aunque la misma ingeniería sirve para la inferencia y otras cargas de trabajo de GPU en Databricks.

Cómo fallan las GPU bajo la carga de entrenamiento

La mayoría de los fallos de GPU a escala se dividen en tres categorías: trabajos caídos, ralentizaciones silenciosas y corrupción numérica. Los trabajos caídos son el caso fácil, en el sentido de que se sabe inmediatamente cuando ocurre uno. Los fallos más difíciles son las cargas de trabajo que finalizan con valores incorrectos en el modelo, o que se ejecutan con un rendimiento degradado durante horas sin que nadie se dé cuenta.

Trabajos caídos. Los trabajos de entrenamiento distribuido se caen por muchas razones: una GPU que se degrada o se desconecta del bus, problemas en la red de interconexión RDMA, un bloqueo del sistema de I/O, o un rango del lado de la CPU que diverge de los demás. Desde la perspectiva de la carga de trabajo, casi todos estos problemas se manifiestan de la misma manera: el trabajo se cae con el temido mensaje de tiempo de espera agotado del watchdog de NCCL en los registros. Cada rango se bloquea en la misma operación colectiva, el watchdog finalmente finaliza el trabajo y se reinicia desde el último punto de control (checkpoint). Pero el tiempo de espera agotado en sí mismo no dice casi nada sobre la causa raíz. Diagnosticar lo que realmente salió mal a menudo significa realizar un seguimiento a través de las capas de hardware, red de interconexión, sistema de archivos y software a partir de un seguimiento de la pila (stack trace) que solo muestra el síntoma.

Ralentizaciones silenciosas. Una GPU degradada silenciosamente puede continuar progresando en el entrenamiento, con registros que parecen correctos y una pérdida (loss) que sigue disminuyendo. Sin embargo, el rendimiento (throughput) se ve limitado por la GPU más lenta, lo que desperdicia capacidad de cómputo y dinero. Estas ralentizaciones provienen de hardware que se ejecuta en un estado degradado, donde los sensores térmicos se activan bajo una carga sostenida, los enlaces de interconexión se degradan tras errores persistentes o el ancho de banda de la memoria disminuye a medida que se acumulan los fallos. Cada uno se manifiesta en diferentes señales a nivel de hardware, por ejemplo, motivos de limitación (throttle) de DCGM como HW_SLOWDOWN o HW_THERMAL_SLOWDOWN para problemas térmicos, o el estado del enlace para las interconexiones.

Corrupción numérica. Las GPU modernas utilizan el código de corrección de errores (ECC) para detectar y corregir automáticamente muchos fallos de memoria transitorios sin interrumpir el entrenamiento. Sin embargo, no todos los fallos se pueden recuperar. La corrupción puede originarse en la memoria, las interconexiones, los kernels o las capas de software, y puede propagarse antes de ser detectada o contenida. En esos casos, el entrenamiento puede detenerse inmediatamente o continuar con valores incorrectos. Los fallos pueden aparecer como pérdidas NaN, convergencia inestable o regresiones en la calidad del modelo que solo se descubren más tarde.

Nuestro enfoque para la fiabilidad de las GPU

Las tasas de eventos de fallo de hardware de las GPU pueden ser un orden de magnitud mayores que las de las CPU. Como una estimación rápida y conservadora, supongamos que cada GPU tiene una tasa anualizada de eventos de fallo del 1%. Para un trabajo que utiliza N GPU durante T días, la probabilidad de que ocurra al menos un evento es aproximadamente:

Un trabajo de 256 GPU que se ejecuta durante 30 días tiene aproximadamente un 19% de probabilidad de experimentar un fallo. Con 1,024 GPU, esa cifra aumenta al 57%. A esta escala, se esperan fallos durante una ejecución, no son una excepción. Como base, dos inversiones en ingeniería mantienen la fiabilidad del entrenamiento a pesar de ellos: las pruebas de esfuerzo con cargas de trabajo diversas y de vanguardia que revelan los fallos de forma temprana, y un sistema de control de estado de varias etapas que los detecta en toda la flota.

Pruebas de esfuerzo de la plataforma con cargas de trabajo de vanguardia

Databricks AI ejecuta una variedad de cargas de trabajo de entrenamiento exigentes en la misma plataforma que utilizan los clientes: entrenamiento de aprendizaje por refuerzo para modelos como KARL, modelos de codificación agénticos, sistemas de inteligencia de documentos como el que está detrás de PDF en producción, y más. Estos no son los trabajos de entrenamiento habituales. Las cargas de trabajo de RL combinan entrenamiento, inferencia y cálculo de recompensas en bucles cerrados a través de muchas GPU. Los modelos de codificación agénticos impulsan evaluaciones con un alto nivel de inferencia junto con el entrenamiento. Los canales (pipelines) de inteligencia de documentos combinan el entrenamiento de modelos con una pesada carga de datos basados en imágenes.

Cada uno somete a la plataforma a esfuerzos de distintas maneras, lo que los hace eficaces para revelar problemas operativos como la inestabilidad de la red de interconexión (fabric), puntos calientes térmicos y casos extremos en la comunicación colectiva antes de que afecten a cargas de trabajo de producción más amplias.

Así es como se vio un problema reciente. Una ejecución de entrenamiento falló con un tiempo de espera agotado de NCCL a las siete horas de haber comenzado. La investigación mostró que un único puerto InfiniBand utilizado para operaciones colectivas NCCL de RDMA se había caído una vez y se había recuperado. No volvió a fluctuar.

La caída se debió a cuál de los dos tiempos de espera agotados de NCCL se activa primero. La mayoría de las discusiones sobre la configuración de NCCL se centran en el tiempo de espera agotado del watchdog de NCCL de PyTorch, configurable a través de init_process_group(timeout=...), que finaliza una operación colectiva colgada después de una duración configurable (normalmente 10 minutos). Un segundo tiempo de espera agotado se encuentra más abajo en la pila y se activa mucho antes: NCCL_IB_TIMEOUT, en la capa de transporte de InfiniBand, controla cuánto tiempo espera una conexión a que se recupere un puerto caído antes de cerrar la conexión. Su valor predeterminado efectivo resulta ser de aproximadamente siete segundos si se tienen en cuenta los reintentos, mucho más corto de lo que la mayoría de los equipos cree. Una vez que una única ventana de puerto caído supera ese tiempo, la conexión se pierde y la operación colectiva ya está muerta, independientemente de cómo esté configurado el tiempo de espera agotado del watchdog de PyTorch. Para cuando el watchdog detecta el bloqueo, la ejecución ya está destinada a caerse.

La señal que importa para el impacto en el entrenamiento es el tiempo de inactividad acumulado, no el recuento de fluctuaciones. Una sola fluctuación lo suficientemente larga puede hacer caer una ejecución de entrenamiento de varios días, al igual que las fluctuaciones repetidas durante horas. Ajustamos nuestros valores predeterminados de NCCL_IB_TIMEOUT para que sean más resilientes, y la misma señal de puerto caído nos permite detener y reiniciar el trabajo desde un punto de control sin dejar las GPU inactivas hasta que se active el watchdog. Esta investigación es una de las muchas que alimentan el sistema de control de estado que se describe en el resto de esta publicación.

Controles de estado a lo largo del ciclo de vida del nodo

Creamos gpu-monitor como un servicio de observabilidad y control de estado de varias etapas que se ejecuta en cada nodo de GPU, cubriendo todo el ciclo de vida del nodo. Se ejecutan diferentes categorías de control en diferentes etapas, porque se pueden detectar diferentes modos de fallo en diferentes condiciones.

Controles de arranque (bootstrap) activos se ejecutan cuando se aprovisiona un nodo por primera vez y nuevamente cada vez que se limpia entre las cargas de trabajo de los clientes. Cada carga de trabajo comienza en un nodo que acaba de superar el conjunto completo de controles. Estos detectan fallos deterministas, cosas que se pueden revelar de manera confiable mediante una prueba específica por adelantado. Una muestra representativa de lo que ejecuta gpu-monitor:

• Velocidad de cómputo de GPU y validación de burn-in
• Conectividad directa de GPU a GPU verificada en cada par (estado de NVLink y NVSwitch)
• Corrección y ancho de banda de all-reduce de NCCL dentro del nodo
• Ancho de banda de NIC RDMA a través de bucle de retorno (loopback) local del host
• Estado de la memoria ECC y HBM, incluido el margen de reasignación de filas
• Topología de PCIe e integridad del enlace
• Diagnósticos de NVIDIA DCGM en el nivel 2

Cualquier nodo que falle una comprobación activa se elimina inmediatamente de la flota antes de que se ejecute cualquier carga de trabajo en él. Los nodos defectuosos se ponen en cuarentena y luego se someten a reinicios y pruebas exhaustivas antes de volver a la flota o eliminarse de forma permanente.

Las comprobaciones continuas pasivas vigilan los modos de fallo no deterministas de las secciones anteriores, fallos que solo surgen bajo una presión de carga de trabajo sostenida. Para estos, gpu-monitor ejecuta una segunda capa de comprobaciones en cada nodo activo, como:

• Estado del carril NVLink (se marca cualquier carril que se caiga)
• Motivos de limitación del reloj de la GPU (HW_SLOWDOWN, HW_THERMAL_SLOWDOWN, HW_POWER_BRAKE)
• Detección de puerto caído en la red RDMA (con umbral basado en el tiempo de inactividad acumulado, no en el recuento de fluctuaciones)
• Errores XID críticos de los registros del kernel
• Errores no corregibles de PCIe AER
• Gradiente térmico entre el núcleo de la GPU y la HBM
• Estados de error de NVSwitch

Los nodos que muestran fallos en las comprobaciones continuas se aíslan, se vacían y pasan por el mismo proceso de cuarentena que los fallos de las comprobaciones de arranque (bootstrap) activas.

Las comprobaciones activas multinodo periódicas validan el comportamiento de la red entre nodos que ningún nodo individual puede detectar por sí solo. Se ejecutan periódicamente en nodos inactivos entre las cargas de trabajo de los clientes para aislar los problemas de la red entre nodos de la degradación de un solo nodo que la capa de arranque ya detecta. Debido a que se ejecutan en nodos inactivos y se pueden interrumpir cuando las cargas de trabajo de los clientes necesitan los nodos, pueden ser más costosas de lo que permite una comprobación activa en el momento del aprovisionamiento.

Las pruebas en sí incluyen sondas de ancho de banda colectivo de NCCL en grupos de nodos, barriendo tamaños de carga útil desde 8 bytes hasta 2 GiB. Los diferentes tamaños de carga útil son importantes porque NCCL activa diferentes rutas de código. Los mensajes pequeños en el rango de KB se ejecutan a través de protocolos de baja latencia como LL y LL128 y están dominados por la latencia, lo que hace que la latencia p95 sea el criterio de aprobación útil. Los mensajes medianos en el rango de MB cruzan umbrales donde NCCL cambia de algoritmo de árbol a anillo. Los mensajes grandes ejercitan la fragmentación (chunking) y la canalización (pipelining) a medida que se alcanzan los límites de ancho de banda, lo que hace que BusBW (ancho de banda del bus) sea el criterio de aprobación útil. Los problemas de hardware a menudo surgen en solo una de esas rutas de código. Un resultado representativo de las condiciones que comprobamos para el ancho de banda de all-reduce en nuestra comprobación de estado:

AlgBW (ancho de banda del algoritmo) mide el rendimiento tal como lo ve la carga de trabajo. BusBW (ancho de banda del bus) tiene en cuenta el hecho de que una colectiva como all-reduce mueve cada byte a través de la red varias veces, por lo que refleja mejor la utilización real del enlace y el estado del hardware.

Juntas, las tres capas verifican el hardware antes de que comiencen las cargas de trabajo, lo vigilan mientras se ejecutan y validan la red en general en el intervalo. A medida que surgen nuevos modos de fallo, incorporamos nuevas comprobaciones de estado y distribuimos gpu-monitor a toda la flota.

Conclusión

La fiabilidad de las GPU es un sistema acumulativo. Las nuevas generaciones de hardware y los patrones de carga de trabajo siguen revelando modos de fallo que deben integrarse de nuevo en las comprobaciones, y cada uno de ellos hace que el sistema sea más sólido. Esta publicación ha cubierto la base sobre la que se asienta todo lo demás. Las próximas publicaciones de esta serie partirán de aquí para abordar el trabajo que mantiene la fiabilidad del entrenamiento a medida que las ejecuciones se hacen más grandes, las arquitecturas cambian y las cargas de trabajo de RL combinan el entrenamiento y la inferencia en el mismo bucle.

Una infraestructura de GPU fiable a esta escala es lo que hace posible la próxima generación de productos de AI. Si la fiabilidad de las GPU a gran escala es el tipo de problema en el que te gustaría trabajar, ¡estamos contratando!

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original