Dlaczego szczyt pamięci przekracza twoje szacowanie?

Zdefiniować obciążenie przed wyborem licznika

«Model 7B» nie precyzuje ani reprezentacji wag, ani pracy do wykonania. Zapisz jego rewizję, framework, wersje rozszerzeń, format faktycznie ładowany i operację: trening, adaptację lub generowanie. Dla tekstu odnotuj długości wejścia i wyjścia; dla wizji rozdzielczość i liczbę obrazów. Model multimodalny wymaga zachowania obu tych wymiarów.

Przygotuj typowe wejście, jedno długie, ale oczekiwane, oraz jedno bliskie twojej granicy funkcjonalnej. Zachowaj je podczas porównań. Sprawdź kształty po tokenizacji, paddingu, grupowaniu lub zmianie rozmiaru: wartość zapisana w konfiguracji nie dowodzi kształtu faktycznie przetwarzanego.

Ustal również, co pozostaje jednocześnie w pamięci: jedna sekwencja, jeden mikrobatch, kilka żądań czy ewaluacja uruchomiona po treningu. Twoje pytanie staje się weryfikowalne: czy to pełne obciążenie mieści się na każdym używanym urządzeniu, także podczas jego najbardziej wymagającego etapu?

• Tożsamość próby: model lub kod, rewizja, zbiór wejść i ziarno, gdy istotne.
• Wymiary: batch, kontekst, generowane tokeny, rozdzielczość lub liczba jednoczesnych żądań.
• Środowisko: wybrany GPU, sterownik, Python, PyTorch, backend CUDA lub HIP/ROCm oraz ustawienia alokatora.
• Zakres: ładowanie, obliczenia, transfer, ewaluacja, eksport; pierwsze przejście lub przejście po rozgrzewce.

Obliczanie wag bez mieszania GB i GiB

Jeden GB to 1 000 000 000 bajtów; jeden GiB to 1 073 741 824 bajty. Używane tu liczniki PyTorch zwracają bajty. Zachowaj tę surową wartość w pliku wyników, a następnie zastosuj pojedynczą konwersję, aby porównać wiersze. Nazwa handlowa karty nie zastępuje pojemności faktycznie zadeklarowanej przez urządzenie.

Dla gęstego zestawu siedmiu miliardów parametrów przechowywanych po dwa bajty każdy wagi odpowiadają 14 000 000 000 bajtów: 14 GB, czyli około 13,04 GiB. Ta operacja nie obejmuje ani aktywacji, ani gradientów, ani pamięci KV, ani stanów optymizatora. Dodanie rezerwy 4 GiB daje około 17,04 GiB jako założenie przygotowawcze; nie dowodzi to, że obciążenie zmieści się w tej obwiedni.

Teoretyczny podział na cztery bity zakłada jednolite, kompaktowe przechowywanie. Rzeczywiste ładowanie skwantyzowane może dodać skale i inne informacje oraz zachować niektóre moduły w innej precyzji. Dlatego format przechowywania wag i format obliczeń muszą pojawić się w twojej karcie oddzielnie.

Źródła techniczne: NIST — przedrostki binarne i porównanie GB/GiB · Hugging Face — formaty i moduły skwantyzowane z bitsandbytes

W treningu zmierz pełny krok

Wagi współistnieją z innymi obiektami: gradientami, stanami optymizatora, aktywacjami potrzebnymi do przejścia wstecznego i tensorami tymczasowymi. Ich rozmiary zależą od pętli, precyzji i wymiarów obciążenia. Uniwersalna stała w bajtach na parametr ukryłaby między innymi wpływ mikrobatcha i wejść.

Instrumentuj przejście w przód, obliczenie straty, propagację wsteczną i aktualizację. Aby zaobserwować stany faktycznie tworzone przez twój optymizator, nie zatrzymuj się na ładowaniu modelu. Zachowaj również pomiar pierwszego pełnego kroku: udana rozgrzewka może już wykonać inicjalizację, którą musisz być w stanie sfinansować pamięciowo przy starcie.

Dodaj ewaluację i eksport, których potrzebuje twój projekt. Jeśli błąd występuje podczas ewaluacji, samo zmniejszenie batcha treningowego nie naprawi tej fazy. Adaptacja, która trenuje niewiele parametrów, może wciąż utrzymywać model bazowy i obszerne aktywacje.

Źródła techniczne: Hugging Face — kategorie pamięci podczas treningu

W inferencji śledź kontekst i współbieżność

W generowaniu autoregresyjnym z uwagą pamięć KV przechowuje stany powiązane z tokenami. Dla gęstej, jednolitej pamięci jej rozmiar zależy od warstw, głów KV, ich wymiaru, zachowanych tokenów i sekwencji obecnych jednocześnie. Użyj głów KV modelu, a nie automatycznie jego głów zapytań.

Przykład arytmetyczny: 32 warstwy, 8 głów KV, wymiar 128, 8 192 tokeny, dwa bajty na wartość i jedna sekwencja dają 1 073 741 824 bajty, czyli 1 GiB dla K i V razem. Cztery identyczne sekwencje dają 4 GiB dla samej tej pozycji. To obliczenie nie mierzy ani przepustowości, ani pełnego zajęcia GPU.

Dostosuj wzór do pamięci faktycznie używanej. Okno przesuwne nie musi zachowywać całej historii; pamięć statyczna może wstępnie alokować maksymalną pojemność. Skwantyzowane i odciążone pamięci również zmieniają problem. Zmierz oddzielnie początkowe przetwarzanie wejścia i generowanie, nie przypisując automatycznie całej ich różnicy pamięci KV.

Źródła techniczne: Hugging Face — strategie pamięci, alokacja statyczna i okna

Allocated i reserved: dwa odczyty, których się nie sumuje

memory_allocated opisuje bajty zajęte przez tensory śledzone przez PyTorch na urządzeniu. memory_reserved opisuje pamięć zarządzaną przez jego alokator z cache, w tym tę już używaną przez te tensory. Sumowanie obu liczy część pamięci dwukrotnie. Zachowaj je w dwóch oddzielnych kolumnach.

Ich warianty max rejestrują każdy szczyt od początku monitorowania lub od ostatniego resetu. Są to szczyty bezwzględne dla danego okresu, które obejmują alokacje obecne już na początku. Wynik nie reprezentuje automatycznie wyłącznie obiektów utworzonych przez daną fazę.

Odczyt systemowy może mieć szerszy zakres. Alokacje wykonane bezpośrednio przez bibliotekę CUDA, na przykład niektóre komunikacje NCCL, nie wszystkie są widoczne w alokatorze PyTorch. Różnica z narzędziem systemowym nie dowodzi więc sama w sobie wycieku.

Źródła techniczne: PyTorch — memory_allocated · PyTorch — memory_reserved · PyTorch — max_memory_allocated · PyTorch — alokacje poza jego alokatorem

Dlaczego różnica między dwoma szczytami nie mierzy pamięci podręcznej

Rozważmy wyłącznie dwa fikcyjne momenty z tabeli. Szczyt allocated wynosi 8 GiB, a szczyt reserved 12 GiB. Ich różnica, 4 GiB, nie jest różnicą obserwowaną w żadnym z tych dwóch momentów: ta wynosi odpowiednio 2 i 6 GiB. Dwa maksima nie opisują zawsze tego samego stanu.

Aby zbadać ich rozbieżność w danym momencie, odczytaj allocated i reserved w tym samym punkcie kontrolnym, po synchronizacji i bez nowej celowej operacji między odczytami. Otrzymasz różnicę liczników w tym momencie, a nie pomiar pamięci podręcznej KV modelu ani gwarancję, że cała ta różnica zaspokoi następną alokację.

Zachowaj też w raporcie backend alokatora. Dokumentacja PyTorch 2.14 precyzuje, że przy cudaMallocAsync max_memory_reserved może łączyć najwyższe poziomy z dwóch pul i podawać górną granicę jednoczesnego szczytu. Wzmacnia to konieczność zachowania nazwy i zakresu licznika.

Źródła techniczne: PyTorch — definicja i ograniczenie max_memory_reserved

Wyznacz granice każdej fazy przed odczytaniem jej szczytu

Operacje GPU mogą być kolejkowane, zanim zostaną ukończone. Aby zmierzyć każdą fazę, zakończ poprzednie zadania przed wyzerowaniem szczytów, a następnie poczekaj na koniec fazy przed odczytem. torch.cuda.synchronize czeka na kernele wszystkich strumieni wybranego urządzenia; ten wybór wyznacza wyraźną granicę dla tego protokołu.

reset_peak_memory_stats resetuje monitorowanie szczytów od bieżącego stanu; nie zwalnia tensorów programu. Najpierw odczytaj poziomy początkowe. Na końcu zachowaj oba szczyty bezwzględne i oba poziomy bieżące. Nie przedstawiaj odejmowania poziomu początkowego jako dokładnej objętości wszystkich tymczasowych tensorów: obiekty sprzed fazy również mogły zostać zwolnione w jej trakcie.

Ta instrumentacja może zmienić zwykłe nakładanie się faz. Użyj jej do zlokalizowania problemu, a następnie sprawdź także pełną pętlę z jej rzeczywistym harmonogramem. W przypadku wielu kart powtórz odczyty dla każdego urządzenia; pomiar na cuda:0 nie opisuje pozostałych GPU.

• 1. Nadaj fazie nazwę i zapisz jej dokładne dane wejściowe.
• 2. Zsynchronizuj urządzenie, a następnie odczytaj początkowe allocated i reserved.
• 3. Wywołaj reset_peak_memory_stats na tym samym urządzeniu.
• 4. Wykonaj zdefiniowaną fazę, zachowując wyniki potrzebne do dalszych kroków.
• 5. Zsynchronizuj, odczytaj szczyty i poziomy końcowe, a następnie zapisz sukces lub błąd.
• 6. Zachowaj surowy wynik, wymiary i konfigurację; nie uzupełniaj brakujących pomiarów zerem.

Źródła techniczne: PyTorch — synchronizacja urządzenia · PyTorch — zerowanie statystyk szczytowych

Rozróżnij pierwsze przejście i przejścia po rozgrzewce

Pierwsza próba i gotowa pętla nie odpowiadają na to samo pytanie. Zachowaj ślad wczytywania i pierwszego przejścia, a następnie udokumentuj liczbę iteracji rozgrzewkowych przed powtórzeniami. Nie usuwaj nieudanej inicjalizacji tylko dlatego, że kolejne przejścia byłyby lżejsze.

Skrypt IteraGPU rozróżnia model_load, inputs, cold_forward, warmup i warm_forward. Jego cold_forward to pierwsze przejście małego modelu po inicjalizacji urządzenia. Nie mierzy całego rozruchu serwera, sterownika ani usługi. Powtórzenia warm_forward pozostają w tym samym procesie i korzystają z jego istniejącego stanu.

W przypadku swojego modelu rozpocznij nową serię w nowym procesie, gdy zmieniasz warunek, który może pozostawić wcześniejsze obiekty lub rezerwacje. Zapisz kolejność prób i politykę rozgrzewania. Pięciokrotne uruchomienie tej samej pętli i uruchomienie pięciu procesów to nie ten sam protokół.

Korzystanie z notebooka i skryptu IteraGPU Lab v1

Zacznij od README, a następnie pobierz samodzielny notebook lub skrypt Python. Obliczenie estimate korzysta z biblioteki standardowej. Pomiar wymaga zainstalowanego PyTorch z kompatybilnym backendem GPU oraz dostępnego urządzenia; nie pobiera modelu ani pakietu. Notebook wymaga środowiska umiejętnego odczytać pliki ipynb.

Ćwiczenie pomiarowe wykorzystuje małą oryginalną sieć gęstą i syntetyczne dane wejściowe. Opcje batch, context i width opisują jej tensory; context nie jest tu długością prawdziwego LLM z pamięcią podręczną KV. Ten materiał służy do zbadania metody pomiaru i zmieniania jednego wymiaru. Nie wykazuje zdolności karty dla Twojego modelu badawczego.

Uruchom poniższe polecenia z katalogu zawierającego skrypt. Najpierw sprawdź raport environment. Jeśli brakuje PyTorch lub GPU, measure musi zakończyć się jawnie z kodem 2; żadnego wyniku CPU nie wolno interpretować jako pomiaru GPU. JSON wyjściowy udanego pomiaru jest tworzony w Twoim środowisku. Wybierz nową nazwę pliku dla każdej serii: skrypt odmawia nadpisania istniejącego wyniku.

Pierwsze polecenie powtarza obliczenie wag i hipotetycznej rezerwy 4 GiB. W kolejnych użyj urządzenia, które masz prawo obciążać, i na początku zachowaj umiarkowane wymiary. Zanotuj faktycznie używaną wersję PyTorch: odwołania techniczne na tej stronie opisują między innymi wersję 2.14, nie narzucając jej instalacji u Ciebie.

Działanie skryptu zostało sprawdzone na małym przypadku: lokalna RTX 5070 spoza katalogu, sterownik 610.62, Python 3.14.6 i PyTorch 2.11.0+cu128. Próba używała batch 1, kontekstu 16, szerokości 64, float32, jednej rozgrzewki i dwóch powtórzeń. Potwierdza ona tę ścieżkę wykonania, nie kwalifikując LLM, treningu ani GPU oferowanych do wynajęcia. Notebook jest dostarczany bez wyników, a tabela porównawcza bez rezultatów; zabezpieczenie braku PyTorch zostało również sprawdzone w osobnym środowisku.

python mesure_memoire.py estimate --parameters 7000000000 --bits 16 --reserve-gib 4
python mesure_memoire.py environment --device cuda:0
python mesure_memoire.py measure --device cuda:0 --batch 2 --context 128 --width 1024 --dtype float32 --warmup 3 --repeats 5 --output mesures.json

• Notebook do obliczeń i pomiarów ↓

  Samodzielny notebook do otwarcia, przejrzenia i uruchomienia w Twoim środowisku.

• Skrypt mesure_memoire.py ↓

  Obliczenia bez zewnętrznych zależności, kontrola środowiska i jawny pomiar GPU.

• Instrukcja obsługi katalogu ↓

  Wymagania wstępne, polecenia, zakres faz i granice interpretacji.

• Archiwum IteraGPU Lab v1 ↓

  Zebrane wersjonowane zasoby wraz z instrukcją obsługi i licencją.

• Licencja zasobów ↓

  Warunki ponownego wykorzystania dostarczonych plików.

Interpretacja awarii przed zmianą karty

Niepełna próba pozostaje użyteczną obserwacją. Zachowaj fazę, żądane wymiary, komunikat błędu i ostatnie dostępne wartości. Częściowy szczyt przed nasyceniem nie stanowi zapotrzebowania pamięciowego pełnego wykonania. Zmniejsz jeden wymiar, aby zbudować przypadek, który się udaje, a następnie szukaj granicy między sukcesem a porażką.

empty_cache zwalnia nieużywane bloki z cache alokatora, nie zwalniając wciąż żywych tensorów. To nie jest uniwersalne rozwiązanie przy zbyt dużym obciążeniu. Wywoływanie go między każdą iteracją zmienia warunki: udokumentuj ten wybór, zamiast mieszać te próby z tymi, które zachowują cache.

Jeśli proste liczniki nie wyjaśniają sytuacji, ślad pamięci może pomóc zidentyfikować alokacje w czasie. Jego zakres pozostaje ograniczony do alokacji widocznych dla PyTorch. Niski szczyt allocated nie wyklucza więc alokacji zewnętrznej lub innego użytkownika karty.

Źródła techniczne: PyTorch — co zwalnia empty_cache · PyTorch — ślady i granice widoczności pamięci

Zbuduj margines na podstawie porównywalnych obciążeń

Unikaj procentu marginesu przedstawianego jako uniwersalny. Margines musi pokrywać zidentyfikowane wahania: dłuższe wejście, dozwolony batch, ewaluacja, eksport, wersja biblioteki lub inne zajęcie karty. Przetestuj oczekiwane przypadki brzegowe, a następnie zapisz to, co pozostaje poza zakresem. Udane uruchomienie na jednym małym wejściu nie potwierdza maksymalnego obciążenia.

Zmieniaj jedną zmienną naraz: batch 1, a potem 2 przy stałym kontekście, albo konteksty 2048, a potem 4096 przy stałym batchu. Zachowaj tę samą treść i te same zasady przygotowania. Obcięcie, które usuwa niezbędną informację, czyni zadanie innym, nawet jeśli zmniejsza szczyt.

Jeśli dominują wagi, rozważ inny format, kontrolując jakość. Jeśli dominują aktywacje, microbatch lub checkpointing aktywacji mogą być tropem. Ten drugi wymienia pamięć na ponowne obliczenia: zmierz także czas i zweryfikuj wyniki. Jeśli dominuje cache KV, przeanalizuj kontekst, współbieżność i strategię cache. Dossier porównawcze uzupełnia to podejście wspólną regułą jakości.

Źródła techniczne: PyTorch — checkpointing aktywacji i ponowne obliczenia

Od śladu do decyzji o konfiguracji

Twoim oczekiwanym wynikiem jest krótka karta: szacunek wag, przetestowane maksymalne obciążenie, udane lub nieudane fazy, cztery liczniki z jednostkami, środowisko i wybrany wariant. Dołącz surowy wynik do tej karty. Oddziel to, co obliczyłeś, od tego, co zaobserwowałeś, i od tego, co wciąż zakładasz.

Następnie porównaj potrzeby z możliwościami każdej karty, zachowując ograniczenia programowe. Wiele GPU wymaga podziału pracy i danych; ich obecność nie tworzy automatycznie jednego wspólnego zasobu pamięci dla aplikacji. Błąd na jednej karcie może się utrzymywać mimo wolnej pamięci na innej.

Protokół PyTorch korzysta z interfejsu torch.cuda; kompilacja HIP/ROCm PyTorch ponownie używa tej nazwy. Zidentyfikuj faktycznie zainstalowany backend, zanim porównasz dwie rodziny sprzętu. Użycie tej samej funkcji Pythona nie dowodzi, że jądra, precyzje lub wyniki są równoważne.

Kalkulator rozmiaru pozwala wrócić do początkowego założenia; karty GPU pozwalają porównać możliwości. Następnie wróć do tego samego przypadku roboczego, aby zweryfikować wybór. Mała sieć z pobierania pozostaje ćwiczeniem z instrumentacji: tylko uruchomienie własnego obciążenia, w udokumentowanym środowisku, może potwierdzić twój własny margines.

Źródła techniczne: NVIDIA — podział pracy na wiele GPU · PyTorch — interfejs torch.cuda w kompilacjach HIP/ROCm