Przewodnik po obciążeniach GPU
Ile pamięci VRAM GPU faktycznie potrzebujesz?
Praktyczny budżet pamięci dla wnioskowania, dostrajania, generowania obrazów i obciążeń wideo — od 24 GB do 192 GB.
Autor: AnchorGPU · Zaktualizowano · 6 min czytaniaVRAM to budżet, a nie etykieta modelu
Pamięć GPU jest zużywana przez kilka niezależnych kategorii: wagi modelu, pamięć podręczną KV wnioskowania, tymczasowe aktywacje, obszary robocze frameworka, pamięć podręczną alokatora oraz — podczas trenowania — gradienty i stan optymalizatora. To, że model mieści się w jednej konfiguracji, nie dowodzi, że zmieści się z dłuższym kontekstem, większą partią, inną precyzją lub większą liczbą równoczesnych żądań.
Planuj na podstawie dokładnej wersji modelu i konfiguracji środowiska uruchomieniowego. Etykiety takie jak 7B, 13B czy 70B opisują skalę parametrów, a nie całkowitą pamięć operacyjną, więc nigdy nie należy ich uniwersalnie mapować na GPU.
Najpierw oszacuj surowe wagi
Jako jawnie hipotetyczny przykład załóżmy, że model ma dokładnie 13 miliardów parametrów i przechowuje każdy parametr w formacie 16-bitowym. Surowe przechowywanie wag to 13,000,000,000 × 2 bajtów = 26,000,000,000 bajtów, czyli około 24.2 GiB. Ta liczba nie obejmuje żadnych innych alokacji, więc jest dolną granicą, a nie rekomendacją GPU.
Kwantyzacja może zmniejszyć pamięć wag, ale rzeczywiste zużycie obejmuje również skale, metadane, bufory dekwantyzacji, zduplikowane tensory i przestrzenie robocze środowiska uruchomieniowego. Użyj formatu generowanego przez rzeczywisty loader, zamiast dzielić liczbę parametrów przez nominalną szerokość bitową i traktować wynik jako ostateczny.
Wnioskowanie dodaje pamięć podręczną KV i pamięć roboczą
Serwowanie autoregresyjne przechowuje tensory kluczy i wartości dla aktywnych sekwencji. Zapotrzebowanie na pamięć podręczną KV zależy od architektury modelu, precyzji pamięci podręcznej, liczby współbieżnych sekwencji oraz liczby aktywnych tokenów w tych sekwencjach. Zwiększenie maksymalnego kontekstu lub współbieżności może wyczerpać pamięć nawet wtedy, gdy wagi ładują się poprawnie.
Tymczasowe aktywacje, przestrzenie robocze uwagi, skompilowane jądra, bufory komunikacyjne i alokator frameworka zużywają dodatkową pamięć. vLLM raportuje dostępną pojemność pamięci podręcznej KV GPU i szacowaną współbieżność dla skonfigurowanej długości sekwencji; traktuj te wartości początkowe jako dowód planistyczny, a następnie odtwórz reprezentatywne prompty przed zatwierdzeniem obciążenia produkcyjnego.
Trening ma inny profil pamięci
Dostrajanie dodaje gradienty, stan optymalizatora, zapisane aktywacje, a czasem dodatkowe kopie w pełnej precyzji. Ich dokładny rozmiar zależy od optymalizatora, polityki precyzji, zestawu trenowanych parametrów i strategii podziału, więc pojedynczy mnożnik wnioskowania jest mylący.
DistributedDataParallel replikuje stan treningowy potrzebny każdemu procesowi roboczemu; nie zamienia kilku procesorów GPU w jedną ciągłą pulę pamięci. Fully Sharded Data Parallel może dzielić parametry, gradienty i stany optymalizatora między procesy robocze, natomiast checkpointing aktywacji zmniejsza pamięć zapisanych aktywacji przez ponowne obliczanie wybranej pracy podczas przejścia wstecznego. Obie techniki wymieniają prostotę lub moc obliczeniową na pamięć.
Zmierz konfigurację, którą zamierzasz uruchomić
Przetestuj ładowanie modelu i kompletne reprezentatywne żądanie wnioskowania lub krok treningowy, w tym aktualizację optymalizatora, z dokładnymi ustawieniami frameworka, precyzji, kontekstu, partii i równoległości. Zanotuj szczytową przydzieloną i zarezerwowaną pamięć, a następnie powtórz z realistyczną współbieżnością lub akumulacją gradientów. Pozostaw zapas operacyjny zamiast dążyć do ostatniego dostępnego bajtu.
Wybierz GPU z większą pamięcią, gdy zmierzonego szczytu nie można bezpiecznie zredukować. Dodawaj GPU tylko wtedy, gdy oprogramowanie jawnie dzieli model lub obciążenie, a dostarczone połączenie międzyprocesorowe jest znane. Powtórz pomiar po każdej zmianie modelu, środowiska uruchomieniowego, kwantyzacji, kontekstu lub partii.
Źródła i metoda redakcyjna
Oficjalna dokumentacja wspiera wyjaśnienia techniczne. Rekomendacje sprzętowe są naszą interpretacją zależną od obciążenia, a nie zmierzoną gwarancją wydajności.
vLLM — równoległość i skalowanie ↗PyTorch — FullyShardedDataParallel ↗PyTorch — checkpointing aktywacji ↗