Verwenden der topologieorientierten Planung in Amazon SageMaker HyperPod - Amazon SageMaker AI
UltraServer-ArchitekturTopologie-LabelsSlurm-Topologie-PluginsBewährte MethodenEinschränkungen

Verwenden der topologieorientierten Planung in Amazon SageMaker HyperPod

Die Effizienz der Datenübertragung ist ein entscheidender Faktor für High Performance Computing (HPC) - und Machine-Learning-Workloads. Wenn Sie UltraServer mit Amazon SageMaker HyperPod verwenden, wendet SageMaker HyperPod automatisch Topologie-Labels auf Ihre Ressourcen an. Die topologieorientierte Planung hilft bei der Zuweisung von Ressourcen, um den Datenübertragungsaufwand zu minimieren, indem sowohl die Instance-Topologie (wie Ressourcen innerhalb einer Instance verbunden sind) als auch die Netzwerktopologie (wie Instances miteinander verbunden sind) berücksichtigt werden. Weitere Informationen zur Instance-Topologie finden Sie unter Instance-Topologie von Amazon EC2.

Die topologieorientierte Planung funktioniert mit beiden Clustern auf Slurm und Amazon EKS. Allgemeine Informationen darüber, wie Topologie mit Slurm funktioniert, finden Sie im Topologie-Leitfaden in der Slurm-Dokumentation.

In Amazon SageMaker HyperPod stammen die Kosten für die Datenübertragung in der Regel aus drei Hauptquellen:

  • Datenübertragung von GPU zu GPU: Moderne Technologien wie NVLink- und NVLink-Switches ermöglichen eine Datenübertragung mit hohem Durchsatz zwischen GPUs, ohne dass andere Rechenressourcen benötigt werden. Dies ist äußerst effizient, beschränkt sich jedoch normalerweise auf eine einzelne Instance.

  • Datenübertragung von GPU zu CPU: NUMA-Systeme (Non-Uniform Memory Access) verfügen über mehrere Systembusse auf einer einzigen Hauptplatine. In einer typischen EC2-Instance-Architektur wie p5.48xlarge gibt es zwei verschiedene Systembusse mit jeweils einer CPU und 4 GPUs. Für eine optimale Leistung sollten Prozesse, die Daten auf GPUs laden oder von ihnen lesen, auf einer CPU ausgeführt werden, die mit demselben Systembus wie die GPU verbunden ist.

  • Netzwerkkommunikation zwischen Instances: Instances übertragen Daten über eine Kette von Netzwerk-Switches. Der kürzeste Pfad entspricht in der Regel der niedrigsten Latenz.

UltraServer-Architektur

SageMaker HyperPod unterstützt die UltraServer-Architektur mit p6e-gb200.36xlarge-Instances. Ein UltraServer enthält bis zu 18 p6e-gb200.36xlarge-Instances mit 4 GPUs auf jeder Instance. Alle GPUs auf allen Knoten sind über NVLink-Switches miteinander verbunden, sodass die Datenübertragung zwischen zwei beliebigen GPUs ohne Netzwerkschnittstellen ermöglicht wird.

Diese Architektur bietet eine deutliche Leistungssteigerung im Vergleich zu einzelnen Instances. Um diese Architektur effektiv nutzen zu können, sollten Jobs von einem einzigen UltraServer aus an Rechenknoten übermittelt werden.

EKS-Topologie-Label

In Übereinstimmung mit der EC2-Instance-Topologie kennzeichnet HyperPod Ihre Knoten automatisch mit den folgenden Labels:

  • topology.kubernetes.io/region — das, in dem sich der Knoten befindet. AWS-Region

  • topology.kubernetes.io/zone — Die Availability Zone, in der sich der Knoten befindet.

  • topology.k8s.aws/network-node-layer — NetworkNodes beschreibt den Netzwerkknotensatz einer Instance. In jedem Netzwerkknotensatz sind die Netzwerkknoten absteigend in hierarchischer Reihenfolge aufgeführt. Der mit der Instance verbundene Netzwerkknoten ist der letzte Netzwerkknoten in der Liste. Es gibt bis zu vier Netzwerkknotenschichten, und jeder Knoten ist mit einer Bezeichnung gekennzeichnet. Verfügbare Ebenen sindtopology.k8s.aws/network-node-layer-1,topology.k8s.aws/network-node-layer-2,topology.k8s.aws/network-node-layer-3.

  • topology.k8s.aws/ultraserver-id — Ein Bezeichner, der verwendet wird, um alle Instances zu kennzeichnen, die zu derselben NVLink-Domain in einem Ultraserver gehören. Weitere Informationen zur Verwendung von UltraServers mit SageMaker HyperPod finden Sie unter Verwenden von UltraServern in Amazon SageMaker HyperPod.

Mithilfe dieser Labels können Sie die topologieorientierte Planung in der HyperPod Task Governance nutzen, um Topologiebezeichnungen und Anmerkungen anzubringen, um die Trainingseffizienz Ihrer Workloads zu optimieren. Weitere Informationen finden Sie unter Verwenden von topologieorientierter Planung in Amazon SageMaker HyperPod Task Governance.

Slurm-Netzwerktopologie-Plugins

Slurm bietet integrierte Plugins zur Erkennung der Netzwerktopologie. Die UltraServer-Architektur in SageMaker HyperPod unterstützt das Block-Plugin.

Verwenden des Topologie-/Block-Plugins

NVIDIA hat ein Topologie-/Block-Plugin entwickelt, das eine hierarchische Planung für Knotenblöcke mit den folgenden Merkmalen ermöglicht:

  • Ein Block ist ein aufeinanderfolgender Bereich von Knoten

  • Blöcke können sich nicht überlappen

  • Alle Knoten in einem Block werden einem Job zugewiesen, bevor der nächste Block verwendet wird

  • Die Planungsblockgröße ist die kleinste konfigurierte Blockgröße

  • Jede höhere Blockebenengröße ist eine Zweierpotenz als die vorherige

Dieses Plugin weist Knoten auf der Grundlage der definierten Netzwerktopologie zu.

Konfiguration

Um die topologieorientierte Planung mit dem Topologie-/Block-Plugin zu konfigurieren,

  • SageMaker HyperPod konfiguriert das Topologie-/Block-Plugin automatisch. Wenn Sie das Plugin konfigurieren möchten, geben Sie Folgendes in der Datei topology.conf in Ihrem Slurm-Konfigurationsverzeichnis an:

    BlockName=us1 Nodes=ultraserver1-[0-17]
  
BlockName=us2 Nodes=ultraserver2-[0-17]
  
BlockSizes=18

  • Stellen Sie sicher, dass Ihr Paket beinhaltet: slurm.conf

    TopologyPlugin=topology/block

Verwendung

Beim Einreichen von Jobs können Sie die folgenden zusätzlichen Argumente mit den srun Befehlen sbatch und verwenden:

  • --segment=N: Geben Sie die Anzahl der Knoten an, die gruppiert werden sollen. Die Größe des Segments muss kleiner oder gleich der Größe des Planungsblocks sein.

  • --exclusive=topo: Fordert an, dass keine anderen Jobs im selben Block platziert werden. Dies ist nützlich für Benchmarking und leistungsabhängige Anwendungen.

Im Folgenden finden Sie Beispielszenarien, die Sie in Betracht ziehen könnten, wenn Sie über die Zuweisung von Blöcken nachdenken.

Ordnen Sie einem leeren System einen ganzen Block von Knoten zu

sbatch -N18

Ordnen Sie einem leeren System zwei Knotenblöcke zu

sbatch -N36

Ordnen Sie einem Block 18 Knoten zu + 6 Knoten einem anderen Block

sbatch -N24

Ordnen Sie einem Block 12 Knoten und einem anderen Block 12 Knoten zu

sbatch -N24 —segment=12

Mit —exclusive=topo muss der Job in einem Block platziert werden, in dem es keine anderen Jobs gibt

sbatch -N12 —exclusive=topo

Bewährte Methoden für die UltraServer-Topologie

Für eine optimale Leistung mit der UltraServer-Architektur in SageMaker HyperPod:

  • Stellen Sie die entsprechenden Blockgrößen ein: Konfigurieren Sie BlockSizes=18 (oder 17, wenn ein Knoten frei ist), sodass sie der UltraServer-Architektur entsprechen.

  • Verwenden Sie Segmente für eine bessere Verfügbarkeit: Verwenden Sie die sbatch Befehle --segment=16--segment=8, oder --segment=9 mit srun und, um die Flexibilität bei der Auftragsplanung zu verbessern.

  • Berücksichtigen Sie die Auftragsgröße und die Segmentgröße:

    • FallsBlockSizes=18, Jobs mit bis zu 18 Instances werden immer auf einem einzigen UltraServer ausgeführt.

    • FallsBlockSizes=16, werden Jobs mit weniger als 16 Instances immer auf einem einzigen UltraServer ausgeführt, während Jobs mit 18 Instances auf einem oder zwei UltraServern ausgeführt werden können.

Wenn Sie über Segmentierung nachdenken, beachten Sie Folgendes

  • Mit --segment=1 kann jede Instance auf einem separaten UltraServer ausgeführt werden.

  • Bei -N 18 --segment 9 dieser Option werden 9 Knoten auf einem UltraServer platziert, und weitere 9 Knoten können auf demselben oder einem anderen UltraServer platziert werden.

  • Mit -N 24 --segment 8 kann der Job auf 2 oder 3 UltraServern ausgeführt werden, wobei jeweils 8 Knoten zusammen auf demselben Server platziert werden.

Einschränkungen bei der topologieorientierten Planung von SageMaker HyperPod

Das topology/block-Plugin hat Einschränkungen bei heterogenen Clustern (Clustern mit unterschiedlichen Instance-Typen):

  • Nur Knoten, die in Blöcken aufgeführt sind, können von Slurm geplant werden

  • Jeder Block muss mindestens BlockSizes[0] Knoten enthalten

Bei heterogenen Clustern sollten Sie die folgenden Alternativen in Betracht ziehen:

  • Verwenden Sie das Block-Plug-In nicht mit heterogenen Clustern. Isolieren Sie stattdessen UltraServer-Knoten in einer anderen Partition.

  • Erstellen Sie einen separaten Cluster mit nur UltraServern in derselben VPC und verwenden Sie das Multicluster-Setup von Slurm.