Llama 2 70B kiirendamine NVIDIA H100-ga

Jõudluse tagaajamine Perplexity vastusemootoris sunnib meid kasutama uusimat tehnoloogiat, mida NVIDIA ja AWS-il on pakkuda. Selles ajaveebis jagame hea meelega oma viimaste katsete tulemusi: Llama 2 70B järeldamise võrdlust erinevates riist- ja tarkvaraseadetes.

Meie LLM-i järeldusplatvorm pplx-api põhineb tipptasemel tarkvaravirnal, mis kasutab avatud lähtekoodiga teeke. Alates ajast, mil pplx-api avalik beetaversioon oktoobris algas, oleme tegelenud mastaapsuse probleemidega ja õppinud, kuidas oma konfiguratsiooni massilise mastaabi saavutamiseks kõige paremini häälestada. See viis meid katsete läbiviimiseni järgmiste juhtküsimustega:

Milline on toorjõudluse kasv, kui vahetame oma GPU-d NVIDIA A100-lt NVIDIA H100 vastu, kusjuures kõik muud sätted jäävad samaks?

Milline on 8-bitise ujukoma (fp8) kvantimise tõhususe kasv, millele H100 lisab omapärase toe? Milline on selle kvantimise täpsuskulu?

Kuidas tensorite paralleelsus ja pakettide suurus mõjutavad latentsust ja tokenite läbilaskevõimet?

Võttes arvesse ülaltoodut, milline konfiguratsioon tagab jõudluse ja kulutõhususe kõige skaleeritavama tasakaalu?

Võrgu latentsuse vältimiseks viisime järgmise katse läbi kohalike võrdlustestide seeriana.

Latentsus: Koguaeg, mis kulub järeldusserveril täieliku vastuse genereerimiseks.

Läbilaskevõime: Väljundtokenite arv sekundis GPU kohta, mida järeldusserver suudab genereerida kõigi kasutajate ja päringute lõikes.

Järgmised tegurid mõjutavad põhimõõdikuid, mistõttu hoidsime need katse erinevates katsetes muutumatuna.

Jõudlus skaleerub koos LLM-i suurusega. Rohkem parameetreid nõuab rohkem arvutusi, mille tulemuseks on aeglasem järeldamine. Näiteks on Llama 2 13B kiirem kui Llama 2 70B, kui muud sätted on võrdsed. Jääme selles eksperimendis Llama 2 70B juurde, kuna soovime optimeerida kõige võimekamate avatud lähtekoodiga mudelite teenindamist.

Sisend- ja väljundtokenite hulk igas näidispäringu/vastuse paaris võib mõjutada jõudlusmõõdikuid. Üldiselt domineerib väljundtokenite genereerimine üldist vastuseaega. Kui andmete valimine kutsub LLM-ilt esile ainult „jah/ei“ vastuseid, on vastus kiirem võrreldes näidistega, mis paluvad LLM-il esseesid kirjutada. Meie andmestik koosneb sünteetilistest päringutest 1024 sisendtokeniga, mis kutsuvad esile 512 väljundtokenit. See jaotus valiti nii, et see vastaks Llama 2 70B avalikul juurutusel täheldatud liiklusjaotusele.

NVIDIA TensorRT-LLM (väljalase v0.5.0) on avatud lähtekoodiga teek LLM-i järeldamise optimeerimiseks. 2023. aasta lõpus välja antud see sünteesib NVIDIA paljud järelduste optimeerimised ja pakub paindliku kohandamiskihi selle katse peamiste parameetrite jaoks: paketi suurus, kvantimine ja tensorite paralleelsus.

Katsetasime neljas konfiguratsiooniteljes: tensorite paralleelsus, GPU arhitektuur, kvantimine ja maksimaalne paketi suurus. Need teljed on omavahel seotud, kuna igaüks neist esindab kompromissi seoses GPU mälu kriitilise kitsaskoha ressursiga.

Üheksanda põlvkonna Hopperi (H100-HBM3-80GB / p5.48xlarge) GPU arhitektuur sisaldab tohutut loendit funktsioone võrreldes eelkäija Ampere'iga (A100-SXM4-80GB / p4de.24xlarge), sealhulgas 2x–6x arvutuskiirust ja peaaegu 2x GPU mälu ribalaiust. GPU mälu ribalaius on järeldamise jaoks kriitiline mõõdik, kuna järelduse maatrikskorrutiste peamine latentsuse kitsaskoht tuleneb gigabaitide mudeliandmete laadimisest GPU mälust arvutusregistritesse. Nende statistiliste andmete põhjal eeldasime, et NVIDIA H100 ja A100 võrdlus näitab 2-kordset paranemist nii latentsuses kui ka läbilaskevõimes.

Teine oluline erinevus NVIDIA H100 ja A100 vahel on see, et H100 tensortuum lisab omapärase toe 8-bitise ujukoma (fp8) käskudele, mis avab ukse täiendavateks optimeerimisteks, mida on kirjeldatud allpool. Seetõttu kasutame fp8-t ja fp16-t spetsiaalselt H100 jaoks.

Selle katse ajal GPU-põhise mälu ühtlasena hoidmiseks pidasime kinni sõlmedest, millel on 8x80GB GPU mälu nii meie NVIDIA A100 kui ka H100 jaoks. Lisaks suuremate pakettide suuruste võimaldamisele on GPU mälu oluline seetõttu, et mudeli parameetrid laaditakse kiireks juurdepääsuks serveri käivitamisel GPU mällu. Näiteks kui iga meie mudeli 70 miljardist parameetrist on 16-bitine ujukomaarv, on mudeli suurus umbes 140 GB, mis ei mahu ühele GPU-le. Siit ka vajadus tensorite paralleelsuse järele, mida selgitame allpool.

Tensorite paralleelsus viitab järeldusserveri käitamiseks kasutatavate GPU-seadmete arvule. Kui eraldame teatud arvu GPU-sid, koondab TensorRT-LLM nende ressursid kokku, et aidata meil saavutada Llama 2 70B käitamiseks vajalik minimaalne mälumaht. Meie hüpotees on, et väiksem tensorite paralleelsus toob kaasa suurema latentsuse (iga paketi rahuldamiseks kuluvate vähemate ressursside tõttu), kuid suurema läbilaskevõime GPU kohta (parema kasutusaste tõttu), võrreldes suurema tensorite paralleelsusega.

Kvantimine on närvivõrkude kasutatavate kaalude ja aktiveeringute täpsuse vähendamine. Kasutame seda tehnikat GPU mälutarbimise poole võrra vähendamiseks, kui läheme üle fp16-lt fp8-le. See võimaldab käitada sama mudelit väiksema GPU mälukasutusega, võimaldades madalamat tensorite paralleelsust, mis suurendab läbilaskevõimet.

Kvantimise rakendustel on potentsiaal täpsust halvendada. Seetõttu hindasime erinevate täpsuste täpsust, võrreldes nende segaduse (perplexity) statistikat – mõõdikut selle kohta, kui hästi LLM ennustab lauses iga järgmist tokenit WikiTexti korpuse põhjal. 8-bitise ujukoma ja 8-bitise kaalu puhul koos 8-bitise aktiveerimise ja SmoothQuantiga (w8a8 SQ) ei toimunud WikiTextis võrreldes fp16-ga olulist muutust segaduses (< 1%), nii et tundsime end enesekindlalt, et jätkata. Kuid w4a16 näitas olulist 7% muutust segaduses, mis võib olla tingitud veelgi madalamast täpsusest ja vajalikest dünaamilistest teisendustest int4 ja fp16 vahel.

Pakettide töötlemise kaudu toimuv paralleelsus on klassikaline strateegia ressursipiiranguga süsteemist jõudluse väljapressimiseks. Töötlemisel mitu päringut igas edasisuunalises läbimises läbi närvivõrgu, on pakettide töötlemine tuntud selle poolest, et see suurendab läbilaskevõimet teatud latentsuse hinnaga. Pakettide töötlemine põhjustab ka suuremat GPU mälutarbimist, kuna tähelepanumehhanismi haldava KV-vahemälu suurus kasvab lineaarselt paketi suurusega.

Llama 2 70B puhul (millel on 80 kihti), fp16 paketi suurusega 32 4096 kontekstisuuruse jaoks, on KV-vahemälu suurus märkimisväärne 40 GB. See takistab Llama 2 70B fp16, mille ainuüksi kaalud võtavad 140 GB, mugavalt mahumast 160 GB GPU mällu, mis on saadaval tensorite paralleelsuse 2 (TP-2) korral.

Vaatasime läbi katse 4 muutuja ühilduvad kombinatsioonid ja esitame allpool kõige sisukamad suundumused.

Joonis 1 – Erineva paketi suurusega päringute latentsus viies erinevas konfiguratsioonis, kõik tensorite paralleelsusega 8, mis annab parima latentsuse 8 saadaoleva GPU-ga. Igas konfiguratsioonis kahekordistub latentsus üldiselt paketi suuruse suurendamisel 1-lt → 32-le ja kahekordistub uuesti 32-lt → 128-le. Piisavalt suurte pakettide suuruste korral vähendab H100 latentsust A100-ga võrreldes ligikaudu poole võrra. A100 kasutab segatäpsust, kuna arhitektuuril puudub omane tugi fp8 jaoks. w8a8 koos SmoothQuantiga (SQ) on mõeldud meenutama fp8-t.

Kvantimise latentsuse paranemine on umbes 10%, kui võrrelda H100 fp16 → fp8 ja A100 fp16 → w8a8 SmoothQuantiga. Kuid segatäpsusega w4a16 toimib tegelikult paremini väikeste pakettide suuruste juures ja halvemini suuremate pakettide suuruste juures võrreldes fp16-ga. See võib olla tingitud mitmest tegurist, sealhulgas vähem optimeeritud arvutustuumadest, valamise ajast int4 ja fp16 vahel ning asjaolust, et w4a16 kasutab aktiveerimiste jaoks endiselt 16-bitiseid ujukomaarve, mille tulemuseks pole kokkuhoidu KV-vahemälu mõõtmetes. Kuna w4a16 näitas ka madalamat täpsust, järeldame, et peaksime A100 puhul jääma w8a8 SQ ja H100 puhul fp8 juurde.

Joonis 2 – Läbilaskevõime TP-8 konfiguratsioonides erineva arhitektuuri, kvantimise ja paketi suurusega. Iga arhitektuuri ja kvantimise jaoks valiti paketi suuruseks suurim, mis vastas latentsusnõudele 25600ms (20 tokenit sekundis 512 tokeni kohta), et saaksime võrrelda sarnase latentsusega konfiguratsioone. Selle nõude kohaselt saavutab H100 BS-128-ga 228% läbilaskevõime võrreldes A100 BS-64-ga, mis kasutab sama kvantimist (fp16), ja sellel on isegi madalam vastuse latentsus vaatamata kahekordistunud paketi suurusele. Kvantimine fp8-ga parandab selle teguri 251%-ni.

Oma esimeses kahes joonises esitame ainult TP-8 konfiguratsioone. H100 saavutab 54% latentsuse ja 184% läbilaskevõime võrreldes A100-ga, kui mõlemad kasutavad fp16 / BS-128 / TP-8, mis paraneb väärtusteni 49% latentsus ja 202% läbilaskevõime, kui kasutatakse fp8-t H100-l. Seda jõudluse paranemist võib seostada arvutusvõimsuse ja mälu ribalaiuse suurenemisega H100 ja A100 vahel. Eriti on erinevus vähem väljendunud väiksemate pakettide suuruste korral, kus kasutusaste võib olla madalam.

Platvormi ehitamisel soovime austada teatud latentsusnõudeid oma kasutajatele, maksimeerides samal ajal läbilaskevõimet. Seega, selle asemel et võrrelda A100 vs. H100 sama paketi suuruse juures, on meie jaoks tegelikult mõttekam võrrelda nende läbilaskevõimet ainult konfiguratsioonides, kus nad täidavad latentsusnõuet. Seadsime 512 väljundtokeni täitmise latentsuse piiriks 25600ms ja leidsime, et H100 / TP-8 / fp8 / BS-128 annab 251% läbilaskevõime võrreldes A100 / TP-8 / fp16 / BS-64-ga, kuna see suudab töödelda kahekordset paketi suurust madalama latentsusega. Arvestades, et kvantimine tagab GPU mälu kokkuhoiu, peame nüüd hindama, kuidas tensorite paralleelsus võib lisada järgmise optimeerimiskihi.

Joonis 3 – Latentsus erinevate pakettide suuruste ja tensorite paralleelsuse korral H100 fp8 jaoks. Latentsus kahekordistub üldiselt paketi suuruse suurendamisel 1-lt → 32-le ja kahekordistub uuesti 32-lt → 128-le. TP-2 on võrdsete pakettide suuruste korral pidevalt umbes kaks korda aeglasem kui TP-8. Tensorite paralleelsuse kahekordistamine paketi suuruse kahekordistamisega hoiab latentsuse suhteliselt stabiilsena, kuna GPU-de kohta töödeldud pakettide arv jääb samaks.

Kvantimise ja arhitektuuri osas on selged võitjad: H100 domineerib A100 üle ja madalama täpsusega kvantimine parandab mälukasutust, latentsust ja läbilaskevõimet. Kuid paketi suurus ja tensorite paralleelsus kujutavad endast kompromissi meie põhimõõdikutes. Suurem paketi suurus optimeerib läbilaskevõimet suurenenud latentsuse ja mälutarbimise hinnaga. Teisest küljest suurendab kõrgem tensorite paralleelsus saadaoleva mälu kogubasseini ja optimeerib latentsust, kuid teeb kompromissi läbilaskevõimega hajutatud maatrikskorrutise sünkroonimiskulude ja rohkemate GPU ressursside hõivamise tõttu.

Joonis 4 – Läbilaskevõime erinevate pakettide suuruste ja tensorite paralleelsuse korral H100 fp8 jaoks. Suurim läbilaskevõime pärineb TP-2 BS-128-lt, mis on 460% võrreldes A100/TP-8/fp16/BS-64 baastasemega. Kuid TP-2 BS-128 on ka joonisel 3 aeglaseim tulemus.

Meie katse läbilaskevõimet maksimeeriv konfiguratsioon on H100 / fp8 / TP-2 / BS-128, kiirusega 767 väljundtokenit sekundis GPU kohta. See on 460% paranemine võrreldes A100 / fp16 / TP-8 / BS-64-ga. Kuid see toimub kahekordistunud latentsuse hinnaga – lähemal 42000ms-le 512 väljundtokeni puhul –, mistõttu ei pruugi see tootmiskonfiguratsioonina sobida. TP-4 BS-128 (626 tok/sec/gpu 26188ms vastuseajaga) ja TP-2 BS-32 (435 tok/sec/gpu 18821ms vastuseajaga) tulemused võivad esindada paremaid kompromisse meie põhimõõdikutes.

Meie tulemused näitavad, et:

Saavutame 54% latentsuse ja 184% läbilaskevõime H100 abil võrreldes A100-ga samas konfiguratsioonis, mis paraneb vastavalt 49%-ni ja 202%-ni, kui H100 kasutab ära oma omase toe fp8 jaoks.

Maksimeerides läbilaskevõimet latentsuspiirangu tingimustes, annab H100 / fp8 / TP-8 / BS-128 251% läbilaskevõime võrreldes A100 / fp16 / TP-8 / BS-64-ga, kuna see suudab topeltpaketti kiirema kiirusega töödelda.

Kasutades H100 koos TP-2 ja fp8-ga, saame saavutada 373% A100 / fp16 / TP-8 / BS-128 läbilaskevõimest, kusjuures latentsus suureneb vähem kui 10%.

Paketi suurus ja tensorite paralleelsus kujutavad LLM-i järeldussüsteemi operaatori jaoks endast kompromissi läbilaskevõime ja latentsuse vahel.

Need tulemused annavad meile kindlustunde täielikuks üleminekuks H100 GPU-dele meie varem A100-l põhinevas riistvaravirnas. Meil on hea meel kinnitada NVIDIA reklaamitud jõudluse kasvu ja ootame nende järgmisi läbimurdeid kiirendatud riistvaras.

Meie järgmine optimeerimise piir on struktureeritud hõreduse ja int4 täpsuse täpsuse ja jõudluse mõju uurimine, mis voiks oluliselt vähendada Llama 2 70B GPU mälujalajälge ja tuua kuni 2-kordse paranemise latentsuses. Meil on hea meel jätkata ülikiire järeldamise teekonda ja loodame anda oma kasutajatele võimaluse ehitada meie platvormi peale võimsaid rakendusi.

Lähiajal eemaldab pplx-api kiiruspiirangud ja pakub rohkem kohandatud Perplexity LLM-e, sealhulgas internetipõhist LLM-i faktide maandamisega.

Registreeruge Perplexity Pro kasutajaks aadressil perplexity.ai/pro. Saate juurdepääsu meie tipptasemel pplx-apile ja saate neid täiustatud võimalusi oma projektides rakendada. Avastage pplx-api kohta lisateavet meie ajaveebist.

Kas olete huvitatud AI tuleviku kujundamisest? Me värbame! Saage osaks meeskonnast, mis juhib massilises mastaabis generatiivse LLM-i infrastruktuuri. Avastage võimalusi Perplexity Careers lehel.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Katse ülesehitus

Põhimõõdikud:

Konstandid:

AI-mudel

Sisend-/väljundtokenite andmestik

Tarkvara versioon

Muutujad

GPU arhitektuur

Tensorite paralleelsus

Kvantimine

Paketi suurus

Tulemused

Kokkuvõte

Mis järgmiseks

Autorid: