View a markdown version of this page

Verwendung von topologieorientierter Planung in Amazon SageMaker HyperPod - Amazon SageMaker KI
UltraServer ArchitekturTopologie-LabelsSlurm-Topologie-PluginsBest PracticesEinschränkungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwendung von topologieorientierter Planung in Amazon SageMaker HyperPod

Die Effizienz der Datenübertragung ist ein entscheidender Faktor für High Performance Computing (HPC) - und Machine-Learning-Workloads. Wendet bei Verwendung UltraServers mit Amazon SageMaker HyperPod SageMaker HyperPod automatisch Topologie-Labels auf Ihre Ressourcen an. Topology-aware Die 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.

Topology-aware Scheduling 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.

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

  • GPU-to-GPU Datenübertragung: 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.

  • GPU-to-CPU Datenübertragung: Non-uniform Speicherzugriffssysteme (NUMA) verfügen über mehrere Systembusse auf einem einzigen Motherboard. 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 to/from Daten-GPUs laden oder 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 UltraServer Architektur mit p6e-gb200.36xlarge-Instanzen. An UltraServer enthält bis zu 18 p6e-gb200.36xlarge-Instanzen mit 4 GPUs auf jeder Instanz. 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 Computer aus an Rechenknoten übermittelt werden. UltraServer

EKS-Topologie-Label

Kennzeichnet Ihre Knoten gemäß der EC2-Instanztopologie HyperPod automatisch mit den folgenden Bezeichnungen:

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

  • topology.kubernetes. io/zone- die Availability Zone, in der sich der Knoten befindet.

  • topology.k8s. aws/network-node-layer — NetworkNodes beschreibt den Netzwerkknotensatz einer Instanz. 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 jede der Instanzen zu kennzeichnen, die zu derselben NVLink-Domäne in einem Ultraserver gehören. Weitere Informationen zur Verwendung UltraServers von with finden Sie unter. SageMaker HyperPod UltraServers In Amazon verwenden SageMaker HyperPod

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

Slurm-Netzwerktopologie-Plugins

Slurm bietet integrierte Plugins zur Erkennung der Netzwerktopologie. SageMaker HyperPod wählt automatisch das passende Topologie-Plugin auf der Grundlage der Instanztypen in Ihrem Cluster aus und konfiguriert es.

Automatische Topologieauswahl

Wenn Sie einen HyperPod Slurm-Cluster erstellen, überprüft das System alle Instanzgruppen und ihre zugehörigen Instanztypen, identifiziert die GPU-Kommunikationsmerkmale jedes Instanztyps und konfiguriert Slurm mit dem entsprechenden Topologie-Plugin. Dieser Prozess läuft automatisch und erfordert keine Konfiguration.

HyperPod verwaltet die Topologie über eine dynamisch generierte topology.conf Datei. Während sich der Cluster durch Skalierungsvorgänge oder den Austausch von Knoten weiterentwickelt, wird die Topologiekonfiguration HyperPod kontinuierlich angepasst, um den aktuellen Clusterstatus widerzuspiegeln. Weitere Informationen finden Sie unter Dynamische Topologieaktualisierungen.

topology/tree Verwenden des Plug-ins

Das topology/tree Plugin modelliert hierarchische Kommunikationsstrukturen mit mehreren Bandbreitenschichten. Die Baumtopologie ermöglicht es Slurm, Jobs so zu platzieren, dass die Kommunikation zwischen den Ebenen minimiert und die Lokalität maximiert wird.

Die Baumtopologie wird für Instance-Typen mit hierarchischen Verbindungen verwendet, bei denen verteilte Trainingsworkloads von einer standortgerechten Platzierung profitieren. Dazu gehören Instanztypen wie, und. ml.p5.48xlarge ml.p5e.48xlarge ml.p5en.48xlarge

SageMaker HyperPod konfiguriert das topology/tree Plugin automatisch, wenn Ihr Cluster diese Instanztypen verwendet. Das generierte topology.conf Objekt ordnet Knoten einer Switch-Hierarchie zu, die die Kommunikationsebenen Ihrer Hardware widerspiegelt.

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

TopologyPlugin=topology/tree

Konfiguration

SageMaker HyperPod konfiguriert das topology/tree Plugin automatisch auf der Grundlage der von Amazon EC2 bereitgestellten Informationen. Weitere Informationen zur Amazon EC2-Topologie finden Sie unter Amazon EC2 EC2-Instance-Topologie.

Wenn das topology/tree Plugin verwendet wird, sieht der Slurm topology.conf wie folgt aus:

SwitchName=nn-6fe9d8a965d34d181 Switches=nn-0b53107754517bf0e

SwitchName=nn-0b53107754517bf0e Switches=nn-424c855d4ad825aa4,nn-95acd7c656329fc30

SwitchName=nn-424c855d4ad825aa4 Nodes=ip-10-1-111-198
SwitchName=nn-95acd7c656329fc30 Nodes=ip-10-1-53-231

Usage

Wenn das topology/tree Plugin konfiguriert ist, versucht Slurm, Maschinen zuzuweisen, die sich nahe beieinander befinden. Sie können Slurm zwingen, Maschinen einem einzigen Switch zuzuweisen, indem Sie den --switch Befehlszeilenparameter an oder übergeben: sbatch srun

sbatch --switch=1 ....

Das Plugin verwenden topology/block

NVIDIA hat ein topology/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.

Die Blocktopologie modelliert einheitliche Kommunikationsdomänen mit hoher Bandbreite, in denen alle GPUs an einer einzigen Hochgeschwindigkeitsdomäne mit nahezu einheitlicher Latenz beteiligt sind. Die Blocktopologie behandelt alle Knoten als Teil einer einzigen zusammenhängenden Kommunikationseinheit. UltraServer architecture in SageMaker HyperPod unterstützt das Block-Plugin.

Die Blocktopologie wird für Instanztypen wie ml.p6e-gb200.NVL72 und ml.p6e-gb300.NVL72 verwendet.

Konfiguration

SageMaker HyperPod konfiguriert das Plugin automatisch. topology/block Wenn Sie das Plugin manuell konfigurieren möchten, geben Sie in der topology.conf Datei in Ihrem Slurm-Konfigurationsverzeichnis Folgendes 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

Usage

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 ohne andere Jobs platziert werden

sbatch -N12 --exclusive=topo

Topologieauswahl für Cluster mit gemischten Instanztypen

HyperPod verwendet derzeit Slurm 24.11, das nur eine einzige Topologiekonfiguration pro Cluster unterstützt. Das bedeutet, dass die Auswahl der Topologie pro Partition nicht unterstützt wird, dass mehrere Topologiemodelle innerhalb eines einzigen Clusters nicht koexistieren können und dass alle Knoten einer einzigen Topologiedefinition entsprechen müssen.

Wenn Ihr Cluster mehrere Instance-Typen enthält, wird eine Topologie HyperPod ausgewählt, die für alle Instance-Typen kompatibel ist. Die folgende Tabelle zeigt ein Beispiel dafür, wie die Topologie für einen Cluster mit gemischten Instance-Typen HyperPod aufgelöst wird.

Instanzgruppe Instance-Typ Bevorzugte Topologie

IG-1

ml.p5.48xlarge

Tree

IG-2

ml.P6E-GB300.nvl72

Blockieren

In diesem Beispiel ist die Blocktopologie optimal für ml.P6E-GB300.nvl72, aber die Baumtopologie ist sowohl mit ml.p5.48xlarge als auch mit ml.P6E-GB300.nvl72 kompatibel. HyperPod wählt Baumtopologie als clusterweite Topologie aus, um sicherzustellen, dass alle Knoten korrekt an der Planung teilnehmen können und kein Instance-Typ ausgeschlossen oder falsch dargestellt wird.

Wichtig

Für Workloads, bei denen eine topologieorientierte Planung für die Leistung entscheidend ist, empfehlen wir, separate Cluster für jeden Instance-Typ zu erstellen, anstatt verschiedene Instance-Typen in einem einzigen Cluster zu kombinieren. Dadurch wird sichergestellt, dass jeder Cluster die optimale Topologie für seine Hardware verwendet und so die bestmögliche Workload-Leistung bietet. Anstatt beispielsweise ml.p5.48xlarge- und ml.p6E-GB300.nvl72-Instances in einem einzigen Cluster zu kombinieren, bei dem die Baumtopologie als kompatibler Kompromiss ausgewählt wurde, sollten Sie für jeden Instance-Typ einen eigenen Cluster erstellen, sodass jeder sein ideales Topologiemodell verwendet.

Deaktivieren oder ändern Sie das Topologie-Plugin

Wenn ein Slurm-Cluster erstellt wird, wird HyperPod automatisch das optimale Topologie-Plugin ausgewählt. Um das Topologie-Plugin manuell zu ändern, aktualisieren Sie den TopologyPlugin Wert slurm.conf auf dem Controller-Knoten.

Beispiel:

# Set this value to disable topology plugin
TopologyPlugin=topology/flat

Dynamische Topologieaktualisierungen

Topology-aware Durch die Planung wird die Topologie kontinuierlich korrekt gehalten, wenn sich Ihr Cluster ändert. Die Topologie wird automatisch neu berechnet und die topology.conf Datei wird neu generiert, wenn eines der folgenden Ereignisse eintritt:

  • Scale-up: Dem Cluster werden neue Knoten hinzugefügt.

  • Scale-down: Knoten werden aus dem Cluster entfernt.

  • Knotenersatz: Fehlerhafte oder fehlerhafte Knoten werden ersetzt, oder Knoten werden manuell mithilfe der BatchReplaceClusterNodesAPI ersetzt.

Wenn die Topologie aktualisiert wird, werden neue Knoten in die richtige Topologiestruktur integriert, entfernte Knoten werden entfernt und die Slurm-Konfiguration wird aktualisiert, ohne dass manuelles Eingreifen erforderlich ist. Dadurch wird sichergestellt, dass die Topologie immer den tatsächlichen Clusterstatus widerspiegelt.

Anmerkung

Fortgeschrittene Benutzer können das Verhalten der Topologie außer Kraft setzen, indem sie sich beim Slurm-Controller-Knoten anmelden und manuell ändern. slurm.conf topology.conf Manuelle Änderungen können jedoch HyperPod bei nachfolgenden Cluster-Updates, einschließlich Skalierungsvorgängen, dem Austausch von Knoten und anderen Ereignissen im Cluster-Lebenszyklus, überschrieben werden. Wenn Sie diese Dateien manuell ändern, überprüfen Sie Ihre Änderungen nach jedem Cluster-Update.

Bewährte Methoden für die UltraServer Topologie

Für optimale Leistung mit 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, werden Jobs mit bis zu 18 Instanzen immer auf einer einzigen Instanz ausgeführt UltraServer.

    • FallsBlockSizes=16, werden Jobs mit weniger als 16 Instanzen immer auf einer einzigen Instanz ausgeführt UltraServer, während Jobs mit 18 Instanzen auf einer oder zwei Instanzen ausgeführt werden können UltraServers.

Wenn Sie über Segmentierung nachdenken, beachten Sie Folgendes

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

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

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

Einschränkungen bei der SageMaker HyperPod topologieorientierten Planung

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 UltraServers nur in derselben VPC und verwenden Sie das Multicluster-Setup von Slurm.