Accelerarea Llama 2 70B cu NVIDIA H100

Căutarea performanței în motorul de răspuns Perplexity ne determină să adoptăm cea mai recentă tehnologie pe care NVIDIA și AWS o au de oferit. În acest blog, suntem încântați să împărtășim rezultatele celor mai recente experimente ale noastre: o comparație a inferenței Llama 2 70B în diferite setări de hardware și software.

Platforma noastră de inferență LLM, pplx-api, este construită pe un stivă de ultimă generație alimentată de biblioteci open-source. De când a început beta-ul public al pplx-api în octombrie, ne-am confruntat cu provocări de scalare și am învățat cum să ne optimizăm cel mai bine configurația pentru a obține o scară masivă. Acest lucru ne-a determinat să efectuăm experimente pornind de la următoarele întrebări directoare:

Care este creșterea brută a performanței prin trecerea GPU-urilor noastre de la NVIDIA A100 la NVIDIA H100, toate celelalte setări rămânând aceleași?

Care este creșterea eficienței a cuantizării în virgulă mobilă pe 8 biți (fp8), pentru care H100 adaugă suport nativ? Care este costul în ceea ce privește acuratețea al acestei cuantizări?

Cum afectează paralelismul tensorilor și dimensiunea lotului (batch size) latența și debitul de tokeni?

Având în cele de mai sus, ce configurație duce la cel mai scalabil echilibru între performanță și eficiența costurilor?

Am efectuat următorul experiment ca o serie de teste de referință locale pentru a evita latența rețelei.

Latență: Timpul total necesar serverului de inferență pentru a genera răspunsul său complet.

Debit: Numărul de tokeni de ieșire, pe secundă, pe GPU, pe care serverul de inferență îi poate genera pentru toți utilizatorii și toate cererile.

Următorii factori ar influența metricile cheie, așa că i-am menținut constanți în diferitele rulări ale experimentului.

Performanța scalează odată cu dimensiunea LLM-ului. Mai mulți parametri necesită mai multe calcule, ceea ce duce la o inferență mai lentă. De exemplu, Llama 2 13B este mai rapid decât Llama 2 70B atunci când celelalte setări sunt egale. Ne menținem la Llama 2 70B în acest experiment deoarece dorim să optimizăm pentru servirea celor mai capabile modele open source.

Cantitatea de tokeni de intrare și ieșire din fiecare pereche de cerere/răspuns din eșantion poate influența măsurătorile de performanță. În general, generarea tokenilor de ieșire domină timpul total de răspuns. Atunci când eșantionarea datelor determină doar răspunsuri de tip „da/nu” din partea LLM-ului, răspunsul este mai rapid în comparație cu eșantioanele care cer LLM-ului să scrie eseuri. Setul nostru de date este compus din cereri sintetice cu 1024 de tokeni de intrare care determină 512 tokeni de ieșire. Această distribuție a fost aleasă pentru a se potrivi cu distribuția observată a traficului pe implementarea noastră publică a Llama2 70B.

NVIDIA TensorRT-LLM (lansarea v0.5.0) este o bibliotecă open-source pentru optimizarea inferenței LLM. Lansată la sfârșitul anului 2023, ea sintetizează numeroasele optimizări de inferență ale NVIDIA și oferă un strat flexibil de personalizare pentru parametrii cheie ai acestui experiment: dimensiunea lotului (batch size), cuantizarea și paralelismul tensorilor.

Am experimentat pe 4 axe de configurare: paralelismul tensorilor, arhitectura GPU, cuantizarea și dimensiunea maximă a lotului (max batch size). Aceste axe sunt interconectate deoarece fiecare reprezintă un compromis în raport cu resursa critică de blocaj reprezentată de memoria GPU.

Arhitectura GPU Hopper de a noua generație (H100-HBM3-80GB / p5.48xlarge) aduce o listă uriașă de funcționalități față de predecesoarea sa, Ampere (A100-SXM4-80GB / p4de.24xlarge), incluzând rate de calcul de 2x-6x și o lățime de bandă a memoriei GPU de aproape 2x. Lățimea de bandă a memoriei GPU este o metrică critică pentru inferență, deoarece un blocaj principal al latenței în înmulțirile de matrice din inferență provine din încărcarea gigabiților de date ale modelului din memoria GPU în registrele de calcul. Pe baza acestei statistici, am emis ipoteza că o comparație directă (apples-to-apples) între NVIDIA H100 și A100 va prezenta o îmbunătățire de 2x atât în ceea ce privește latența, cât și debitul.

O altă diferență cheie între NVIDIA H100 și A100 este că nucleul tensor H100 adaugă nativ suport pentru instrucțiuni în virgulă mobilă pe 8 biți (fp8), ceea ce deschide calea către alte optimizări detaliate mai jos. Acesta este motivul pentru care folosim fp8 și fp16 în mod specific pentru H100.

Pentru a menține memoria pe GPU consistentă în acest experiment, ne-am bazat pe noduri cu memorie GPU de 8x80GB atât pentru NVIDIA A100, cât și pentru H100. Pe lângă faptul că permite dimensiuni mai mari ale lotului, memoria GPU este importantă deoarece parametrii modelului sunt încărcați în memoria GPU în timpul pornirii serverului pentru un acces rapid. De exemplu, dacă fiecare dintre cei 70 de miliarde de parametri din modelul nostru este un număr în virgulă mobilă pe 16 biți, atunci modelul are o dimensiune de aproximativ 140 GB, ceea ce nu încape pe un singur GPU. De aici necesitatea paralelismului tensorilor, pe care o explicăm mai jos.

Paralelismul tensor se referă la numărul de dispozitive GPU consumate pentru a rula serverul de inferență. Atunci când alocăm un număr de GPU-uri, TensorRT-LLM pune resursele acestora în comun pentru a ne ajuta să atingem bugetul de memorie minim necesar pentru a rula Llama2 70B. Ipoteza noastră este că un paralelism tensor mai redus va duce la o latență mai mare (din cauza resurselor mai puține consumate pentru a satisface fiecare lot), dar la un debit mai mare pe GPU (datorită unei utilizări mai bune) în comparație cu un paralelism tensor mai ridicat.

Cuantizarea este reducerea preciziei ponderilor și activărilor utilizate de rețelele neuronale. Folosim această tehnică pentru a înjumătăți consumul de memorie GPU atunci când trecem de la fp16 la fp8. Acest lucru face posibilă rularea aceluiași model cu o utilizare totală mai mică a memoriei GPU, permițând un paralelism tensor mai redus, ceea ce crește debitul.

Implementările cuantizării au potențialul de a reduce acuratețea. Astfel, am evaluat acuratețea pentru diferite precizii comparând statistica lor de perplexitate, o măsură a cât de bine prezice LLM-ul fiecare token următor dintr-o propoziție, pe corpusul WikiText. Pentru virgulă mobilă pe 8 biți și ponderi pe 8 biți cu activare pe 8 biți și SmoothQuant (w8a8 SQ), nu a existat nicio modificare semnificativă a perplexității (< 1%) în comparație cu fp16 pe WikiText, așa că ne-am simțit încrezători să continuăm. Cu toate acestea, w4a16 a prezentat o modificare substanțială de 7% a perplexității, probabil atribuită preciziei și mai scăzute și conversiilor dinamice necesare între int4 și fp16.

Paralelismul prin utilizarea loturilor (batching) este o strategie clasică pentru a obține performanță maximă dintr-un sistem cu resurse limitate. Procesând cereri multiple în fiecare trecere înainte prin rețeaua neuronală, utilizarea loturilor este cunoscută pentru creșterea debitului în schimbul unei anumite latențe. De asemenea, utilizarea loturilor generează un consum mai mare de memorie GPU deoarece dimensiunea memoriei cache KV, care gestionează mecanismul de atenție, crește liniar odată cu dimensiunea lotului.

În cazul Llama 2 70B (care are 80 de straturi), fp16 cu o dimensiune a lotului de 32 pentru o dimensiune de context de 4096, dimensiunea memoriei cache KV ajunge la o valoare substanțială de 40 GB. Acest lucru ajunge să împiedice Llama 2 70B fp16, ale cărui ponderi singure ocupă 140 GB, să încapă confortabil în memoria GPU de 160 GB disponibilă la paralelismul tensor 2 (TP-2).

Am parcurs combinațiile compatibile ale celor 4 variabile ale experimentului și prezentăm mai jos cele mai relevante tendințe.

Figura 1 - Latența cererilor cu dimensiuni variate ale lotului în cinci configurații diferite, toate având paralelism tensor 8, ceea ce oferă cea mai bună latență cu 8 GPU-uri disponibile. În cadrul fiecărei configurații, latența se dublează în general la creșterea dimensiunii lotului de la 1 la 32 și se dublează din nou de la 32 la 128. La dimensiuni de lot suficient de mari, H100 înjumătățește aproximativ latența în comparație cu A100. A100 utilizează precizie mixtă deoarece arhitectura nu are suport nativ pentru fp8. w8a8 cu SmoothQuant (SQ) este menit să semene cu fp8.

Îmbunătățirea latenței prin cuantizare este în jur de 10% când se compară H100 fp16 → fp8 și A100 fp16 → w8a8 cu SmoothQuant. Cu toate acestea, precizia mixtă w4a16 performează de fapt mai bine la dimensiuni mici ale lotului și mai slab la dimensiuni mai mari ale lotului în comparație cu fp16. Acest lucru se poate datora unui număr de factori, inclusiv nuclee de calcul mai puțin optimizate, timpul de conversie între int4 și fp16 și faptul că w4a16 folosește în continuare numere în virgulă mobilă pe 16 biți pentru activări, ceea ce nu aduce economii în dimensiunile memoriei cache KV. Deoarece w4a16 a demonstrat, de asemenea, o acuratețe mai redusă, concluzionăm că ar trebui să ne menținem la w8a8 SQ pentru A100 și fp8 pentru H100.

Figura 2 - Debitul în configurațiile TP-8 cu diferite arhitecturi, cuantizări și dimensiuni ale lotului. Pentru fiecare arhitectură și cuantizare, dimensiunea lotului a fost aleasă ca fiind cea mai mare care a respectat o cerință de latență de 25600ms (20 de tokeni pe secundă pentru 512 tokeni), astfel încât să comparăm configurații având o latență similară. În conformitate cu această cerință, H100 cu BS-128 atinge un debit de 228% în comparație cu A100 BS-64 utilizând aceeași cuantizare (fp16) și are chiar o latență de răspuns mai mică în ciuda dimensiunii dublate a lotului. Cuantizarea cu fp8 îmbunătățește acest factor la 251%.

În primele noastre două figuri, prezentăm doar configurații TP-8. H100 obține o latență de 54% și un debit de 184% în comparație cu A100 atunci când ambele utilizează fp16 / BS-128 / TP-8, ceea ce se îmbunătățește la o latență de 49% și un debit de 202% atunci când se utilizează fp8 pe H100. Această îmbunătățire a performanței poate fi atribuită creșterii puterii de calcul și a lățimii de bandă a memoriei între H100 și A100. În mod notable, diferența este mai puțin pronunțată la dimensiuni mai mici ale lotului, unde utilizarea poate fi mai redusă.

Pe măsură ce ne construim platforma, dorim să respectăm anumite cerințe de latență pentru utilizatorii noștri, maximizând în același timp debitul. Astfel, în loc să comparăm A100 cu H100 la aceeași dimensiune a lotului, are de fapt mai mult sens pentru noi să le comparăm debitul doar în configurații în care îndeplinesc o cerință de latență. Am setat o limită de 25600ms latență pentru finalizarea celor 512 tokeni de ieșire și am constatat că H100 / TP-8 / fp8 / BS-128 aduce un debit de 251% în comparație cu A100 / TP-8 / fp16 / BS-64, deoarece poate procesa o dimensiune dublă a lotului la o latență mai mică. Având în vedere că cuantizarea oferă economii de memorie GPU, trebuie acum să evaluăm modul în care paralelismul tensor poate adăuga un nou nivel de optimizare.

Figura 3 - Latența în funcție de dimensiunile variabile ale lotului și paralelismul tensor pentru H100 fp8. Latența se dublează în general la creșterea dimensiunii lotului de la 1 la 32 și se dublează din nou de la 32 la 128. TP-2 este în mod constant de aproximativ două ori mai lent decât TP-8 atunci când dimensiunile lotului sunt egale. Dublarea paralelismului tensor în timp ce se dublează dimensiunea lotului menține latența relativ stabilă, deoarece numărul de loturi procesate per GPU rămâne constant.

În ceea ce privește cuantizarea și arhitectura, există câștigători clari: H100 domină A100, iar cuantizarea cu precizie redusă îmbunătățește utilizarea memoriei, latența și debitul. Cu toate acestea, dimensiunea lotului și paralelismul tensor prezintă un compromis în metricile noastre cheie. O dimensiune mai mare a lotului optimizează debitul în schimbul unei latențe crescute și al unui consum mai mare de memorie. Pe de altă parte, un paralelism tensor mai ridicat crește fondul total de memorie disponibilă și optimizează latența, dar aduce un compromis cu debitul din cauza costurilor de sincronizare ale înmulțirii distribuite de matrice și prin blocarea a mai multor resurse GPU.

Figura 4 - Debitul în funcție de dimensiunile variabile ale lotului și paralelismul tensor pentru H100 fp8. Cel mai mare debit provine de la TP-2 BS-128, la 460% în comparație cu linia de bază A100/TP-8/fp16/BS-64. Cu toate acestea, TP-2 BS-128 este, de asemenea, cel mai lent rezultat din Figura 3.

Configurația care maximizează debitul în experimentul nostru este H100 / fp8 / TP-2 / BS-128, la 767 de tokeni de ieșire pe secundă per GPU. Aceasta reprezintă o îmbunătățire de 460% față de A100 / fp16 / TP-8 / BS-64. Cu toate acestea, vine în schimbul dublării latenței - aproape de 42000ms pentru 512 tokeni de ieșire - așa că poate fi nepotrivită ca și configurație de producție. Rezultatele pentru TP-4 BS-128 (626 tok/sec/gpu la un timp de răspuns de 26188ms) și TP-2 BS-32 (435 tok/sec/gpu la un timp de răspuns de 18821ms) pot reprezenta compromisuri mai bune în ceea ce privește metricile noastre cheie.

Rezultatele noastre demonstrează că:

Atingem o latență de 54% și un debit de 184% utilizând H100 în comparație cu A100 în aceeași configurație, ceea ce se îmbunătățește la 49% și respectiv 202% atunci când H100 profită de suportul său nativ pentru fp8.

Atunci când maximizăm debitul sub rezerva unei constrângeri de latență, H100 / fp8 / TP-8 / BS-128 aduce un debit de 251% în comparație cu A100 / fp16 / TP-8 / BS-64, deoarece poate procesa un lot dublu la o viteză mai mare.

Profitând de H100 cu TP-2 și fp8, putem obține un debit de 373% față de A100 / fp16 / TP-8 / BS-128, cu o creștere a latenței de mai puțin de 10%.

Dimensiunea lotului și paralelismul tensor prezintă un compromis între debit și latență pentru operatorul unui sistem de inferență LLM.

Aceste rezultate ne fac să fim încrezători în privința unei tranziții complete la GPU-urile H100 în stiva noastră hardware alimentată anterior de A100. Suntem încântați să putem confirma câștigurile de performanță promovate de NVIDIA și așteptăm cu nerăbdare următoarele lor descoperiri în domeniul hardware-ului accelerat.

Următoarea noastră frontieră pentru optimizare este să examinăm impactul asupra acurateței și performanței al sparsity-ului structurat (rarității structurate) și al preciziei int4, care ar putea reduce semnificativ amprenta de memorie GPU a Llama 2 70B și ar putea aduce îmbunătățiri de până la 2x în latență. Suntem încântați să continuăm călătoria unei inferențe extrem de rapide și sperăm să le oferim utilizatorilor noștri posibilitatea de a construi aplicații puternice pe baza platformei noastre.

Pe termen scurt, pplx-api va elimina limitele de rată și va oferi mai multe LLM-uri Perplexity personalizate, inclusiv un LLM alimentat de internet cu fundamentare pentru fapte.

Înscrieți-vă la Perplexity Pro la perplexity.ai/pro. Obțineți acces la pplx-api-ul nostru de ultimă generație și valorificați aceste capabilități avansate în proiectele dumneavoastră. Aflați mai multe despre pplx-api pe blogul nostru.

Sunteți interesat să contribuiți la modelarea viitorului IA? Facem angajări! Faceți parte dintr-o echipă care impulsionează infrastructura LLM generativă la scară masivă. Explorați oportunitățile la Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Configurarea experimentală

Metrici cheie:

Constante:

Model AI

Set de date pentru tokeni de intrare/ieșire

Versiune software

Variabile

Arhitectură GPU

Paralelism tensor

Cuantizare

Dimensiunea lotului

Rezultate

Concluzie

Ce urmează

Autori: