Turbo-lad Llama 2 70B med NVIDIA H100

Jakten på ytelse i Perplexity sin svarmotor driver oss til å ta i bruk den nyeste teknologien som NVIDIA og AWS har å tilby. I dette innlegget er vi glade for å dele resultatene fra våre siste eksperimenter: en sammenligning av Llama 2 70B-inferens på tvers av ulike maskinvare- og programvareinnstillinger.

Vår LLM-inferensplattform, pplx-api, er bygget på en banebrytende stabel drevet av open source-biblioteker. Siden den offentlige betaversjonen av pplx-api startet i oktober, har vi tatt tak i skaleringsutfordringer og lært hvordan vi best kan finjustere konfigurasjonen vår for å oppnå massiv skalering. Dette førte til at vi kjørte eksperimenter med følgende ledende spørsmål:

Hva er den rå ytelsesøkningen ved å bytte våre GPU-er fra NVIDIA A100 til NVIDIA H100, når alle andre innstillinger forbli de samme?

Hva er effektivitetsøkningen ved 8-bits flyttallskvantisering (fp8), som H100 legger til innebygd støtte for? Hva er nøyaktigheten til denne kvantiseringen?

Hvordan påvirker tensorparallelitet og batchstørrelse ventetid og tokengjennomstrømming?

Når man tar det ovennevnte i betraktning, hvilken konfigurasjon gir den mest skalerbare balansen mellom ytelse og kostnadseffektivitet?

Eksperimentelt oppsett

Vi kjørte følgende eksperiment som en serie lokale ytelsestester for å unngå nettverksforsinkelse.

Nøkkelmetrikker:

Ventetid: Den totale tiden det tar for inferensserveren å generere hele svaret sitt.

Gjennomstrømming: Antallet utdatatokener per sekund per GPU som inferensserveren kan generere på tvers av alle brukere og forespørsler.

Konstanter:

Følgende faktorer vil påvirke nøkkelmetrikkene, så vi holdt dem konsekvente på tvers av ulike runder i eksperimentet.

AI-modell

Ytelsen skalerer med størrelsen på LLM-en. Flere parametere krever flere beregninger, noe som resulterer i langsommere inferens. For eksempel er Llama 2 13B raskere enn Llama 2 70B når andre innstillinger er like. Vi holder oss til Llama 2 70B i dette eksperimentet fordi vi ønsker å optimalisere for å betjene de mest kapable open source-modellene.

Dataset for inndata-/utdatatokener

Mengden inndata- og utdatatokener i hvert forespørsel-/svarparet kan påvirke ytelsesmålingene. Generelt dominerer generering av utdatatokener den totale svartiden. Når datainnsamling kun utløser «ja/nei»-svar fra LLM-en, er svaret raskere sammenlignet med eksempler som ber LLM-en om å skrive essays. Datasettet vårt består av syntetiske forespørsler med 1024 inndatatokene som utløser 512 utdatatokener. Denne distribusjonen ble valgt for å matche den observerte distribusjonen av trafikk på vår offentlige distribusjon av Llama 2 70B.

Programvareversjon

NVIDIA TensorRT-LLM (versjon v0.5.0) er et open source-bibliotek for å optimalisere LLM-inferens. Det ble utgitt i slutten av 2023, og syntetiserer NVIDIAs mange inferensoptimaliseringer og gir et fleksibelt lag med tilpasning for nøkkelparameterne i dette eksperimentet: batchstørrelse, kvantisering og tensorparallelitet.

Variabler

Vi eksperimenterte på tvers av 4 konfigurasjonsakser: tensorparallelitet, GPU-arkitektur, kvantisering og maks. batchstørrelse. Disse aksene henger sammen fordi hver av dem representerer en avveining med hensyn til den kritiske flaskehalsressursen, som er GPU-minne.

GPU-arkitektur

Den niende generasjonen Hopper-GPU-arkitektur (H100-HBM3-80GB / p5.48xlarge) har en enorm mengde funksjoner sammenlignet med forgjengeren Ampere (A100-SXM4-80GB / p4de.24xlarge), inkludert 2x–6x beregningsrater og nesten 2x GPU-minnebåndbredde. GPU-minnebåndbredde er en kritisk metrikk for inferens fordi en primær flaskehals for ventetid i inferensens matrisemultiplikasjoner kommer fra lasting av gigabyte med modelldata fra GPU-minne til beregningsregistre. Basert på denne statistikken fremsatte vi en hypotese om at en direkte sammenligning av NVIDIA H100 og A100 vil vise en 2x forbedring i både ventetid og gjennomstrømming.

En annen vesentlig forskjell mellom NVIDIA H100 og A100 er at H100-tensorkjernen i tillegg har innebygd støtte for 8-bits flyttallsinstruksjoner (fp8), noe som åpner for ytterligere optimaliseringer som er beskrevet nedenfor. Dette er grunnen til at vi bruker fp8 og fp16 spesifikt for H100.

For å holde minne per GPU konsistent i dette eksperimentet holdt vi oss til noder med 8x80GB GPU-minne for både våre NVIDIA A100- og H100-enheter. I tillegg til å muliggjøre større batchstørrelser, er GPU-minne viktig fordi modellens parametere lastes inn i GPU-minnet under oppstart av serveren for rask tilgang. Hvis for eksempel hver av de 70 milliarder parameterne i modellen vår er et 16-bits flyttall, er modellen rundt 140 GB stor, noe som ikke får plass på én enkelt GPU. Derfor er det behov for tensorparallelitet, som vi forklarer nedenfor.

Tensorparallelitet

Tensorparallelitet refererer til antall GPU-enheter som brukes til å kjøre inferensserveren. Når vi tildeler et antall GPU-er, slår TensorRT-LLM ressursene deres sammen for å hjelpe oss med å nå minimumskravet til minnebudsjett for å kjøre Llama 2 70B. Hypotesen vår er at lavere tensorparallelitet vil føre til høyere ventetid (på grunn av færre ressurser som brukes for å tilfredsstille hver batch), men høyere gjennomstrømming per GPU (på grunn av bedre utnyttelse) sammenlignet med høyere tensorparallelitet.

Kvantisering

Kvantisering er reduksjonen av presisjon i vektene og aktiveringene som brukes av nevrale nettverk. Vi bruker denne teknikken for a halvere GPU-minneforbruket når vi bytter fra fp16 til fp8. Dette gjør det mulig å kjøre den samme modellen med lavere totalt GPU-minnebruk, noe som muliggjør lavere tensorparallelitet, som igjen øker gjennomstrømmingen.

Implementeringer av kvantisering har potensial til å redusere nøyaktigheten. Derfor evaluerte vi nøyaktigheten for ulike presisjoner ved å sammenligne perplexity-statistikken deres – et mål på hvor godt LLM-en forutsier hvert neste token i en setning – på WikiText-korpuset. For 8-bits flyttall og 8-bits vekt med 8-bits aktivering og SmoothQuant (w8a8 SQ) var det ingen vesentlig endring i perplexity (< 1 %) sammenlignet med fp16 på WikiText, så vi følte oss trygge på å gå videre. Imidlertid viste w4a16 en betydelig endring på 7 % i perplexity, noe som potensielt kan tilskrives den enda lavere presisjonen og nødvendige dynamiske konverteringer mellom int4 og fp16.

Batchstørrelse

Parallelisme via batching er en klassisk strategi for å presse ytelse ut av et ressursbegrenset system. Ved å behandle flere forespørsler i hver framover-passering gjennom det neurale nettverket, er det kjent at batching øker gjennomstrømmingen på bekostning av noe ventetid. Batching medfører også høyere GPU-minneforbruk fordi størrelsen på KV-mellomlageret som administrerer oppmerksomhetsmekanismen, vokser lineært med batchstørrelsen.

Forstørr

Når det gjelder Llama 2 70B (som har 80 lag), fp16 med batchstørrelse 32 for 4096 kontekststørrelse, blir størrelsen på KV-mellomlageret hele 40 GB. Dette ender opp med å hindre at Llama 2 70B fp16, der vektene alene tar opp 140 GB, komfortabelt får plass i det 160 GB store GPU-minnet som er tilgjengelig ved tensorparallelitet 2 (TP-2).

Resultater

Vi gikk gjennom kompatible kombinasjoner av de 4 variablene i eksperimentet og presenterer de mest innsiktsfulle trendene nedenfor.

Forstørr

Forbedringen i ventetid fra kvantisering er i størrelsesorden 10 % når man sammenligner H100 fp16 → fp8 og A100 fp16 → w8a8 med SmoothQuant. Imidlertid presterer den blandede presisjonen w4a16 faktisk bedre ved lave batchstørrelser og verre ved høyere batchstørrelser sammenlignet med fp16. Dette kan skyldes en rekke faktorer, inkludert mindre optimaliserte beregningskjerner, casting-tid mellom int4 og fp16, og det faktum at w4a16 fortsatt bruker 16-bits flyttall for aktiveringer, noe som ikke gir noen besparelser i dimensjonene til KV-mellomlageret. Ettersom w4a16 også viste lavere nøyaktighet, konkluderer vi med at vi bør holde oss til w8a8 SQ for A100-er og fp8 for H100-er.

Forstørr

I de to første figurene presenterer vi kun konfigurasjoner for TP-8. H100 oppnår 54 % ventetid og 184 % gjennomstrømming sammenlignet med A100 når begge bruker fp16 / BS-128 / TP-8, noe som forbedres til 49 % ventetid og 202 % gjennomstrømming når du bruker fp8 på H100. Denne ytelsesforbedringen kan tilskrives økningen i beregningskraft og minnebåndbredde mellom H100 og A100. Det er verdt å merke seg at forskjellen er mindre utpreget ved lavere batchstørrelser der utnyttelsen kan være lavere.

Når vi bygger plattformen vår, ønsker vi å overholde visse krav til ventetid for brukerne våre samtidig som vi maksimerer gjennomstrømmingen. Derfor gir det mer mening for oss å sammenligne gjennomstrømmingen deres under konfigurasjoner der de oppfyller et krav til ventetid, i stedet for å sammenligne A100 vs. H100 ved samme batchstørrelse. Vi satte en grense på 25600 ms ventetid for fullføring av de 512 utdatatokenene og fant ut at H100 / TP-8 / fp8 / BS-128 gir 251 % gjennomstrømming sammenlignet med A100 / TP-8 / fp16 / BS-64, siden den er i stand til å behandle dobbel batchstørrelse ved en lavere ventetid. Gitt at kvantisering gir besparelser i GPU-minne, må vi nå evaluere hvordan tensorparallelitet kan legge til et nytt lag med optimalisering.

Forstørr

Når det gjelder kvantisering og arkitektur, er det klare vinnere: H100 dominerer A100, og kvantisering med redusert presisjon forbedrer minneutnyttelse, ventetid og gjennomstrømming. Imidlertid representerer batchstørrelse og tensorparallelitet en avveining i nøkkelmetrikkene våre. En større batchstørrelse optimaliserer for gjennomstrømming på bekostning av økt ventetid og minneforbruk. På den annen side øker høyere tensorparallelitet den totale potten av tilgjengelig minne og optimaliserer for ventetid, men gir en avveining med gjennomstrømming på grunn av synkroniseringskostnader ved distribuert matrisemultiplikasjon og ved at flere GPU-ressurser bindes opp.

Forstørr

Den gjennomstrømmingsmaksimerende konfigurasjonen i eksperimentet vårt er H100 / fp8 / TP-2 / BS-128, med 767 utdatatokener per sekund per GPU. Dette er en 460 % forbedring over A100 / fp16 / TP-8 / BS-64. Det kommer imidlertid til prisen av doblet ventetid – nærmere 42000 ms for 512 utdatatokener – så den egner seg kanskje ikke som en produksjonskonfigurasjon. Resultatene for TP-4 BS-128 (626 tok/sek/gpu ved 26188 ms svartid) og TP-2 BS-32 (435 tok/sek/gpu ved 18821 ms svartid) kan representere bedre avveininger for nøkkelmetrikkene våre.

Konklusjon

Resultatene våre viser at:

Vi oppnår 54 % ventetid og 184 % gjennomstrømming ved å bruke H100 sammenlignet med A100 gitt den samme konfigurasjonen, noe som forbedres til henholdsvis 49 % og 202 % når H100 utnytter sin innebygde støtte for fp8.

Når man maksimerer gjennomstrømmingen underlagt et krav om ventetid, gir H100 / fp8 / TP-8 / BS-128 251 % gjennomstrømming sammenlignet med A100 / fp16 / TP-8 / BS-64, siden den kan behandle dobbel batch med raskere hastighet.

Ved å utnytte H100 med TP-2 med fp8 kan vi oppnå 373 % av gjennomstrømmingen til A100 / fp16 / TP-8 / BS-128, med en økning i ventetid på under 10 %.

Batchstørrelse og tensorparallelitet representerer en avveining mellom gjennomstrømming og ventetid for operatøren av et LLM-inferenssystem.

Disse resultatene gjør oss trygge på en fullstendig overgang til H100-GPUer i vår tidligere A100-drevne maskinvarestabel. Vi er glade for å kunne bekrefte ytelsesgevinstene som annonseres av NVIDIA, og ser fram til deres neste gjennombrudd innen akselerert maskinvare.

Hva som skjer videre

Vår neste grense for optimalisering er å undersøke nøyaktigheten og ytelseseffekten av strukturert sparsommelighet og int4-presisjon, noe som kan redusere Llama 2 70B sitt GPU-minneavtrykk betraktelig og gi opptil 2x forbedring i ventetid. Vi er glade for å fortsette reisen med lynrask inferens og håper å styrke brukerne våre i å bygge kraftige applikasjoner på toppen av plattformen vår.

På kort sikt vil pplx-api fjerne hastighetsbegrensninger og tilby flere tilpassede Perplexity LLM-er, inkludert en internettdrevet LLM med forankring for fakta.

Registrer deg for Perplexity Pro på perplexity.ai/pro. Få tilgang til vår banebrytende pplx-api, og utnytt disse avanserte funksjonene i prosjektene dine. Oppdag mer om pplx-api på bloggen vår.

Er du interessert i å forme framtiden for KI? Vi ansetter! Bli en del av et team som driver massiv, generativ LLM-infrastruktur. Utforsk mulighetne på Perplexity Careers.

Forfattere:

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats