Turboopladning af Llama 2 70B med NVIDIA H100

Jagten på ydeevne i Perplexitys svarmotor driver os til at tage den nyeste teknologi til sig, som NVIDIA og AWS har at tilbyde. I dette blogindlæg er vi glade for at kunne dele resultaterne af vores seneste eksperimenter: en sammenligning af Llama 2 70B-inferens på tværs af forskellige hardware- og softwareindstillinger.

Vores LLM-inferensplatform, pplx-api, er bygget på en banebrydende stack baseret på open source-biblioteker. Siden den offentlige betaversion af pplx-api startede i oktober, har vi tacklet skaleringsudfordringer og lært, hvordan vi bedst finjusterer vores konfiguration for at opnå massiv skala. Dette fik os til at køre eksperimenter med følgende ledende spørgsmål:

Hvad er den rå ydeevneforbedring ved at skifte vores GPU'er fra NVIDIA A100 til NVIDIA H100, hvor alle andre indstillinger forbliver de samme?

Hvad er effektivitetsgevinsten ved 8-bit flydende kommatal (fp8)-kvantisering, som H100 tilføjer indbygget understøttelse af? Hvad er nøjagtighedsomkostningen ved denne kvantisering?

Hvordan påvirker tensorparallelisme og batchstørrelse latenstid og token-throughput?

Med udgangspunkt i ovenstående, hvilken konfiguration resulterer i den mest skalerbare balance mellem ydeevne og omkostningseffektivitet?

Eksperimentel opsætning

Vi kørte følgende eksperiment som en række lokale benchmarks for at undgå netværkslatens.

Nøglemålinger:

Latens: Den samlede tid det tager for inferensserveren at generere hele sit svar.

Throughput: Antallet af output-tokens, pr. sekund, pr. GPU, som inferensserveren kan generere på tværs af alle brugere og anmodninger.

Konstanter:

Følgende faktorer ville påvirke nøglemålingerne, så vi holdt dem konsekvente på tværs af forskellige forsøg med eksperimentet.

AI-model

Ydeevnen skalerer med størrelsen på LLM'en. Flere parametre kræver flere beregninger, hvilket resulterer i langsommere inferens. For eksempel er Llama 2 13B hurtigere end Llama 2 70B, når andre indstillinger er ens. Vi holder os til Llama 2 70B i dette eksperiment, fordi vi ønsker at optimere til at betjene de mest kapable open source-modeller.

Input-/output-token-dataset

Mængden af input- og output-tokens i hvert par af anmodning og svar kan påvirke ydeevnemålingerne. Generelt dominerer generering af output-tokens den samlede svartid. Når dataprøvetagning kun fremkalder "ja/nej"-svar fra LLM'en, er svaret hurtigere sammenlignet med prøver, der beder LLM'en om at skrive essays. Vores dataset består af syntetiske anmodninger med 1024 input-tokens, der fremkalder 512 output-tokens. Denne fordeling blev valgt for at matche den observerede fordeling af trafik på vores offentlige implementering af Llama2 70B.

Softwareversion

NVIDIA TensorRT-LLM (udgivelse v0.5.0) er et open source-bibliotek til optimering af LLM-inferens. Det blev udgivet i slutningen af 2023, syntetiserer NVIDIAs mange inferensoptimeringer og giver et fleksibelt lag af tilpasning for de vigtigste parametre i dette eksperiment: batchstørrelse, kvantisering og tensorparallelisme.

Variabler

Vi eksperimenterede på tværs af 4 konfigurationsakser: tensorparallelisme, GPU-arkitektur, kvantisering og maks. batchstørrelse. Disse akser er forbundet, fordi de hver især repræsenterer et kompromis i forhold til den kritiske flaskehalsressource: GPU-hukommelse.

GPU-arkitektur

Niende generation af Hopper (H100-HBM3-80GB / p5.48xlarge) GPU-arkitekturen indeholder en enorm liste af funktioner i forhold til sin forgænger, Ampere (A100-SXM4-80GB / p4de.24xlarge), herunder 2x-6x beregningsrater og næsten 2x GPU-hukommelsesbåndbredde. GPU-hukommelsesbåndbredde er en kritisk måling for inferens, fordi en primær latensflaskehals ved inferensens matrixmultiplikationer kommer fra indlæsning af gigabyte af modeldata fra GPU-hukommelse til beregningsregistre. Baseret på disse statistikker opstillede vi den hypotese, at en direkte sammenligning af NVIDIA H100 og A100 vil udvise en 2x forbedring i både latens og throughput.

En anden vigtig forskel mellem NVIDIA H100 og A100 er, at H100-tensorkernen indbygget tilføjer understøttelse af 8-bit flydende kommatal (fp8)-instruktioner, hvilket åbner døren for yderligere optimeringer beskrevet nedenfor. Det er derfor, vi bruger fp8 og fp16 specifikt til H100.

For at holde hukommelse pr. GPU konsekvent i dette eksperiment holdt vi os til noder med 8x80GB GPU-hukommelse for både vores NVIDIA A100'ere og H100'ere. Ud over at muliggøre højere batchstørrelser er GPU-hukommelse vigtig, fordi modellens parametre indlæses i GPU-hukommelsen under serveropstart for hurtig adgang. For eksempel, hvis hver af de 70 milliarder parametre i vores model er et 16-bit flydende kommatal, er modellen omkring 140 GB i størrelse, hvilket ikke kan være der på en enkelt GPU. Derfor er der behov for tensorparallelisme, som vi forklarer nedenfor.

Tensorparallelisme

Tensorparallelisme refererer til antallet af GPU-enheder, der bruges til at køre inferensserveren. Når vi allokerer et antal GPU'er, puljer TensorRT-LLM deres ressourcer sammen for at hjælpe os med at nå det minimum af påkrævet hukommelse til at køre Llama2 70B. Vores hypotese er, at lavere tensorparallelisme vil resultere i højere latens (på grund af færre ressourcer brugt på at opfylde hver batch), men højere throughput pr. GPU (på grund af bedre udnyttelse), når det sammenlignes med højere tensorparallelisme.

Kvantisering

Kvantisering er reduktionen af præcision i vægte og aktiveringer, der bruges af neurale netværk. Vi bruger denne teknik til at halvere GPU-hukommelsesforbruget, når vi skifter fra fp16 til fp8. Dette gør det muligt at køre den samme model med lavere samlet GPU-hukommelsesforbrug, hvilket muliggør lavere tensorparallelisme, som øger throughput.

Implementeringer af kvantisering har potentiale til at forringe nøjagtigheden. Derfor evaluerede vi nøjagtigheden for forskellige præcisioner ved at sammenligne deres perplexity-statistik – et mål for, hvor godt LLM'en forudsiger hvert næste token i en sætning – på WikiText-korpuset. For 8-bit flydende kommatal og 8-bit vægt med 8-bit aktivering og SmoothQuant (w8a8 SQ) var der ingen væsentlig ændring i perplexity (< 1%) sammenlignet med fp16 på WikiText, så vi følte os sikre på at fortsætte. w4a16 udviste dog en væsentlig ændring på 7% i perplexity, hvilket potentielt kan tilskrives den endnu lavere præcision og nødvendige dynamiske konverteringer mellem int4 og fp16.

Batchstørrelse

Parallelisme via batching er en klassisk strategi til at presse ydeevne ud af et ressourcebegrænset system. Ved at behandle flere anmodninger i hvert fremadrettet gennemløb gennem det neurale netværk er det kendt, at batching øger throughput på bekostning af en vis latens. Batching medfører også et højere GPU-hukommelsesforbrug, fordi størrelsen på KV-cachen, som administrerer opmærksomhedsmekanismen, vokser lineært med batchstørrelsen.

Udvid

I tilfælde af Llama 2 70B (som har 80 lag), fp16 med batchstørrelse 32 for 4096 kontextstørrelse, beløber størrelsen af KV-cachen sig til hele 40 GB. Dette ender med at forhindre Llama 2 70B fp16, hvis vægte alene optager 140 GB, i ubesværet at kunne være der i den 160 GB store GPU-hukommelse, der er til rådighed ved tensorparallelisme 2 (TP-2).

Resultater

Vi gennemgik kompatible kombinationer af eksperimentets 4 variabler og præsenterer de mest indsigtsfulde tendenser nedenfor.

Udvid

Latensforbedringen ved kvantisering er i størrelsesordenen 10% ved sammenligning af H100 fp16 → fp8 og A100 fp16 → w8a8 med SmoothQuant. Dog yder den blandede præcision w4a16 faktisk bedre ved lave batchstørrelser og dårligere ved højere batchstørrelser sammenlignet med fp16. Dette kan skyldes en række faktorer, herunder mindre optimerede beregningskerner, castningstid mellem int4 og fp16 samt det faktum, at w4a16 stadig bruger 16-bit flydende kommatal til aktiveringer, hvilket resulterer i nul besparelser i dimensionerne af KV-cachen. Da w4a16 også demonstrerede lavere nøjagtighed, konkluderer vi, at vi bør holde os til w8a8 SQ for A100'ere og fp8 for H100'ere.

Udvid

I vores første to figurer præsenterer vi kun TP-8-konfigurationer. H100 opnår 54% latens og 184% throughput sammenlignet med A100, når begge bruger fp16 / BS-128 / TP-8, hvilket forbedres til 49% latens og 202% throughput ved brug af fp8 på H100. Denne forbedring i ydeevne kan tilskrives stigningerne i beregningskraft og hukommelsesbåndbredde mellem H100 og A100. Navnlig er forskellen mindre udtalt ved lavere batchstørrelser, hvor udnyttelsen kan være lavere.

Når vi opbygger vores platform, ønsker vi at overholde visse latenskrav for vores brugere og samtidig maksimere throughput. Derfor giver det i stedet for at sammenligne A100 vs. H100 ved samme batchstørrelse mere mening for os kun at sammenligne deres throughput under konfigurationer, hvor de opfylder et latenskrav. Vi satte en grænse på 25600ms latens for fuldførelse af de 512 output-tokens og fandt ud af, at H100 / TP-8 / fp8 / BS-128 giver 251% throughput sammenlignet med A100 / TP-8 / fp16 / BS-64, da den er i stand til at behandle den dobbelte batchstørrelse ved en lavere latens. Da kvantisering giver besparelser på GPU-hukommelsen, skal vi nu evaluere, hvordan tensorparallelisme kan tilføje et næste lag af optimering.

Udvid

Når det kommer til kvantisering og arkitektur, er der klare vindere: H100 dominerer A100, og kvantisering med reduceret præcision forbedrer hukommelsesudnyttelse, latens og throughput. Batchstørrelse og tensorparallelisme udgør dog et kompromis i vores nøglemålinger. En større batchstørrelse optimerer for throughput på bekostning af øget latens og hukommelsesforbrug. På den anden side øger højere tensorparallelisme den samlede pool af tilgængelig hukommelse og optimerer for latens, men går på kompromis med throughput på grund af synkroniseringsomkostninger ved distribueret matrixmultiplikation og ved at beslaglægge flere GPU-ressourcer.

Udvid

Den throughput-maksimerende konfiguration i vores eksperiment er H100 / fp8 / TP-2 / BS-128 på 767 output-tokens pr. sekund pr. GPU. Dette er en forbedring på 460% i forhold til A100 / fp16 / TP-8 / BS-64. Det kommer dog på bekostning af fordoblet latens – tættere på 42000 ms for 512 output-tokens – så den er muligvis uegnet som produktionskonfiguration. Resultaterne for TP-4 BS-128 (626 tok/sec/gpu ved 26188 ms svartid) og TP-2 BS-32 (435 tok/sec/gpu ved 18821 ms svartid) repræsenterer muligvis bedre kompromiser på vores nøglemålinger.

Konklusion

Vores resultater viser, at:

Vi når 54% latens og 184% throughput ved brug af H100 sammenlignet med A100 givet den samme konfiguration, hvilket forbedres til henholdsvis 49% og 202%, når H100 drager fordel af sin indbyggede understøttelse af fp8.

Når throughput maksimeres underlagt et latenskrav, giver H100 / fp8 / TP-8 / BS-128 251% throughput sammenlignet med A100 / fp16 / TP-8 / BS-64, da den kan behandle den dobbelte batch med en hurtigere hastighed.

Ved at drage fordel af H100 med TP-2 med fp8 kan vi opnå 373% af throughputten for A100 / fp16 / TP-8 / BS-128 med mindre end 10% stigning i latens.

Batchstørrelse og tensorparallelisme udgør et kompromis mellem throughput og latens for operatøren af et LLM-inferenssystem.

Disse resultater gør os sikre på en fuldstændig overgang til H100 GPU'er i vores tidligere A100-drevne hardware-stack. Vi glæder os over at kunne bekræfte de ydeevnegevinster, som NVIDIA annoncerer, og ser frem til deres næste gennembrud inden for accelereret hardware.

Hvad er det næste

Vores næste grænse for optimering er at undersøge nøjagtigheden og ydeevnepåvirkningen af struktureret sparsommelighed og int4-præcision, hvilket markant kunne reducere Llama 2 70B's GPU-hukommelsesfodaftryk og give op til 2x forbedringer i latens. Vi glæder os til at fortsætte rejsen med lynhurtig inferens og håber at kunne give vores brugere mulighed for at bygge kraftfulde applikationer oven på vores platform.

På kort sigt vil pplx-api fjerne hastighedsgrænser og tilbyde flere tilpassede Perplexity LLM'er, herunder en internetdrevet LLM med grunding af fakta.

Tilmeld dig Perplexity Pro på perplexity.ai/pro. Få adgang til vores banebrydende pplx-api, og udnyt disse avancerede funktioner i dine projekter. Oplev mere om pplx-api på vores blog.

Er du interesseret i at forme fremtidens AI? Vi ansætter! Bliv en del af et hold, der driver massivt skaleret, generativ LLM-infrastruktur. Udforsk muligheder hos Perplexity Careers.

Forfattere:

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats