Turbomatad Llama 2 70B med NVIDIA H100

Strävan efter prestanda i Perplexitys svarsmotor driver oss att använda den senaste tekniken som NVIDIA och AWS har att erbjuda. I den här bloggen delar vi gärna med oss av resultaten från våra senaste experiment: en jämförelse av Llama 2 70B-inferens i olika hård- och mjukvaruinställningar.

Vår plattform för LLM-inferens, pplx-api, är byggd på en banbrytande stack som drivs av bibliotek med öppen källkod. Sedan pplx-apis publika betaversion startade i oktober har vi tagit oss an skalningsutmaningar och lärt oss hur vi bäst finjusterar vår konfiguration för att uppnå massiv skalning. Detta ledde till att vi utförde experiment med följande vägledande frågor:

Vad blir prestandavinsten av att byta våra GPU:er från NVIDIA A100 till NVIDIA H100, medan alla andra inställningar förblir desamma?

Vad är effektivitetsvinsten med 8-bitars flyttalskvantisering (fp8) som H100 har inbyggt stöd för? Vad är noggrannhetskostnaden för denna kvantisering?

Hur påverkar tensorparallellism och batchstorlek latens och token-genomströmning?

Med hänsyn till ovanstående, vilken konfiguration ger den mest skalbara balansen mellan prestanda och kostnadseffektivitet?

Vi körde följande experiment som en serie lokala prestandatester för att undvika nätverkslatens.

Latens: Den totala tid det tar för inferensservern att generera hela sitt svar.

Genomströmning: Antalet utmatningstokens per sekund och GPU som inferensservern kan generera över alla användare och förfrågningar.

Följande faktorer skulle påverka nyckeltalen, så vi höll dem konsekventa över olika körningar av experimentet.

Prestandan skalas med storleken på LLM:en. Fler parametrar kräver mer beräkningar vilket resulterar i långsammare inferens. Till exempel är Llama 2 13B snabbare än Llama 2 70B när andra inställningar är lika. Vi håller oss till Llama 2 70B i det här experimentet eftersom vi vill optimera för att köra de mest kapabla modellerna med öppen källkod.

Mängden indata- och utdata-tokens i varje provförfrågnings-/svarspar kan påverka prestandamätningarna. Generellt sett dominerar genereringen av utdata-tokens den totala svarstiden. När samplingsdata endast framkallar "ja/nej"-svar från LLM:en är svaret snabbare jämfört med prover som ber LLM:en att skriva uppsatser. Vårt dataset består av syntetiska förfrågningar med 1024 indata-tokens som framkallar 512 utdata-tokens. Denna fördelning valdes för att matcha den observerade trafikfördelningen på vår publika distribution av Llama 2 70B.

NVIDIA TensorRT-LLM (utgåva v0.5.0) är ett bibliotek med öppen källkod för att optimera LLM-inferens. Det släpptes i slutet av 2023, sammanfattar NVIDIAs många inferensoptimeringar och tillhandahåller ett flexibelt anpassningslager för experimentets nyckelparametrar: batchstorlek, kvantisering och tensorparallellism.

Vi experimenterade över 4 konfigurationsaxlar: tensorparallellism, GPU-arkitektur, kvantisering och max batchstorlek. Dessa axlar är sammankopplade eftersom de var och en representerar en avvägning med avseende på den kritiska flaskhalsresursen GPU-minne.

Nionde generationens Hopper-GPU-arkitektur (H100-HBM3-80GB / p5.48xlarge) har en enorm mängd funktioner jämfört med föregångaren Ampere (A100-SXM4-80GB / p4de.24xlarge), inklusive 2x-6x beräkningshastigheter och nästan 2x GPU-minnesbandbredd. GPU-minnesbandbredd är ett kritiskt mått för inferens eftersom en primär latensflaskhals för inferensens matrismultiplikationer kommer från att ladda gigabyte med modelldata från GPU-minne till beräkningsregister. Baserat på denna statistik ställde vi hypotesen att en direkt jämförelse av NVIDIA H100 och A100 kommer att uppvisa en fördubbling i både latens och genomströmning.

En annan nyckelskillnad mellan NVIDIA H100 och A100 är att H100-tensorkärnan i grunden lägger till stöd för 8-bitars flyttalsinstruktioner (fp8), vilket öppnar dörren för ytterligare optimeringar som beskrivs nedan. Det är därför vi använder fp8 och fp16 specifikt för H100.

För att hålla minnet per GPU konsekvent i detta experiment höll vi oss till noder med 8x80 GB GPU-minne för både våra NVIDIA A100 och H100. Förutom att möjliggöra större batchstorlekar är GPU-minne viktigt eftersom modellens parametrar laddas in i GPU-minnet under serverns uppstart för snabb åtkomst. Om till exempel var och en av de 70 miljarder parametrarna i vår modell är ett 16-bitars flyttal är modellen cirka 140 GB stor, vilket inte ryms på en enda GPU. Därav behovet av tensorparallellism, som vi förklarar nedan.

Tensorparallellism avser antalet GPU-enheter som förbrukas för att köra inferensservern. När vi allokerar ett antal GPU:er slår TensorRT-LLM samman deras resurser för att hjälpa oss att nå den lägsta erforderliga minnesbudgeten för att köra Llama 2 70B. Vår hypotes är att lägre tensorparallellism kommer att resultera i högre latens (på grund av färre resurser som förbrukas för att uppfylla varje batch) men högre genomströmning per GPU (på grund av bättre utnyttjande) jämfört med högre tensorparallellism.

Kvantisering är en reduktion av precisionen i de vikter och aktiveringar som används av neurala nätverk. Vi använder denna teknik för att halvera GPU-minnesförbrukningen när vi växlar från fp16 till fp8. Detta gör det möjligt att köra samma modell med lägre total GPU-minnesanvändning, vilket möjliggör lägre tensorparallellism, vilket driver upp genomströmningen.

Implementeringar av kvantisering har potential att försämra noggrannheten. Därför utvärderade vi noggrannheten för olika precisioner genom att jämföra deras perplexitetsstatistik – ett mått på hur väl LLM:en förutspår varje nästa token i en mening – på WikiText-korpusen. För 8-bitars flyttal och 8-bitars vikt med 8-bitars aktivering och SmoothQuant (w8a8 SQ) skedde ingen signifikant förändring i perplexitet (< 1 %) jämfört med fp16 på WikiText, så vi kände oss trygga med att gå vidare. W4a16 uppvisade dock en avsevärd förändring i perplexitet på 7 %, vilket kan bero på den ännu lägre precisionen och nödvändiga dynamiska konverteringar mellan int4 och fp16.

Parallellism via batchning är en klassisk strategi för att klämma ut prestanda ur ett resursbegränsat system. Genom att bearbeta flera förfrågningar i varje framåtskrap genom det neurala nätverket är batchning känd för att öka genomströmningen till priset av viss latens. Batchning medför också högre GPU-minnesförbrukning eftersom storleken på KV-cachen som hanterar uppmärksamhetsmekanismen växer linjärt med batchstorleken.

När det gäller Llama 2 70B (som har 80 lager), fp16 med batchstorlek 32 för 4096 kontextstorlek, uppgår storleken på KV-cachen till hela 40 GB. Detta gör att Llama 2 70B fp16, vars enbart vikter upptar 140 GB, inte bekvämt får plats i det 160 GB stora GPU-minne som finns tillgängligt vid tensorparallellism 2 (TP-2).

Vi gick igenom kompatibla kombinationer av experimentets 4 variabler och presenterar de mest insiktsfulla trenderna nedan.

Figur 1 – Latensen för förfrågningar med varierande batchstorlek i fem olika konfigurationer, samtliga med tensorparallellism 8, vilket ger bäst latens med 8 tillgängliga GPU:er. Inom varje konfiguration fördubblas latensen generellt när batchstorleken ökas från 1 → 32, och fördubblas igen från 32 → 128. Vid tillräckligt stora batchstorlekar halverar H100 ungefär latensen jämfört med A100. A100 använder blandad precision eftersom arkitekturen saknar inbyggt stöd för fp8. w8a8 med SmoothQuant (SQ) är avsett att likna fp8.

Latensförbättringen genom kvantisering ligger i storleksordningen 10 % när man jämför H100 fp16 → fp8 och A100 fp16 → w8a8 med SmoothQuant. W4a16 med blandad precision presterar dock faktiskt bättre vid låga batchstorlekar och sämre vid högre batchstorlekar jämfört med fp16. Detta kan bero på ett antal faktorer, inklusive mindre optimerade beräkningskärnor, castningstid mellan int4 och fp16, och det faktum att w4a16 fortfarande använder 16-bitars flyttal för aktiveringar, vilket inte resulterar i några besparingar i KV-cachens dimensioner. Eftersom w4a16 dessutom uppvisade lägre noggrannhet drar vi slutsatsen att vi bör hålla oss till w8a8 SQ för A100 och fp8 för H100.

Figur 2 – Genomströmningen över TP-8-konfigurationer med olika arkitektur, kvantisering och batchstorlek. För varje arkitektur och kvantisering valdes batchstorleken som den största som uppfyllde ett latenskrav på 25600 ms (20 tokens per sekund för 512 tokens), så att vi kan jämföra konfigurationer med liknande latens. Under detta krav når H100 med BS-128 en genomströmning på 228 % jämfört med A100 BS-64 med samma kvantisering (fp16) och har till och med lägre svarslatens trots den fördubblade batchstorleken. Kvantisering med fp8 förbättrar denna faktor till 251 %.

I våra två första figurer presenterar vi endast konfigurationer för TP-8. H100 uppnår 54 % latens och 184 % genomströmning jämfört med A100 när båda använder fp16 / BS-128 / TP-8, vilket förbättras till 49 % latens och 202 % genomströmning när man använder fp8 på H100. Denna prestandaförbättring kan tillskrivas ökningarna i beräkningskraft och minnesbandbredd mellan H100 och A100. Skillnaden är särskilt mindre uttalad vid lägre batchstorlekar där resursutnyttjandet kan vara lägre.

När vi bygger vår plattform vill vi uppfylla vissa latenskrav för våra användare samtidigt som vi maximerar genomströmningen. Istället för att jämföra A100 mot H100 vid samma batchstorlek är det därför faktiskt mer meningsfullt för oss att endast jämföra deras genomströmning under konfigurationer där de uppfyller ett latenskrav. Vi satte en gräns vid 25600 ms latens för slutförande av de 512 utdata-tokena och fann att H100 / TP-8 / fp8 / BS-128 ger 251 % genomströmning jämfört med A100 / TP-8 / fp16 / BS-64, eftersom den kan bearbeta dubbla batchstorleken vid en lägre latens. Med tanke på att kvantisering ger besparingar i GPU-minne behöver vi nu utvärdera hur tensorparallellism kan addera ett nästa lager av optimering.

Figur 3 – Latensen över varierande batchstorlekar och tensorparallellism för H100 fp8. Latensen fördubblas generellt när batchstorleken ökas från 1 → 32, och fördubblas igen från 32 → 128. TP-2 är genomgående ungefär dubbelt så långsam som TP-8 när batchstorlekarna är lika. Att fördubbla tensorparallellismen samtidigt som batchstorleken fördubblas håller latensen relativt stabil eftersom antalet bearbetade batchar per GPU förblir jämnt.

När det gäller kvantisering och arkitektur finns det tydliga vinnare: H100 dominerar A100 och kvantisering med lägre precision förbättrar minnesutnyttjandet, latensen och genomströmningen. Batchstorlek och tensorparallellism innebär dock en avvägning i våra nyckeltal. En större batchstorlek optimerar för genomströmning till priset av ökad latens och minnesförbrukning. Å andra sidan ökar högre tensorparallellism den totala poolen av tillgängligt minne och optimerar för latens, men innebär en avvägning mot genomströmning på grund av synkroniseringskostnader för distribuerad matrismultiplikation och genom att uppta fler GPU-resurser.

Figur 4 – Genomströmningen över varierande batchstorlekar och tensorparallellism för H100 fp8. Den högsta genomströmningen kommer från TP-2 BS-128, på 460 % jämfört med baslinjen för A100/TP-8/fp16/BS-64. TP-2 BS-128 är dock också det långsammaste resultatet i figur 3.

Den genomströmningsmaximerande konfigurationen för vårt experiment är H100 / fp8 / TP-2 / BS-128, med 767 utdata-tokens per sekund och GPU. Detta är en förbättring med 460 % jämfört med A100 / fp16 / TP-8 / BS-64. Det sker dock till priset av en fördubblad latens – närmare 42000 ms för 512 utdata-tokens – så den kan vara olämplig som produktionskonfiguration. Resultaten för TP-4 BS-128 (626 tok/sek/gpu vid 26188 ms svarstid) och TP-2 BS-32 (435 tok/sek/gpu vid 18821 ms svarstid) kan representera bättre avvägningar för våra nyckeltal.

Våra resultat visar att:

Vi når 54 % latens och 184 % genomströmning med H100 jämfört med A100 givet samma konfiguration, vilket förbättras till 49 % respektive 202 % när H100 drar nytta av sitt inbyggda stöd för fp8.

När genomströmningen maximeras under ett latenskrav ger H100 / fp8 / TP-8 / BS-128 251 % genomströmning jämfört med A100 / fp16 / TP-8 / BS-64, eftersom den kan bearbeta dubbla batchen i högre hastighet.

Genom att dra nytta av H100 med TP-2 med fp8 kan vi uppnå 373 % av genomströmningen för A100 / fp16 / TP-8 / BS-128, med mindre än 10 % ökad latens.

Batchstorlek och tensorparallellism innebär en avvägning mellan genomströmning och latens för operatören av ett LLM-inferenssystem.

Dessa resultat gör oss trygga med en fullständig övergång till H100-GPU:er i vår tidigare A100-drivna hårdvarustack. Vi är glada över att kunna bekräfta de prestandavinster som NVIDIAs marknadsför och ser fram emot deras nästa genombrott inom accelererad hårdvara.

Vår nästa gräns för optimering är att undersöka noggrannhets- och prestandapåverkan av strukturerad gleshet (structured sparsity) och int4-precision, vilket avsevärt skulle kunna minska Llama 2 70B:s GPU-minnesfotavtryck och ge upp till dubbelt så bra latens. Vi är glada över att fortsätta resan mot blixtsnabb inferens och hoppas kunna ge våra användare möjlighet att bygga kraftfulla applikationer ovanpå vår plattform.

Inom den närmaste tiden kommer pplx-api att ta bort hastighetsbegränsningar och erbjuda fler anpassade Perplexity LLM:er, inklusive en internetdriven LLM med faktaunderlag.

Registrera dig för Perplexity Pro på perplexity.ai/pro. Få tillgång till vår banbrytande pplx-api och dra nytta av dessa avancerade funktioner i dina projekt. Upptäck mer om pplx-api i vår blogg.

Vill du vara med och forma AI:s framtid? Vi söker medarbetare! Bli en del av ett team som driver storskalig, generativ LLM-infrastruktur. Utforska möjligheter på Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Experimentell konfiguration

Nyckeltal:

Konstanter:

AI-modell

Dataset för indata-/utdata-tokens

Mjukvaruversion

Variabler

GPU-arkitektur

Tensorparallellism

Kvantisering

Batchstorlek

Resultat

Slutsats

Vad händer härnäst

Författare: