AWS veröffentlichte am 25. September 2026 den Beitrag Multi-Region training with Amazon SageMaker HyperPod and Qumulo. Darin beschreibt das Unternehmen einen Trainingstest, bei dem Rechenleistung in einer AWS-Region auf Daten in einer anderen Region zugriff. Die folgenden Angaben zur Architektur und Leistung stammen aus diesem AWS-Bericht.

Aufbau des Tests

Der Hub-Cluster stand in US East (Ohio) am selben Standort wie die Daten. Ein Spoke-Cluster in US West (Oregon) las die Daten über Qumulo Cloud Data Fabric aus der Ferne. Für die Verbindung zwischen den Regionen nennt AWS eine Netzwerklatenz von 60 ms. Dieser Wert beschreibt die regionsübergreifende Verbindung und ist von den später genannten Leselatenzen während des Trainings zu unterscheiden.

Jeder HyperPod-Cluster band eine lokale Cloud Native Qumulo-Instanz über NFS ein. Die Instanz des Spoke-Clusters rief die Daten über VPC Peering vom Hub ab. Für die Einordnung der Messwerte sind damit drei Orte beziehungsweise Wege relevant: Die Daten lagen beim Hub, der zweite Trainingscluster stand in Oregon, und beide Cluster nutzten einen lokalen NFS-Zugang zu ihrer jeweiligen Qumulo-Instanz.

Modell, Daten und Einstellungen

Der beschriebene Trainingsauftrag verwendete ein LLaMA-v3-Modell mit 1,02 Milliarden Parametern. Pro Cluster kamen zwei Instanzen des Typs ml.p5.48xlarge mit zusammen 16 H100-GPUs zum Einsatz. AWS testete mit PyTorch 2.1 FSDP, einer Batchgröße von 24 pro GPU und einer Sequenzlänge von 4.096 Token. Für die Anleitung wurde der für LLaMA tokenisierte C4-Datensatz genutzt: 48,4 Millionen Sequenzen waren in Fenster mit jeweils 4.096 Token gepackt.

Diese Angaben begrenzen die Aussagekraft der Leistungswerte auf den beschriebenen Versuch. Samples pro Sekunde geben hier die Trainingsgeschwindigkeit dieser Aufgabe an. Aus den Zahlen allein folgt kein bestimmtes Ergebnis für andere Datensätze, Zugriffsmuster, Netzbedingungen oder Bereitstellungen. Auch die Startphase des Spoke-Clusters gehört zur Bewertung, weil sich sein Verhalten während der ersten Batches änderte.

Gemessener Verlauf

Für das Training auf dem Hub berichtet AWS einen anhaltenden Lesedurchsatz von 1,0–1,3 GB pro Sekunde, eine Leselatenz von 2–3 ms und eine GPU-Auslastung von 98–100 Prozent. Diese Werte betreffen den Cluster direkt bei den Daten und bilden den Vergleichskontext für den entfernten Cluster.

Beim Spoke meldet AWS für die ersten 100–150 Batches zunächst 95–105 Samples pro Sekunde; danach habe sich die Geschwindigkeit bei 115–117 Samples pro Sekunde eingependelt. Für die Batches 0–100 des Kaltstarts nennt der Beitrag 80–90 Prozent GPU-Auslastung und 500–800 MB pro Sekunde Durchsatz. Für die Batches 100–150 nennt er 5–10 ms Leselatenz, ungefähr 115 Samples pro Sekunde und 98–100 Prozent GPU-Auslastung. Die Intervalle beschreiben aufeinanderfolgende Teile der Aufwärmphase, keinen durchgehend gleichen Startwert.

Nachdem NeuralCache aufgewärmt war, wurden laut AWS 94–96 Prozent der Lesezugriffe aus dem lokalen NVMe-Cache mit einer Latenz unter 5 ms bedient. Dieser Befund hilft, die Veränderung zwischen Start und späterem Verlauf einzuordnen. Anteil der Cache-Lesezugriffe, Leselatenz, GPU-Auslastung und Trainingsgeschwindigkeit sind dabei unterschiedliche Messgrößen; keine einzelne Zahl fasst den gesamten Versuch zusammen.

Einordnung

Der Beitrag dokumentiert eine konkrete Konfiguration mit Hub in Ohio und Spoke in Oregon. Das wesentliche beobachtete Muster ist ein langsamerer Beginn auf dem entfernten Cluster und die anschließend gemeldete stabile Trainingsgeschwindigkeit nach dem Aufwärmen des Caches. Bei einer Übertragung auf eigene Vorhaben müssen Modell, Daten, Hardware, Software und Verbindung des Tests berücksichtigt werden. Die Angaben sind Messwerte aus einem von AWS beschriebenen Versuch und keine Zusage für andere Umgebungen.