Hoe wij de volgende generatie LLM's van DeepL hebben ontwikkeld met FP8 voor training en inferentie

Toen DeepL onze huidige NVIDIA DGX SuperPOD met 544 NVIDIA H100 Tensor Core GPU's uitrolde, kregen we niet alleen een aanzienlijke toename in rekenkracht. De H100 introduceert ook native ondersteuning voor 8-bits floating point (FP8) datatypes, via een nieuwe generatie Tensor Cores, waarmee de GPU matrixvermenigvuldigingen en andere tensorbewerkingen met FP8-precisie kan uitvoeren. Door matrixvermenigvuldigingen in FP8 te berekenen, kunnen we de doorvoer verhogen bij het trainen en uitrollen van onze large language models (LLM's), aangezien het grootste deel van de berekeningen in moderne LLM's bestaat uit matrixvermenigvuldigingen.

Het overzetten van berekeningen van 16-bits naar 8-bits precisie had een aanzienlijke impact op de ontwikkeling van DeepL's volgende generatie LLM's. Hierdoor kunnen we veel grotere Language AI-modellen bouwen, met aanzienlijk meer parameters die volgens taalexperts een aanzienlijke verbetering in kwaliteit opleveren, maar binnen hetzelfde latentievenster voor productie-inferentie. Dit betekent dat de vertalingen 1,4 keer beter presteren dan onze vorige modellen voor Europese talen en 1,7 keer beter voor complexere talencombinaties zoals Engels en Japans, maar dat de resultaten even snel worden geleverd. Dit betekent ook dat onze modellen een groter aantal verzoeken kunnen verwerken voor meer functies en mogelijkheden, zonder dat dit ten koste gaat van de gebruikerservaring.

Met andere woorden, FP8-training en -inferentie hebben een centrale rol gespeeld bij het opschalen van DeepL's Language AI.

In dit bericht willen we de weg die we hebben afgelegd om FP8 toe te passen voor training en inferentie toelichten, enkele van de tools en technieken delen die aan dit succes ten grondslag liggen, en u een idee geven van de resultaten die we onderweg genereren in termen van trainings- en inferentieprestaties. 

Wat is het verschil tussen de formaten BF16 en FP8?

De eenvoudige uitleg van het verschil tussen BFloat16 (BF16) en FP8 is dat de laatste de helft minder bits gebruikt om waarden weer te geven. In feite maakt BF16 gebruik van de 16 beschikbare posities in twee bytes van elk 8 bits. FP8 gebruikt slechts één byte. 

Het aantal bits dat beschikbaar is, bepaalt de nauwkeurigheid waarmee de mantisse- en exponentelementen van drijvende-kommagetallen in wetenschappelijke notatie kunnen worden uitgerold. BF16 heeft 1 tekenbit, 8 bits voor de exponent en 7 bits voor de mantisse. FP8 heeft de helft minder bits om mee te werken, met 1 tekenbit en 7 bits verdeeld over de exponent en mantisse. Hierdoor heeft het een kleiner bereik en een lagere nauwkeurigheid dan BF16. Het kan een beperkter bereik en minder aantallen binnen dat bereik vertegenwoordigen.

Laten we als voorbeeld nemen dat we de leeftijd van de aarde in miljarden jaren willen weergeven (ongeveer 4,543). In BF16 kunnen we dit precies weergeven als 0100000010010001.  

Zou het mogelijk zijn om dat getal in FP8 weer te geven? Er zijn twee FP8-formaten waaruit u kunt kiezen: E4M3 en E5M2. De letters en cijfers hier geven aan hoe de bits zijn verdeeld tussen de exponent (E) en de mantisse (M). Hoe meer bits u aan de exponent toewijst, hoe groter het bereik van getallen dat u kunt beschrijven, en hoe meer bits u aan de mantisse toewijst, hoe meer getallen u binnen dat bereik kunt beschrijven. 

Welk FP8-formaat u ook kiest, het is niet mogelijk om 4,543 nauwkeurig weer te geven. Indien u kiest voor E4M3 met zijn relatief grotere nauwkeurigheid, kunt u het dichtstbijzijnde resultaat verkrijgen (4,5). In E5M2 is 5 het dichtstbijzijnde dat u kunt bereiken.

Aan de andere kant van dit gebrek aan bereik en precisie maakt FP8 snellere berekeningen mogelijk en vereist het aanzienlijk minder geheugen in vergelijking met BF16. Dit is van grote waarde voor inferentie en met de juiste aanpak kan het ook van grote waarde zijn voor het versnellen van trainen. Het komt neer op de vraag hoeveel bereik en precisie het daadwerkelijk vereist om een LLM te trainen. Moet u de leeftijd van de aarde nauwkeurig weergeven? Of is een schatting van 43 miljoen jaar voldoende nauwkeurig? Indien u geïnteresseerd bent in het universum als geheel, zult u waarschijnlijk tevreden zijn met dat tweede nauwkeurigheidsniveau. De afrondingsfout vertegenwoordigt immers slechts ongeveer 0,3% van de leeftijd van het universum.

Het traject van DeepL bewijst dat FP8 kan bieden wat nodig is voor hoogwaardige LLM-training. Dit heeft nieuwe mogelijkheden gecreëerd voor wat we onze modellen trainen en hoe we ze in de praktijk uitrollen.

Voorbereiding voor DeepL LLMs

De reis die we met FP8-training en -inferentie maken, begint met het trainen van onze LLM's. Na de pre-training verfijnen wij onze modellen voor bepaalde taken, distilleren wij grote modellen tot kleinere modellen, passen wij reinforcement learning toe en rollen wij een reeks parallellisatiestrategieën uit, zodat wij gebruik kunnen maken van het grote aantal GPU's waarover wij beschikken.

Het FP8-formaat toepassen voor trainen met gemengde precisie

We hebben onze bestaande trainingscode van BF16 naar FP8 overgezet met behulp van NVIDIA Transformer Engine: een trainingsbibliotheek van NVIDIA die transformatiemodellen versnelt en FP8 ondersteunt. Transformer Engine biedt essentiële componenten die het trainen met gemengde precisie mogelijk maken, waarbij de conversie tussen FP8- en BF16-formaten naadloos wordt beheerd en schaalfactoren worden verwerkt.

Wij maken gebruik van de standaardinstellingen van de Transformer Engine, zoals aanbevolen door NVIDIA, waarbij E4M3 wordt toegepast in de voorwaartse pass voor training en vervolgens E5M2 in de achterwaartse pass. Dit betekent in feite dat we het formaat met een hogere precisie gebruiken voor het voorspellen van de waarschijnlijkheidsverdeling van het volgende token, en vervolgens het formaat met een lagere precisie, maar een groter bereik, om de gradiënten te berekenen die nodig zijn voor het bijwerken van het model, wanneer precisie minder belangrijk is. Wij gebruiken elk van de twee formaten voor de taak waarvoor het het meest geschikt is.

In de onderstaande grafiek hebben we alle getallen weergegeven die met het E4M3-formaat kunnen worden weergegeven. Zoals u kunt zien, zijn deze getallen geconcentreerd rond nul, met een maximale waarde van minder dan 500. Het aantal weer te geven waarden voor FP8-formaten kan in feite in een zeer korte tabel worden weergegeven. De sleutel tot het succesvol toepassen van dit format bij trainen is het bewustzijn van de verdeling van deze waarden en het werken binnen deze verdeling. 

Hierbij worden aanvullende schaalfactoren opgeslagen naast de FP8-gewichtstensoren om het beperkte bereik te overwinnen en overflow en underflow te voorkomen. Bij het uitvoeren van berekeningen met uw tensoren met lage precisie dient u ook rekening te houden met de schaalfactoren. Bijvoorbeeld, bij het vermenigvuldigen van twee tensoren gebruikt u de formule: (A_fp8 * A_scale) x (B_fp8 * B_scale), waarbij A_fp8 en B_fp8 8-bits tensoren zijn en de schalen 32-bits scalairen zijn. Er is specifieke hardware die deze processen ondersteunt.

FP8 versus BF16 voor trainingsprestaties

Wanneer we het hebben over trainingsprestaties, bedoelen we hoe snel een model kan worden getraind met de rekenkracht die ervoor beschikbaar is. Om de trainingsprestaties van FP8 en BF16 te vergelijken, kijken we naar het Model FLOPS-gebruik (MFU), dat wil zeggen het aantal floating-point-processen per seconde (FLOPS) dat het model uitvoert, als percentage van de FLOPS die technisch mogelijk zijn met de beschikbare hardware.

Voor onze vergelijking hebben we het aantal FLOPS dat mogelijk is met het BF16-formaat als gemeenschappelijke noemer gebruikt, ondanks het feit dat er technisch gezien meer FLOPS mogelijk zijn wanneer men overstapt op FP8. Hierdoor konden wij de incrementele winst in het gebruik van beschikbare verwerkingskracht meten die mogelijk wordt wanneer men overstapt van BF16 naar FP8.

Zoals te zien is in de onderstaande grafiek, is de efficiëntie waarmee onze modeltraining gebruikmaakt van de beschikbare rekenkracht gestegen van 44,6% MFU naar 67% MFU met FP8, waardoor onze modeltraining effectief met 50% is versneld.

Dat is op zich al een indrukwekkende prestatieverbetering. Om dit te bereiken, hebben wij met NVIDIA samengewerkt om ons gebruik van Transformer Engine-functies te optimaliseren. Op basis van een andere trainingsopzet zijn we erin geslaagd om de trainingsprestaties in 15 maanden tijd stapsgewijs met 25% te verbeteren, waardoor we nu op 80% MFU zitten.

FP8 versus BF16 voor de kwaliteit van LLM-training

De verbeteringen van FP8 in termen van trainingsprestaties zijn dan ook zeer indrukwekkend. De output die voor DeepL echter van groot belang is, is de kwaliteit van het trainen. Hoe zou dit zich verhouden tot de trainingskwaliteit met BF16-precisie?

Om de kwaliteit van FP8 te controleren, hebben wij een van onze modellen in beide formaten getraind. Hierdoor konden wij de verliezen van het trainen en de kwaliteit van de downstream vergelijken. 

We hebben een 1,5B-model getraind op drie biljoen tokens en vervolgens de kwaliteit van de FP8-training vergeleken met die van BF16. De belangrijkste maatstaf hier was het verlies bij trainen, dat verwijst naar het vermogen van het model om het volgende token te voorspellen.

Zoals u in de onderstaande grafiek kunt zien, konden we een kleine superioriteit van BF16 ten opzichte van FP8 vaststellen, zoals blijkt uit onze FP8-lijn die net boven die van BF16 ligt. Dit verschil wordt echter tenietgedaan door de veel grotere schommelingen in trainingsverlies van de ene stap naar de andere die bij beide formaten optreden. In beide gevallen zien we dezelfde tastbare verbetering in het minimaliseren van trainingsverlies in de loop van de tijd.

FP8 versus BF16 kwaliteit van downstreamtraining

Vervolgens hebben we de kwaliteit getest die getraind werd in FP8 versus BF16 in een praktische, downstream-applicatie.

In dit geval hebben we onderzocht hoe het model presteerde bij het werken met Engels en Duits. We hebben de validatieperplexiteit vergeleken, die de onzekerheid kwantificeert die een model ervaart bij het voorspellen van het volgende token in een reeks. Nogmaals, de verwachting is dat de verwarring na verloop van tijd zal afnemen. In dit praktische scenario hebben wij geen kwaliteitsverlies geconstateerd bij FP8-training in vergelijking met BF16.

Het netto resultaat van de overstap van BF16 naar FP8 is dat we onze modellen sneller kunnen trainen, met minder geheugengebruik, en dezelfde trainingskwaliteit kunnen bereiken, met slechts een minimale verslechtering in termen van trainingsverlies en vergelijkbare validatieperplexiteit. Dit betekent in feite dat DeepL in staat is om meer geavanceerde modellen te bouwen en complexere taken aan te pakken door de verwerkingskracht optimaal te benutten. Het vergroot de mogelijkheden van LLM-training aanzienlijk.

Van FP8-training tot inferentie

De volgende fase in het traject omvat het voorbereiden van LLM's voor productie-inferentie. Hier wordt het zware werk op het gebied van support uitgevoerd door NVIDIA TensorRT-LLM, de oplossing van NVIDIA voor schaalbare LLM-inferentie, die FP8 ondersteunt. Het neemt de gewichten van uw model uit de training en bouwt een engine om de processen van het model te optimaliseren, zodat het zo rekenkrachtig mogelijk is, met behulp van optimalisatietechnieken zoals kernel fusion, geoptimaliseerde C++/CUDA-code, KV-caching en continue in-flight batching. 

De voordelen van FP8 voor inferentie

Inferentie voor LLMs omvat altijd de interactie tussen doorvoer (het aantal tokens dat binnen een bepaald tijdsbestek kan worden verwerkt) en latentie. Het spreekt voor zich dat het leveren van de best mogelijke klantervaring het beheersen van latentie vereist. De doorvoercapaciteit is echter ook van groot belang voor DeepL, omdat deze bepalend is voor het aantal verzoeken dat we op een bepaald moment kunnen verwerken en daarmee voor de reikwijdte van wat ons model in de praktijk kan doen.

Het is onvermijdelijk dat, naarmate de doorvoer toeneemt, ook de latentie toeneemt. Het bundelen van meerdere verzoeken zorgt voor een hogere doorvoersnelheid, maar dit gaat ten koste van een hogere latentie voor elk individueel verzoek. Dit kan van invloed zijn op de klantervaring. De inferentieprestaties van FP8 ten opzichte van BF16 wijzigen echter deze afweging in ons voordeel aanzienlijk.

Zoals de onderstaande grafiek laat zien, kan FP8 voor de meeste batchgroottes het dubbele van de doorvoer verwerken bij dezelfde mate van latentie als BF16. Indien we een specifiek latentiebudget instellen dat overeenkomt met de optimale ervaring voor onze gebruikers, kunnen we dit in de praktijk waarnemen. In feite heeft FP8 de effectieve capaciteit van onze LLM's in termen van doorvoer effectief verdubbeld. 

Met andere woorden, de overgang van BF16 naar FP8 heeft ons niet alleen in staat gesteld om krachtigere en geavanceerdere LLM's voor DeepL te ontwikkelen. Het zorgt er ook voor dat we deze LLM's effectief kunnen toepassen, om optimale klantervaringen te bieden en de impact van onze Language AI in de praktijk te vergroten. We kunnen grotere modellen sneller trainen, die vervolgens binnen dezelfde latentieparameters kunnen werken en tegelijkertijd het dubbele aantal verzoeken kunnen verwerken.

Volgende stappen Onlangs hebben wij de nieuwe NVIDIA DGX SuperPOD met NVIDIA DGX GB200-systemen uitgerold, wat een bijna exponentiële toename in rekenkracht oplevert. Wat voor ons bijzonder interessant is, is dat deze machine een nieuwe generatie Tensor Cores zal introduceren die native FP4-tensorpprocessen zoals matrixvermenigvuldigingen ondersteunen. Op dat moment begint onze reis opnieuw. Het is fascinerend om te observeren wat we met een enkele byte kunnen bereiken op het gebied van trainen en inferentie. Houd deze ruimte in de gaten om te ontdekken wat er mogelijk is met een halve byte.

Over de auteurs

Markus Schnös, Staff Research HPC Engineer

Markus Schnös is als Staff Research HPC Engineer werkzaam bij DeepL, waar hij zich richt op het opschalen van LLM-training en -inferentie. Hij heeft een bijzondere interesse in gedistribueerd trainen en drijvende-kommaberekeningen met lage precisie.

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

https://github.com/Marks101

Fabian Joswig, Onderzoeksingenieur HPC

Fabian Joswig is stafonderzoeksingenieur bij DeepL en heeft een achtergrond in machine learning, high-performance computing en theoretische deeltjesfysica. Hij richt zich op het opschalen van AI-modellen en infrastructuur voor 's werelds meest nauwkeurige vertaler.

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

https://github.com/fjosw