Turbocharging Llama 2 70B met NVIDIA H100

Het streven naar prestaties in de antwoordengine van Perplexity drijft ons ertoe de nieuwste technologie te gebruiken die NVIDIA en AWS te bieden hebben. In deze blog delen we graag de resultaten van onze nieuwste experimenten: een vergelijking van Llama 2 70B-inferentie in verschillende hardware- en softwareconfiguraties.

Ons LLM-inferentieplatform, pplx-api, is gebouwd op een geavanceerde stack aangedreven door opensource-bibliotheken. Sinds de publieke bèta van pplx-api in oktober zijn we bezig met het aanpakken van schaalbaarheidsproblemen en het leren hoe we onze configuratie het beste kunnen afstemmen om massale schaal te bereiken. Dit leidde ertoe dat we experimenten uitvoerden met de volgende sturende vragen:

Wat is de ruwe prestatiewinst van het overschakelen van onze GPU's van NVIDIA A100 naar NVIDIA H100, terwijl alle andere instellingen gelijk blijven?

Wat is de efficiëntiewinst van 8-bit floating point (fp8)-kwantisatie, waarvoor de H100 native ondersteuning biedt? Wat zijn de nauwkeurigheidskosten van deze kwantisatie?

Hoe beïnvloeden tensor-parallelisme en batchgrootte de latentie en token-doorvoer?

Welke configuratie resulteert, gelet op het bovenstaande, in de meest schaalbare balans tussen prestaties en kostenefficiëntie?

We hebben het volgende experiment uitgevoerd als een reeks lokale benchmarks om netwerklatentie te vermijden.

Latentie: De totale tijd die de inferentieserver nodig heeft om zijn volledige antwoord te genereren.

Doorvoer: Het aantal output-tokens per seconde, per GPU, dat de inferentieserver kan genereren voor alle gebruikers en verzoeken.

De volgende factoren zouden de kernstatistieken beïnvloeden, dus we hebben deze consistent gehouden tijdens de verschillende testrondes van het experiment.

Prestaties schalen met de grootte van het LLM. Meer parameters vereisen meer berekeningen, wat resulteert in tragere inferentie. Llama 2 13B is bijvoorbeeld sneller dan Llama 2 70B als andere instellingen gelijk zijn. We houden vast aan Llama 2 70B in dit experiment omdat we willen optimaliseren voor het serveren van de meest capabele opensource-modellen.

De hoeveelheid input- en output-tokens in elk voorbeeldverzoek/antwoordpaar kan prestatie-metingen beïnvloeden. Over het algemeen domineert het genereren van output-tokens de totale responstijd. Wanneer data-sampling alleen "ja/nee"-antwoorden uitlokt van het LLM, is het antwoord sneller in vergelijking met voorbeelden waarbij het LLM essays moet schrijven. Onze dataset bestaat uit synthetische verzoeken met 1024 input-tokens die 512 output-tokens uitlokken. Deze verdeling is gekozen om overeen te komen met de waargenomen verdeling van verkeer op onze publieke implementatie van Llama2 70B.

NVIDIA TensorRT-LLM (release v0.5.0) is een opensource-bibliotheek voor het optimaliseren van LLM-inferentie. Het werd eind 2023 uitgebracht, synthetiseert de vele inferentie-optimalisaties van NVIDIA en biedt een flexibele laag voor aanpassing van de belangrijkste parameters van dit experiment: batchgrootte, kwantisatie en tensor-parallelisme.

We hebben geëxperimenteerd met 4 configuratieassen: tensor-parallelisme, GPU-architectuur, kwantisatie en maximale batchgrootte. Deze assen zijn onderling verbonden omdat ze elk een afweging vertegenwoordigen met betrekking tot de kritieke bottleneck-resource: GPU-geheugen.

De negende-generatie Hopper (H100-HBM3-80GB / p5.48xlarge) GPU-architectuur bevat een enorme lijst aan functies ten opzichte van zijn voorganger, Ampere (A100-SXM4-80GB / p4de.24xlarge), waaronder 2x-6x rekenkracht en bijna 2x GPU-geheugenbandbreedte. GPU-geheugenbandbreedte is een kritieke statistiek voor inferentie omdat een primaire latentie-bottleneck van inferentie-matrixvermenigvuldigingen voortkomt uit het laden van gigabytes aan modelgegevens van GPU-geheugen naar rekenregisters. Op basis van deze statistieken veronderstelden we dat een directe vergelijking tussen de NVIDIA H100 en A100 een verbetering van 2x in zowel latentie als doorvoer zou laten zien.

Een ander belangrijk verschil tussen de NVIDIA H100 en A100 is dat de H100-tensorkern native ondersteuning toevoegt voor 8-bit floating point (fp8)-instructies, wat de deur opent voor verdere optimalisaties die hieronder worden beschreven. Daarom gebruiken we specifiek fp8 en fp16 voor de H100.

Om het geheugen per GPU consistent te houden in dit experiment, hielden we vast aan nodes met 8x80GB GPU-geheugen voor zowel onze NVIDIA A100's als H100's. Naast het mogelijk maken van hogere batchgroottes, is GPU-geheugen belangrijk omdat de parameters van het model tijdens het opstarten van de server in het GPU-geheugen worden geladen voor snelle toegang. Als elk van de 70 miljard parameters in ons model bijvoorbeeld een 16-bit floating point-getal is, dan is het model ongeveer 140GB groot, wat niet op een enkele GPU past. Vandaar de noodzaak voor tensor-parallelisme, dat we hieronder uitleggen.

Tensor-parallelisme verwijst naar het aantal GPU-apparaten dat wordt verbruikt om de inferentieserver uit te voeren. Wanneer we een aantal GPU's toewijzen, bundelt TensorRT-LLM hun resources om ons te helpen het minimaal vereiste geheugenbudget te bereiken voor het uitvoeren van Llama2 70B. Onze hypothese is dat een lager tensor-parallelisme zal resulteren in een hogere latentie (vanwege minder verbruikte resources om elke batch te voldoen), maar een hogere doorvoer per GPU (vanwege betere benutting) in vergelijking met een hoger tensor-parallelisme.

Kwantisatie is de vermindering van precisie in de gewichten en activaties die door neurale netwerken worden gebruikt. We gebruiken deze techniek om het GPU-geheugenverbruik te halveren wanneer we overschakelen van fp16 naar fp8. Dit maakt het mogelijk om hetzelfde model uit te voeren met een lager totaal GPU-geheugenverbruik, wat een lager tensor-parallelisme mogelijk maakt, wat de doorvoer verhoogt.

Implementaties van kwantisatie hebben de potentie om de nauwkeurigheid te verminderen. Daarom hebben we de nauwkeurigheid voor verschillende precisies geëvalueerd door hun perplexiteitsstatistiek te vergelijken, een maatstaf voor hoe goed het LLM elk volgend token in een zin voorspelt, op het WikiText-corpus. Voor 8-bit floating point en 8-bit gewicht met 8-bit activatie en SmoothQuant (w8a8 SQ) was er geen significante verandering in perplexiteit (< 1%) in vergelijking met fp16 op WikiText, dus we voelden ons zelfverzekerd om door te gaan. Echter, w4a16 vertoonde een substantiële 7% verandering in perplexiteit, mogelijk toe te schrijven aan de nog lagere precisie en noodzakelijke dynamische conversies tussen int4 en fp16.

Parallelisme via batching is een klassieke strategie om prestaties uit een systeembelasting-beperkt systeem te persen. Door meerdere verzoeken te verwerken in elke forward pass door het neurale netwerk, staat batching erom bekend de doorvoer te verhogen ten koste van enige latentie. Batching brengt ook een hoger GPU-geheugenverbruik met zich mee omdat de grootte van de KV-cache, die het aandachtmechanisme beheert, lineair groeit met de batchgrootte.

In het geval van Llama 2 70B (dat 80 lagen heeft), fp16 met batchgrootte 32 voor 4096 contextgrootte, komt de grootte van de KV-cache uit op een aanzienlijke 40 GB. Dit voorkomt uiteindelijk dat Llama 2 70B fp16, waarvan de gewichten alleen al 140GB in beslag nemen, comfortabel past in de 160GB GPU-geheugen die beschikbaar is bij tensor-parallelisme 2 (TP-2).

We hebben de compatibele combinaties van de 4 variabelen van het experiment doorlopen en presenteren hieronder de meest inzichtelijke trends.

Figuur 1 - De latentie van verzoeken met variërende batchgrootte over vijf verschillende configuraties, allemaal met tensor-parallelisme 8, wat de beste latentie oplevert met 8 beschikbare GPU's. Binnen elke configuratie verdubbelt de latentie over het algemeen bij het verhogen van de batchgrootte van 1 naar 32, en verdubbelt opnieuw van 32 naar 128. Bij voldoende grote batchgroottes halveert de H100 de latentie in vergelijking met de A100. A100 gebruikt gemengde precisie omdat de architectuur geen native ondersteuning heeft voor fp8. w8a8 met SmoothQuant (SQ) is bedoeld om op fp8 te lijken.

De latentieverbetering van kwantisatie ligt in de buurt van 10% bij het vergelijken van H100 fp16 naar fp8 en A100 fp16 naar w8a8 met SmoothQuant. Echter, de gemengde precisie w4a16 presteert daadwerkelijk beter bij lage batchgroottes en slechter bij hogere batchgroottes in vergelijking met fp16. Dit kan te wijten zijn aan een aantal factoren, waaronder minder geoptimaliseerde rekengestuurde kernels, cast-tijd tussen int4 en fp16, en het feit dat w4a16 nog steeds 16-bit floating points gebruikt voor activaties, wat resulteert in geen besparingen in de dimensies van de KV-cache. Omdat w4a16 ook een lagere nauwkeurigheid vertoonde, concluderen we dat we bij w8a8 SQ voor A100's en fp8 voor H100's moeten blijven.

Figuur 2 - De doorvoer over TP-8-configuraties met verschillende architectuur, kwantisatie en batchgrootte. Voor elke architectuur en kwantisatie werd de batchgrootte gekozen als de grootste die voldeed aan een latentie-eis van 25600ms (20 tokens per seconde voor 512 tokens), zodat we configuraties vergelijken die vergelijkbare latentie hebben. Onder deze eis bereikt de H100 met BS-128 228% doorvoer in vergelijking met de A100 BS-64 met dezelfde kwantisatie (fp16) en heeft zelfs een lagere responslatentie ondanks de verdubbelde batchgrootte. Kwantisatie met fp8 verbetert deze factor naar 251%.

In onze eerste twee figuren presenteren we alleen configuraties van TP-8. H100 behaalt 54% latentie en 184% doorvoer in vergelijking met A100 wanneer beide fp16 / BS-128 / TP-8 gebruiken, wat verbetert naar 49% latentie en 202% doorvoer bij gebruik van fp8 op H100. Deze verbetering in prestaties kan worden toegeschreven aan de toename in rekenkracht en geheugenbandbreedte tussen H100 en A100. Opvallend is dat het verschil minder uitgesproken is bij lagere batchgroottes waar de benutting lager kan zijn.

Terwijl we ons platform bouwen, willen we bepaalde latentie-eisen voor onze gebruikers honoreren en tegelijkertijd de doorvoer maximaliseren. Daarom is het, in plaats van A100 vs. H100 te vergelijken bij dezelfde batchgrootte, zinvoller voor ons om hun doorvoer alleen te vergelijken onder configuraties waar ze voldoen aan een latentie-eis. We stelden een limiet in op 25600ms latentie voor voltooiing van de 512 output-tokens en ontdekten dat H100 / TP-8 / fp8 / BS-128 251% doorvoer oplevert in vergelijking met A100 / TP-8 / fp16 / BS-64, aangezien het in staat is om de dubbele batchgrootte te verwerken bij een lagere latentie. Gegeven dat kwantisatie GPU-geheugenbesparingen oplevert, moeten we nu evalueren hoe tensor-parallelisme een volgende optimalisatielaag kan toevoegen.

Figuur 3 - De latentie over variërende batchgroottes en tensor-parallelisme voor H100 fp8. Latentie verdubbelt over het algemeen bij het verhogen van de batchgrootte van 1 naar 32, en verdubbelt opnieuw van 32 naar 128. TP-2 is consistent ongeveer twee keer zo traag als TP-8 bij gelijke batchgroottes. Het verdubbelen van het tensor-parallelisme terwijl de batchgrootte wordt verdubbeld, houdt de latentie relatief stabiel omdat het aantal batches dat per GPU wordt verwerkt gelijk blijft.

Wat kwantisatie en architectuur betreft, zijn er duidelijke winnaars: H100 domineert A100 en kwantisatie met lagere precisie verbetert geheugenbenutting, latentie en doorvoer. Echter, batchgrootte en tensor-parallelisme vormen een afweging in onze kernstatistieken. Een grotere batchgrootte optimaliseert voor doorvoer ten koste van verhoogde latentie en geheugenverbruik. Aan de andere kant verhoogt een hoger tensor-parallelisme de totale pool van beschikbaar geheugen en optimaliseert het voor latentie, maar gaat het ten koste van doorvoer vanwege synchronisatiekosten van gedistribueerde matrixvermenigvuldiging en door het vastleggen van meer GPU-resources.

Figuur 4 - De doorvoer over variërende batchgroottes en tensor-parallelisme voor H100 fp8. De hoogste doorvoer komt van TP-2 BS-128, op 460% in vergelijking met de baseline van A100/TP-8/fp16/BS-64. Echter, TP-2 BS-128 is ook het traagste resultaat in Figuur 3.

De doorvoermaximaliserende configuratie van ons experiment is H100 / fp8 / TP-2 / BS-128, met 767 output-tokens per seconde per GPU. Dit is een 460% verbetering ten opzichte van A100 / fp16 / TP-8 / BS-64. Echter, dit gaat ten koste van een verdubbelde latentie - dichter bij 42000ms voor 512 output-tokens - dus het is mogelijk ongeschikt als productieconfiguratie. De resultaten van TP-4 BS-128 (626 tok/sec/gpu bij 26188ms responstijd) en TP-2 BS-32 (435 tok/sec/gpu bij 18821ms responstijd) kunnen betere afwegingen vertegenwoordigen voor onze kernstatistieken.

Onze resultaten tonen aan dat:

We bereiken 54% latentie en 184% doorvoer met H100 in vergelijking met A100 bij dezelfde configuratie, wat verbetert naar 49% en 202% respectievelijk wanneer H100 profiteert van zijn native ondersteuning voor fp8.

Bij het maximaliseren van de doorvoer onder een latentiebeperking, levert H100 / fp8 / TP-8 / BS-128 251% doorvoer in vergelijking met A100 / fp16 / TP-8 / BS-64, aangezien het de dubbele batch kan verwerken bij een hogere snelheid.

Door te profiteren van H100 met TP-2 met fp8, kunnen we 373% van de doorvoer van A100 / fp16 / TP-8 / BS-128 bereiken, met minder dan een 10% toename in latentie.

Batchgrootte en tensor-parallelisme vormen een afweging tussen doorvoer en latentie voor de operator van een LLM-inferentiesysteem.

Deze resultaten geven ons vertrouwen in een volledige overgang naar H100 GPU's in onze voorheen op A100 aangedreven hardware-stack. We zijn verheugd om de prestatiewinsten die door NVIDIA zijn geadverteerd te kunnen bevestigen en kijken uit naar hun volgende doorbraken in versnelde hardware.

Onze volgende grens voor optimalisatie is het onderzoeken van de nauwkeurigheid en prestatie-impact van gestructureerde spaarzaamheid en int4-precisie, wat de GPU-geheugenvoetafdruk van Llama 2 70B aanzienlijk zou kunnen verminderen en tot 2x verbeteringen in latentie zou kunnen opleveren. We zijn enthousiast om de reis van razendsnelle inferentie voort te zetten en hopen onze gebruikers in staat te stellen krachtige applicaties op ons platform te bouwen.

Op korte termijn zal pplx-api tarieflimieten opheffen en meer aangepaste Perplexity LLM's aanbieden, waaronder een op internet gebaseerd LLM met feitenonderbouwing.

Meld je aan voor Perplexity Pro op perplexity.ai/pro. Krijg toegang tot onze geavanceerde pplx-api en benut deze geavanceerde mogelijkheden in je projecten. Ontdek meer over pplx-api op onze blog.

Geïnteresseerd in het vormgeven van de toekomst van AI? Wij nemen mensen aan! Maak deel uit van een team dat grootschalige, generatieve LLM-infrastructuur stimuleert. Ontdek mogelijkheden bij Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Experimentele opzet

Kernstatistieken:

Constanten:

AI-model

Dataset voor input/output-tokens

Softwareversie

Variabelen

GPU-architectuur

Tensor-parallelisme

Kwantisatie

Batchgrootte

Resultaten

Conclusie

Wat volgt

Auteurs: