Hosting aplikacji opartych na sztucznej inteligencji: dobór wydajności procesorów, kart graficznych i pamięci masowej

Najpierw należy zawęzić zakres obciążenia związanego ze sztuczną inteligencją

Wybór sprzętu należy rozpocząć od zadania, a nie od karty graficznej. W przypadku Wnioskowanie Istniejący model przetwarza dane wejściowe i generuje na przykład odpowiedzi. Dostrajanie polega na dostosowaniu wstępnie wytrenowanego modelu do dodatkowych danych lub zadania; natomiast pełne trenowanie polega na budowaniu wag modelu w ramach oddzielnego cyklu trenowania.

Cele te skutkują różnymi profilami obciążenia: serwis czatowy musi reagować na zapytania, podczas gdy zadanie szkoleniowe przetwarza dane przez dłuższy czas i zapisuje wyniki pośrednie. Dla Hosting AI Dlatego powinieneś określić, czy na pierwszym planie znajduje się czas odpowiedzi, liczba obsłużonych zapytań, czas trwania szkolenia, czy też na przykład koszty danego zadania.

Należy udokumentować wersję modelu i czas działania, a także liczbę parametrów, architekturę, precyzję oraz planowaną kwantyzację. Należy również odnotować przewidywane długości danych wejściowych i wyjściowych, liczbę równoczesnych zapytań lub wielkość partii, a także obciążenie szczytowe. Dzięki temu można porównać oferty i późniejsze testy w oparciu o te same założenia, zamiast ograniczać się wyłącznie do zestawiania nominalnych danych dotyczących sprzętu.

W przypadku wewnętrznego asystenta czatu pojedyncze, krótkie zapytanie może przebiegać bez problemów, podczas gdy kilka długich rozmów może przeciążyć pamięć. Pamięć podręczna KV przechowuje dodatkowe stany podczas generowania tekstu; jej zapotrzebowanie zależy między innymi od modelu i przetwarzania. Dlatego należy uwzględnić nie tylko przeciętną długość dialogu, ale także długie konteksty i równoległe korzystanie z systemu.

Należy również określić, jakie dane są przetwarzane, gdzie mogą być przechowywane oraz jaki poziom dostępności i czas przywrócenia danych są wymagane. Te cele operacyjne mają wpływ na wybór między pojedynczym serwerem a bardziej złożoną architekturą. Założenia te stanowią jedynie punkt wyjścia: dopiero test z reprezentatywnym obciążeniem pokaże, czy są one uzasadnione.

Procesor i pamięć RAM w przygotowaniu

Nawet jeśli model działa na procesorze graficznym (GPU), procesor centralny (CPU) również uczestniczy w przetwarzaniu danych. Może on przyjmować zapytania, tokenizować tekst, odczytywać pliki oraz przygotowywać dane wejściowe do przetwarzania przez model. Jeśli przygotowanie to przebiega zbyt wolno, procesor graficzny (GPU) czeka na zadania; wówczas nawet większy procesor graficzny niekoniecznie rozwiąże ten wąski gardło.

Der Pamięć robocza W zależności od zastosowania zajmuje miejsce na elementy modelu, przygotowane dane i pamięć podręczną plików. Do tego dochodzi pamięć dla procesów, które ładują i przekształcają dane szkoleniowe. Należy zatem zaplanować nie tylko sam model, ale także ścieżkę od zbioru danych do gotowej partii oraz zapewnić wystarczające rezerwy na potrzeby szczytowego obciążenia podczas przetwarzania.

Moduł PyTorch-DataLoader może wykorzystywać wiele procesów roboczych do równoległego przetwarzania danych. Dodatkowe procesy robocze również zajmują jednak pamięć; nawet wspólna przestrzeń pamięci może okazać się niewystarczająca. Dlatego należy zwiększać ich liczbę stopniowo i obserwować czasy oczekiwania na dane oraz zapotrzebowanie na pamięć, zamiast przyjmować stałą wartość jako uniwersalną rekomendację.

Większa liczba rdzeni procesora jest pomocna przede wszystkim w sytuacjach, w których zadania mogą być wykonywane równolegle. Jeśli natomiast przepustowość jest ograniczona przez dostęp do pamięci masowej, pojedynczy etap przetwarzania lub sam procesor graficzny, dodatkowe rdzenie niewiele tu zmienią. Również częstotliwość taktowania może mieć znaczenie w przypadku krótkich zapytań; więcej informacji na ten temat można znaleźć w artykule poświęconym Regulator wydajności procesora na serwerach hostingowych.

W przypadku małych modeli lub sporadycznych zapytań wnioskowanie na procesorze (CPU) stanowi alternatywę wartą rozważenia w stosunku do systemu z procesorem graficznym (GPU) udostępnionego na stałe. Należy porównać oba warianty, stosując ten sam model, odpowiednią precyzję oraz zakładany profil obciążenia. Decydujące znaczenie ma to, czy procesor (CPU) osiąga wymagany czas odpowiedzi nawet w okresach szczytowego obciążenia oraz jakie koszty faktycznie się z tym wiążą.

Jak właściwie zrozumieć działanie procesora graficznego (GPU) i pamięci VRAM

W przypadku wnioskowania odbywającego się w całości na procesorze graficznym wagi modelu muszą zmieścić się w dostępnej pamięci procesora graficznego. Zapotrzebowanie na pamięć VRAM Ale to nie wszystko: środowisko uruchomieniowe wymaga dodatkowych obszarów na wyniki pośrednie i bufory tymczasowe. Karta, na której obliczeniowo mieszczą się wagi, nie stanowi zatem jeszcze pewnej podstawy do pracy produkcyjnej.

W przypadku autoregresyjnego generowania tekstu dochodzi jeszcze pamięć podręczna KV. Przechowuje ona już obliczone stany kluczy i wartości, aby można je było ponownie wykorzystać w kolejnych etapach generowania. Długie konteksty i jednocześnie przetwarzane zapytania mogą zwiększyć to dodatkowe zapotrzebowanie na pamięć; w jakim stopniu – zależy to od modelu i sposobu przetwarzania.

Dokumentacja do Transformers 4.48.2 opisuje między innymi kwantyzację pamięci podręcznej i wyładowywanie jako sposoby oszczędzania pamięci VRAM. Korzyści zależą jednak od sposobu implementacji i obciążenia; dodatkowe operacje przetwarzania lub transfery danych mogą spowolnić działanie. Należy zatem wspólnie sprawdzić zużycie pamięci i czas odpowiedzi, zamiast automatycznie traktować oszczędność pamięci jako wzrost wydajności.

Podczas uczenia się obliczenia wnioskowania są zdecydowanie niewystarczające. Oprócz wag pojawia się zapotrzebowanie na pamięć dla gradientów, stanów optymalizatora i zapisanych aktywacji. To, jak duże będą te części, zależy między innymi od optymalizatora, precyzji i metody uczenia; dłuższe sekwencje lub większe partie mogą w szczególności zwiększyć zapotrzebowanie na pamięć dla aktywacji.

Aby przetwarzanie odbywało się w całości na GPU, dostępna pamięć VRAM musi pomieścić wymagane wagi i dane dotyczące czasu działania. Metody hybrydowe mogą przechowywać część przetwarzania lub wagi modelu poza procesorem graficznym; ich przydatność oraz koszty transferu danych zależą od czasu działania. Należy to odróżnić od przenoszenia pamięci podręcznej KV opisanego w Transformers 4.48.2.

Należy wspólnie przeanalizować model, czas trwania oraz planowaną równoległość i sprawdzić maksymalne poziomy wykorzystania pamięci przy reprezentatywnym obciążeniu. Wystarczająca ilość pamięci dla wybranego sposobu wykonania nie stanowi jeszcze dowodu na osiągnięcie pożądanego czasu odpowiedzi lub wykorzystania zasobów.

Przybliżone obliczenie pojemności pamięci modeli

Wstępne obliczenia dotyczące pamięci opierają się na liczbie parametrów modelu oraz formacie, w jakim faktycznie zapisywane są ich wagi. Dostarczają one dolnej granicy dla tego udziału pamięci, ale nie stanowią jeszcze pełnego wymiarowania serwera GPU. W szczególności nie wskazują one, ile pamięci wymaga konkretne zapytanie w czasie wykonywania.

Przykład obliczeniowy o charakterze ilustracyjnym, nie jest to pomiar: Siedem miliardów parametrów pomnożonych przez dwa bajty daje 14 miliardów bajtów na wagi. Po podzieleniu przez 1 073 741 824 bajtów na GiB daje to około 13,0 GiB. Warunkiem jest, aby wszystkie rozpatrywane wagi faktycznie miały jednolity format dwóch bajtów na parametr; inne formaty lub dodatkowe reprezentacje zmieniają wynik obliczeń.

Nie obejmuje to Pamięć podręczna KV na generowanie tekstu, bufory tymczasowe i obciążenie związane z działaniem programu. Zwłaszcza w przypadku długich kontekstów pamięć podręczna może znacznie się powiększyć; również liczba jednocześnie przetwarzanych zapytań ma znaczenie dla wymaganej rezerwy. Dokumentacja pamięci podręcznej w Transformers 4.48.2 opisuje ponadto metody, które mogą oszczędzać pamięć, ale w zależności od metody mogą obniżać szybkość działania.

W przypadku uczenia się obliczenia dotyczące wielkości są zdecydowanie niewystarczające. Dokumentacja do Transformers 4.35.0 szacuje, że dla przykładowej konfiguracji o mieszanej precyzji z AdamW potrzeba 18 bajtów na parametr plus aktywacje. Liczba ta uwzględnia również inne elementy, takie jak gradienty i stany optymalizatora; aktywacje zależą między innymi od długości sekwencji i wielkości partii.

Te 18 bajtów nie stanowi ogólnego mnożnika dla każdego treningu: optymalizatory, precyzja i metody treningowe mogą wpływać na zapotrzebowanie. Dlatego ani z tej liczby, ani z wartości 13,0 GiB nie wynika zalecenie dotyczące konkretnej wielkości pamięci VRAM. O wyborze decyduje konkretny czas działania oraz przewidywane maksymalne zużycie pamięci przy reprezentatywnym obciążeniu.

Porównanie obciążeń i wąskich gardeł

Te same obciążenia modelowe mogą, w zależności od zadania, powodować bardzo różne wymagania. Tabela przedstawia możliwe punkty krytyczne, nie zawiera jednak żadnej hierarchii ani nie gwarantuje występowania wąskich gardeł. To, który zasób faktycznie stanowi ograniczenie, zależy między innymi od modelu, potoku danych, równoległości przetwarzania i obciążenia.

W przypadku wewnętrznego asystenta czatu model i generowanie to tylko część procesu planowania. Należy określić maksymalną długość wprowadzanych danych, oczekiwaną długość odpowiedzi oraz liczbę jednoczesnych użytkowników. Następnie można sprawdzić, czy czas odpowiedzi pozostaje na akceptowalnym poziomie w okresach szczytowego obciążenia oraz czy wagi, pamięć podręczna i bufor mieszczą się jednocześnie w dostępnej pamięci.

Wyszukiwanie dokumentów z odpowiedzią generatywną charakteryzuje się dłuższą ścieżką przetwarzania danych: dokumenty są importowane i przetwarzane, generowane są wektorowanie, przeszukiwany jest indeks, a trafne treści przekazywane są do modelu językowego. Import i wyszukiwanie mogą wiązać się z innymi wymaganiami dotyczącymi procesora, pamięci RAM i pamięci masowej niż generowanie odpowiedzi. Dlatego warto osobno rejestrować czasy trwania i zapotrzebowanie na pamięć tych etapów.

Podczas dostrajania można Akumulacja gradientu umożliwiają uzyskanie większego efektywnego rozmiaru partii, mimo że jednocześnie przetwarzane są tylko mniejsze pojedyncze partie. Gradienty z kilku kroków są gromadzone przed aktualizacją parametrów. Może to pomóc w przypadku ograniczonej pamięci, ale nie gwarantuje wzrostu przepustowości; dodatkowe etapy przetwarzania mogą wydłużyć czas realizacji.

Na szczególną uwagę zasługuje również sposób dostarczania danych: jeśli przetwarzanie wstępne lub ładowanie danych przebiega wolniej niż przetwarzanie modelu, większy procesor graficzny niekoniecznie będzie pomocny. Z drugiej strony szybki potok danych nie zastąpi zbyt małej pamięci VRAM. Dlatego należy porównywać alternatywne rozwiązania przy użyciu tych samych danych wejściowych i zrozumiałego profilu obciążenia.

Planowanie pamięci masowej i połączeń z procesorami graficznymi

Przy planowaniu pamięci warto rozróżnić dane według typu i sposobu dostępu: zbiory danych szkoleniowych są wielokrotnie odczytywane, a wagi modelu ładowane przed użyciem. Oba elementy wymagają niezawodnego źródła, z którego będą mogły zostać ponownie udostępnione po zmianie serwera. Sama pojemność nie wystarczy; na działanie systemu wpływają również czas ładowania i wzorce dostępu.

Tymczasowe dane robocze mogą być przechowywane na lokalnym dysku NVMe, jeśli potrzebna jest szybka przestrzeń robocza. Należy sprawdzić u dostawcy, czy dane te przetrwają ponowne uruchomienie systemu i zmianę hosta. Z kolei punkty kontrolne i kopie zapasowe wymagają starannie zaplanowanego przechowywania oraz sprawdzonej ścieżki przywracania; lokalny katalog roboczy nie stanowi automatycznie niezależnej kopii zapasowej.

Pamięć masowa dostępna wspólnie lub oparta na obiektach może ułatwić dystrybucję i przechowywanie zestawów danych, wag oraz punktów kontrolnych. Kluczowe znaczenie ma to, czy aplikacja obsługuje wybrany rodzaj dostępu oraz czy dane można załadować i przywrócić w przewidzianym czasie. Dodatkowa lokalna przestrzeń robocza może być przydatna, ale nie zastępuje trwałego przechowywania danych.

GPUDirect Storage w odpowiednich warunkach sprzętowych, programowych i związanych z systemem plików umożliwia bardziej bezpośrednią ścieżkę przesyłu danych między pamięcią masową a pamięcią procesora graficznego. Jest to szczególnie interesujące, gdy operacje wejścia i wyjścia znajdują się na ścieżce krytycznej, a aplikacja korzysta z obsługiwanej ścieżki. Jeśli procesor musi najpierw zdekodować lub wstępnie przetworzyć dane, może to ograniczyć korzyści płynące z tej funkcji.

W przypadku wielu procesorów graficznych należy rozróżnić replikację od podziału. Replikacja udostępnia kopie modelu w celu rozłożenia obciążenia; nie przekształca ona oddzielnych obszarów pamięci VRAM w wspólną pamięć w sposób automatyczny. Dokumentacja dotycząca wersji vLLM 0.20.1 opisuje takie równoległe udostępnianie danych; nie ma w niej żadnych informacji dotyczących innych wersji środowiska uruchomieniowego.

Z kolei równoległość tensorowa i potokowa rozdzielają części przetwarzania i powodują potrzebę komunikacji. W tym celu sprawdź połączenia między procesorami graficznymi, a w przypadku wielu serwerów – topologię sieci oraz obsługę przez model i środowisko uruchomieniowe. Dokumentacja dotycząca vLLM 0.8.5 omawia te strategie obsługi rozproszonej; zawarte w niej konkretne wskazówki są powiązane z daną wersją.

Wykrywanie wąskich gardeł pod obciążeniem

Międzynarodowe porównanie ma sens dopiero wtedy, gdy opiera się na udokumentowanych danych profil obciążenia. Należy określić wersję modelu, dokładność, konkretny wariant sprzętowy oraz wersję środowiska uruchomieniowego. Należy również podać typową i maksymalną długość kontekstu, długość wyników oraz liczbę równoczesnych zapytań. Pozwoli to na sprawdzenie późniejszych zmian w infrastrukturze w tych samych warunkach.

Podczas wnioskowania należy mierzyć czas do pojawienia się pierwszego tokenu oraz szybkość generowania. Należy również rejestrować błędy i czasy odpowiedzi zarówno przy zwykłym obciążeniu, jak i podczas spodziewanych szczytów. Wysoka średnia przepustowość nie wystarczy, jeśli poszczególne zapytania – w przypadku długich kontekstów lub wysokiego stopnia równoległości – czekają zbyt długo lub kończą się niepowodzeniem.

Jako punkt wyjścia do szkolenia i dostrajania warto wykorzystać kroki lub przetworzone przykłady w jednostce czasu. Należy również obserwować, jak długo potok danych każe czekać na kolejną partię. Moduł PyTorch-DataLoader może przygotowywać dane przy użyciu wielu procesorów; ich zapotrzebowanie na pamięć oraz obciążenie pamięci współdzielonej również należy uwzględnić w ocenie.

Rejestruj wartości szczytowe dotyczące pamięci GPU i pamięci RAM, a także obciążenia pamięci masowej i czasów oczekiwania. Na istniejącym systemie NVIDIA polecenie odczytu pokazuje nvidia-smi w zależności od urządzenia i sterownika, między innymi stan procesora graficznego i zajętość pamięci. Nie zmienia on konfiguracji produkcyjnej, ale nie zastępuje pomiarów przeprowadzanych przez aplikację.

Niskie obciążenie procesora graficznego samo w sobie nie wskazuje ani na problem z procesorem centralnym, ani z pamięcią masową. Porównaj je w czasie z czasami oczekiwania na dane, przebiegiem zapytań i zajętością pamięci, starając się zmieniać w każdym porównaniu tylko jedną istotną zmienną. Udokumentuj również ograniczenia testu, na przykład jeśli brakuje w nim rzadkich szczytów obciążenia lub szczególnie długich wpisów.

Niezawodne zarządzanie infrastrukturą sztucznej inteligencji

Planowanie eksploatacji obejmuje weryfikowalną kombinację wariantu GPU, sterownika, frameworka i środowiska uruchomieniowego modelu. Przed aktualizacją należy sprawdzić, które wersje są ze sobą kompatybilne oraz w jaki sposób w razie problemów można powrócić do poprzedniej kombinacji. W przypadku specjalnych ścieżek danych, takich jak GPUDirect Storage, sprzęt, oprogramowanie i system plików muszą dodatkowo być dostosowane do przewidywanego zastosowania.

Określ, kto może przeglądać lub modyfikować modele, dane szkoleniowe, protokoły i interfejsy administracyjne. W przypadku danych wrażliwych należy ponadto dostosować miejsce przechowywania, sposób przesyłania danych oraz okres przechowywania do wymogów dotyczących ochrony danych. Sprawdź te kwestie w odniesieniu do wszystkich zaangażowanych usług, a nie tylko do serwera, na którym działa model.

A Punkt kontrolny zapisuje stan treningu na potrzeby późniejszego wznowienia. Zaplanuj, jakie stany będą potrzebne Twojemu oprogramowaniu treningowemu, jak często mają być zapisywane i jak długo mają być przechowywane. Wagi modeli przeznaczone do dostarczenia oraz punkty kontrolne służące do wznowienia mają różne cele i powinny być odpowiednio oznaczone.

Lokalna pamięć robocza nie jest automatycznie trwała i nie zastępuje niezależnej kopii zapasowej. Zapytaj dostawcę, co stanie się z danymi lokalnymi w przypadku ponownego uruchomienia, wymiany serwera lub wygaśnięcia umowy. Przechowuj potrzebne dane niezależnie od środowiska roboczego i sprawdź w praktyce możliwość ich przywrócenia, w tym czas potrzebny do przywrócenia sprawności.

W przypadku zadań rozproszonych monitorowanie obejmuje nie tylko poszczególne procesory graficzne, ale także węzły, połączenia sieciowe oraz postęp całej aplikacji. Należy zaplanować, od jakiego zapisanego stanu zadanie ma zostać ponownie uruchomione po awarii oraz jakie zasoby muszą być w tym celu dostępne. Jeśli części modelu są rozłożone na wielu serwerach, ich połączenia również mają wpływ na działanie systemu; wskazówki zawarte w dokumentacji vLLM 0.8.5 odnoszą się konkretnie do tej wersji.

Wybierz model hostingu i serwer z procesorem graficznym

W przypadku prac dorywczych można skorzystać z tymczasowo udostępnionego Serwer z procesorem graficznym może być opłacalne: płacisz zgodnie z konkretnymi warunkami oferty za faktycznie wykorzystaną przepustowość, zamiast utrzymywać stałą rezerwę przepustowości. Porównaj przy tym również terminy uruchomienia, dostępność w wybranym terminie oraz koszty przechowywania danych i transmisji danych.

W przypadku równomiernego obciążenia opłaca się rozważyć rozwiązanie oparte na trwale zarezerwowanej infrastrukturze. Rozwiązanie to może zapewnić większą kontrolę nad czasem działania i ścieżką danych, wymaga jednak samodzielnego planowania aktualizacji, monitorowania i przywracania danych. Zarządzana usługa wnioskowania przejmuje część tych zadań; w zamian za to sprawdź, jakie modele, ustawienia i ścieżki danych są tam faktycznie dostępne.

W celu wyboru infrastruktury uczenia maszynowego proszę o podanie informacji dotyczących konkretny model procesora graficznego np.: pojemność pamięci VRAM, przepustowość pamięci, obsługiwane formaty obliczeniowe i konstrukcja. Nie należy bez weryfikacji przenosić wartości maksymalnych z jednej rodziny produktów na każdy wariant. Dane dotyczące wydajności należy porównywać wyłącznie z warunkami testowymi i konkretnym modelem, zamiast podejmować decyzję wyłącznie na podstawie teoretycznej wartości szczytowej.

W ofercie uwzględniono również rodzaj skalowania: instancje replikowane mogą rozdzielać żądania, podczas gdy podział modelu wymaga wsparcia ze strony środowiska uruchomieniowego i topologii połączeń. Dokumentacja vLLM omawia równoległość przetwarzania danych w wersji 0.20.1 oraz rozproszone serwowanie w wersji 0.8.5; informacji tych nie należy przenosić na inną wersję bez uprzedniej weryfikacji.

Najpierw określ model i profil obciążenia, następnie oszacuj pojemność pamięci i ścieżkę danych, a potem zbierz odpowiednie oferty. Następnie sprawdź czas odpowiedzi, błędy i zapotrzebowanie na zasoby, korzystając z reprezentatywnych zapytań lub danych szkoleniowych. Dalsze informacje dotyczące klasyfikacji znajdziesz w sekcji Hosting z wykorzystaniem procesorów graficznych (GPU) dla aplikacji internetowych. Bez takiego porównania obciążeń nie da się sformułować uniwersalnej rekomendacji dotyczącej karty graficznej.