View a markdown version of this page

Utilisation de la planification basée sur la topologie dans Amazon SageMaker HyperPod - Amazon SageMaker AI
UltraServer architectureÉtiquettes de topologiePlug-ins de topologie SlurmBonnes pratiquesLimitations

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 basée sur 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 utilisez UltraServers Amazon SageMaker HyperPod, applique SageMaker HyperPod automatiquement des étiquettes topologiques à 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 généraux liés au transfert de données proviennent généralement de trois sources principales :

  • GPU-to-GPU transfert de données : les technologies modernes telles que NVLink et les commutateurs NVLink permettent le transfert de données à haut débit entre les GPU sans impliquer d'autres ressources de calcul. Ceci est extrêmement efficace mais généralement limité à une seule instance.

  • GPU-to-CPU transfert de données : les systèmes d'accès à la Non-uniform mémoire (NUMA) disposent de plusieurs bus système sur une seule carte mère. Dans une architecture d’instance EC2 standard telle que p5.48xlarge, il existe deux bus système différents, chacun doté d’un CPU et de 4 GPU. Pour des performances optimales, les processus qui chargent ou lisent des to/from GPU de données doivent s'exécuter sur un processeur connecté au même bus système que le GPU.

  • Communications réseau entre instances : les instances transfèrent des données via une chaîne de commutateurs réseau. Le chemin le plus court correspond généralement à la latence la plus faible.

UltraServer architecture

SageMaker HyperPod prend en charge UltraServer l'architecture avec des 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 exploiter efficacement cette architecture, 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, étiquetez HyperPod automatiquement vos nœuds avec les étiquettes suivantes :

  • topologie.kubernetes. io/region- Région AWS celui dans lequel réside le nœud.

  • topologie.kubernetes. io/zone- la zone de disponibilité dans laquelle réside le nœud.

  • topologie.k8s. aws/network-node-layer - NetworkNodes décrit l'ensemble de nœuds réseau d'une instance. Dans chaque ensemble de nœuds de réseau, les nœuds de réseau sont répertoriés par ordre hiérarchique de haut en bas. Le nœud de réseau connecté à l’instance est le dernier nœud de réseau de la liste. Il existe jusqu’à quatre couches de nœuds de réseau, et chaque nœud est balisé avec une étiquette. Les couches disponibles sont topology.k8s.aws/network-node-layer-1, topology.k8s.aws/network-node-layer-2, topology.k8s.aws/network-node-layer-3.

  • topologie.k8s. aws/ultraserver-id - Un identifiant utilisé pour étiqueter chacune des instances appartenant au même domaine NVLink dans un Ultraserver. Pour en savoir plus sur l'utilisation UltraServers avec SageMaker HyperPod, voirUtilisation UltraServers sur Amazon SageMaker HyperPod.

À l'aide de ces étiquettes, vous pouvez utiliser une planification basée sur la topologie dans le cadre de la gouvernance des HyperPod tâches pour appliquer des étiquettes topologiques 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 basée sur la topologie dans la gouvernance des tâches Amazon SageMaker HyperPod.

Plug-ins de topologie réseau Slurm

Slurm fournit des plugins intégrés pour connaître 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 topologique approprié. Ce processus s'exécute automatiquement et ne nécessite aucune configuration.

HyperPod gère la topologie par le biais d'un topology.conf fichier généré dynamiquement. Au fur et à mesure que le cluster évolue par le biais d'opérations de dimensionnement ou de 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 topologiques dynamiques.

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 les communications entre niveaux et à optimiser la localisation.

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 plugin lorsque votre cluster utilise ces types d'instances. Les nœuds générés topology.conf mappent 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 le topology/tree plug-in en fonction des informations fournies par Amazon EC2. Pour plus de détails sur la topologie Amazon EC2, consultez Topologie d'instance Amazon EC2.

Lorsque le topology/tree plugin est utilisé, le Slurm topology.conf ressemble à ce qui suit :

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 en : 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 :

  • Un bloc est une série de nœuds consécutifs.

  • Les blocs ne peuvent pas se chevaucher.

  • Tous les nœuds d’un bloc sont alloués à une tâche avant que le bloc suivant soit utilisé.

  • La taille de bloc de planification est la plus petite taille de bloc configurée.

  • La taille de chaque niveau de bloc supérieur correspond au carré de la taille du précédent.

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 à large bande passante dans lesquels tous les GPU participent à un seul domaine haut débit avec une latence quasi uniforme. La topologie des 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 des blocs est utilisée pour les types d'instances tels que ml.p6e-gb200.NVL72 etml.p6e-gb300.NVL72.

Configuration

SageMaker HyperPod configure automatiquement le topology/block plugin. Si vous souhaitez configurer le plugin manuellement, spécifiez ce qui suit dans le topology.conf fichier de votre répertoire de configuration Slurm :

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

Veillez à ce que slurm.conf inclue :

TopologyPlugin=topology/block

Usage

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

  • --segment=N : spécifiez le nombre de nœuds à regrouper. La taille du segment doit être inférieure ou égale à la taille du bloc de planification.

  • --exclusive=topo : demandez à ce qu’aucune autre tâche ne soit placée dans le même bloc. Cela est utile pour les analyses comparatives et les applications sensibles aux performances.

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, le job doit être mis en bloc sans aucun autre job

sbatch -N12 --exclusive=topo

Sélection de topologie pour les clusters avec des types d'instances mixtes

HyperPod utilise actuellement Slurm 24.11, qui ne prend en charge qu'une seule configuration topologique par cluster. Cela signifie que la sélection de topologie par partition n'est pas prise en charge, que plusieurs modèles de topologie ne peuvent pas coexister au sein d'un même cluster et que tous les nœuds doivent être conformes à une définition topologique unique.

Lorsque votre cluster contient plusieurs types d'instances, HyperPod sélectionne une topologie compatible avec tous ces types d'instances. Le tableau suivant montre un exemple de résolution de la HyperPod topologie pour un cluster avec des types d'instances mixtes.

Groupe d'instances Type d’instance Topologie préférée

IG-1

ml.p5.48xlarge

Arborescence

IG-2

ML.P6E-GB300.NVL72

Bloc

Dans cet exemple, la topologie par blocs est optimale pour ML.p6e-GB300.nvl72, mais la topologie arborescente est compatible avec ml.p5.48xlarge et ml.P6e-GB300.nvl72. HyperPod sélectionne la topologie arborescente comme topologie à l'échelle du cluster pour garantir que tous les nœuds peuvent participer correctement à la planification et qu'aucun type d'instance n'est exclu ou mal représenté.

Important

Pour les charges de travail où la planification basée sur la topologie est essentielle aux performances, nous recommandons de créer des clusters distincts pour chaque type d'instance plutôt que de combiner différents types d'instances dans un seul cluster. Cela garantit que chaque cluster utilise la topologie optimale pour son matériel, offrant ainsi les meilleures performances de charge de travail possibles. Par exemple, au lieu de combiner les instances ml.p5.48xlarge et ml.p6e-GB300.NVL72 dans un seul cluster où la topologie arborescente est sélectionnée comme compromis compatible, créez un cluster dédié pour chaque type d'instance afin que chacune utilise son modèle topologique idéal.

Désactiver ou modifier le plug-in de topologie

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

Exemple :

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

Mises à jour topologiques dynamiques

Topology-aware la planification garantit en permanence l'exactitude de la topologie à mesure que votre cluster change. La topologie est automatiquement recalculée et le topology.conf fichier est régénéré lorsque l'un des événements suivants se produit :

  • Scale-up: De nouveaux nœuds sont ajoutés au cluster.

  • Scale-down: les nœuds sont supprimés du cluster.

  • Remplacement des nœuds : les nœuds défaillants ou défectueux sont remplacés, ou les nœuds sont remplacés manuellement à l'aide de l'BatchReplaceClusterNodesAPI.

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.

Note

Les utilisateurs expérimentés peuvent modifier le comportement topologique en se connectant au nœud du contrôleur Slurm et en modifiant manuellement et. slurm.conf topology.conf Cependant, les modifications manuelles peuvent être remplacées lors des mises à jour ultérieures du cluster, notamment HyperPod lors des opérations de dimensionnement, des remplacements de nœuds et d'autres événements du cycle de vie du cluster. Si vous modifiez ces fichiers manuellement, vérifiez vos modifications après chaque mise à jour du cluster.

Bonnes pratiques en matière de UltraServer topologie

Pour des performances optimales grâce à une UltraServer architecture dans SageMaker HyperPod :

  • Définissez les tailles de bloc appropriées : configurez BlockSizes=18 (ou 17 si un nœud est de rechange) en fonction de l' UltraServer architecture.

  • Utilisez des segments pour une meilleure disponibilité : utilisez --segment=16, --segment=8 ou --segment=9 avec les commandes srun et sbatch pour améliorer la flexibilité de la planification des tâches.

  • Tenez compte de la taille des tâches et de la taille des segments :

    • Dans BlockSizes=18 ce cas, les tâches comportant jusqu'à 18 instances seront toujours exécutées sur une seule instance UltraServer.

    • Dans BlockSizes=16 ce cas, les tâches comportant moins de 16 instances seront toujours exécutées sur une seule instance UltraServer, tandis que les tâches comportant 18 instances peuvent s'exécuter sur une ou deux instances UltraServers.

En ce qui concerne la segmentation, tenez compte des éléments suivants

  • Avec--segment=1, chaque instance peut être exécutée séparément UltraServer.

  • Avec-N 18 --segment 9, 9 nœuds seront placés sur l'un UltraServer, et 9 autres nœuds peuvent être placés sur le même ou sur un autre UltraServer.

  • Avec-N 24 --segment 8, la tâche peut être exécutée sur 2 ou 3 UltraServers, tous les 8 nœuds étant placés ensemble sur le même serveur.

Limites de la planification SageMaker HyperPod tenant compte de la topologie

Le plug-in topology/block présente des limites avec les clusters hétérogènes (clusters avec différents types d’instances) :

  • Seuls les nœuds répertoriés dans des blocs sont planifiables par Slurm.

  • Chaque bloc doit avoir au moins BlockSizes[0] nœuds.

Pour les clusters hétérogènes, considérez les alternatives suivantes :

  • N’utilisez pas le plug-in de bloc avec des clusters hétérogènes. Isolez plutôt UltraServer les nœuds dans une autre partition.

  • Créez un cluster distinct UltraServers uniquement dans le même VPC et utilisez la configuration multicluster de Slurm.