Llama 2 70B feltöltése NVIDIA H100-zal

A teljesítményre való törekvés a Perplexity válaszadó motorjában arra ösztönöz minket, hogy az NVIDIA és az AWS által kínált legújabb technológiákat alkalmazzuk. Ebben a blogbejegyzésben örömmel osztjuk meg legújabb kísérleteink eredményeit: a Llama 2 70B inferencia összehasonlítását különböző hardver- és szoftverbeállítások között.

Az LLM inferencia platformunk, a pplx-api, nyílt forráskódú könyvtárakon alapuló, élvonalbeli technológiai veremre épül. Amióta októberben elindult a pplx-api nyilvános béta verziója, a skálázási kihívások leküzdésén dolgozunk, és azt tanuljuk, hogyan hangoljuk legjobban a konfigurációnkat a hatalmas skálájú működés eléréséhez. Ez arra ösztönzött minket, hogy a következő vezérlő Kérdésekkel végezzünk kísérleteket:

Mekkora a nyers teljesítménynövekedés, ha a GPU-kat NVIDIA A100-ról NVIDIA H100-ra cseréljük, miközben minden egyéb beállítás változatlan marad?

Mekkora a hatékonyságnövekedése a 8 bites lebegőpontos (fp8) kvantálásnak, amelyhez a H100 natív támogatást nyújt? Mekkora a pontosságromlása ennek a kvantálásnak?

Hogyan befolyásolja a tenzorpárhuzamosság és a kötegyméret a késleltetést és a token-átviteli sebességet?

A fentieket figyelembe véve, melyik konfiguráció eredményezi a teljesítmény és a költséghatékonyság leginkább skálázható egyensúlyát?

Kísérleti beállítás

A következő kísérletet helyi benchmarkok sorozataként futtattuk a hálózati késleltetés elkerülése érdekében.

Kulcsfontosságú mutatók:

Késleltetés: Az az idő, amely alatt az inferencia szerver generálja a teljes választ.

Átviteli sebesség: Azon kimeneti tokenek száma másodpercenként és GPU-nként, amelyeket az inferencia szerver generálni tud az összes felhasználó és kérés vonatkozásában.

Állandók:

A következő tényezők befolyásolnák a kulcsfontosságú mutatókat, ezért ezeket konzisztensen tartottuk a kísérlet különböző futásai során.

MI-modell

A teljesítmény az LLM méretével skálázódik. Több paraméter több számítást igényel, ami lassabb inferenciát eredményez. Például a Llama 2 13B gyorsabb, mint a Llama 2 70B, ha a többi beállítás azonos. Ebben a kísérletben a Llama 2 70B mellett maradunk, mert a leginkább képes nyílt forráskódú modellek kiszolgálásának optimalizálására törekszünk.

Bemeneti/kimeneti token adatkészlet

Az egyes mintakérés/válasz párokban lévő bemeneti és kimeneti tokenek mennyisége befolyásolhatja a teljesítményméréseket. Általánosságban elmondható, hogy a kimeneti tokenek generálása dominálja a teljes válaszidőt. Ha a mintavételezés során az LLM csak „igen/nem” válaszokat ad, akkor a válasz gyorsabb a esszéírást kérő mintákhoz képest. Adatkészletünk 1024 bemeneti tokent tartalmazó szintetikus kérésekből áll, amelyek 512 kimeneti tokent váltanak ki. Ezt a eloszlást úgy választottuk meg, hogy illeszkedjen a Llama2 70B nyilvános üzembe helyezésünkön megfigyelt forgalom eloszlásához.

Szoftververzió

Az NVIDIA TensorRT-LLM (v0.5.0-ás kiadás) egy nyílt forráskódú könyvtár az LLM inferencia optimalizálásához. A 2023 végén megjelent szoftver szintetizálja az NVIDIA számos inferencia-optimalizálását, és rugalmas testreszabási réteget biztosít a kísérlet kulcsparamétereihez: a kötegyméret, a kvantálás és a tenzorpárhuzamosság tekintetében.

Változók

4 konfigurációs tengely mentén kísérleteztünk: tenzorpárhuzamosság, GPU-architektúra, kvantálás és maximális kötegyméret. Ezek a tengelyek összefüggnek, mivel mindegyik kompromisszumot képvisel a GPU-memória kritikus szűk keresztmetszetet jelentő erőforrásával kapcsolatban.

GPU-architektúra

A kilencedik generációs Hopper (H100-HBM3-80GB / p5.48xlarge) GPU-architektúra hatalmas funkciólistát kínál elődjéhez, az Ampere-hez (A100-SXM4-80GB / p4de.24xlarge) képest, beleértve a 2x–6x-os számítási sebességet és a közel kétszeres GPU-memória-sávszélességet. A GPU-memória-sávszélesség kritikus mutató az inferencia szempontjából, mivel az inferencia mátrixszorzásainak elsődleges késleltetési szűk keresztmetszete a modelladatok gigabájtjainak betöltéséből származik a GPU memóriájából a számítási regiszterekbe. Ezen adatok alapján feltételeztük, hogy az NVIDIA H100 és A100 közvetlen összehasonlítása kétszeres javulást mutat majd mind a késleltetés, mind az átviteli sebesség terén.

Az NVIDIA H100 és az A100 másik kulcsfontosságú különbsége, hogy a H100 tenzormagja natívan támogatja a 8 bites lebegőpontos (fp8) utasításokat, ami megnyitja az utat az alábbiakban részletezett további optimalizációk előtt. Ezért használunk fp8-at és fp16-ot kifejezetten a H100-hoz.

Annak érdekében, hogy a GPU-nkénti memória konzisztens maradjon ebben a kísérletben, 8x80 GB-os GPU-memóriával rendelkező csomókat használtunk mind az NVIDIA A100, mind a H100 esetében. A nagyobb kötegyméretek lehetővé tétele mellett a GPU-memória azért is fontos, mert a modell paraméterei a szerver indításakor betöltődnek a GPU memóriájába a gyors elérés érdekében. Ha például a modellünk mind a 70 milliárd paramétere egy 16 bites lebegőpontos szám, akkor a modell mérete körülbelül 140 GB, ami nem fér el egyetlen GPU-n sem. Ezért van szükség a tenzorpárhuzamosságra, amelyet az alábbiakban ismertetünk.

Tenzorpárhuzamosság

A tenzorpárhuzamosság az inferencia szerver futtatásához felhasznált GPU-eszközök számára utal. Amikor lefoglalunk egy bizonyos számú GPU-t, a TensorRT-LLM összefogja az erőforrásaikat, hogy elérjük a Llama2 70B futtatásához szükséges minimális memóriaköltségvetést. Feltételezésünk szerint az alacsonyabb tenzorpárhuzamosság magasabb késleltetést (az egyes kötegek kiszolgálásához felhasznált kevesebb erőforrás miatt), de magasabb GPU-nkénti átviteli sebességet (a jobb kihasználtság miatt) eredményez a magasabb tenzorpárhuzamossághoz képest.

Kvantálás

A kvantálás a neurális hálózatok által használt súlyok és aktivációk pontosságának csökkentése. Ezt a technikát használjuk a GPU-memóriafelhasználás felezésére, amikor fp16-ról fp8-ra váltunk. Ez lehetővé teszi ugyanannak a modellnek az alacsonyabb teljes GPU-memória-felhasználással történő futtatását, ami alacsonyabb tenzorpárhuzamosságot tesz lehetővé, ezáltal növelve az átviteli sebességet.

A kvantálás implementációi ronthatják a pontosságot. Ezért értékeltük a különböző pontosságok pontosságát a WikiText korpuszon mutatott perplexitási statisztikájuk összehasonlításával, amely azt méri, hogy az LLM milyen jól jósolja meg a mondatban szereplő egyes következő tokeneket. A 8 bites lebegőpontos, a 8 bites súlyú, 8 bites aktivációs és SmoothQuant (w8a8 SQ) esetében nem volt szignifikáns változás a perplexitásban (< 1%) az fp16-hoz képest a WikiTexten, így magabiztosan haladtunk tovább. A w4a16 azonban jelentős, 7%-os változást mutatott a perplexitásban, ami valószínűleg az még alacsonyabb pontosságnak és az int4 és az fp16 közötti szükséges dinamikus konverzióknak tudható be.

Kötegyméret

A kötegelésen alapuló párhuzamosság egy klasszikus stratégia a teljesítmény kisajtolására egy erőforrás-korlátos rendszerből. Azáltal, hogy a neurális hálózaton való minden egyes előremenő áthaladás során több kérést dolgoz fel, a kötegelés bizonyítottan növeli az átviteli sebességet bizonyos késleltetés árán. A kötegelés emellett magasabb GPU-memória-felhasználással is jár, mivel a figyelmi mechanizmust kezelő KV-gyorsítótár mérete lineárisan nő a kötegymérettel.

Nagyítás

A Llama 2 70B (amely 80 réteggel rendelkezik) esetében, 4096-os kontextusméret és 32-es kötegyméret mellett az fp16 használatakor a KV-gyorsítótár mérete jelentős, 40 GB lesz. Ez végül megakadályozza, hogy a Llama 2 70B fp16, amelynek önmagában a súlyai 140 GB-ot tesznek ki, kényelmesen elférjen a 2-es tenzorpárhuzamosság (TP-2) mellett rendelkezésre álló 160 GB-os GPU-memóriában.

Eredmények

Végignéztük a kísérlet 4 változójának kompatibilis kombinációit, és az alábbiakban bemutatjuk a legtanulságosabb trendeket.

Nagyítás

A kvantálás késleltetési javulása a 10%-os tartományban mozog a H100 fp16 → fp8 és az A100 fp16 → w8a8 SmoothQuant összehasonlításakor. A vegyes pontosságú w4a16 azonban a valóságban jobban teljesít alacsony kötegyméreteknél, és rosszabbul magasabb kötegyméreteknél az fp16-hoz képest. Ennek számos oka lehet, beleértve a kevésbé optimalizált számítási kerneleket, az int4 és az fp16 közötti konverziós időt, valamint azt a tényt, hogy a w4a16 továbbra is 16 bites lebegőpontos számokat használ az aktivációkhoz, ami nem eredményez megtakarítást a KV-gyorsítótár dimenzióiban. Mivel a w4a16 alacsonyabb pontosságot is mutatott, arra a következtetésre jutottunk, hogy az A100 esetében a w8a8 SQ-t, a H100 esetében pedig az fp8-at érdemes használnunk.

Nagyítás

Az első két ábránkon csak a TP-8 konfigurációkat mutatjuk be. A H100 54%-os késleltetést és 184%-os átviteli sebességet ér el az A100-hoz képest, amikor mindkettő fp16 / BS-128 / TP-8 beállítást használ, ami 49%-os késleltetésre és 202%-os átviteli sebességre javul, ha a H100-on fp8-at használunk. Ez a teljesítményjavulás a H100 és az A100 közötti számítási teljesítmény és memória-sávszélesség növekedésének tulajdonítható. Említésre méltó, hogy a különbség kevésbé hangsúlyos az alacsonyabb kötegyméreteknél, ahol a kihasználtság alacsonyabb lehet.

Platformunk építése során ki akarjuk tartani a felhasználóink számára meghatározott bizonyos késleltetési követelményeket, miközben maximalizáljuk az átviteli sebességet. Ezért ahelyett, hogy az A100-at és a H100-at azonos kötegyméret mellett hasonlítanánk össze, valójában sokkal ésszerűbb számunkra az átviteli sebességüket kizárólag olyan konfigurációkban összehasonlítani, amelyekben teljesítik a késleltetési követelményt. Az 512 kimeneti token elkészülésére 25600 ms-os késleltetési küszöbértéket állapítottunk meg, és azt találtuk, hogy a H100 / TP-8 / fp8 / BS-128 251%-os átviteli sebességet biztosít az A100 / TP-8 / fp16 / BS-64 konfigurációhoz képest, mivel képes alacsonyabb késleltetéssel duplájára növelni a kötegyméretet. Tekintettel arra, hogy a kvantálás GPU-memória-megtakarítást biztosít, most azt kell felmérnünk, hogy a tenzorpárhuzamosság hogyan adhatja az optimalizáció következő rétegét.

Nagyítás

Ami a kvantálást és az architektúrát illeti, egyértelmű győztesek vannak: a H100 felülmúlja az A100-at, és az alacsonyabb pontosságú kvantálás javítja a memóriafelhasználást, a késleltetést és az átviteli sebességet. A kötegyméret és a tenzorpárhuzamosság azonban kompromisszumot jelent a kulcsfontosságú mutatóinkban. A nagyobb kötegyméret az átviteli sebességet optimalizálja a megnövekedett késleltetés és memóriafogyasztás árán. Másrészt a magasabb tenzorpárhuzamosság növeli a rendelkezésre álló memória teljes készletét és a késleltetést optimalizálja, de kompromisszumot köt az átviteli sebességgel a elosztott mátrixszorzás szinkronizációs költségei miatt, valamint azáltal, hogy több GPU-erőforrást köt le.

Nagyítás

Kísérletünk átviteli sebességet maximalizáló konfigurációja a H100 / fp8 / TP-2 / BS-128, amely másodpercenként és GPU-nként 767 kimeneti tokent eredményez. Ez 460%-os javulást jelent az A100 / fp16 / TP-8 / BS-64 konfigurációhoz képest. Ez azonban a megduplázódott késleltetés áraként jelentkezik – 512 kimeneti token esetén ez inkább megközelíti a 42000 ms-ot –, így valószínűleg nem alkalmas éles (production) konfigurációként. A TP-4 BS-128 (626 token/mp/gpu 26188 ms-os válaszidő mellett) és a TP-2 BS-32 (435 token/mp/gpu 18821 ms-os válaszidő mellett) eredményei jobb kompromisszumokat képviselhetnek a kulcsfontosságú mutatóinkon.

Következtetés

Eredményeink azt mutatják, hogy:

Az azonos konfigurációt használó A100-hoz képest a H100-zal 54%-os késleltetést és 184%-os átviteli sebességet érünk el, ami 49%-ra, illetve 202%-ra javul, amikor a H100 kihasználja az fp8 natív támogatását.

Ha a késleltetési korlát figyelembe vételével maximalizáljuk az átviteli sebességet, a H100 / fp8 / TP-8 / BS-128 251%-os átviteli sebességet biztosít az A100 / fp16 / TP-8 / BS-64 konfigurációhoz képest, mivel nagyobb sebességgel képes feldolgozni a duplaköteget.

A H100 TP-2-vel és fp8-cal történő kihasználásával az A100 / fp16 / TP-8 / BS-128 átviteli sebességének 373%-át érhetjük el, kevesebb mint 10%-os késleltetésnövekedés mellett.

A kötegyméret és a tenzorpárhuzamosság kompromisszumot jelent az átviteli sebesség és a késleltetés között egy LLM-inferencia rendszert üzemeltető szakember számára.

Ezek az eredmények magabiztosságmal töltenek bennünket el a korábban A100-al meghajtott hardververemünk H100 GPU-kra történő teljes átállását illetően. Örömmel tudjuk megerősíteni az NVIDIA által hirdetett teljesítménynövekedést, és várakozással tekintünk elébe a gyorsított hardverek terén elért következő áttöréseiknek.

Mi a következő lépés?

Az optimalizálás terén a következő határunk a strukturált ritkaság és az int4 pontosság pontosságra és teljesítményre gyakorolt hatásának vizsgálata, ami jelentősen csökkenthetné a Llama 2 70B GPU-memória-igényét, és akár kétszeres késleltetési javulást is eredményezhetne. Izgatottan folytatjuk a villámgyors inferencia útját, és reméljük, hogy képessé tehetjük felhasználóinkat arra, hogy hatékony alkalmazásokat építsenek a platformunk tetejére.

A közeljövőben a pplx-api megszünteti a sebességhatárokat, és további egyedi Perplexity LLM-eket kínál, beleértve egy internetalapú, tényellenőrzéssel (grounding) ellátott LLM-et is.

Regisztráljon a Perplexity Pro-ra a perplexity.ai/pro oldalon. Szerezzen hozzáférést élvonalbeli pplx-api-nkoz, és hasznosítsa ezeket a fejlett képességeket a projektjeiben. Fedezzen fel többet a pplx-api-ról a blogunkon.

Érdekli az MI jövőjének alakítása? Csapatunkba új munkatársakat keresünk! Legyen részese egy olyan csapatnak, amely hatalmas skálájú, generatív LLM-infrastruktúrát fejleszt. Fedezze fel a lehetőségeket a Perplexity Karrier oldalon.

Szerzők:

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats