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. Bei Verwendung UltraServers mit Amazon SageMaker HyperPod werden Ihre Ressourcen SageMaker HyperPod automatisch mit Topologiebezeichnungen versehen. Topology-aware Die Planung hilft bei der Zuweisung von Ressourcen zur Minimierung des Datenübertragungsaufwands, 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 Die 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.

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

UltraServer Architektur

SageMaker HyperPod unterstützt die UltraServer Architektur mit p6e-gb200.36xlarge Instances. Und 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 Computer aus an die Rechenknoten gesendet werden. UltraServer

EKS-Topologie-Label

Beschriftet Ihre Knoten gemäß der EC2-Instance-Topologie HyperPod automatisch mit den folgenden Bezeichnungen:

Mithilfe dieser Labels können Sie die topologieorientierte Planung bei der HyperPod Aufgabensteuerung verwenden, um Topologiebezeichnungen und Anmerkungen anzubringen und so die Trainingseffizienz Ihrer Workloads zu optimieren. Weitere Informationen finden Sie unter Verwendung einer topologieorientierten Planung bei der Amazon-Aufgabensteuerung SageMaker HyperPod.

Slurm-Netzwerktopologie-Plugins

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

Automatische Topologieauswahl

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

HyperPod verwaltet die Topologie mithilfe dynamisch generierter Konfigurationsdateien. In Slurm 25.11 und höher wird die Topologie in einer topology.yaml Datei definiert, die die Quelle der Wahrheit ist und mehrere Topologiedefinitionen sowie Zuweisungen pro Partition unterstützt. Auf Slurm 24.x wird die Topologie in einer Datei mit einer einzigen clusterweiten Topologie definiert. topology.conf Während sich der Cluster durch Skalierungsvorgänge oder den Austausch von Knoten weiterentwickelt, gleicht er die Topologiekonfiguration HyperPod kontinuierlich ab, um den aktuellen Cluster-Status widerzuspiegeln. Weitere Informationen finden Sie unter Dynamische Topologie-Aktualisierungen.

Instanztypen, die die Netzwerktopologie unterstützen

HyperPod konfiguriert die Baum- oder Blocktopologie für Instance-Typen, die die Amazon EC2-Instance-Topologie unterstützen. Eine verbindliche, aktuelle Liste der unterstützten Instance-Typen finden Sie unter Voraussetzungen für die Amazon EC2-Topologie im Amazon EC2-Benutzerhandbuch.

Zu den unterstützten Instance-Typen gehören Accelerated Computing-Familien wie G6e, G7e, P4d, P4de, P5, P5e, P5en und AWS Trainium-Familien wie Trn1, Trn1n und P6e-GB200 Trn2. UltraServerml.p6e-gb200.36xlargeInstanztypen (z. B.) verwenden eine Blocktopologie, und andere topologiefähige Instanztypen verwenden eine Baumtopologie.

Verwenden des Plug-ins topology/tree

Das topology/tree Plugin modelliert hierarchische Kommunikationsstrukturen mit mehreren Bandbreitenstufen. 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 Instanztypen mit hierarchischen Verbindungen verwendet, bei denen verteilte Trainingslasten von einer standortbezogenen Platzierung profitieren. Dazu gehören Instance-Typen 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. Die generierte Topologiekonfiguration 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 automatisch die Baumtopologie auf der Grundlage der von Amazon EC2 bereitgestellten Informationen. Weitere Informationen zur Amazon EC2-Topologie finden Sie unter Amazon EC2-Instance-Topologie.

HyperPod Definiert in Slurm 25.11 und höher die Topologie intopology.yaml, was die Quelle der Wahrheit ist. Ein Baumtopologieeintrag ordnet Knoten einer Switch-Hierarchie zu, die die Kommunikationsebenen Ihrer Hardware widerspiegelt:

- topology: tree
  cluster_default: true
  tree:
    switches:
      - switch: root
        children: leaf-0,leaf-1
      - switch: leaf-0
        nodes: compute-1,compute-2
      - switch: leaf-1
        nodes: compute-3,compute-4

In Slurm 24.x wird topology.conf stattdessen die Baumtopologie in definiert, die das folgende Format verwendet:

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 nahe beieinander liegen. Du kannst Slurm zwingen, Maschinen auf einem einzigen Switch zuzuweisen, indem du den --switch Kommandozeilenparameter an oder übergibst: sbatch srun

sbatch --switch=1 ....

Verwenden Sie das Plugin topology/block

NVIDIA hat ein topology/block Plugin entwickelt, das eine hierarchische Planung über Knotenblöcke hinweg mit den folgenden Merkmalen ermöglicht:

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. Bei der Blocktopologie werden alle Knoten als Teil einer einzigen zusammenhängenden Kommunikationseinheit behandelt. UltraServer Die Architektur in SageMaker HyperPod unterstützt das Block-Plugin.

Die Blocktopologie wird für UltraServer Instanztypen wie ml.p6e-gb200.36xlarge verwendet.

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

TopologyPlugin=topology/block

Konfiguration

SageMaker HyperPod konfiguriert automatisch die Blocktopologie. In Slurm 25.11 und höher ist die Blocktopologie in definierttopology.yaml, was die Quelle der Wahrheit ist. Block- und Baumtopologien für einen Cluster werden zusammen in derselben Datei definiert. Das folgende Beispiel zeigt einen Cluster mit einer P5-Partition (Baum) und einer UltraServer Partition (Block):

- topology: tree
  cluster_default: true
  tree:
    switches:
      - switch: root
        children: leaf-0,leaf-1
      - switch: leaf-0
        nodes: compute-p5-1,compute-p5-2
      - switch: leaf-1
        nodes: compute-p5-3,compute-p5-4
- topology: block
  cluster_default: false
  block:
    block_sizes:
      - 18
    blocks:
      - block: cb-001
        nodes: ultraserver-1-[1-18]

Auf Slurm 24.x wird topology.conf stattdessen die Blocktopologie in definiert, die das folgende Format verwendet:

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

Usage

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

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 auf einem Block platziert werden, es gibt keine anderen Jobs

sbatch -N12 --exclusive=topo

Partition-level Auswahl der Topologie

Ab Slurm 25.11 HyperPod unterstützt es die Topologiekonfiguration auf Partitionsebene. Jeder Partition wird eine Topologie zugewiesen, die auf den Instanztypen ihrer Compute-Instanzgruppen basiert, sodass ein einzelner Cluster eine Baumtopologie in einer Partition und eine Blocktopologie in einer anderen ausführen kann. Partitionen, die Instanztypen ohne Netzwerktopologieunterstützung enthalten, erben eine clusterweite flat Standardeinstellung, sodass ihre Knoten planbar sind.

HyperPod löst die Topologie für jede Partition wie folgt auf:

Die clusterweite Standardtopologie wird auf der Grundlage der im Cluster vorhandenen Topologien ausgewählt: Wenn nur ein Topologietyp vorhanden ist, ist dieser Typ der Standardtyp; wenn sowohl Block als auch Baum ohne Nicht-Topologiegruppen vorhanden sind, ist Baum die Standardeinstellung; und wenn eine Nicht-Topologie-Berechnungsgruppe vorhanden ist, flat ist dies die Standardeinstellung, sodass diese Knoten planbar bleiben.

Die folgende Tabelle zeigt ein Beispiel für die HyperPod Auflösung der Topologie für einen Cluster mit gemischten Instanztypen.

In diesem Beispiel verwendet die P5-Partition eine Baumtopologie und die UltraServer Partition eine Blocktopologie. Bei der Topologie auf Partitionsebene verwendet jede Partition ihre optimale Topologie innerhalb desselben Clusters, sodass Sie keine separaten Cluster mehr erstellen müssen, um jedem Instanztyp sein ideales Topologiemodell zuzuweisen.

Flache Topologie (Standardeinstellung)

Wenn ein Cluster eine Mischung aus topologiefähigen und nicht topologiefähigen Instanztypen enthält, HyperPod gilt dies als Cluster-Standard. topology/flat Topology-aware Partitionen verweisen in slurm.conf (Slurm 25.11 und höher) durch partitionsspezifische Topology= Direktiven auf ihre Baum- oder Blocktopologie, wohingegen Partitionen mit Knoten, die keine Topologie haben, keine Direktive haben und den flachen Standard erben. Topology= Dadurch wird sichergestellt, dass jeder Knoten planbar bleibt.

Deaktivieren oder ändern Sie das Topologie-Plugin

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

Um die topologieorientierte Platzierung zu deaktivieren, setzen Sie das Plugin auf topology/flat (oder): topology/default

# Set this value to disable topology-aware placement
TopologyPlugin=topology/flat

Dynamische Topologie-Aktualisierungen

Topology-aware Bei der Planung bleibt die Topologie kontinuierlich korrekt, wenn sich Ihr Cluster ändert. Die Topologie wird automatisch neu berechnet und die Topologie-Konfigurationsdatei wird neu generiert, wenn eines der folgenden Ereignisse eintritt:

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 ein manuelles Eingreifen erforderlich ist. Dadurch wird sichergestellt, dass die Topologie immer den tatsächlichen Cluster-Status widerspiegelt.

Bewährte Methoden für die UltraServer Topologie

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

Wenn Sie über Segmentierung nachdenken, sollten Sie Folgendes berücksichtigen:

Einschränkungen bei der SageMaker HyperPod topologieorientierten Planung

Mit Slurm 25.11 und höher werden heterogene Cluster (Cluster mit unterschiedlichen Instanztypen) durch die Topologie auf Partitionsebene und den Cluster-Standard unterstützt. flat Jede Partition erhält die Topologie, die für ihre Instanztypen am besten geeignet ist, und Knoten, die keine Topologie sind, bleiben innerhalb desselben Clusters planbar. UltraServer Weitere Informationen finden Sie unter Partition-level Auswahl der Topologie.

Auf Clustern, auf denen Slurm 24.x ausgeführt wird, gilt eine einzige clusterweite Topologie, und das Plugin hat die folgenden Einschränkungen bei heterogenen Clustern: topology/block

Für heterogene Cluster auf Slurm 24.x sollten Sie diese Alternativen in Betracht ziehen: