Najlepsze GPU w chmurze do obsługi i wdrażania dużych modeli językowych

Czego rzeczywiście wymaga serwowanie LLM od wynajętego GPU

Serwowanie dużego modelu językowego to zasadniczo inny rodzaj obciążenia niż jego trenowanie. Trenowanie jest ograniczone przepustowością i toleruje opóźnienia; serwowanie jest wrażliwe na opóźnienia, ograniczone pamięcią i nieregularne. Gdy wynajmujesz GPU do wdrożenia LLM za API, wąskim gardłem rzadko są surowe FLOPS. Liczy się, ile modelu i jego pamięci podręcznej KV możesz zmieścić w VRAM, jak szybko ta pamięć przesyła dane oraz ile jednoczesnych żądań możesz zgrupować, zanim liczba tokenów na sekundę na użytkownika spadnie.

Pamięć podręczna KV to część, którą większość osób niedoszacowuje. Każde aktywne żądanie przechowuje klucze i wartości uwagi dla swojego kontekstu, a ten ślad rośnie wraz z długością sekwencji i liczbą jednoczesnych użytkowników. Model, który wygodnie mieści się w stanie bezczynności, może zabraknąć pamięci w momencie, gdy zaczynasz obsługiwać rzeczywisty ruch z długimi promptami. Dlatego wdrożenia serwowania często potrzebują więcej zapasu VRAM niż sugerują same wagi modelu.

Jak dobrać rozmiar GPU do modelu

Praktycznym pierwszym pytaniem jest, czy model mieści się na jednym GPU, czy musi być podzielony na kilka. Porównując powyższe względem swojego modelu, rozważ następujące czynniki:

• Pojemność VRAM decyduje, które modele się mieszczą. Kwantowany model 7B–13B w FP8 lub INT8 można serwować z pojedynczego akceleratora średniej klasy, podczas gdy model 70B w BF16 zazwyczaj wymaga karty o dużej pamięci lub węzła z wieloma GPU. Bardzo duże modele klasy frontier faktycznie wymagają wielu połączonych ze sobą topowych GPU.
• Przepustowość pamięci determinuje prędkość generowania tokenów. Dekodowanie autoregresywne odczytuje pełny zestaw wag dla każdego wygenerowanego tokena, więc pamięć klasy HBM (występująca na kartach do centrów danych) generuje tokeny znacznie szybciej niż karty konsumenckie oparte na GDDR przy tym samym rozmiarze modelu. Dla interaktywnego czatu przepustowość często ma większe znaczenie niż moc obliczeniowa.
• Obsługiwane precyzje decydują o tym, jak agresywnie można zmniejszyć model. Karty z obsługą tensorów FP8 i INT8 pozwalają serwować większe modele na mniejszej ilości VRAM i z wyższą przepustowością, pod warunkiem, że stos serwowania i schemat kwantyzacji modelu są kompatybilne.
• Połączenie między GPU ma znaczenie, gdy model rozciąga się na wiele GPU. Serwowanie równoległe tensorowo wymienia aktywacje między GPU na każdej warstwie, więc łącza klasy NVLink w węźle zapewniają znacznie lepsze opóźnienia niż konfiguracje tylko PCIe. W przypadku wdrożeń na pojedynczym GPU połączenie jest nieistotne.

Serwowanie na pojedynczym GPU kontra wielo-GPU

Jeśli model i jego maksymalna pamięć podręczna KV mieszczą się na jednym GPU, trzymaj się tego rozwiązania. Serwowanie na pojedynczym GPU całkowicie eliminuje narzut komunikacji między urządzeniami i jest prostsze w obsłudze. Przejdź do równoległości tensorowej lub serwowania wielowęzłowego tylko wtedy, gdy model naprawdę się nie mieści, ponieważ każdy dodany GPU wprowadza koszty synchronizacji i komplikuje autoskalowanie. Gdy potrzebujesz wielu GPU, preferuj instancje z powyższej listy, które łączą karty o dużej pamięci z szybkim połączeniem wewnątrz węzła, zamiast łączyć luźno sprzężone karty.

Funkcje dostawcy ważne dla serwowania, a nie trenowania

Poza samym krzemem, model operacyjny dostawcy decyduje, czy wdrożenie jest wykonalne. Przeglądając powyższe porównanie pod kątem obciążenia serwowania, a nie treningu, priorytety są inne:

• Czas zimnego startu i konfiguracji stają się kluczowymi kwestiami. Punkt końcowy serwowania, który skaluje się do zera między szczytami ruchu, ponosi koszt zimnego startu przy każdym skalowaniu w górę, więc szybkie uruchamianie i buforowanie obrazów bezpośrednio wpływają na opóźnienia na końcu.
• Szczegółowość rozliczeń zmienia ekonomię ruchu nieregularnego. Rozliczenia sekundowe lub minutowe pasują do punktów końcowych autoskalujących się, które uruchamiają i wyłączają instancje; rozliczenia godzinowe karzą taki model.
• Niezawodność na żądanie zamiast spot jest zwykle właściwym wyborem. Instancje przerywalne lub spot są doskonałe do treningu i zadań wsadowych, ale ryzykowne dla punktu końcowego skierowanego do użytkownika, gdzie przerwanie w trakcie żądania powoduje utratę ruchu na żywo. Spot nadal dobrze nadaje się do nieinteraktywnego wnioskowania wsadowego.
• Trwała pamięć i szybkie ładowanie modelu zmniejszają ból restartów. Wagi o wielkości wielu gigabajtów, które ładują się z zimnego magazynu obiektów przy każdym restarcie, dodają minuty przestojów; pamięć podręczna lub dołączone wolumeny skracają ten czas.
• Sieć i transfer danych wpływają na koszty przy dużej skali. Wnioskowanie o wysokiej przepustowości może przesyłać dużo danych na zewnątrz; sprawdź warunki transferu przed zobowiązaniem się do wdrożenia o dużym ruchu.

Wnioskowanie wsadowe kontra w czasie rzeczywistym oraz gdzie leżą koszty

Zdecyduj wcześnie, jaki tryb optymalizujesz. Serwowanie interaktywne w czasie rzeczywistym ceni niski czas do pierwszego tokena i stałe tempo tokenów na użytkownika, co sprzyja pamięci o wysokiej przepustowości i umiarkowanym rozmiarom wsadów. Wnioskowanie wsadowe lub offline ceni całkowitą przepustowość i może pakować duże wsady na tańszym lub przerywalnym sprzęcie, kosztem opóźnień na żądanie, ale z dużo lepszym kosztem na token. Wiele zespołów stosuje oba tryby: responsywną warstwę na żądanie dla użytkowników na żywo oraz wsadową warstwę opartą na spot do masowej generacji.

Jeśli chodzi o koszt wynajmu, serwowanie rozciąga się na całe spektrum. Mały kwantowany model na karcie średniej klasy jest tani i szeroko dostępny; modele frontier na wielo-GPU węzłach o dużej pamięci są rzadkie, droższe i czasem ograniczone pojemnością podczas szczytów popytu. Ponieważ stawki zmieniają się nieustannie i różnią w zależności od regionu i zobowiązań, traktuj powyższe porównanie na żywo jako źródło prawdy, a instancje porównuj według VRAM, klasy przepustowości, połączenia i modelu rozliczeń, a nie tylko ceny nominalnej.

Najczęściej zadawane pytania

Ile VRAM potrzebuję do serwowania LLM?

Zaplanuj miejsce na wagi modelu w wybranej precyzji plus znaczny zapas na pamięć podręczną KV, która rośnie wraz z długością kontekstu i liczbą jednoczesnych użytkowników. Jako ogólna wskazówka, kwantowane małe i średnie modele serwuje się z pojedynczej karty średniej klasy, podczas gdy duże modele w wyższej precyzji potrzebują karty o dużej pamięci lub kilku GPU. Zawsze planuj pod kątem szczytowej współbieżności, nie stanu bezczynności.

Czy GPU spot lub przerywalne nadają się do serwowania LLM?

Dla punktów końcowych w czasie rzeczywistym skierowanych do użytkownika zazwyczaj nie, ponieważ odzyskanie instancji może przerwać aktywne żądania i wymusić zimne restarty. Instancje spot dobrze nadają się do wnioskowania offline lub wsadowego, gdzie przerwy tylko opóźniają przepustowość, a nie przerywają sesję interaktywną. Wiele zespołów utrzymuje pojemność na żądanie dla ruchu na żywo i używa spot do zadań wsadowych.

Dlaczego przepustowość pamięci ma większe znaczenie niż moc obliczeniowa dla serwowania?

Dekodowanie token po tokenie odczytuje wagi modelu z pamięci dla każdego generowanego tokena, więc prędkość generowania jest ograniczona przez szybkość przesyłania pamięci przez GPU, a nie przez jego szczytowe FLOPS. Dlatego karty z pamięcią HBM do centrów danych generują tokeny szybciej niż karty konsumenckie trzymające ten sam model, i dlatego przepustowość jest kluczową kolumną do porównania powyżej.

Czy powinienem serwować na jednym GPU, czy rozdzielić na kilka?

Używaj pojedynczego GPU, gdy model i jego maksymalna pamięć podręczna KV się mieszczą, ponieważ unikasz wtedy komunikacji między urządzeniami i upraszcza to skalowanie. Przejdź do równoległości tensorowej na wielu GPU tylko wtedy, gdy model naprawdę się nie mieści, a gdy to robisz, wybierz instancje łączące karty o dużej pamięci z szybkim połączeniem wewnątrz węzła.