Zaplanuj powtarzalne uruchomienie PyTorch

Udowodnij jeden kompletny krok przed skalowaniem

Zablokuj wersje modelu i zbioru danych, wersje zależności, konfigurację treningu, ziarna losowe i skrót kontenera. Uruchom ładowanie modelu, pełny krok treningowy, ewaluację, zapis punktu kontrolnego i przywracanie punktu kontrolnego na jednym akceleratorze.

Użyj tej samej długości sekwencji i ustawień mikropartii, które są przewidziane dla dłuższego przebiegu. Mały pilotaż, który pomija stan optymalizatora lub używa krótszych sekwencji, może ukryć problem z pamięcią, który próbujesz zmierzyć.

Zmierz reprezentatywny krok optymalizacji

W istniejącym programie treningowym otocz reprezentatywny krok pomiarem szczytowego zużycia pamięci. Przykład zakłada, że model, batch i optymalizator zostały już zainicjalizowane na GPU. Uwzględnij krok optymalizatora, ponieważ część stanu jest tworzona leniwie.

torch.cuda.reset_peak_memory_stats()
optimizer.zero_grad(set_to_none=True)
loss = model(**batch).loss
loss.backward()
optimizer.step()
torch.cuda.synchronize()
peak_gib = torch.cuda.max_memory_allocated() / 2**30
print(f"Peak tensor memory: {peak_gib:.2f} GiB")

To raportuje szczytową alokację tensorów, a nie pełny ślad urządzenia. Sprawdź również zarezerwowaną pamięć, narzut środowiska uruchomieniowego i raport pamięci urządzenia systemu.

Wybierz DDP lub sharding z właściwego powodu

DistributedDataParallel utrzymuje replikę modelu na każdym procesie i synchronizuje gradienty. Jest przydatny, gdy pełny stan treningowy mieści się na każdym GPU i chcesz przetwarzać więcej danych równolegle; nie łączy VRAM w jedną ciągłą pulę.

Fully Sharded Data Parallel może rozdzielać parametry, gradienty i stan optymalizatora. Użyj go, gdy presja na pamięć uzasadnia sharding, i uwzględnij dodatkową komunikację oraz złożoność rozproszonych punktów kontrolnych.

Precyzja mieszana i checkpointing aktywacji to osobne wybory. Zweryfikuj zachowanie numeryczne dla niższej precyzji; zmierz koszt obliczeniowy ponownego przeliczania aktywacji, gdy checkpointing oszczędza pamięć.

Uruchom pilotaż na jednym węźle

Skrypt treningowy musi zainicjować wykonanie rozproszone i przypisać jeden proces do każdego GPU, korzystając z informacji o randze lokalnej. Dopasuj liczbę procesów do widocznych GPU. Poniższy przykład uruchomienia dotyczy skryptu obsługującego rozproszenie, a nie kompletnej implementacji treningowej.

torchrun --standalone --nproc-per-node=4 \
  train.py --config configs/pilot.yaml

Uruchom to tylko na udostępnionym węźle. Lokalne demo AnchorGPU nie wykonuje treningu ani nie przydziela zdalnych GPU.

Wybierz sprzęt na podstawie wyniku pilotażu

Użyj A100 jako tańszego punktu odniesienia 80 GB CUDA, a H100 przetestuj, jeśli obciążenie ma użyteczną ścieżkę specyficzną dla Hoppera. H200 oferuje większą konfigurację pamięci CUDA. MI300X oferuje większą pojemność na akcelerator w tym katalogu, pod warunkiem że cała aplikacja została zakwalifikowana na ROCm.

W przypadku AMD sprawdź niestandardowe rozszerzenia, jądra, wersje pakietów oraz obraz PyTorch testowany z ROCm jako kompletny zestaw. Zgodność na poziomie frameworka nie waliduje każdej opcjonalnej operacji.

Testuj przywracanie, nie tylko zapisywanie

Zapisz stan modelu, optymalizatora, harmonogramu, kroku treningowego, konfiguracji oraz skalera precyzji mieszanej, jeśli ma to znaczenie. Zapisz punkt kontrolny, zakończ proces, a następnie przywróć i wznów przed rozpoczęciem długiego przebiegu.

Użyj metody punktów kontrolnych odpowiedniej dla stanu rozproszonego. Przetestuj, czy zapisane artefakty można odczytać niezależnie od pierwotnego procesu i czy wynik ewaluacji pozostaje w oczekiwanej tolerancji.

Zaplanuj budżet na cały potok

Uwzględnij pobieranie, przetwarzanie wstępne, ładowanie danych, walidację, punkty kontrolne, eksport i kopiowanie wyników poza węzeł. Mierz przepustowość razem z pamięcią, przestojami ładowania danych, czasem komunikacji, czasem trwania punktów kontrolnych i jakością walidacji.

Okres 7-dniowy jest przydatny do ograniczonego testu zgodności i profilowania. Wybierz rezerwację 30-dniową dopiero po oszacowaniu użytecznej pracy i bufora operacyjnego. Więcej GPU pomaga tylko wtedy, gdy dodatkowe obliczenia przewyższają ograniczenia komunikacji i potoku wejściowego.