Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de la planification tenant compte de la topologie dans Amazon SageMaker HyperPod

L’efficacité du transfert de données est un facteur critique dans les charges de travail de calcul haute performance (HPC) et de machine learning. Lorsque vous l'utilisez UltraServers avec Amazon SageMaker HyperPod, applique SageMaker HyperPod automatiquement des étiquettes de topologie à vos ressources. Topology-aware la planification permet d'allouer des ressources afin de minimiser les frais de transfert de données en tenant compte à la fois de la topologie de l'instance (comment les ressources sont connectées au sein d'une instance) et de la topologie du réseau (comment les instances sont connectées les unes aux autres). Pour en savoir plus sur la topologie d’instance, consultez Topologie d’instance Amazon EC2.

Topology-aware la planification fonctionne avec les deux clusters sur Slurm et Amazon EKS. Pour des informations générales sur le fonctionnement de la topologie avec Slurm, consultez le guide de topologie dans la documentation de Slurm.

Sur Amazon SageMaker HyperPod, les frais de transfert de données proviennent généralement de trois sources principales :

UltraServer architecture

SageMaker HyperPod prend en charge UltraServer l'architecture avec les instances p6e-gb200.36xlarge. An UltraServer contient jusqu'à 18 instances p6e-gb200.36xlarge, avec 4 GPU sur chaque instance. Tous les GPU de tous les nœuds sont interconnectés via des commutateurs NVLink, ce qui permet le transfert des données entre deux GPU sans utiliser d’interfaces réseau.

Cette architecture offre un gain de performances significatif par rapport aux instances individuelles. Pour tirer parti de cette architecture de manière efficace, les tâches doivent être soumises aux nœuds de calcul à partir d'un seul nœud UltraServer.

Étiquette de topologie EKS

Conformément à la topologie de l'instance EC2, HyperPod étiquetez automatiquement vos nœuds avec les étiquettes suivantes :

À l'aide de ces étiquettes, vous pouvez utiliser une planification tenant compte de la topologie dans la gouvernance des HyperPod tâches pour appliquer des étiquettes de topologie et des annotations afin d'optimiser l'efficacité de la formation de vos charges de travail. Pour de plus amples informations, veuillez consulter Utilisation de la planification tenant compte de la topologie dans Amazon Task Governance SageMaker HyperPod.

Plug-ins de topologie réseau Slurm

Slurm fournit des plugins intégrés pour la prise en compte de la topologie du réseau. SageMaker HyperPod sélectionne et configure automatiquement le plug-in de topologie approprié en fonction des types d'instances de votre cluster.

Sélection automatique de la topologie

Lorsque vous créez un cluster HyperPod Slurm, le système inspecte tous les groupes d'instances et leurs types d'instances associés, identifie les caractéristiques de communication GPU de chaque type d'instance et configure Slurm avec le plug-in de topologie approprié. Ce processus s'exécute automatiquement et ne nécessite aucune configuration.

HyperPod gère la topologie via des fichiers de configuration générés dynamiquement. Sur Slurm 25.11 et versions ultérieures, la topologie est définie dans un topology.yaml fichier, qui constitue la source de vérité et prend en charge plusieurs définitions de topologie et une attribution par partition. Sur Slurm 24.x, la topologie est définie dans un topology.conf fichier avec une topologie unique à l'échelle du cluster. Au fur et à mesure que le cluster évolue grâce à des opérations de dimensionnement ou à des remplacements de nœuds, réconcilie HyperPod en permanence la configuration topologique pour refléter l'état actuel du cluster. Pour de plus amples informations, veuillez consulter Mises à jour dynamiques de la topologie.

Types d'instances prenant en charge la topologie du réseau

HyperPod configure la topologie en arborescence ou en blocs pour les types d'instances qui prennent en charge la topologie d'instance Amazon EC2. Pour obtenir la liste officielle et actualisée des types d'instances pris en charge, consultez la section Prérequis pour la topologie Amazon EC2 dans le guide de l'utilisateur Amazon EC2.

Les types d'instances pris en charge incluent les familles de calcul accéléré telles que G6e, G7e, P4d, P4de, P5, P5e, P5en et, ainsi que les familles AWS Trainium telles que Trn1 P6e-GB200, Trn1n et Trn2. UltraServerles types d'instance (par exempleml.p6e-gb200.36xlarge) utilisent la topologie par blocs, tandis que les autres types d'instances compatibles avec la topologie utilisent la topologie arborescente.

Utilisation du topology/tree plugin

Le topology/tree plugin modélise des structures de communication hiérarchiques avec plusieurs niveaux de bande passante. La topologie arborescente permet à Slurm de placer les tâches de manière à minimiser la communication entre les niveaux et à maximiser la localité.

La topologie arborescente est utilisée pour les types d'instances dotés d'interconnexions hiérarchiques, où les charges de travail de formation distribuées bénéficient d'un placement tenant compte de la localisation. Cela inclut les types d'instances tels que ml.p5.48xlargeml.p5e.48xlarge, etml.p5en.48xlarge.

SageMaker HyperPod configure automatiquement le topology/tree plug-in lorsque votre cluster utilise ces types d'instances. La configuration topologique générée mappe les nœuds dans une hiérarchie de commutateurs qui reflète les niveaux de communication de votre matériel.

Veillez à ce que slurm.conf inclue :

TopologyPlugin=topology/tree

Configuration

SageMaker HyperPod configure automatiquement la topologie arborescente en fonction des informations fournies par Amazon EC2. Pour plus de détails sur la topologie Amazon EC2, consultez la rubrique Topologie d'instance Amazon EC2.

Sur Slurm 25.11 et versions ultérieures, HyperPod définit la topologie danstopology.yaml, qui est la source de vérité. Une entrée de topologie arborescente mappe les nœuds dans une hiérarchie de commutateurs qui reflète les niveaux de communication de votre matériel :

- 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

Sur Slurm 24.x, la topologie arborescente est définie dans topology.conf instead, qui utilise le format suivant :

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

Lorsque le topology/tree plugin est configuré, Slurm essaie d'allouer des machines proches les unes des autres. Vous pouvez forcer Slurm à allouer des machines sur un seul commutateur en passant le paramètre de ligne de --switch commande à sbatch ou : srun

sbatch --switch=1 ....

Utilisation du topology/block plugin

NVIDIA a développé un topology/block plugin qui fournit une planification hiérarchique entre des blocs de nœuds avec les caractéristiques suivantes :

Ce plug-in alloue des nœuds en fonction de la topologie réseau définie.

La topologie par blocs modélise des domaines de communication uniformes à bande passante élevée où tous les GPU participent à un seul domaine haut débit avec une latence quasi uniforme. La topologie par blocs traite tous les nœuds comme faisant partie d'une seule unité de communication cohésive. UltraServer architecture in SageMaker HyperPod prend en charge le plugin block.

La topologie par blocs est utilisée pour les types d' UltraServer instances tels queml.p6e-gb200.36xlarge.

Veillez à ce que slurm.conf inclue :

TopologyPlugin=topology/block

Configuration

SageMaker HyperPod configure automatiquement la topologie des blocs. Sur Slurm 25.11 et versions ultérieures, la topologie des blocs est définie danstopology.yaml, qui est la source de vérité. Les topologies en blocs et en arborescence d'un cluster sont définies ensemble dans le même fichier. L'exemple suivant montre un cluster avec une partition P5 (arbre) et une UltraServer partition (bloc) :

- 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]

Sur Slurm 24.x, la topologie des blocs est définie dans topology.conf instead, qui utilise le format suivant :

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

Usage

Lorsque vous soumettez des tâches, vous pouvez utiliser les arguments supplémentaires suivants avec les commandes sbatch et srun :

Voici quelques exemples de scénarios que vous pourriez envisager lorsque vous réfléchissez à l’affectation de blocs.

Affectation d’un bloc entier de nœuds sur un système vide

sbatch -N18

Affectation de deux blocs de nœuds sur un système vide

sbatch -N36

Affectation de 18 nœuds sur un bloc + 6 nœuds sur un autre bloc

sbatch -N24

Affectation de 12 nœuds sur un bloc et de 12 nœuds sur un autre bloc

sbatch -N24 --segment=12

Avec --exclusive=topo, la tâche doit être placée en bloc sans aucune autre tâche

sbatch -N12 --exclusive=topo

Partition-level sélection de la topologie

À partir de Slurm 25.11, HyperPod prend en charge la configuration topologique au niveau de la partition. Une topologie est attribuée à chaque partition en fonction des types d'instance de ses groupes d'instances de calcul, de sorte qu'un cluster peut exécuter une topologie arborescente dans une partition et une topologie de blocs dans une autre. Les partitions qui contiennent des types d'instance ne prenant pas en charge la topologie réseau héritent d'une flat valeur par défaut à l'échelle du cluster, ce qui permet de garder leurs nœuds planifiables.

HyperPod résout la topologie de chaque partition comme suit :

La topologie par défaut à l'échelle du cluster est sélectionnée en fonction des topologies présentes dans le cluster : si un seul type de topologie est présent, ce type est le type par défaut ; si le bloc et l'arbre sont présents sans aucun groupe non topologique, tree est le type par défaut ; et si un groupe de calcul non topologique est présent, flat c'est le groupe par défaut afin que ces nœuds restent planifiables.

Le tableau suivant présente un exemple de résolution de la HyperPod topologie d'un cluster avec des types d'instances mixtes.

Dans cet exemple, la partition P5 utilise une topologie arborescente et la UltraServer partition utilise une topologie par blocs. Avec la topologie au niveau des partitions, chaque partition utilise sa topologie optimale au sein du même cluster. Vous n'avez donc plus besoin de créer des clusters distincts pour attribuer à chaque type d'instance son modèle topologique idéal.

Topologie plate par défaut

Lorsqu'un cluster contient une combinaison de types d'instances compatibles avec la topologie et non topologiques, HyperPod s'applique topology/flat par défaut au cluster. Topology-aware les partitions sont pointées vers leur arborescence ou leur topologie de blocs par le biais de Topology= directives par partition dans slurm.conf (Slurm 25.11 et versions ultérieures), tandis que les partitions comportant des nœuds non topologiques n'ont aucune Topology= directive et héritent de la valeur par défaut plate. Cela garantit que chaque nœud reste planifiable.

Désactiver ou modifier le plug-in de topologie

Lorsqu'un cluster Slurm est créé, sélectionne HyperPod automatiquement le plug-in de topologie optimal. Pour modifier manuellement le plug-in de topologie, mettez à jour la TopologyPlugin valeur dans slurm.conf le nœud du contrôleur.

Pour désactiver le placement tenant compte de la topologie, configurez le plug-in sur topology/flat (ou) : topology/default

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

Mises à jour dynamiques de la topologie

Topology-aware la planification permet de maintenir en permanence l'exactitude de la topologie au fur et à mesure de l'évolution de votre cluster. La topologie est automatiquement recalculée et le fichier de configuration de la topologie est régénéré lorsque l'un des événements suivants se produit :

Lorsque la topologie est mise à jour, les nouveaux nœuds sont incorporés dans la structure topologique appropriée, les nœuds supprimés sont élagués et la configuration de Slurm est mise à jour sans intervention manuelle. Cela garantit que la topologie reflète toujours l'état réel du cluster.

Meilleures pratiques en matière de UltraServer topologie

Pour des performances optimales avec une UltraServer architecture en SageMaker HyperPod :

Lorsque vous songez à segmenter, tenez compte des points suivants :

Limites de la planification SageMaker HyperPod tenant compte de la topologie

Avec Slurm 25.11 et versions ultérieures, les clusters hétérogènes (clusters avec différents types d'instances) sont pris en charge via la topologie au niveau des partitions et le cluster par défaut. flat Chaque partition reçoit la topologie la mieux adaptée à ses types d'instance, et les UltraServer nœuds non liés à la topologie restent planifiables au sein du même cluster. Pour de plus amples informations, veuillez consulter Partition-level sélection de la topologie.

Sur les clusters exécutant Slurm 24.x, une topologie unique s'applique à l'ensemble du cluster, et le topology/block plug-in présente les limites suivantes pour les clusters hétérogènes :

Pour les clusters hétérogènes sur Slurm 24.x, considérez les alternatives suivantes :