Zrýchlenie Llama 2 70B pomocou NVIDIA H100

Cesta akcelerovanej inferencie LLM

The journey of accelerated LLM inference

Snaha o maximálny výkon v odpovedovom motore Perplexity nás vedie k využívaniu najnovších technológií, ktoré NVIDIA a AWS ponúkajú. V tomto blogu s radosťou zdieľame výsledky našich najnovších experimentov: porovnanie inferencie modelu Llama 2 70B v rôznych hardvérových a softvérových nastaveniach.

Naša platforma pre inferenciu LLM, pplx-api, je postavená na špičkovom zásobníku poháňanom open-source knižnicami. Od začiatku verejnej bety pplx-api v októbri sme riešili problémy so škálovaním a učili sa, ako najlepšie ladiť našu konfiguráciu na dosiahnutie masívneho škálovania. To nás viedlo k spusteniu experimentov s nasledujúcimi hlavnými otázkami:

Aké je priame zvýšenie výkonu pri prechode našich GPU z NVIDIA A100 na NVIDIA H100, pričom všetky ostatné nastavenia zostávajú nezmenené?

Aké je zvýšenie efektivity 8-bitovej kvantizácie s plávacou rádovou čiarkou (fp8), pre ktorú H100 pridáva natívnu podporu? Aká je daň za túto kvantizáciu z hľadiska presnosti?

Ako tenzorový paralelizmus a veľkosť dávky ovplyvňujú latenciu a priepustnosť tokenov?

S ohľadom na vyššie uvedené, ktorá konfigurácia prináša najlepšie škálovateľnú rovnováhu medzi výkonom a nákladovou efektívnosťou?

Experimentálne nastavenie

Nasledujúci experiment sme spustili ako sériu lokálnych benchmarkov, aby sme sa vyhli sieťovej latencii.

Kľúčové metriky:

Latencia: Celkový čas, ktorý inferenčný server potrebuje na vygenerovanie kompletnej odpovede.

Priepustnosť: Počet výstupných tokenov za sekundu na jedno GPU, ktoré vie inferenčný server vygenerovať naprieč všetkými používateľmi a požiadavkami.

Konštanty:

Nasledujúce faktory by ovplyvnili kľúčové metriky, preto sme ich udržiavali konzistentné v rôznych pokusoch experimentu.

Model AI

Výkon sa škáluje s veľkosťou LLM. Viac parametrov vyžaduje viac výpočtov, čoho výsledkom je pomalšia inferencia. Napríklad Llama 2 13B je rýchlejšia ako Llama 2 70B, ak sú ostatné nastavenia rovnaké. V tomto experimente sa držíme Llama 2 70B, pretože chceme optimalizovať poskytovanie tých najschopnejších open-source modelov.

Dátová sada vstupných/výstupných tokenov

Množstvo vstupných a výstupných tokenov v každom páre požiadavka/odpoveď môže ovplyvniť merania výkonu. Generovanie výstupných tokenov vo všeobecnosti dominuje celkovému času odozvy. Keď vzorkovanie údajov vyvoláva od LLM iba odpovede „áno/nie“, odpoveď je rýchlejšia v porovnaní so vzorkami, ktoré od LLM vyžadujú písanie esejí. Naša dátová sada sa skladá zo syntetických požiadaviek s 1024 vstupnými tokenmi vyvolávajúcimi 512 výstupných tokenov. Toto rozdelenie bolo zvolené tak, aby zodpovedalo pozorovanému rozdeleniu prevádzky na našom verejnom nasadení modelu Llama 2 70B.

Verzia softvéru

NVIDIA TensorRT-LLM (vydanie v0.5.0) je open-source knižnica na optimalizáciu inferencie LLM. Bola vydaná koncom roku 2023, syntetizuje mnohé inferenčné optimalizácie od NVIDIA a poskytuje flexibilnú vrstvu prispôsobenia pre kľúčové parametre tohto experimentu: veľkosť dávky, kvantizáciu a tenzorový paralelizmus.

Premenné

Experimentovali sme so 4 osami konfigurácie: tenzorový paralelizmus, architektúra GPU, kvantizácia a maximálna veľkosť dávky. Tieto osi sú prepojené, pretože každá z nich predstavuje kompromis vzhľadom na kritický úzky profil zdrojov – pamäť GPU.

Architektúra GPU

Architektúra GPU Hopper deviatej generácie (H100-HBM3-80GB / p5.48xlarge) prináša oproti svojmu predchodcovi Ampere (A100-SXM4-80GB / p4de.24xlarge) obrovské množstvo funkcií vrátane 2x až 6x vyššej výpočtovej rýchlosti a takmer 2x väčšej šírky pásma pamäte GPU. Šírka pásma pamäte GPU je kritickou metrikou pre inferenciu, pretože primárne úzke hrdlo latencie maticového násobenia pri inferencii pochádza z načítavania gigabajtov údajov modelu z pamäte GPU do výpočtových registrov. Na základe týchto štatistík sme predpokladali, že priame porovnanie NVIDIA H100 a A100 vykáže dvojnásobné zlepšenie latencie aj priepustnosti.

Ďalším kľúčovým rozdielom medzi NVIDIA H100 a A100 je, že tenzorové jadro H100 natívne pridáva podporu pre 8-bitové inštrukcie s plávacou rádovou čiarkou (fp8), čo otvára dvere k ďalším optimalizáciám podrobne opísaným nižšie. Preto používame fp8 a fp16 špecificky pre H100.

Aby sme v tomto experimente udržali pamäť na jedno GPU konzistentnú, držali sme sa uzlov s 8x 80GB pamäťou GPU pre naše NVIDIA A100 aj H100. Okrem umožnenia väčších dávok je pamäť GPU dôležitá, pretože parametre modelu sa počas spúšťania servera načítavajú do pamäte GPU na rýchly prístup. Ak má napríklad každý zo 70 miliárd parametrov v našom modeli podobu 16-bitového čísla s plávacou rádovou čiarkou, model má veľkosť približne 140 GB, čo sa nezmestí na jediné GPU. Odtiaľ pramení potreba tenzorového paralelizmu, ktorý vysvetľujeme nižšie.

Tenzorový paralelizmus

Tenzorový paralelizmus označuje počet zariadení GPU spotrebovaných na spustenie inferenčného servera. Keď priradíme určitý počet GPU, TensorRT-LLM spojí ich zdroje dohromady, aby nám pomohla dosiahnuť minimálny požadovaný pamäťový rozpočet na spustenie Llama 2 70B. Naša hypotéza hovorí, že nižší tenzorový paralelizmus bude mať za následok vyššiu latenciu (v dôsledku menšieho počtu spotrebovaných zdrojov na splnenie každej dávky), ale vyššiu priepustnosť na jedno GPU (v dôsledku lepšieho využitia) v porovnaní s vyšším tenzorovým paralelizmom.

Kvantizácia

Kvantizácia je zníženie presnosti váh a aktivácií používaných neurónovými sieťami. Túto techniku používame na zníženie spotreby pamäte GPU na polovicu pri prechode z fp16 na fp8. To umožňuje spustiť rovnaký model s nižším celkovým využitím pamäte GPU, čo umožňuje nižší tenzorový paralelizmus, ktorý zvyšuje priepustnosť.

Implementácie kvantizácie môžu zhoršiť presnosť. Preto sme vyhodnotili presnosť pre rôzne presnosti porovnaním ich štatistiky perplexity (miery toho, ako dobre LLM predikuje každý nasledujúci token vo vete) v korpuse WikiText. V prípade 8-bitovej plávajúcej rádovej čiarky a 8-bitovej váhy s 8-bitovou aktiváciou a SmoothQuant (w8a8 SQ) nedošlo k žiadnej významnej zmene perplexity (< 1 %) v porovnaní s fp16 na WikiText, takže sme sa cítili iste pokračovať. Avšak w4a16 vykazoval podstatnú 7% zmenu perplexity, čo je pravdepodobne pripísateľné ešte nižšej presnosti a potrebným dynamickým konverziám medzi int4 a fp16.

Veľkosť dávky

Paralelizácia prostredníctvom dávkovania je klasická stratégia na získanie výkonu zo systému obmedzeného zdrojmi. Je známe, že dávkovanie spracovaním viacerých požiadaviek v každom prechode dopredu neurónovou sieťou zvyšuje priepustnosť za cenu určitej latencie. Dávkovanie tiež spôsobuje vyššiu spotrebu pamäte GPU, pretože veľkosť KV vyrovnávacej pamäte, ktorá spravuje mechanizmus pozornosti, rastie lineárne s veľkosťou dávky.

V prípade Llama 2 70B (ktorá má 80 vrstiev), fp16 s veľkosťou dávky 32 pre veľkosť kontextu 4096, dosahuje veľkosť KV vyrovnávacej pamäte úctyhodných 40 GB. To nakoniec bráni tomu, aby sa Llama 2 70B fp16, ktorej samotné váhy zaberajú 140 GB, pohodlne zmestila do 160 GB pamäte GPU dostupnej pri tenzorovom paralelizme 2 (TP-2).

Výsledky

Prešli sme kompatibilné kombinácie 4 premenných experimentu a nižšie uvádzame najinikatívnejšie trendy.

Obrázok 1 – Latencia požiadaviek s rôznou veľkosťou dávky naprieč piatimi rôznymi konfiguráciami, všetky s tenzorovým paralelizmom 8, ktorý prináša najlepšiu latenciu s 8 dostupnými GPU. V rámci každej konfigurácie sa latencia vo všeobecnosti zdvojnásobí pri zvýšení veľkosti dávky z 1 → 32 a opäť sa zdvojnásobí z 32 → 128. Pri dostatočne veľkých veľkostiach dávok H100 približne na polovicu znižuje latenciu v porovnaní s A100. A100 používa zmiešanú presnosť, pretože architektúra postráda natívnu podporu pre fp8. w8a8 so SmoothQuant (SQ) má pripomínať fp8.

Zlepšenie latencie pri kvantizácii sa pohybuje okolo 10 % pri porovnaní H100 fp16 → fp8 a A100 fp16 → w8a8 so SmoothQuant. Avšak zmiešaná presnosť w4a16 v skutočnosti funguje lepšie pri nízkych veľkostiach dávok a horšie pri vyšších veľkostiach dávok v porovnaní s fp16. To môže byť spôsobené viacerými faktormi vrátane menej optimalizovaných výpočtových jadier, času pretypovania medzi int4 a fp16 a skutočnosti, že w4a16 stále používa 16-bitové plávajúce rádové čiarky pre aktivácie, čo neprináša žiadne úspory v rozmeroch KV vyrovnávacej pamäte. Keďže w4a16 preukázal aj nižšiu presnosť, usudzujeme, že by sme sa mali držať w8a8 SQ pre A100 a fp8 pre H100.

Obrázok 2 – Priepustnosť naprieč konfiguráciami TP-8 s rôznou architektúrou, kvantizáciou a veľkosťou dávky. Pre každú architektúru a kvantizáciu bola veľkosť dávky zvolená ako najväčšia, ktorá splnila požiadavku na latenciu 25 600 ms (20 tokenov za sekundu pre 512 tokenov), aby sme porovnali konfigurácie s podobnou latenciou. Za tejto požiadavky dosahuje H100 s BS-128 228 % priepustnosti v porovnaní s A100 BS-64 s použitím rovnakej kvantizácie (fp16) a dokonca má nižšiu latenciu odozvy napriek zdvojnásobenej veľkosti dávky. Kvantizácia s fp8 zvyšuje tento faktor na 251 %.

V našich prvých dvoch obrázkoch prezentujeme iba konfigurácie TP-8. H100 dosahuje 54 % latencie a 184 % priepustnosti v porovnaní s A100, keď obe používajú fp16 / BS-128 / TP-8, čo sa zlepší na 49 % latencie a 202 % priepustnosti pri použití fp8 na H100. Toto zlepšenie výkonu možno pripísať zvýšeniu výpočtového výkonu a šírky pásma pamäte medzi H100 a A100. Pozoruhodné je, že rozdiel je menej výrazný pri nižších veľkostiach dávok, kde môže byť využitie nižšie.

Keď budujeme našu platformu, chceme dodržať určité požiadavky na latenciu pre našich používateľov a zároveň maximalizovať priepustnosť. Preto namiesto porovnávania A100 vs. H100 pri rovnakej veľkosti dávky dáva pre nás väčší zmysel porovnávať ich priepustnosť iba v konfiguráciách, kde spĺňajú požiadavku na latenciu. Stanovili sme hranicu latencie na 25 600 ms pre dokončenie 512 výstupných tokenov a zistili sme, že H100 / TP-8 / fp8 / BS-128 prináša 251 % priepustnosti v porovnaní s A100 / TP-8 / fp16 / BS-64, pretože dokáže spracovať dvojnásobnú veľkosť dávky pri nižšej latencii. Vzhľadom na to, že kvantizácia poskytuje úsporu pamäte GPU, musíme teraz vyhodnotiť, ako môže tenzorový paralelizmus pridať ďalšiu vrstvu optimalizácie.

Obrázok 3 – Latencia naprieč rôznymi veľkosťami dávok a tenzorovým paralelizmom pre H100 fp8. Latencia sa vo všeobecnosti zdvojnásobí pri zvýšení veľkosti dávky z 1 → 32 a opäť sa zdvojnásobí z 32 → 128. TP-2 je konštantne približne dvakrát pomalší ako TP-8, keď sú veľkosti dávok rovnaké. Zdvojnásobenie tenzorového paralelizmu pri súčasnom zdvojnásobení veľkosti dávky udržiava latenciu relatívne stabilnú, pretože počet dávok spracovaných na jedno GPU zostáva rovnaký.

Pokiaľ ide o kvantizáciu a architektúru, existujú jasní víťazi: H100 dominuje nad A100 a kvantizácia s nižšou presnosťou zlepšuje využitie pamäte, latenciu a priepustnosť. Avšak veľkosť dávky a tenzorový paralelizmus predstavujú kompromis v našich kľúčových metrikách. Väčšia veľkosť dávky optimalizuje priepustnosť za cenu zvýšenej latencie a spotreby pamäte. Na druhej strane, vyšší tenzorový paralelizmus zvyšuje celkový fond dostupnej pamäte a optimalizuje latenciu, ale vyvažuje to priepustnosťou v dôsledku nákladov na synchronizáciu distribuovaného maticového násobenia a viazaním viacerých zdrojov GPU.

Obrázok 4 – Priepustnosť naprieč rôznymi veľkosťami dávok a tenzorovým paralelizmom pre H100 fp8. Najvyššia priepustnosť pochádza z TP-2 BS-128, a to 460 % v porovnaní so základnou líniou A100/TP-8/fp16/BS-64. Avšak TP-2 BS-128 je zároveň najpomalším výsledkom na obrázku 3.

Konfigurácia nášho experimentu maximalizujúca priepustnosť je H100 / fp8 / TP-2 / BS-128, s 767 výstupnými tokenmi za sekundu na jedno GPU. Ide o 460% zlepšenie oproti A100 / fp16 / TP-8 / BS-64. To však je vykúpené zdvojnásobenou latenciou – blížiacou sa k 42 000 ms pre 512 výstupných tokenov –, takže nemusí byť vhodná ako výrobná konfigurácia. Výsledky TP-4 BS-128 (626 tok/s/gpu pri čase odozvy 26 188 ms) a TP-2 BS-32 (435 tok/s/gpu pri čase odozvy 18 821 ms) môžu predstavovať lepšie kompromisy pre naše kľúčové metriky.

Záver

Naše výsledky ukazujú, že:

Dosahujeme 54 % latencie a 184 % priepustnosti s použitím H100 v porovnaní s A100 pri rovnakej konfigurácii, čo sa zlepší na 49 % a 202 %, keď H100 využije svoju natívnu podporu pre fp8.

Pri maximalizácii priepustnosti s ohľadom na obmedzenie latencie poskytuje H100 / fp8 / TP-8 / BS-128 251 % priepustnosti v porovnaní s A100 / fp16 / TP-8 / BS-64, pretože dokáže spracovať dvojnásobnú dávku vyššou rýchlosťou.

Využitím H100 s TP-2 a fp8 môžeme dosiahnuť 373 % priepustnosti A100 / fp16 / TP-8 / BS-128 s nárastom latencie menším ako 10 %.

Veľkosť dávky a tenzorový paralelizmus predstavujú pre prevádzkovateľa inferenčného systému LLM kompromis medzi priepustnosťou a latenciou.

Tieto výsledky nám dávajú istotu ohľadom úplného prechodu na GPU H100 v našom hardvérovom zásobníku, ktorý bol predtým poháňaný A100. Sme nadšení, že môžeme potvrdiť zvýšenie výkonu deklarované spoločnosťou NVIDIA, a tešíme sa na ich ďalšie prelomy v oblasti akcelerovaného hardvéru.

Čo bude nasledovať

Našou ďalšou hranicou pre optimalizáciu je preskúmať vplyv štruktúrovanej redosti a presnosti int4 na presnosť a výkon, čo by mohlo výrazne znížiť stopu v pamäti GPU pre Llama 2 70B a priniesť až dvojnásobné zlepšenie latencie. Sme nadšení, že môžeme pokračovať na ceste bleskovo rýchlej inferencie a dúfame, že umožníme našim používateľom vytvárať výkonné aplikácie na našej platforme.

V blízkej budúcnosti bude pplx-api odstraňovať limity sadzieb a ponúkať viac vlastných modelov Perplexity LLM vrátane LLM poháňaného internetom s uzemnením pre fakty.

Zaregistrujte sa do Perplexity Pro na perplexity.ai/pro. Získajte prístup k našej špičkovej službe pplx-api a využite tieto pokročilé schopnosti vo svojich projektoch. Zistite viac o pplx-api na našom blogu.

Máte záujem formovať budúcnosť umelej inteligencie? Hľadáme nových ľudí! Staňte sa súčasťou tímu, ktorý poháňa generatívnu infraštruktúru LLM v masívnom meradle. Preskúmajte pracovné príležitosti na Perplexity Careers.

Autori:

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats