Los modelos de lenguaje grande (LLM) han ganado una importancia significativa en los últimos años, impulsando la necesidad de una utilización eficiente de la GPU en tareas de aprendizaje automático. Sin embargo, los investigadores se enfrentan a un desafío crítico para evaluar con precisión el rendimiento de la GPU. La métrica de uso común, la utilización de la GPU, a la que se accede a través de nvidia-smi o herramientas de observación integradas, ha demostrado ser un indicador poco confiable de la eficiencia computacional real. Sorprendentemente, se puede lograr una utilización del 100 % de la GPU simplemente leyendo y escribiendo en la memoria sin realizar ningún cálculo. Esta revelación ha provocado una reevaluación de las métricas y metodologías de rendimiento en el campo del aprendizaje automático, lo que ha llevado a los investigadores a buscar formas más precisas de medir y optimizar el rendimiento de la GPU para las tareas de inferencia y entrenamiento de LLM.
Los investigadores han intentado abordar las limitaciones de la utilización de la GPU mediante la introducción de métricas alternativas. Un enfoque ampliamente conocido es la utilización de FLOPS (operaciones de punto flotante por segundo) del modelo, o MFU, introducida en el artículo PaLM de Google. Las MFU miden la relación entre el rendimiento observado y el rendimiento máximo teórico de un sistema que funciona en FLOP pico, lo que proporciona una representación más precisa del rendimiento de la GPU. Esta métrica ofrece información sobre la eficiencia con la que una carga de trabajo utiliza las capacidades computacionales de una GPU. Sin embargo, las MFU tienen un inconveniente en su complejidad de cálculo, ya que dependen de los parámetros y del marco. A pesar de esta limitación, las MFU han revelado discrepancias significativas entre la utilización de la GPU y la eficiencia computacional real. Por ejemplo, se descubrió que algunos entrenamientos LLM que lograban una utilización del 100 % de la GPU tenían solo un 20 % de MFU, muy por debajo del rango típico del 35 al 45 % para la mayoría de los entrenamientos LLM, lo que resalta la necesidad de una comprensión más profunda de las métricas de rendimiento de la GPU.
Investigadores de IA entrenados (una empresa especializada en infraestructura de gestión de clústeres de GPU) abordó el desafío de optimizar la eficiencia de entrenamiento de LLM para una empresa de modelos básicos. Su enfoque implicó implementar una serie de técnicas de ajuste de rendimiento comúnmente recomendadas para PyTorch. Estas optimizaciones incluyeron saturar la GPU ajustando los parámetros del cargador de datos, maximizar el uso del núcleo tensor a través de un entrenamiento de precisión mixto, emplear optimizadores fusionados de apex o deepspeed y utilizar instancias y redes diseñadas específicamente para tareas de entrenamiento. Al aplicar estos métodos, Trainy logró con éxito una utilización del 100 % de la GPU y un consumo de energía significativo, lo que inicialmente indica un rendimiento mejorado. Sin embargo, para obtener una comprensión más completa de la eficiencia computacional real, el equipo fue un paso más allá al calcular la utilización de FLOPS del modelo (MFU) de la carga de trabajo de entrenamiento, reconociendo las limitaciones de confiar únicamente en la utilización de la GPU como una métrica de rendimiento.
La arquitectura de la GPU es clave para comprender las limitaciones de la utilización de la GPU como métrica de rendimiento. Las GPU constan de núcleos y administradores de multiprocesamiento (SM en NVIDIA, CU en AMD). La GPU GH100, por ejemplo, tiene 144 SM, cada uno de los cuales administra varios núcleos CUDA. La definición de NVIDIA de la utilización de la GPU es vaga, mientras que la documentación NVML de Datadog proporciona más claridad. Sin embargo, esta métrica puede ser engañosa, ya que solo indica la actividad de la GPU, no la eficiencia computacional. Cuando se lanza un kernel CUDA, el trabajo se distribuye entre los núcleos por SM, pero el porcentaje de utilización no refleja la intensidad o la eficacia de estos cálculos.
Para investigar más a fondo los cuellos de botella en el rendimiento, los investigadores recurrieron a la creación de perfiles del bucle de entrenamiento del modelo mediante PyTorch Profiler. Este análisis reveló una información fundamental: el núcleo Softmax registraba una alta utilización de la GPU pero una baja eficiencia del SM (Multiprocesador de transmisión). Esta discrepancia generó inquietudes, ya que la implementación ingenua de Softmax es un cuello de botella bien conocido para los modelos de lenguaje grandes. La baja eficiencia del SM indicó posibles ineficiencias en la ejecución del modelo, a pesar de la alta utilización de la GPU. Esta observación se alinea con las limitaciones de confiar únicamente en la utilización de la GPU como métrica de rendimiento. Para abordar estas operaciones limitadas por la memoria, se han desarrollado varias técnicas de fusión del núcleo como FlashAttention. Los resultados de la creación de perfiles enfatizaron la necesidad de un enfoque más matizado para optimizar el entrenamiento LLM, centrándose en mejorar la eficiencia del SM junto con la utilización de la GPU.
La eficiencia de los SM, también conocida como actividad de los SM, es una métrica crucial para las GPU NVIDIA que mide el porcentaje de SM activos en un intervalo de tiempo determinado. Por ejemplo, una GPU NVIDIA H100 contiene 132 SM, cada uno de los cuales administra 128 núcleos, lo que suma un total de 16 896 núcleos. Esta métrica proporciona información sobre la eficacia con la que los núcleos CUDA utilizan los SM disponibles. Un núcleo CUDA que se ejecuta de forma continua durante 10 segundos pero utiliza solo un SM en una H100 mostraría una utilización de la GPU del 100 %, pero una eficiencia de SM de apenas el 0,7 %. Esta discrepancia destaca la importancia de mirar más allá de la utilización de la GPU. Al monitorear la eficiencia de los SM capa por capa, los investigadores pueden identificar posibles oportunidades de optimización y oportunidades de fácil acceso en el entrenamiento LLM, lo que permite mejoras de rendimiento más específicas y una evaluación más precisa de la eficiencia computacional.
Para optimizar el entrenamiento de LLM, los investigadores se centraron en fusionar capas dentro del bloque de transformadores. Este enfoque implica reemplazar las definiciones de capas nativas de PyTorch con núcleos de GPU implementados en CUDA o Triton, combinando múltiples capas en un solo núcleo. Los objetivos de optimización incluyeron Softmax (usando Flash Attention), MLP y operaciones de adición residual de norma de capa de abandono. Estos núcleos fusionados, a menudo disponibles en bibliotecas como Flash Attention, ofrecen un rendimiento mejorado y un uso reducido de la memoria.
Los desafíos de implementación involucraron principalmente la identificación de capas adecuadas para el reemplazo, ya que las optimizaciones automáticas de Torch.Compile eran incompatibles con estrategias distribuidas más nuevas como FSDP. La implementación manual de núcleos fusionados fue necesaria debido a estas limitaciones.
Los esfuerzos de optimización produjeron mejoras significativas: una aceleración de 4 veces en el tiempo de entrenamiento y un aumento en la utilización de FLOPS del modelo (MFU) del 20 % al 38 %. Estas ganancias fueron el resultado de la implementación de núcleos fusionados y el ajuste fino del paralelismo del modelo para aprovechar de manera efectiva la infraestructura Infiniband de 3,2 Tbps disponible.
En este estudio, los investigadores recomiendan realizar un seguimiento de la eficiencia de SM y la utilización de GPU en clústeres de GPU para medir el rendimiento con precisión. Mientras que la utilización de GPU indica si la máquina está inactiva, la eficiencia de SM muestra la eficacia con la que se utiliza la GPU. Calcular las MFU es beneficioso, pero complejo para la monitorización continua. El administrador de GPU del centro de datos (DCGM) de Nvidia realiza un seguimiento de la actividad de SM de forma predeterminada. Otras métricas, como la ocupación de SM, proporcionan información detallada sobre la carga de trabajo de cada SM, pero son más complejas de interpretar. Para obtener una comprensión más profunda, consulte el blog de Pytorch Profiler, la documentación de DCGM y las guías de creación de perfiles de Nsight.
Echa un vistazo a la PapelTodo el crédito por esta investigación corresponde a los investigadores de este proyecto. Además, no olvides seguirnos en Gorjeo y únete a nuestro Canal de Telegram y LinkedIn Gr¡Arriba!. Si te gusta nuestro trabajo, te encantará nuestro hoja informativa..
No olvides unirte a nuestro Subreddit con más de 50 000 millones de usuarios
A continuación se muestra un seminario web muy recomendado por nuestro patrocinador: ‘Desarrollo de aplicaciones de IA de alto rendimiento con NVIDIA NIM y Haystack’
Asjad es consultor en prácticas en Marktechpost. Está cursando la licenciatura en ingeniería mecánica en el Instituto Indio de Tecnología de Kharagpur. Asjad es un entusiasta del aprendizaje automático y del aprendizaje profundo que siempre está investigando las aplicaciones del aprendizaje automático en el ámbito de la atención médica.