25 września 2026 r. AWS opublikowało wpis Multi-Region training with Amazon SageMaker HyperPod and Qumulo. Opisano w nim próbę treningu, w której zasoby obliczeniowe w jednym regionie AWS korzystały z danych znajdujących się w drugim. Poniższa architektura i wyniki są danymi podanymi przez AWS dla tej próby.

Rozmieszczenie klastrów i danych

Klaster centralny, określony jako hub, działał w US East (Ohio) razem z danymi. Klaster spoke znajdował się w US West (Oregon) i odczytywał dane zdalnie przez Qumulo Cloud Data Fabric. AWS podało 60 ms opóźnienia sieciowego połączenia między regionami. Jest to miara połączenia między lokalizacjami, którą należy odróżnić od opóźnienia odczytu raportowanego dla poszczególnych etapów treningu.

Każdy klaster HyperPod montował lokalną instancję Cloud Native Qumulo przez NFS. Instancja klastra spoke pobierała dane z huba przez VPC peering. Przy interpretacji wyników istotne są więc zarówno lokalizacja źródłowych danych, jak i sposób dostępu klastra treningowego do plików: spoke pracował z dala od danych, ale łączył się przez NFS ze swoją lokalną instancją Qumulo.

Warunki pomiaru

Raportowane zadanie wykorzystywało model LLaMA v3 o 1,02 mld parametrów. Na każdy klaster przypadały dwie instancje ml.p5.48xlarge, łącznie 16 procesorów GPU H100 na klaster. Testy prowadzono z PyTorch 2.1 FSDP, partią o wielkości 24 na GPU oraz sekwencjami długości 4096 tokenów. W opisanym przebiegu użyto zbioru C4 poddanego tokenizacji dla LLaMA: 48,4 mln sekwencji spakowano w okna po 4096 tokenów.

Te ustawienia wyznaczają kontekst wszystkich podanych szybkości. Liczba próbek na sekundę opisuje tempo tej konkretnej pracy treningowej. Sama nie przesądza o zachowaniu innych zbiorów danych, wzorców dostępu, sieci czy wdrożeń. Trzeba także oddzielić etap rozruchu klastra spoke od późniejszego przebiegu, ponieważ AWS podało dla nich różne wartości.

Przebieg treningu

Dla huba AWS podało utrzymującą się przepustowość odczytu 1,0–1,3 GB na sekundę, opóźnienie odczytu 2–3 ms oraz wykorzystanie GPU na poziomie 98–100%. Są to wyniki klastra położonego razem z danymi i stanowią punkt odniesienia dla odczytów zdalnych.

Spoke zaczynał wolniej. Według wpisu przez pierwsze 100–150 partii osiągał 95–105 próbek na sekundę, po czym tempo ustaliło się na poziomie 115–117 próbek na sekundę. Dla partii 0–100 zimnego startu AWS osobno podało wykorzystanie GPU wynoszące 80–90% i przepustowość 500–800 MB na sekundę. Dla partii 100–150 podano opóźnienie odczytu 5–10 ms, około 115 próbek na sekundę i wykorzystanie GPU 98–100%. Zakresy te opisują zmieniające się etapy rozgrzewania, a nie jedną stałą szybkość całego początku zadania.

Po rozgrzaniu NeuralCache, według AWS, 94–96% odczytów obsługiwała lokalna pamięć podręczna NVMe z opóźnieniem poniżej 5 ms. Pomaga to zrozumieć zmianę widoczną między początkowymi partiami a późniejszym pomiarem. Udział odczytów z pamięci podręcznej, opóźnienie odczytu, wykorzystanie GPU i tempo treningu są różnymi miarami tego samego opisanego przebiegu; nie należy sprowadzać ich do jednej liczby.

Znaczenie wyniku

Wpis przedstawia pojedynczą próbę z hubem w Ohio i spoke w Oregonie, przy wskazanym modelu, zbiorze danych, sprzęcie i oprogramowaniu. Najważniejszą obserwacją jest przejście z wolniejszego zimnego startu do raportowanego ustalonego tempa po rozgrzaniu pamięci podręcznej. Przy porównywaniu tego wyniku z innym planowanym treningiem trzeba zachować kontekst konfiguracji oraz rozróżnienie między opóźnieniem sieci między regionami a późniejszym opóźnieniem odczytu z lokalnej pamięci. Źródłem liczb jest opis testu opublikowany przez AWS.