Turboładowanie Llama 2 70B z NVIDIA H100

Dążenie do wydajności silnika odpowiedzi Perplexity skłania nas do stosowania najnowszych technologii oferowanych przez NVIDIA i AWS. Na niniejszym blogu z przyjemnością dzielimy się wynikami naszych najnowszych eksperymentów: porównaniem wnioskowania modelu Llama 2 70B w różnych konfiguracjach sprzętowych i programowych.

Nasza platforma wnioskowania LLM, pplx-api, została zbudowana w oparciu o najnowocześniejszy stos technologiczny zasilany bibliotekami open-source. Od momentu rozpoczęcia publicznych testów beta pplx-api w październiku, zajmujemy się wyzwaniami związanymi ze skalowaniem oraz optymalizacją naszej konfiguracji w celu osiągnięcia ogromnej skali. Skłoniło nas to do przeprowadzenia eksperymentów w oparciu o następujące pytania pomocnicze:

Jaki jest rzeczywisty wzrost wydajności wynikający z przejścia z procesorów GPU NVIDIA A100 na NVIDIA H100 przy zachowaniu tych samych ustawień?

Jaki jest wzrost efektywności kwantyzacji 8-bitowej zmiennoprzecinkowej (fp8), dla której H100 zapewnia natywne wsparcie? Jaki jest koszt dokładności tej kwantyzacji?

W jaki sposób zrównoleglenie tensorowe i rozmiar partii wpływają na opóźnienia i przepustowość tokenów?

Biorąc pod uwagę powyższe, która konfiguracja zapewnia najbardziej skalowalną równowagę między wydajnością a efektywnością kosztową?

Przeprowadziliśmy poniższy eksperyment jako serię lokalnych testów porównawczych, aby uniknąć opóźnień sieciowych.

Opóźnienie: Całkowity czas potrzebny serwerowi wnioskowania na wygenerowanie pełnej odpowiedzi.

Przepustowość: Liczba tokenów wyjściowych na sekundę, na jednostkę GPU, które serwer wnioskowania może wygenerować dla wszystkich użytkowników i zapytań.

Poniższe czynniki wpływają na kluczowe wskaźniki, dlatego utrzymywaliśmy je na stałym poziomie podczas różnych prób eksperymentu.

Wydajność skaluje się wraz z rozmiarem modelu LLM. Więcej parametrów wymaga większej liczby obliczeń, co skutkuje wolniejszym wnioskowaniem. Na przykład model Llama 2 13B jest szybszy niż Llama 2 70B, przy założeniu równych pozostałych ustawień. W niniejszym eksperymencie trzymamy się modelu Llama 2 70B, ponieważ chcemy zoptymalizować serwowanie najbardziej zaawansowanych modeli open source.

Liczba tokenów wejściowych i wyjściowych w każdej parze zapytanie/odpowiedź może wpływać na pomiary wydajności. Zasadniczo generowanie tokenów wyjściowych dominuje w całkowitym czasie odpowiedzi. Gdy dane próbkowe wywołują jedynie odpowiedzi „tak/nie” z modelu LLM, odpowiedź jest szybsza w porównaniu do próbek wymagających od modelu LLM pisania wypracowań. Nasz zbiór danych składa się z syntetycznych zapytań z 1024 tokenami wejściowymi wywołującymi 512 tokenów wyjściowych. Rozkład ten został dobrany tak, aby odpowiadał zaobserwowanemu rozkładowi ruchu w naszym publicznym wdrożeniu Llama2 70B.

NVIDIA TensorRT-LLM (wydanie v0.5.0) to biblioteka open-source służąca do optymalizacji wnioskowania LLM. Wydana pod koniec 2023 roku, syntezuje wiele optymalizacji wnioskowania NVIDIA i zapewnia elastyczną warstwę dostosowania dla kluczowych parametrów tego eksperymentu: rozmiaru partii, kwantyzacji i zrównoleglenia tensorowego.

Eksperyment przeprowadziliśmy w ramach 4 osi konfiguracji: zrównoleglenia tensorowego, architektury GPU, kwantyzacji oraz maksymalnego rozmiaru partii. Osie te są ze sobą powiązane, ponieważ każda z nich stanowi kompromis w odniesieniu do krytycznego zasobu wąskiego gardła, jakim jest pamięć GPU.

Architektura procesorów GPU dziewiątej generacji Hopper (H100-HBM3-80GB / p5.48xlarge) oferuje ogromną listę funkcji w porównaniu do poprzednika, Ampere (A100-SXM4-80GB / p4de.24xlarge), w tym 2-6-krotnie szybsze tempo obliczeń i prawie dwukrotnie większą przepustowość pamięci GPU. Przepustowość pamięci GPU jest krytycznym wskaźnikiem dla wnioskowania, ponieważ podstawowym wąskim gardłem opóźnień wnioskowania w operacjach mnożenia macierzy jest ładowanie gigabajtów danych modelu z pamięci GPU do rejestrów obliczeniowych. Na podstawie tych statystyk postawiliśmy hipotezę, że bezpośrednie porównanie NVIDIA H100 i A100 wykaże dwukrotną poprawę zarówno w zakresie opóźnień, jak i przepustowości.

Kolejną kluczową różnicą między NVIDIA H100 a A100 jest to, że rdzenie tensorowe H100 natywnie wspierają instrukcje 8-bitowe zmiennoprzecinkowe (fp8), co otwiera drogę do dalszych optymalizacji opisanych poniżej. Dlatego dla modelu H100 stosujemy specjalnie formaty fp8 i fp16.

Aby zapewnić spójność pamięci na jednostkę GPU w niniejszym eksperymencie, dla obu modeli NVIDIA A100 i H100 korzystaliśmy z węzłów z pamięcią GPU 8x80GB. Oprócz umożliwienia stosowania większych rozmiarów partii, pamięć GPU jest istotna, ponieważ parametry modelu są ładowane do pamięci GPU podczas uruchamiania serwera w celu uzyskania szybkiego dostępu. Na przykład, jeśli każdy z 70 miliardów parametrów w naszym modelu jest 16-bitową liczbą zmiennoprzecinkową, model zajmuje około 140 GB, co nie mieści się na pojedynczym procesorze GPU. Stąd potrzeba zrównoleglenia tensorowego, które wyjaśniamy poniżej.

Zrównoleglenie tensorowe odnosi się do liczby urządzeń GPU wykorzystywanych do obsługi serwera wnioskowania. Po przydzieleniu określonej liczby jednostek GPU, TensorRT-LLM łączy ich zasoby, aby pomóc nam osiągnąć minimalny wymagany budżet pamięci potrzebny do uruchomienia Llama2 70B. Nasza hipoteza zakłada, że niższe zrównoleglenie tensorowe skutkuje wyższymi opóźnieniami (z uwagi na mniejszą liczbę zasobów zużywanych na obsługę każdej partii), ale wyższą przepustowością na jednostkę GPU (z uwagi na lepsze wykorzystanie) w porównaniu do wyższego zrównoleglenia tensorowego.

Kwantyzacja to redukcja precyzji wag i aktywacji stosowanych przez sieci neuronowe. Technikę tę stosujemy, aby zmniejszyć o połowę zużycie pamięci GPU podczas przejścia z fp16 na fp8. Umożliwia to uruchomienie tego samego modelu przy mniejszym całkowitym wykorzystaniu pamięci GPU, pozwalając na niższe zrównoleglenie tensorowe, co zwiększa przepustowość.

Implementacje kwantyzacji mogą prowadzić do pogorszenia dokładności. Dlatego dokonaliśmy oceny dokładności dla różnych precyzji poprzez porównanie ich statystyki perplexity, czyli miary określającej, jak dobrze model LLM przewiduje kolejny token w zdaniu, na korpusie WikiText. W przypadku formatu 8-bitowego zmiennoprzecinkowego oraz wagi 8-bitowej z aktywacją 8-bitową i SmoothQuant (w8a8 SQ), nie odnotowano istotnej zmiany wskaźnika perplexity (< 1%) w porównaniu do fp16 na WikiText, więc uznaliśmy za zasadne kontynuowanie prac. Jednakże format w4a16 wykazał znaczną 7% zmianę w perplexity, co może wynikać z jeszcze niższej precyzji i koniecznych dynamicznych konwersji między int4 a fp16.

Zrównoleglenie poprzez grupowanie w partie (batching) to klasyczna strategia wyciskania wydajności z systemu o ograniczonych zasobach. Poprzez przetwarzanie wielu zapytań w każdym przejściu w przód przez sieć neuronową, grupowanie w partie zwiększa przepustowość kosztem pewnych opóźnień. Grupowanie w partie powoduje również wyższe zużycie pamięci GPU, ponieważ rozmiar pamięci podręcznej KV, która zarządza mechanizmem uwagi, rośnie liniowo wraz z rozmiarem partii.

W przypadku modelu Llama 2 70B (posiadającego 80 warstw), formatu fp16 przy rozmiarze partii 32 i rozmiarze kontekstu 4096, rozmiar pamięci podręcznej KV osiąga znaczną wartość 40 GB. Uniemożliwia to swobodne zmieszczenie modelu Llama 2 70B fp16, którego same wagi zajmują 140 GB, w 160 GB pamięci GPU dostępnej przy zrównolegleniu tensorowym 2 (TP-2).

Przeanalizowaliśmy kompatybilne kombinacje 4 zmiennych eksperymentu i przedstawiamy poniżej najbardziej znaczące trendy.

Rysunek 1 - Opóźnienie zapytań przy różnym rozmiarze partii w pięciu różnych konfiguracjach, wszystkie przy zrównolegleniu tensorowym 8, co zapewnia najlepsze opóźnienie przy 8 dostępnych jednostkach GPU. W ramach każdej konfiguracji opóźnienie generalnie podwaja się przy zwiększeniu rozmiaru partii z 1 do 32 i podwaja się ponownie przy przejściu z 32 do 128. Przy wystarczająco dużych rozmiarach partii procesor H100 skraca opóźnienie w przybliżeniu o połowę w porównaniu do A100. A100 wykorzystuje mieszaną precyzję, ponieważ architektura ta nie posiada natywnego wsparcia dla fp8. Format w8a8 z SmoothQuant (SQ) ma przypominać fp8.

Poprawa opóźnienia wynikająca z kwantyzacji wynosi około 10% przy porównaniu H100 fp16 do fp8 oraz A100 fp16 do w8a8 z SmoothQuant. Jednakże mieszana precyzja w4a16 faktycznie działa lepiej przy małych rozmiarach partii i gorzej przy większych rozmiarach partii w porównaniu do fp16. Może to wynikać z szeregu czynników, w tym mniej zoptymalizowanych jąder obliczeniowych, czasu rzutowania między int4 a fp16 oraz faktu, że w4a16 nadal wykorzystuje 16-bitowe liczby zmiennoprzecinkowe dla aktywacji, co nie skutkuje oszczędnościami w wymiarach pamięci podręcznej KV. Ponieważ w4a16 wykazał również niższą dokładność, doszliśmy do wniosku, że należy pozostać przy w8a8 SQ dla A100 oraz fp8 dla H100.

Rysunek 2 - Przepustowość w konfiguracjach TP-8 przy różnej architekturze, kwantyzacji i rozmiarze partii. Dla każdej architektury i kwantyzacji rozmiar partii został dobrany jako największy, który spełniał wymóg opóźnienia 25600ms (20 tokenów na sekundę dla 512 tokenów), tak aby porównać konfiguracje o podobnym opóźnieniu. Przy tym wymogu, H100 z BS-128 osiąga 228% przepustowości w porównaniu do A100 BS-64 przy użyciu tej samej kwantyzacji (fp16) i ma nawet niższe opóźnienie odpowiedzi pomimo podwojonego rozmiaru partii. Kwantyzacja z fp8 poprawia ten współczynnik do 251%.

Na naszych pierwszych dwóch rysunkach prezentujemy tylko konfiguracje TP-8. H100 osiąga 54% opóźnienia i 184% przepustowości w porównaniu do A100, gdy oba używają fp16 / BS-128 / TP-8, co poprawia się do 49% opóźnienia i 202% przepustowości przy użyciu fp8 na H100. Tę poprawę wydajności można przypisać wzrostowi mocy obliczeniowej i przepustowości pamięci między H100 a A100. Co istotne, różnica jest mniej wyraźna przy niższych rozmiarach partii, gdzie wykorzystanie może być mniejsze.

Budując naszą platformę, chcemy spełniać określone wymagania dotyczące opóźnień dla naszych użytkowników, maksymalizując jednocześnie przepustowość. Dlatego, zamiast porównywać A100 z H100 przy tym samym rozmiarze partii, bardziej sensowne jest dla nas porównanie ich przepustowości tylko w konfiguracjach, w których spełniają one wymóg dotyczący opóźnienia. Ustaliliśmy próg opóźnienia na 25600ms dla zakończenia generowania 512 tokenów wyjściowych i odkryliśmy, że H100 / TP-8 / fp8 / BS-128 zapewnia 251% przepustowości w porównaniu do A100 / TP-8 / fp16 / BS-64, ponieważ jest w stanie przetworzyć podwójny rozmiar partii przy niższym opóźnieniu. Biorąc pod uwagę, że kwantyzacja zapewnia oszczędności pamięci GPU, musimy teraz ocenić, w jaki sposób zrównoleglenie tensorowe może dodać kolejną warstwę optymalizacji.

Rysunek 3 - Opóźnienie przy różnym rozmiarze partii i zrównolegleniu tensorowym dla H100 fp8. Opóźnienie generalnie podwaja się przy zwiększeniu rozmiaru partii z 1 do 32 i podwaja się ponownie przy przejściu z 32 do 128. TP-2 jest konsekwentnie około dwa razy wolniejsze niż TP-8 przy równych rozmiarach partii. Podwojenie zrównoleglenia tensorowego przy jednoczesnym podwojeniu rozmiaru partii utrzymuje opóźnienie na stosunkowo stabilnym poziomie, ponieważ liczba partii przetwarzanych na jednostkę GPU pozostaje równa.

Jeśli chodzi o kwantyzację i architekturę, istnieją wyraźni zwycięzcy: H100 dominuje nad A100, a kwantyzacja o obniżonej precyzji poprawia wykorzystanie pamięci, opóźnienia i przepustowość. Jednak rozmiar partii i zrównoleglenie tensorowe stanowią kompromis w naszych kluczowych wskaźnikach. Większy rozmiar partii optymalizuje przepustowość kosztem zwiększonych opóźnień i zużycia pamięci. Z drugiej strony, wyższe zrównoleglenie tensorowe zwiększa całkowitą pulę dostępnej pamięci i optymalizuje opóźnienia, ale wiąże się z kompromisem w postaci przepustowości z powodu kosztów synchronizacji rozproszonego mnożenia macierzy i konieczności blokowania większej liczby zasobów GPU.

Rysunek 4 - Przepustowość przy różnych rozmiarach partii i zrównolegleniu tensorowym dla H100 fp8. Najwyższa przepustowość pochodzi z TP-2 BS-128, co stanowi 460% w porównaniu do linii bazowej A100/TP-8/fp16/BS-64. Jednakże konfiguracja TP-2 BS-128 jest również najwolniejszym wynikiem na Rysunku 3.

Konfiguracja naszego eksperymentu maksymalizująca przepustowość to H100 / fp8 / TP-2 / BS-128, osiągająca 767 tokenów wyjściowych na sekundę na jednostkę GPU. Jest to 460% poprawa względem A100 / fp16 / TP-8 / BS-64. Odbywa się to jednak kosztem podwojonego opóźnienia – bliższego 42000ms dla 512 tokenów wyjściowych – więc może być nieodpowiednia jako konfiguracja produkcyjna. Wyniki TP-4 BS-128 (626 tok/s/gpu przy czasie odpowiedzi 26188ms) oraz TP-2 BS-32 (435 tok/s/gpu przy czasie odpowiedzi 18821ms) mogą stanowić lepsze kompromisy w ramach naszych kluczowych wskaźników.

Nasze wyniki dowodzą, że:

Osiągamy 54% opóźnienia i 184% przepustowości przy użyciu H100 w porównaniu do A100 przy tej samej konfiguracji, co poprawia się do 49% i 202% odpowiednio, gdy H100 wykorzystuje swoje natywne wsparcie dla fp8.

Podczas maksymalizacji przepustowości z uwzględnieniem ograniczenia opóźnienia, H100 / fp8 / TP-8 / BS-128 zapewnia 251% przepustowości w porównaniu do A100 / fp16 / TP-8 / BS-64, ponieważ może przetwarzać podwójną partię przy szybszym tempie.

Wykorzystując H100 z TP-2 oraz fp8, możemy osiągnąć 373% przepustowości modelu A100 / fp16 / TP-8 / BS-128, przy wzroście opóźnienia o mniej niż 10%.

Rozmiar partii i zrównoleglenie tensorowe stanowią dla operatora systemu wnioskowania LLM kompromis między przepustowością a opóźnieniem.

Wyniki te sprawiają, że z ufnością podchodzimy do pełnego przejścia na procesory GPU H100 w naszym stosie sprzętowym, który dotychczas był zasilany przez A100. Jesteśmy podekscytowani możliwością potwierdzenia wzrostu wydajności reklamowanego przez NVIDIA i z niecierpliwością czekamy na ich kolejne przełomy w akcelerowanym sprzęcie.

Naszym kolejnym obszarem optymalizacji jest zbadanie dokładności i wpływu na wydajność strukturalnej rzadkości oraz precyzji int4, co mogłoby znacząco zmniejszyć zapotrzebowanie modelu Llama 2 70B na pamięć GPU i przynieść nawet dwukrotną poprawę opóźnień. Jesteśmy podekscytowani kontynuacją naszej podróży ku niezwykle szybkiemu wnioskowaniu i mamy nadzieję umożliwić naszym użytkownikom tworzenie potężnych aplikacji w oparciu o naszą platformę.

W najbliższym czasie pplx-api zniesie limity stawek i zaoferuje więcej niestandardowych modeli LLM od Perplexity, w tym model LLM zasilany internetem z weryfikacją faktów.

Zarejestruj się w Perplexity Pro na stronie perplexity.ai/pro. Uzyskaj dostęp do naszego najnowocześniejszego pplx-api i wykorzystaj te zaawansowane możliwości w swoich projektach. Dowiedz się więcej o pplx-api na naszym blogu.

Interesuje Cię kształtowanie przyszłości AI? Rekrutujemy! Dołącz do zespołu tworzącego infrastrukturę LLM generatywnego na ogromną skalę. Sprawdź możliwości kariery w Perplexity.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Konfiguracja eksperymentalna

Kluczowe wskaźniki:

Stałe:

Model AI

Zbiór danych tokenów wejściowych/wyjściowych

Wersja oprogramowania

Zmienne

Architektura GPU

Zrównoleglenie tensorowe

Kwantyzacja

Rozmiar partii

Wyniki

Podsumowanie

Co dalej

Autorzy: