Wie wir die DeepL-LLMs der nächsten Generation mit FP8 für Training und Inferenz entwickelt haben

Mit dem Einsatz unseres aktuellen NVIDIA DGX SuperPOD mit 544 NVIDIA H100 Tensor Core‑GPUs hat DeepL nicht nur eine enorme Steigerung der Rechenleistung erzielt. Der H100 bietet auch native Unterstützung für 8‑Bit-Gleitkomma-Datentypen (FP8) durch eine neue Generation von Tensor-Kernen, die es der GPU ermöglichen, Matrixmultiplikationen und andere Tensoroperationen mit FP8‑Genauigkeit durchzuführen. Durch die Berechnung von Matrixmultiplikationen in FP8 können wir den Durchsatz beim Training und Einsatz unserer Large Language Models (LLMs) steigern, da der Großteil der Rechenleistung in modernen LLMs in Form von Matrixmultiplikationen erfolgt.

Die Umstellung der Berechnungen von 16‑Bit- auf 8-Bit-Genauigkeit hatte einen großen Einfluss auf die Entwicklung der nächsten Generation von LLMs bei DeepL. Dadurch können wir viel größere KI‑Sprachmodelle mit weitaus mehr Parametern erstellen, die nach Einschätzung von Sprachexperten eine deutliche Qualitätsverbesserung bieten, jedoch innerhalb des gleichen Latenzfensters für die Produktionsinferenz bleiben. Das bedeutet, dass die Übersetzungen unsere bisherigen Modelle um das 1,4‑Fache für europäische Sprachen und um das 1,7‑Fache für komplexere Sprachkombinationen wie Englisch und Japanisch übertreffen, aber dennoch ebenso schnell Ergebnisse liefern. Dies bedeutet auch, dass unsere Modelle eine größere Anzahl von Anfragen über mehr Funktionen hinweg verarbeiten können, ohne die Benutzerfreundlichkeit zu beeinträchtigen.

Mit anderen Worten: Das FP8‑Training und die FP8‑Inferenz haben eine zentrale Rolle bei der Skalierung der KI‑Sprachtechnologie von DeepL gespielt.

In diesem Beitrag möchten wir Ihnen erläutern, welchen Weg wir zurückgelegt haben, um FP8 für Training und Inferenz anzuwenden, einige der Tools und Techniken vorstellen, die diesem Erfolg zugrunde liegen, und Ihnen einen Eindruck von den Ergebnissen vermitteln, die wir in Bezug auf die Trainings‑ und Inferenzleistung auf dieser Reise erzielt haben. 

Was ist der Unterschied zwischen den Formaten BF16 und FP8?

Der Unterschied zwischen BFloat16 (BF16) und FP8 lässt sich einfach damit erklären, dass Letzteres nur halb so viele Bits zur Darstellung von Werten verwendet. Effektiv nutzt BF16 die 16 verfügbaren Positionen in zwei Bytes mit jeweils 8 Bit. FP8 nutzt nur ein Byte. 

Die Anzahl der verfügbaren Bits bestimmt die Genauigkeit, mit der Sie die Mantissen‑ und Exponentenelemente von Gleitkommazahlen in wissenschaftlicher Notation einsetzen können. BF16 hat 1 Vorzeichenbit, 8 Bits für den Exponenten und 7 Bits für die Mantisse. FP8 hat nur halb so viele Bits zur Verfügung, mit 1 Vorzeichenbit und 7 Bits, die zwischen Exponent und Mantisse aufgeteilt sind. Aus diesem Grund hat es einen kleineren Bereich und eine geringere Genauigkeit als BF16. Es kann einen engeren Bereich und weniger Zahlen innerhalb dieses Bereichs darstellen.

Nehmen wir als Beispiel an, wir wollten das Alter der Erde in Milliarden Jahren (ungefähr 4,543) darstellen. In BF16 können wir dies genau als 0100000010010001 darstellen.  

Wie sieht es mit der Darstellung dieser Zahl in FP8 aus? Tatsächlich stehen zwei FP8‑Formate zur Auswahl: E4M3 und E5M2. Die Buchstaben und Zahlen stehen hier für die Verteilung der Bits zwischen Exponent (E) und Mantisse (M). Je mehr Bits Sie für den Exponenten verwenden, desto größer ist der Zahlenbereich, den Sie beschreiben können, und je mehr Bits Sie für die Mantisse verwenden, desto mehr Zahlen können Sie innerhalb dieses Bereichs beschreiben. 

Unabhängig davon, für welches FP8‑Format Sie sich entscheiden, ist es nicht möglich, 4,543 präzise darzustellen. Wenn Sie sich für E4M3 mit seiner relativ höheren Präzision entscheiden, kommen Sie dem Wert am nächsten (4,5). Bei E5M2 ist 5 der nächstgelegene Wert.

Als Gegengewicht zu diesem Mangel an Bereich und Präzision ermöglicht FP8 eine schnellere Berechnung und benötigt im Vergleich zu BF16 deutlich weniger Speicherplatz. Dies ist für die Inferenz von großem Wert und kann mit dem richtigen Ansatz auch für die Beschleunigung des Trainings von großem Wert sein. Es kommt also auf die Frage an, wie groß der Bereich und die Präzision sein müssen, die für das LLM‑Training tatsächlich erforderlich sind. Müssen Sie das Alter der Erde genau darstellen? Oder reicht eine Genauigkeit von 43 Millionen Jahren aus? Wenn Sie sich für das Universum als Ganzes interessieren, würden Sie sich wahrscheinlich mit dieser zweiten Genauigkeitsstufe zufrieden geben. Der Rundungsfehler macht schließlich nur etwa 0,3 % des Alters des Universums aus.

Die Entwicklung von DeepL beweist, dass FP8 die Anforderungen für ein hochwertiges LLM‑Training erfüllt. Dies hat neue Möglichkeiten für das Training unserer Modelle und deren Einsatz in der Praxis eröffnet.

Vortraining für DeepL‑LLMs

Unsere Reise mit FP8‑Training und ‑Inferenz beginnt mit dem Vortraining unserer LLMs. Nach dem Vortraining optimieren wir unsere Modelle für bestimmte Aufgaben, destillieren große Modelle zu kleineren Modellen, führen Reinforcement Learning durch und setzen eine Reihe von Parallelisierungsstrategien ein, damit wir die große Anzahl unserer GPUs nutzen können.

Anwendung des FP8‑Formats für gemischtes Präzisionstraining

Wir haben unseren bestehenden Trainingscode von BF16 auf FP8 umgestellt, indem wir die NVIDIA Transformer Engine verwendet haben: eine von NVIDIA bereitgestellte Trainingsbibliothek, die Transformer-Modelle beschleunigt und FP8 unterstützt. Die Transformer Engine bietet wichtige Komponenten, die das gemischte Präzisionstraining erleichtern, indem sie die Konvertierung zwischen den Formaten FP8 und BF16 nahtlos verwaltet und Skalierungsfaktoren verarbeitet.

Wir verwenden die von NVIDIA empfohlene Standardeinstellung der Transformer Engine, wobei wir E4M3 im Vorwärtsdurchlauf für das Training und E5M2 im Rückwärtsdurchlauf verwenden. Das bedeutet, dass wir das Format mit höherer Präzision für die Vorhersage der Wahrscheinlichkeitsverteilung des nächsten Tokens verwenden und dann das Format mit geringerer Präzision, aber größerem Bereich, um die für die Aktualisierung des Modells erforderlichen Gradienten zu berechnen, wenn die Präzision weniger wichtig ist. Wir verwenden jedes der beiden Formate für die Aufgabe, für die es am besten geeignet ist.

In der folgenden Grafik haben wir alle Zahlen dargestellt, die mit dem E4M3‑Format dargestellt werden können. Wie Sie sehen können, konzentrieren sich diese Zahlen um den Wert Null, mit einem Maximalwert von weniger als 500. Tatsächlich lässt sich die Anzahl der darstellbaren Werte für FP8‑Formate in einer sehr kurzen Tabelle darstellen. Der Trick bei der Verwendung dieses Formats für das Training besteht darin, sich der Verteilung dieser Werte bewusst zu sein und innerhalb dieser zu arbeiten. 

Dazu müssen zusätzliche Skalierungsfaktoren neben den FP8‑Gewichtstensoren gespeichert werden, um den begrenzten Bereich zu überwinden und Über‑ und Unterläufe zu verhindern. Bei Berechnungen mit Ihren Tensoren mit geringer Genauigkeit müssen Sie auch die Skalierungsfaktoren berücksichtigen. Wenn Sie beispielsweise zwei Tensoren multiplizieren, verwenden Sie die Formel: (A_fp8 * A_scale) x (B_fp8 * B_scale), wobei A_fp8 und B_fp8 8‑Bit-Tensoren und die Skalen 32‑Bit-Skalarwerte sind. Für diese Vorgänge gibt es spezielle Hardwareunterstützung.

FP8 vs. BF16 für die Trainingsleistung

Wenn wir über Trainingsleistung sprechen, beziehen wir uns darauf, wie schnell ein Modell mit der ihm zur Verfügung stehenden Rechenleistung trainiert werden kann. Um die Trainingsleistung zwischen FP8 und BF16 zu vergleichen, betrachten wir die Model FLOPS Utilization (MFU), also die Anzahl der Fließkommaoperationen pro Sekunde (FLOPS), die das Modell ausführt, als Prozentsatz der FLOPS, die mit der verfügbaren Hardware technisch möglich sind.

Für unseren Vergleich haben wir die mit dem BF16‑Format möglichen FLOPS als gemeinsamen Nenner verwendet, obwohl technisch gesehen mehr FLOPS möglich sind, wenn man zu FP8 wechselt. Auf diese Weise konnten wir den inkrementellen Gewinn an verfügbarer Rechenleistung messen, der durch den Wechsel von BF16 zu FP8 möglich wird.

Wie in der folgenden Grafik dargestellt, stieg die Effizienz, mit der unser Modelltraining die verfügbare Rechenleistung nutzt, von 44,6 % MFU auf 67 % MFU mit FP8, wodurch unser Modelltraining effektiv um 50 % beschleunigt wurde.

Das ist an sich schon eine beeindruckende Leistungssteigerung. Um dies zu erreichen, haben wir gemeinsam mit NVIDIA daran gearbeitet, die Nutzung der Transformer Engine-Funktionen zu optimieren. Basierend auf einem anderen Trainingsaufbau ist es uns gelungen, die Trainingsleistung über einen Zeitraum von 15 Monaten schrittweise um 25 % zu steigern, wodurch wir nun eine MFU von 80 % erreichen.

FP8 vs. BF16 für die LLM-Trainingsqualität

Die FP8‑Gewinne in Bezug auf die Trainingsleistung sind daher in der Tat sehr beeindruckend. Was uns bei DeepL jedoch wirklich interessiert, ist die Trainingsqualität. Wie würde diese im Vergleich zur Trainingsqualität mit BF16-Präzision aussehen?

Um die Qualität von FP8 zu überprüfen, haben wir das Training eines unserer Modelle in beiden Formaten getestet. So konnten wir die Trainingsverluste und die nachgelagerte Qualität vergleichen. 

Wir haben ein 1,5‑Milliarden-Modell mit drei Billionen Tokens trainiert und dann die Qualität des FP8-Trainings mit der von BF16 verglichen. Das wichtigste Maß war dabei der Trainingsverlust, der sich auf die Fähigkeit des Modells bezieht, das nächste Token vorherzusagen.

Wie Sie der folgenden Grafik entnehmen können, konnten wir eine geringe Überlegenheit von BF16 gegenüber FP8 feststellen, was sich daran zeigt, dass unsere FP8-Linie knapp über der von BF16 liegt. Dieser Unterschied wird jedoch durch die viel größeren Schwankungen des Trainingsverlusts von einem Schritt zum nächsten überdeckt, die bei beiden Formaten auftreten, und in beiden Fällen sehen wir die gleiche spürbare Verbesserung bei der Minimierung des Trainingsverlusts im Laufe der Zeit.

FP8 vs. BF16 – Qualität des Downstream-Trainings

Anschließend haben wir die Qualität des Trainings in FP8 im Vergleich zu BF16 in einer praktischen Downstream-Anwendung getestet.

In diesem Fall haben wir geprüft, wie sich das Modell bei der Arbeit mit Englisch und Deutsch verhält. Wir haben die Validierungsperplexität verglichen, die die Unsicherheit quantifiziert, die ein Modell bei der Vorhersage des nächsten Tokens in einer Sequenz erlebt. Auch hier ist zu erwarten, dass die Perplexität im Laufe der Zeit abnimmt. In diesem praktischen Szenario konnten wir tatsächlich keine Qualitätsminderung beim FP8-Training im Vergleich zu BF16 feststellen.

Das Endergebnis der Umstellung von BF16 auf FP8 ist, dass wir unsere Modelle schneller und mit geringerem Speicherbedarf trainieren können und dabei die gleiche Trainingsqualität mit nur minimaler Verschlechterung in Bezug auf Trainingsverlust und vergleichbarer Validierungsperplexität erzielen. Dies bedeutet, dass DeepL durch die maximale Ausnutzung der Rechenleistung komplexere Modelle erstellen und komplexere Aufgaben bewältigen kann. Dadurch erweitert sich der Anwendungsbereich des LLM-Trainings erheblich.

Vom FP8-Training zur Inferenz

Der nächste Schritt besteht darin, die LLMs für die Produktionsinferenz vorzubereiten. Hier übernimmt NVIDIA TensorRT-LLM, die Lösung von NVIDIA für skalierbare LLM‑Inferenz, die FP8 unterstützt, die Hauptlast der Unterstützung. Es übernimmt die Gewichte Ihres Modells aus dem Training und erstellt eine Engine, um die Operationen des Modells so rechenintensiv wie möglich zu optimieren, wobei Optimierungstechniken wie Kernel-Fusion, optimierter C++/CUDA-Code, KV‑Caching und kontinuierliches In‑Flight-Batching zum Einsatz kommen.

Vorteile von FP8 für die Inferenz

Die Inferenz für LLMs beinhaltet immer das Zusammenspiel von Durchsatz (die Anzahl der Tokens, die in einem bestimmten Zeitraum verarbeitet werden können) und Latenz. Es versteht sich von selbst, dass die bestmögliche Kundenerfahrung die Kontrolle der Latenz erfordert. Der Durchsatz ist für DeepL jedoch ebenfalls von großer Bedeutung, da er die Anzahl der Anfragen definiert, die wir zu einem bestimmten Zeitpunkt bearbeiten können, und damit den Umfang dessen, was unser Modell in der Praxis leisten kann.

Es ist unvermeidlich, dass mit steigendem Durchsatz auch die Latenz tendenziell zunimmt. Das Batching mehrerer Anfragen ermöglicht einen höheren Durchsatz, jedoch auf Kosten einer erhöhten Latenz für jede einzelne Anfrage. Dies kann sich potenziell auf das Kundenerlebnis auswirken. Die Inferenzleistung von FP8 im Vergleich zu BF16 verändert dieses Gleichgewicht jedoch erheblich zu unseren Gunsten.

Wie die folgende Grafik zeigt, kann FP8 bei den meisten Batch-Größen den doppelten Durchsatz bei gleichem Latenzgrad wie BF16 verarbeiten. Wenn wir ein bestimmtes Latenzbudget festlegen, das dem optimalen Erlebnis für unsere Nutzer entspricht, können wir dies in der Praxis sehen. Tatsächlich hat FP8 die effektive Kapazität unserer LLMs in Bezug auf den Durchsatz effektiv verdoppelt. 

Mit anderen Worten: Der Wechsel von BF16 zu FP8 hat es uns nicht nur ermöglicht, leistungsfähigere und ausgefeiltere LLMs für DeepL zu entwickeln. Er hat auch dafür gesorgt, dass wir diese LLMs effektiv einsetzen können, um ein optimales Kundenerlebnis zu bieten und die Wirkung unserer KI‑Sprachtechnologie in der Praxis zu skalieren. Wir können größere Modelle schneller trainieren, die dann innerhalb derselben Latenzparameter arbeiten und gleichzeitig doppelt so viele Anfragen bearbeiten können.

Ausblick Wir haben kürzlich den neuen NVIDIA DGX SuperPOD mit NVIDIA DGX GB200-Systemen eingeführt, der eine weitere nahezu exponentielle Steigerung der Rechenleistung ermöglicht. Für uns ist besonders interessant, dass diese Maschine eine neue Generation von Tensor-Kernen einführt, die FP4-Tensoroperationen wie Matrixmultiplikationen nativ unterstützen können. Damit beginnt unsere Reise von Neuem. Es war spannend zu sehen, was wir mit einem einzigen Byte in Bezug auf Training und Inferenz erreichen können. Schauen Sie hier bald mal wieder herein, um zu erfahren, was mit einem halben Byte möglich ist.

Über die Autoren

Markus Schnös, Staff Research HPC Engineer

Markus Schnös ist Staff Research HPC Engineer bei DeepL, wo er sich auf die Skalierung von LLM-Training und ‑Inferenz konzentriert. Er hat ein besonderes Interesse an verteiltem Training und Fließkomma-Berechnungen mit geringer Genauigkeit.

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

https://github.com/Marks101

Fabian Joswig, Staff Research HPC Engineer

Fabian Joswig ist Staff Research Engineer bei DeepL und verfügt über einen Hintergrund in maschinellem Lernen, Hochleistungsrechnen und theoretischer Teilchenphysik. Er konzentriert sich auf die Skalierung von KI‑Modellen und Infrastruktur für den weltweit präzisesten Übersetzer.

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

https://github.com/fjosw