Szkolenie Amazon EKS NVRx skraca odzyskiwanie po awarii GPU z minut do sekund
Amazon EKS zintegrował NVIDIA NVRx ze stosem szkoleniowym umożliwiającym odtwarzalne wyniki, który odzyskiwał sprawność po celowo wywołanych awariach GPU w około 10–17 sekund. Projekt szkolenia Amazon EKS NVRx utrzymał również efektywność punktów kontrolnych powyżej 99% w wybranych testach obejmujących od 16 do 64 GPU H100. Wyniki te podważają kosztowne założenie, że niezawodne odzyskiwanie musi zaczynać się od restartowania kontenerów lub przebudowy całego zadania Kubernetes.
System łączy PyTorch Fully Sharded Data Parallel, czyli FSDP, z trzema odrębnymi możliwościami NVRx. Asynchroniczne punkty kontrolne przenoszą zapisy do pamięci masowej poza pętlę szkoleniową. Restart w procesie odtwarza stan rozproszony bez zastępowania procesu Python. Komponent ft_launcher uruchamia nowe procesy robocze w istniejącym zadaniu po poważniejszych awariach.
Najważniejsza rywalizacja nie toczy się więc między AWS a innym dostawcą chmury. Chodzi o odzyskiwanie świadome aplikacji kontra odzyskiwanie oparte wyłącznie na infrastrukturze. Kubernetes nadal odpowiada za harmonogramowanie i awarie na poziomie węzłów, lecz NVRx obsługuje błędy bliżej procesu szkoleniowego. AWS twierdzi, że taki podział znacząco skraca czas, przez który sprawne, kosztowne GPU czekają na uszkodzonego współpracownika.
Szkolenie Amazon EKS NVRx przenosi odzyskiwanie do wnętrza zadania
Kluczowa zmiana polega na tym, że awaria procesu roboczego nie musi już przeradzać się w pełne zdarzenie cyklu życia kontenera.
AWS i NVIDIA zbudowały środowisko referencyjne wokół Amazon EKS, samodzielnie zarządzanych grup węzłów GPU oraz PyTorch FSDP. W ich opublikowanym benchmarku wykorzystano instancje p5.48xlarge, z których każda zawiera osiem GPU NVIDIA H100 z 80 GB pamięci.
Testowany klaster skalował się od dwóch do ośmiu węzłów, czyli od 16 do 64 GPU. Każda instancja udostępniała również 32 interfejsy Elastic Fabric Adapter do komunikacji o wysokiej przepustowości. Amazon FSx for Lustre zapewniał współdzieloną pamięć punktów kontrolnych dla podów szkoleniowych.
NVRx, skrót od NVIDIA Resiliency Extension, to pakiet Python dodający komponenty odzyskiwania i punktów kontrolnych do obciążeń PyTorch. Nie wymaga forka PyTorch, niestandardowych jąder ani rekompilacji. Zespoły mogą dodawać jego możliwości niezależnie, zamiast zastępować cały framework szkoleniowy.
Ta modułowa konstrukcja ma znaczenie, ponieważ wydajność punktów kontrolnych i odzyskiwanie po awarii to różne problemy. Dane obciążenie może potrzebować szybszych zapisów bez odzyskiwania procesu. Inne może wymagać ochrony przed awariami procesów przy zachowaniu dotychczasowej implementacji punktów kontrolnych.
Architektura referencyjna traktuje każdą warstwę zgodnie z zakresem jej awarii. Restart w procesie obsługuje wyjątki i zawieszenia komunikacji, które pozostawiają interpreter Python aktywny. ft_launcher obsługuje zdarzenia takie jak SIGKILL, zakończenie z powodu braku pamięci oraz niektóre zawieszenia na poziomie systemu operacyjnego.
Kubernetes pozostaje zewnętrzną warstwą dla awarii usuwających cały węzeł. Podejście to przypomina zbiór zagnieżdżonych stref odzyskiwania. Każdy mechanizm interweniuje tylko wtedy, gdy awaria przekroczy granicę warstwy znajdującej się poniżej.
Pody szkoleniowe używają bezgłowych usług Kubernetes Services do wykrywania równorzędnych procesów. Procesy robocze odnajdują się przez DNS zamiast stałych adresów IP. Taki układ pomaga zastępczym procesom roboczym wracać do działania bez konieczności przepisywania konfiguracji zadania przez operatorów.
AWS wcześniej opisywał elastyczne szkolenie rozproszone w EKS z użyciem narzędzi PyTorch. Prace nad NVRx jeszcze bardziej zawężają pętlę odzyskiwania. Koncentrują się na utrzymaniu produktywności aktywnego zadania, gdy poszczególne rangi zawodzą, zatrzymują się lub znikają.
To rozróżnienie tworzy główne napięcie artykułu. Kubernetes może przywracać infrastrukturę, ale odzyskiwanie infrastruktury nie ma szczegółowej wiedzy o stanie modelu, grupach procesów ani czasie tworzenia punktów kontrolnych. NVRx przenosi te decyzje do aplikacji szkoleniowej.
Blokujące punkty kontrolne pochłaniały około 40% czasu ściennego
Pierwszym problemem wydajności nie były obliczenia GPU. Był nim czas, który każda ranga spędzała, czekając na zapis danych punktu kontrolnego do pamięci masowej.
Synchroniczny punkt kontrolny wstrzymuje szkolenie, aż wymagany stan modelu i optymalizatora zostanie zapisany. W rozproszonym zadaniu FSDP taka przerwa dotyczy każdej uczestniczącej rangi. Sprawne GPU pozostają przydzielone, lecz podczas zapisu nie wykonują obliczeń propagacji w przód ani wstecz.
AWS poinformował, że synchroniczne punkty kontrolne zapewniały jedynie od 57% do 61% efektywności szkolenia w testach skalowania. Zapisy do pamięci masowej trwały około 275 sekund, a czas ten pozostawał zasadniczo stały między 16 a 64 GPU. Dodanie mocy obliczeniowej nie eliminowało zatem przerwy ograniczanej przez pamięć masową.
Asynchroniczne punkty kontrolne NVRx zmieniają ścieżkę zapisu. Proces szkoleniowy przygotowuje stan na CPU i przekazuje zadanie trwałemu procesowi działającemu w tle. Główny proces przechodzi następnie do kolejnego kroku szkoleniowego, podczas gdy wejście/wyjście pamięci masowej trwa nadal.
Implementacja wykorzystuje TorchAsyncCheckpoint oraz metodę async_save(). Przed rozpoczęciem kolejnego zapisu lub przed zakończeniem działania aplikacja finalizuje oczekującą operację. Ta koordynacja zapobiega cichemu kolidowaniu niedokończonego punktu kontrolnego z następnym.
Lokalne słowniki stanów FSDP wzmacniają ten projekt. Każda ranga zapisuje własny fragment, unikając operacji all-gather i wąskiego gardła pojedynczego zapisu przez rangę zero. Dokumentacja FSDP PyTorch opisuje szerszy model shardingu, który rozdziela parametry między uczestniczące procesy robocze.
Przy interwale punktu kontrolnego wynoszącym 1 000 kroków AWS twierdzi, że asynchroniczne punkty kontrolne NVRx osiągnęły 99,2% efektywności szkolenia na dwóch węzłach. Na ośmiu węzłach efektywność osiągnęła 99,8%. Porównanie synchroniczne osiągnęło 60,3% na ośmiu węzłach.
Te wartości są wynikami benchmarków raportowanymi przez dostawcę, a nie gwarancjami dla każdego modelu lub konfiguracji pamięci masowej. Mimo to mechanizm stojący za nimi jest prosty. Jeśli obliczenia trwają dłużej niż zapis do pamięci masowej, operacja w tle może zostać niemal całkowicie ukryta za użyteczną pracą szkoleniową.
Granica stała się wyraźna, gdy AWS zwiększył częstotliwość punktów kontrolnych. Na ośmiu węzłach i przy jednym punkcie kontrolnym co 100 kroków efektywność synchroniczna spadła do 14,7%. Efektywność asynchroniczna również spadła, ale pozostała wyższa i wyniosła 29,6%.
Powodem było tempo. Sto kroków szkoleniowych zajmowało około 280 sekund, podczas gdy zapis punktu kontrolnego trwał około 275 sekund. Praktycznie nie pozostawało wolne okno obliczeniowe, które mogłoby ukryć kolejną operację pamięci masowej.
To jest rzeczywiste ograniczenie asynchronicznych punktów kontrolnych NVRx. Asynchroniczne wejście/wyjście może ukryć zapis za obliczeniami, ale nie może uczynić pamięci masowej nieskończenie szybką. Gdy zapisy napływają równie szybko, jak system plików potrafi je ukończyć, kolejka w końcu zaczyna wywierać presję.
Nawet przy tym ograniczeniu funkcja zmienia sposób, w jaki zespoły mogą wybierać interwały punktów kontrolnych. Systemy synchroniczne zachęcają do rzadszych punktów kontrolnych, ponieważ każdy zapis powoduje widoczny czas bezczynności. Rzadkie zapisy zwiększają następnie ilość szkolenia traconego po awarii.
Asynchroniczne punkty kontrolne osłabiają ten kompromis. Zespoły mogą zapisywać częściej, gdy między zapisami istnieje wystarczająca ilość obliczeń. Krótszy interwał zmniejsza dystans cofania, a nakładające się wejście/wyjście pozwala zachować większą część inwestycji w GPU.
Rezultatem nie jest po prostu szybsze API punktów kontrolnych. To inna równowaga między efektywnością w stanie ustalonym a postępem możliwym do odzyskania. Równowaga ta staje się cenniejsza, gdy zadania trwają dłużej i obejmują więcej komponentów podatnych na awarie.
Restart w procesie podważa model odzyskiwania oparty wyłącznie na Kubernetes
Najszybsza ścieżka odzyskiwania zachowuje proces Python i odtwarza wyłącznie zasoby rozproszone uszkodzone przez awarię.
W implementacji referencyjnej NVRx opakowuje główną funkcję szkoleniową kontrolerem restartu w procesie. Jeśli wystąpi obsługiwany wyjątek, opakowanie przerywa aktywną próbę i przygotowuje kolejne wywołanie. Zewnętrzny proces Python pozostaje aktywny przez całą tę sekwencję.
NVRx najpierw przerywa uszkodzoną rozproszoną grupę procesów PyTorch. Może zbierać ślady rejestratora lotu, zatrzymywać backendy NCCL i niszczyć nieprawidłową grupę. NCCL to biblioteka komunikacyjna NVIDIA do operacji kolektywnych między GPU.
Kontrole kondycji następnie badają zasoby powiązane z każdą rangą. Mogą one obejmować GPU, połączenia NVLink, interfejsy sieciowe oraz powtarzające się awarie rang. Kontroler ponownych prób ogranicza liczbę prób restartu i określa, ile aktywnych rang musi przetrwać.
System ponownie przypisuje ocalałe rangi do ciągłej grupy i rozpoczyna nowe uzgadnianie. Opakowana funkcja szkoleniowa odtwarza model FSDP, ładuje najnowszy punkt kontrolny i wznawia pracę. Interpreter Python oraz obiekty znajdujące się poza opakowaną funkcją pozostają dostępne.
Technika ta jest skierowana na miękkie awarie. Przykłady obejmują nieobsłużone wyjątki aplikacji i zawieszenia NCCL, które może wykryć watchdog. Nie zakłada ona, że wyjątek Python niezawodnie pojawi się po każdym zablokowanym wywołaniu natywnym.
Zamiast tego watchdog postępu rejestruje aktywność między operacjami kodu bajtowego Python. Oddzielny wątek monitorujący sprawdza współdzielony stan i może zażądać restartu, gdy jedna ranga przestanie robić postępy. System następnie koordynuje przerwanie między uczestniczącymi procesami roboczymi.
AWS porównał to podejście z ft_launcher oraz bazowym odzyskiwaniem Kubernetes. Eksperyment wykorzystał dwa węzły p5.48xlarge, 16 GPU H100 i Llama 3.1 8B w konfiguracji FSDP. Zadanie działało przez 2 000 kroków i zapisywało stan co 500 kroków.
Badacze wprowadzili pięć deterministycznych awarii do każdego uruchomienia, stosując ten sam harmonogram. Restart NVRx w procesie odzyskiwał sprawność po każdej awarii w około 10 sekund bez restartowania kontenerów. AWS zmierzył 31% użytecznego postępu szkoleniowego i 87% użytecznej dostępności infrastruktury.
Użyteczny postęp szkoleniowy mierzy czas, który tworzy prawidłowy postęp szkolenia. Użyteczna dostępność infrastruktury mierzy czas, w którym przydzielona infrastruktura pozostaje operacyjna i dostępna. Różnica między nimi obejmuje pracę, która nie posuwa modelu naprzód, w tym cofanie postępu i ładowanie punktów kontrolnych.
Bazowe odzyskiwanie Kubernetes zajmowało około 270 sekund na każdą wstrzykniętą awarię. W raportowanym eksperymencie zapewniło 11,5% użytecznego postępu szkoleniowego i 35,8% użytecznej dostępności infrastruktury. To sprawia, że porównanie wykracza poza optymalizację uruchamiania kontenerów.
Według AWS jedna uszkodzona ranga wywoływała limity czasu komunikacji w ocalałych rangach. Pody były następnie restartowane bez synchronizacji, powodując powtarzające się cykle limitów czasu i zachowanie CrashLoopBackOff. Orkiestrator przywracał kontenery, nie rozumiejąc, w jaki sposób rozproszona grupa szkoleniowa musi odzyskiwać sprawność jako całość.
Odzyskiwanie świadome aplikacji ma dostęp do tego brakującego kontekstu. Wie, kiedy postęp się zatrzymał, która grupa procesów stała się nieprawidłowa i który punkt kontrolny może wznowić szkolenie. Kubernetes widzi stan podów i kondycję węzłów, lecz nie pełną semantykę kroku szkoleniowego FSDP.
Nie oznacza to, że odzyskiwanie Kubernetes staje się niepotrzebne. Martwy węzeł nie może zachować swojego interpretera, stanu CUDA ani lokalnych procesów. Zastępowanie węzłów nadal należy do warstwy klastra, a odzyskane procesy robocze nadal wymagają trwałych danych punktów kontrolnych.
Presja spada na zespoły, które polegają na restartach podów jako jedynej polityce odporności na awarie. Takie podejście pozostaje proste, ale jego okno odzyskiwania może marnować znaczną ilość czasu akceleratorów. Większe klastry wzmacniają ten koszt, ponieważ jedna awaria może unieruchomić wiele skądinąd sprawnych procesów roboczych.
Odporność na awarie NVRx rozdziela miękkie i twarde awarie
Żaden pojedynczy mechanizm restartu nie obejmuje wszystkich awarii, dlatego odporność na awarie NVRx rozdziela odzyskiwanie zachowujące proces od zastępowania procesów roboczych.
Komponent ft_launcher obsługuje awarie, których nie da się przetrwać poprzez restart w procesie. Obejmują one SIGKILL, zakończenia z powodu braku pamięci oraz błędy, po których nie pozostaje używalny interpreter Python. Zastępuje torchrun, zachowując znane koncepcje rendezvous.
Każdy rank treningowy tworzy RankMonitorClient po inicjalizacji rozproszonej. Klient wysyła sygnały heartbeat podczas treningu. Serwery monitorujące dla poszczególnych ranków porównują te sygnały z limitami czasu skonfigurowanymi dla normalnych warunków oraz początkowego uruchamiania.
Konfiguracja AWS używała 900-sekundowego limitu czasu heartbeat dla ranku. Początkowy limit czasu heartbeat wynosił 1 200 sekund, dając więcej czasu na pierwsze ładowanie modelu. Pięciosekundowy interwał monitorowania określał, jak często launcher sprawdzał stan workerów.
Wartości te są przykładami konfiguracji, a nie uniwersalnymi zaleceniami. Limit czasu heartbeat musi przekraczać najdłuższe uzasadnione opóźnienie między sygnałami. Jeśli jest zbyt krótki, wolne checkpointy lub inicjalizacja modelu mogą wyglądać jak awaria workerów.
Gdy worker umiera lub przestaje odpowiadać, ft_launcher kończy działanie pozostałych workerów. Odzyskuje pamięć GPU, uruchamia kolejne rendezvous i startuje nowe procesy w ramach tego samego zadania. Nowi workerzy przywracają stan z najnowszego checkpointu.
Przewodnik po launcherze przedstawia ten sam ogólny wzorzec w stosie NeMo RL firmy NVIDIA. Ta szersza integracja sugeruje, że NVRx ma być wielokrotnie wykorzystywaną warstwą odporności, a nie narzędziem wyłącznie dla EKS.
AWS zmierzył około 17 sekund odzyskiwania po każdej wstrzykniętej awarii z użyciem ft_launcher. Zgłoszony przebieg osiągnął 25,5% goodputu treningowego i 85,9% goodputu infrastruktury. Było to wolniejsze niż odzyskiwanie w procesie, ale znacznie szybsze niż 270-sekundowa bazowa konfiguracja Kubernetes.
Różnica odzwierciedla ilość stanu zachowywanego przez każdą metodę. Restart w procesie utrzymuje interpreter i proces nadrzędny przy życiu. ft_launcher musi utworzyć nowych workerów, zainicjalizować stan rozproszony, odbudować model oraz ponownie wczytać checkpoint.
Przy większej skali ładowanie checkpointu może dominować czas odzyskiwania. Szybsze tworzenie procesów nie eliminuje potrzeby odczytu shardów modelu i optymalizatora. Przepustowość współdzielonego systemu plików pozostaje więc częścią projektu odporności na awarie.
Architektura treningowa Amazon EKS NVRx korzystała z systemu plików FSx for Lustre SCRATCH_2 w tej samej strefie dostępności co węzły GPU. Takie rozmieszczenie miało zmniejszyć opóźnienie odczytu checkpointów. Po odzyskaniu wszyscy workerzy mogli uzyskać dostęp do tego samego utrwalonego stanu.
Asynchroniczne checkpointowanie NVRx jest niezależne od obu ścieżek restartu. Redukuje czas bezczynności związany z zapisem i ogranicza ilość postępu zagrożonego utratą. Warstwa restartu określa, jak szybko workerzy wracają do działania po awarii.
To rozdzielenie daje operatorom więcej możliwości, ale zwiększa też nakład pracy związany z politykami. Muszą zdecydować, które wyjątki mogą wywołać odzyskiwanie w procesie, ile ponowień jest bezpiecznych i które kontrole kondycji powinny usunąć rank. Muszą również ustawić limity czasu heartbeat i rendezvous.
NVIDIA określa projekt NVRx jako eksperymentalny i aktywnie rozwijany. Jego dokumentacja ostrzega, że funkcje i interfejsy mogą się zmieniać. Zespoły produkcyjne powinny traktować wybór wersji i testowanie aktualizacji jako część planu odporności.
AWS użył NVRx 0.4.1 do odtworzenia benchmarku. Wpis rekomenduje wersję 0.6.0 wraz ze zaktualizowaną konfiguracją launchera dla aktualnego wdrożenia. To rozróżnienie wersji ma znaczenie, ponieważ systemy odporności na awarie działają bezpośrednio na krytycznych ścieżkach uruchamiania i odzyskiwania.
Nieskuteczny mechanizm odzyskiwania może być gorszy niż brak automatyzacji, jeśli wielokrotnie restartuje zadanie, którego nie da się odzyskać. Limity ponowień, minimalny rozmiar world size i liczniki awarii zapobiegają nieograniczonym pętlom. Operatorzy nadal potrzebują alertów odróżniających udane odzyskanie od powtarzających się awarii.
Wynik 99% ma istotne ograniczenia
Benchmark potwierdza skuteczność mechanizmu, ale nie ustanawia 99% efektywności dla każdego rozproszonego obciążenia treningowego.
AWS przetestował jedną główną konfigurację modelu: Llama 3.1 8B z PyTorch FSDP na instancjach p5 opartych na H100. Użyto sieci EFA i pamięci FSx for Lustre. Inne rozmiary modeli, ścieżki pamięci masowej, formaty checkpointów i czasy kroków zmienią okno nakładania się operacji.
Wartość 99% dotyczy efektywności asynchronicznego checkpointowania przy wybranych interwałach. Nie opisuje ona goodputu end-to-end podczas powtarzających się awarii. W testach z wstrzykiwanymi awariami goodput treningowy wyniósł 31% dla odzyskiwania w procesie oraz 25,5% dla ft_launcher.
Te niższe wyniki nie przeczą pomiarom checkpointowania. Odpowiadają na inne pytanie. Efektywność asynchroniczna mierzy narzut checkpointu podczas zwykłego treningu, podczas gdy goodput obejmuje wstrzykiwanie awarii, wycofywanie postępu, ładowanie i inne działania odzyskiwania.
Częstotliwość checkpointów również ma nieuniknione ograniczenie. Przy jednym checkpoincie co 100 kroków trening asynchroniczny osiągnął 29,6% efektywności zamiast 99%. System pamięci masowej był niemal stale zajęty, ponieważ czasy obliczeń i zapisu były podobne.
Na uwagę zasługuje także presja na pamięć. Asynchroniczne checkpointowanie przygotowuje dane poza bezpośrednią operacją GPU i przekazuje procesowi w tle odpowiedzialność za zapisy. Zespoły powinny mierzyć pamięć CPU, głębokość kolejki i zaległości pamięci masowej na rzeczywistych słownikach stanu.
Kolejnym ograniczeniem jest zakres odzyskiwania. Restart w procesie nie pomoże, gdy system operacyjny zakończy workera lub zniknie węzeł. ft_launcher może zastąpić martwy proces, ale nadal zależy od zadania, sieci klastra, usługi rendezvous i magazynu checkpointów.
Utrata węzła pozostaje problemem Kubernetes. Regionalna przerwa w działaniu pamięci masowej lub uszkodzony checkpoint mogą jednocześnie pokonać każdą warstwę odzyskiwania. Architektura ogranicza koszty kilku typowych awarii, ale nie usuwa współdzielonych zależności.
Wykrywanie awarii może również generować fałszywe alarmy. Długa faza kompilacji, przerwa w ładowaniu danych lub zastój systemu plików mogą przekroczyć zbyt agresywny limit czasu heartbeat. Launcher zrestartowałby wtedy zdrowych workerów i odrzucił prawidłowy postęp.
Zespoły potrzebują danych o limitach czasu specyficznych dla obciążenia przed włączeniem automatycznego odzyskiwania. Powinny rejestrować najdłuższe okresy inicjalizacji modelu, checkpointowania, walidacji i wejścia danych. Testy powinny obejmować awarie podczas tych faz, a nie wyłącznie awarie w zwykłym kroku treningowym.
Benchmark AWS używał deterministycznych wstrzykiwanych awarii. Podejście to umożliwia powtarzalne porównania, ale awarie produkcyjne są mniej uporządkowane. Rzeczywiste klastry mogą doświadczać jednoczesnego pogorszenia sieci, spowolnienia pamięci masowej, problemów termicznych i awarii procesów.
Implementacja referencyjna daje zespołom użyteczny punkt wyjścia do odtworzenia konfiguracji. Odtworzenie jej na różnych rodzinach instancji i skalach modeli określi, na ile przenośne są zgłoszone korzyści.
Ostatnim kompromisem jest złożoność operacyjna. Stos obejmuje Kubernetes Jobs, wykrywanie peerów oparte na DNS, zasoby EFA, współdzieloną pamięć masową, wrappery NVRx, klientów monitorujących i wiele warstw limitów czasu. Każdy komponent tworzy kolejną powierzchnię konfiguracji.
Ta złożoność może być nadal uzasadniona, gdy duża flota GPU spędza minuty bezczynnie po awarii jednego ranku. Mniejsze zadania mogą jednak zaakceptować prostszą strategię restartu poda. Istotne wyliczenie to koszt odzyskiwania pomnożony przez częstotliwość awarii, a nie prestiż benchmarku.
Zespoły oceniające ten projekt powinny śledzić zarówno goodput treningowy, jak i infrastrukturalny. Samo wykorzystanie GPU może wyglądać zdrowo, gdy model wielokrotnie ponownie ładuje stare checkpointy. Użyteczny dashboard musi pokazywać ukończone kroki, odległość wycofania postępu, aktualność checkpointów i przyczynę restartu.
Organizacje inżynieryjne potrzebują również trwałych zapisów tych eksperymentów. Przeszukiwalna baza wiedzy inżynierskiej może łączyć zmiany limitów czasu, ślady awarii i wyniki benchmarków. Ten kontekst pomaga zespołom uniknąć powtarzania nieskutecznych konfiguracji odzyskiwania.
Co obserwować po benchmarku Amazon EKS NVRx
Kolejne dowody powinny pokazać, czy projekt zachowuje przewagę w przypadku większych modeli, rzeczywistych awarii i zmieniających się wersji NVRx.
Pierwszym sygnałem jest niezależne odtworzenie wyników poza 64 GPU H100. AWS testował skalowanie od dwóch do ośmiu węzłów, lecz częstotliwość awarii i koszty koordynacji rosną wraz z rozmiarem klastra. Wyniki dla setek akceleratorów lepiej ujawniłyby ograniczenia rendezvous i ładowania checkpointów.
Większy test powinien raportować więcej niż średni czas odzyskiwania. Rozkład ma znaczenie, ponieważ rzadkie pięciominutowe odzyskiwanie może zdominować ekonomię długiego przebiegu. Raporty powinny obejmować opóźnienie ogonowe, nieudane próby restartu oraz postęp utracony na incydent.
Drugim sygnałem jest wdrażanie w głównych frameworkach treningowych. NVRx już łączy się z obciążeniami opartymi na PyTorch i pojawia się w szerszym stosie oprogramowania NVIDIA. Więcej natywnych integracji ograniczyłoby ilość niestandardowego kodu wrapperów i launcherów, który zespoły muszą utrzymywać.
Wdrożenie przez frameworki wzmocniłoby argument, że odporność na awarie NVRx może stać się standardową warstwą aplikacyjną. Fragmentaryczne integracje osłabiłyby go, zwłaszcza jeśli każdy framework wymagałby odmiennej logiki limitów czasu, checkpointów i rendezvous.
Trzecim sygnałem są dane z niekontrolowanych awarii produkcyjnych. Deterministyczne wstrzykiwanie awarii jest konieczne do porównań, ale incydenty w praktyce testują kombinacje, których laboratoria rzadko odtwarzają. Operatorzy powinni osobno publikować wskaźniki odzyskiwania dla błędów GPU, zacięć NCCL, zakończeń z powodu OOM i utraty węzłów.
Udane odzyskanie powinno oznaczać więcej niż restart procesu. Zadanie musi przywrócić prawidłowy stan, nadal generować poprawne aktualizacje i unikać cichego uszkodzenia checkpointów. Zbieżność modelu po wielokrotnym odzyskiwaniu zasługuje na taką samą analizę jak szybkość odzyskiwania.
Dla zespołów rozważających teraz trening Amazon EKS NVRx praktycznym pierwszym krokiem jest kontrolowany benchmark równoległy. Należy użyć rzeczywistego modelu, rozmiaru checkpointu, systemu plików i czasu kroku. Porównaj synchroniczne zapisy, asynchroniczne zapisy, odzyskiwanie przez launcher oraz odzyskiwanie wyłącznie przez Kubernetes przy jednym harmonogramie awarii.
Następnie dostrój interwały checkpointów na podstawie zaobserwowanych czasów obliczeń i zapisu do pamięci masowej. Jeśli checkpoint trwa prawie tak długo jak interwał między zapisami, asynchroniczne nakładanie się operacji pozostanie niepełne. Jeśli obliczenia zapewniają szersze okno, zgłoszona efektywność 99% staje się bardziej prawdopodobna.
Polityki odzyskiwania powinny zaczynać się od konserwatywnych limitów ponowień. Rejestruj każdą przyczynę restartu i zachowuj ślady diagnostyczne. Zadanie, które wielokrotnie zawodzi na tym samym ranku lub checkpoincie, wymaga eskalacji, a nie niekończącej się pętli odzyskiwania.
Prace AWS i NVIDIA prowadzą do jednego trudnego do zignorowania wniosku. Niezawodność treningu rozproszonego nie może pozostać wyłącznie problemem infrastruktury. Aplikacja rozumie postęp, poprawność checkpointów i stan grupy procesów w sposób niedostępny dla orkiestratora.
Amazon EKS nadal zapewnia niezbędną podstawę do harmonogramowania i zastępowania węzłów. NVRx dodaje szybszą reakcję w tych granicach. Razem oferują wiarygodną drogę od czterominutowych cykli odzyskiwania do restartów w skali sekund dla kilku istotnych klas awarii.
Otwarte pytanie ma teraz charakter operacyjny, a nie koncepcyjny. Czy zespoły potrafią odtworzyć te korzyści z własnymi modelami, systemami pamięci masowej i rzeczywistymi wzorcami awarii? To właśnie ten test powinien ukierunkować kolejne wdrożenie treningowe Amazon EKS NVRx.
