Cómo creamos los LLM de última generación de DeepL con FP8 para entrenar y la inferencia

Cuando DeepL implementó nuestro actual NVIDIA DGX SuperPOD con 544 GPU NVIDIA H100 Tensor Core, no solo obtuvimos un gran aumento en la potencia de cálculo. El H100 también introduce compatibilidad nativa con tipos de datos de coma flotante de 8 bits (FP8), a través de una nueva generación de núcleos Tensor, que permiten a la GPU realizar multiplicaciones matriciales y otras operaciones tensoriales con precisión FP8. Al calcular las multiplicaciones matriciales en FP8, podemos aumentar el rendimiento al entrenar e implementar nuestros modelos de lenguaje grandes (LLM), ya que la mayor parte del cálculo que implican los LLM modernos adopta la forma de multiplicaciones matriciales.

El cambio de los cálculos de 16 bits a 8 bits de precisión tuvo un gran impacto en el desarrollo de los LLM de última generación de DeepL. Nos permite crear modelos de IA lingüística mucho más grandes, con muchos más parámetros que ofrecen mejoras significativas en la calidad según la valoración de expertos lingüísticos, pero dentro de la misma ventana de latencia para la inferencia de producción. Esto significa que las traducciones superan a nuestros modelos anteriores en 1,4 veces para los idiomas europeos y en 1,7 veces para combinaciones de idiomas más complejas, como el inglés y el japonés, pero ofrecen resultados con la misma rapidez. Esto también significa que nuestros modelos pueden gestionar un mayor número de solicitudes en más funciones y funciones, sin comprometer la experiencia de usuario.

En otras palabras, entrenar y realizar la inferencia de FP8 han desempeñado un papel fundamental en la ampliación de la IA lingüística de DeepL.

En esta publicación, queremos explicar el camino que hemos recorrido para aplicar FP8 al entrenar y la inferencia, compartir algunas de las herramientas y técnicas que sustentan este éxito y daros una idea de los resultados que generamos en términos de rendimiento de entrenamiento e inferencia a lo largo del proceso. 

¿Cuál es la diferencia entre los formatos BF16 y FP8?

La simple explicación de la diferencia entre BFloat16 (BF16) y FP8 es que este último utiliza la mitad de bits para expresar valores. Efectivamente, BF16 utiliza las 16 posiciones disponibles en dos bytes de 8 bits cada uno. FP8 utiliza solo un byte. 

El número de bits disponibles determina la precisión con la que puedes implementar los elementos de mantisa y exponente de los números de coma flotante en notación científica. BF16 tiene 1 bit de signo, 8 bits para el exponente y 7 bits para la mantisa. FP8 tiene la mitad de bits con los que jugar, con 1 bit de signo y 7 bits divididos entre el exponente y la mantisa. Por este motivo, tiene un rango más reducido y una precisión menor que el BF16. Puede representar un rango más estrecho y menos números dentro de ese rango.

Por ejemplo, supongamos que queremos representar la edad de la Tierra en miles de millones de años (aproximadamente 4,543). En BF16, podemos representar esto precisamente como 0100000010010001.  

¿Qué tal si representamos ese número en FP8? En realidad, hay dos formatos FP8 entre los que elegir: E4M3 y E5M2. Las letras y los números aquí representan la forma en que se distribuyen los bits entre el exponente (E) y la mantisa (M). Cuantos más bits dediques al exponente, mayor será el rango de números que podrás describir, y cuantos más bits dediques a la mantisa, más números podrás describir dentro de ese rango. 

Sea cual sea el formato FP8 que elijas, en realidad no es posible representar 4,543 con precisión. Si eliges E4M3, con su precisión relativamente mayor, puedes obtener el resultado más cercano (4,5). En E5M2, lo más cerca que puedes llegar es 5.

Por otro lado, a pesar de esta falta de rango y precisión, FP8 permite un cálculo más rápido y requiere una memoria significativamente menor en comparación con BF16. Esto es muy valioso para la inferencia y, con el enfoque adecuado, también puede ser muy valioso para acelerar el proceso de entrenar. Todo se reduce a la cuestión de cuán grande debe ser realmente el alcance y la precisión de entrenar a LLM. ¿Necesitas representar con precisión la edad de la Tierra? ¿O acaso acercarse a 43 millones de años es suficiente? Si te interesa el universo en su conjunto, probablemente te bastará con ese segundo nivel de precisión. Después de todo, el error de redondeo solo representa alrededor del 0,3 % de la edad del universo.

La trayectoria de DeepL demuestra que FP8 puede ofrecer lo necesario para un entrenamiento LLM de alta calidad, lo que ha abierto nuevas posibilidades en cuanto a lo que entrenamos a nuestros modelos a hacer y cómo los implementamos en la práctica.

Preentrenamiento para los modelos de lenguaje grande (LLM) de DeepL

El viaje que emprendemos con el entrenamiento y la inferencia FP8 comienza con el preentrenamiento de nuestros LLM. Después del preentrenamiento, entrenamos nuestros modelos para determinadas tareas, destilamos los modelos grandes en modelos más pequeños, realizamos aprendizaje por refuerzo y implementamos un conjunto de estrategias de paralelización para poder aprovechar la gran cantidad de GPU de las que disponemos.

Aplicación del formato FP8 para entrenar con precisión mixta

Hemos migrado nuestro código de entrenamiento existente de BF16 a FP8 utilizando NVIDIA Transformer Engine: una biblioteca de entrenamiento proporcionada por NVIDIA que acelera los modelos de transformadores y admite FP8. Transformer Engine proporciona componentes esenciales que facilitan el entrenar de precisión mixta, con un gestor que gestiona a la perfección la conversión entre los formatos FP8 y BF16 y maneja los factores de escala.

Utilizamos la configuración predeterminada del motor Transformer, tal y como recomienda NVIDIA, utilizando E4M3 en la pasada hacia adelante para entrenar, y, a continuación, utilizando E5M2 en la pasada hacia atrás. Esto significa, en la práctica, que utilizamos el formato con mayor precisión para predecir la distribución de probabilidad del siguiente token y, a continuación, el formato con menor precisión, pero con un rango mayor, para calcular los gradientes necesarios para actualizar el modelo, cuando la precisión es menos importante. Utilizamos cada uno de los dos formatos para la tarea a la que mejor se adapta.

En la tabla siguiente, hemos representado todos los números que se pueden representar con el formato E4M3. Como verás, esos números se concentran alrededor de cero, con un valor máximo inferior a 500. De hecho, el número de valores representables para los formatos FP8 se puede imprimir en una tabla muy breve. El truco para que este formato funcione para entrenar es ser consciente de la distribución de esos valores y trabajar dentro de ella. 

Esto implica almacenar factores de escala adicionales junto con los tensores de peso FP8 para superar el rango limitado y evitar el desbordamiento y el desbordamiento por debajo del rango. Al realizar cálculos con tus tensores de baja precisión, también debes tener en cuenta los factores de escala. Por ejemplo, al multiplicar dos tensores, se utiliza la fórmula: (A_fp8 * A_scale) x (B_fp8 * B_scale), donde A_fp8 y B_fp8 son tensores de 8 bits y las escalas son escalares de 32 bits. El hardware admite específicamente estas operaciones.

FP8 frente a BF16 para el rendimiento al entrenar

Cuando hablamos del rendimiento del entrenamiento, nos referimos a la rapidez con la que se puede entrenar un modelo dada la potencia de cálculo de la que dispone. Para comparar el rendimiento al entrenar entre FP8 y BF16, analizamos la utilización de FLOPS del modelo (MFU), que es el número de operaciones de coma flotante por segundo (FLOPS) que realiza el modelo, como porcentaje de los FLOPS que son técnicamente posibles con el hardware disponible.

Para nuestra comparación, utilizamos el número de FLOPS posibles con el formato BF16 como denominador común, a pesar de que, técnicamente hablando, se pueden obtener más FLOPS al pasar a FP8. Esto nos permitió evaluar la ganancia incremental en el uso de la potencia de procesamiento disponible que se consigue al pasar de BF16 a FP8.

Como se muestra en el gráfico siguiente, la eficiencia con la que nuestro modelo se entrena utilizando la potencia de cálculo disponible aumentó del 44,6 % MFU al 67 % MFU con FP8, lo que aceleró eficazmente el proceso de entrenar nuestro modelo en un 50 %.

Es una mejora impresionante en cuanto al rendimiento, en sí misma. Para lograrlo, colaboramos con NVIDIA con el fin de optimizar el uso de las funciones de Transformer Engine. Basándonos en otra configuración de entrenar, logramos aumentar gradualmente el rendimiento del entrenar en un 25 % a lo largo de 15 meses, lo que nos llevó a alcanzar un 80 % de MFU.

FP8 frente a BF16 para la calidad de entrenar LLM

Por lo tanto, las mejoras del FP8 en términos de rendimiento al entrenar son realmente impresionantes. Sin embargo, el resultado que realmente nos importa en DeepL es la calidad de entrenar. ¿Cómo se compararía esto con la calidad de entrenar con precisión BF16?

Para comprobar la calidad que ofrece FP8, probamos a entrenar uno de nuestros modelos en ambos formatos. Esto nos permitió comparar las pérdidas de entrenamiento y la calidad posterior. 

Entrenamos un modelo de 1.500 millones con tres billones de tokens y luego comparamos la calidad del entrenamiento FP8 con la del BF16. La medida clave aquí fue la pérdida de entrenamiento, que se refiere a la capacidad del modelo para predecir el siguiente token.

Como se puede observar en el gráfico siguiente, se aprecia una ligera superioridad de BF16 sobre FP8, ya que la línea de FP8 se sitúa justo por encima de la de BF16. Sin embargo, esta diferencia queda eclipsada por las fluctuaciones mucho más amplias en la pérdida de entrenamiento de un paso a otro que se producen en ambos formatos, y en ambos casos observamos que la minimización de la pérdida de entrenamiento mejora de forma tangible a lo largo del tiempo.

Calidad para entrenar descendente FP8 frente a BF16

A continuación, pasamos a probar la calidad que ofrecían el entrenamiento en FP8 y BF16 en una aplicación práctica posterior.

En este caso, probamos cómo funcionaba el modelo al trabajar con inglés y alemán. Comparamos la perplejidad de validación, que cuantifica la incertidumbre que experimenta un modelo al predecir el siguiente token en una secuencia. Una vez más, se espera que la perplejidad disminuya con el tiempo. En este escenario práctico, no observamos ninguna pérdida de calidad al entrenar con FP8 en comparación con BF16.

El resultado neto del cambio de BF16 a FP8 es que podemos entrenar nuestros modelos más rápidamente, con una menor demanda de memoria, y lograr la misma calidad de entrenamiento, con una degradación mínima en términos de pérdida de entrenamiento y una perplejidad de validación comparable. Esto significa, en efecto, que DeepL es capaz de crear modelos más sofisticados y abordar tareas más complejas, maximizando la utilización de la potencia de procesamiento. Amplía significativamente el alcance de lo que podemos hacer al entrenar LLM.

Desde entrenar en FP8 hasta la inferencia

La siguiente etapa del proceso consiste en preparar los LLM para la inferencia de producción. Aquí, el trabajo pesado del soporte lo realiza NVIDIA TensorRT-LLM, la solución de NVIDIA para la inferencia LLM escalable, que admite FP8. Toma los pesos de tu modelo entrenado y crea un motor para optimizar las operaciones del modelo con el fin de que sea lo más eficiente posible desde el punto de vista computacional, utilizando técnicas de optimización como la fusión de núcleos, el código C++/CUDA optimizado, el almacenamiento en caché KV y el procesamiento por lotes continuo en vuelo. 

Las ventajas de FP8 para la inferencia

La inferencia para los LLM siempre implica la interacción entre el rendimiento (el número de tokens que se pueden procesar en un periodo de tiempo) y la latencia. No hace falta decir que ofrecer la mejor experiencia posible al cliente implica controlar la latencia. Sin embargo, el rendimiento también es muy importante para DeepL, ya que define el número de solicitudes que podemos gestionar en un momento dado y, por lo tanto, el alcance de lo que nuestro modelo puede hacer en la práctica.

Es inevitable que, a medida que aumenta el rendimiento, la latencia también tienda a aumentar. Agrupar varias solicitudes permite un mayor rendimiento, pero a costa de aumentar la latencia de cada solicitud individual. Esto puede afectar a la experiencia del cliente. Sin embargo, el rendimiento de inferencia de FP8 frente a BF16 cambia significativamente este equilibrio a vuestro favor.

Como muestra el gráfico siguiente, para la mayoría de los tamaños de lote, FP8 puede manejar el doble de rendimiento con el mismo grado de latencia que BF16. Si definimos un presupuesto de latencia específico que equivalga a la experiencia óptima para nuestros usuarios, podremos verlo en la práctica. De hecho, FP8 ha duplicado la capacidad efectiva de tus LLM en términos de rendimiento. 

En otras palabras, el paso de BF16 a FP8 no solo nos ha permitido crear modelos de lenguaje grandes (LLM) más potentes y sofisticados para DeepL. También garantiza que podamos aplicar esos LLM de manera eficaz, para ofrecer una experiencia óptima al cliente y ampliar el impacto de nuestra IA lingüística en el mundo real. Conseguimos entrenar más rápido modelos más grandes, que luego pueden operar dentro de los mismos parámetros de latencia, al tiempo que gestionan el doble de solicitudes.

De cara al futuro Recientemente hemos implementado el nuevo NVIDIA DGX SuperPOD con sistemas NVIDIA DGX GB200, que ofrece otro aumento casi exponencial de la potencia de cálculo. Lo que nos resulta realmente interesante es que esta máquina introducirá una nueva generación de núcleos Tensor que pueden admitir de forma nativa operaciones tensoriales FP4, como multiplicaciones matriciales. Ahí es cuando tu viaje comienza de nuevo. Ha sido emocionante ver lo que se puede hacer con un solo byte en lo que respecta al entrenamiento y la inferencia. Estate atento a este espacio para ver lo que se puede hacer con medio byte.

Acerca de los autores

Markus Schnös, Staff Research HPC Engineer

Markus Schnös es ingeniero de investigación HPC en DeepL, donde se centra en el escalado para entrenar y para la inferencia de LLM. Tienes un interés especial en el entrenamiento distribuido y el cálculo de coma flotante de baja precisión.

www.linkedin.com/in/markus-schnoes-349300185

https://github.com/Marks101

Fabian Joswig, ingeniero investigador de HPC

Fabian Joswig es ingeniero investigador en DeepL, con experiencia en aprendizaje automático, computación de alto rendimiento y física teórica de partículas. Se centra en ampliar los modelos e infraestructura de IA para el traductor más preciso del mundo.

https://www.linkedin.com/in/fabianjoswig/

https://github.com/fjosw