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 pratiquesLimites

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 essentiel pour les charges de travail liées au calcul haute performance (HPC) et à l'apprentissage automatique. Lorsque vous l'utilisez UltraServers avec Amazon SageMaker HyperPod, applique SageMaker HyperPod automatiquement des étiquettes topologiques à vos ressources. La planification basée sur la topologie 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 plus d'informations sur la topologie des instances, consultez la section Topologie des EC2 instances Amazon.

La planification basée sur la topologie 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 de 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 les NVLink commutateurs permettent le transfert de données à haut débit entre elles GPUs sans impliquer d'autres ressources informatiques. C'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 mémoire non uniforme (NUMA) possèdent plusieurs bus système sur une seule carte mère. Dans une architecture d' EC2 instance typique telle que p5.48xlarge, il existe deux bus système différents, chacun doté d'un processeur et de 4. GPUs Pour des performances optimales, les processus qui chargent ou lisent des données to/from GPUs 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 par instance. GPUs Tous les GPUs nœuds sont interconnectés via des NVLink commutateurs, ce qui permet le transfert de données entre deux nœuds GPUs sans utiliser d'interfaces réseau.

Cette architecture fournit une amélioration significative des performances 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' EC2 instance, HyperPod étiquetez automatiquement vos nœuds avec les étiquettes suivantes :

  • topology.kubernetes.io/region : le nœud dans lequel réside le nœud. Région AWS

  • topology.kubernetes.io/zone : zone de disponibilité dans laquelle réside le nœud.

  • topology.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 dans un 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 étiqueté avec une étiquette. Les couches disponibles sont topology.k8s.aws/network-node-layer-1topology.k8s.aws/network-node-layer-2,topology.k8s.aws/network-node-layer-3.

  • topology.k8s.aws/ultraserver-id : identifiant utilisé pour étiqueter chacune des instances appartenant au même domaine dans un Ultraserver. NVLink 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. UltraServer architecture in SageMaker HyperPod prend en charge le plugin block.

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 ne soit utilisé

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

  • Chaque niveau de bloc supérieur correspond à une puissance de deux par rapport au précédent

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

Configuration

Pour configurer la planification basée sur la topologie avec le plugin, topology/block

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

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

  • Assurez-vous que vous slurm.conf incluez :

    TopologyPlugin=topology/block

Utilisation

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

  • --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 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.

Vous trouverez ci-dessous des exemples de scénarios que vous pourriez envisager lorsque vous envisagez d'allouer des blocs.

Alloue un bloc entier de nœuds sur un système vide

sbatch -N18

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

sbatch -N36

Allouez 18 nœuds sur un bloc + 6 nœuds sur un autre bloc

sbatch -N24

Allouez 12 nœuds sur un bloc et 12 nœuds sur un autre bloc

sbatch -N24 —segment=12

Avec —exclusive=topo, la tâche doit être mise en bloc sans aucune autre tâche

sbatch -N12 —exclusive=topo

Bonnes pratiques en matière de UltraServer topologie

Pour des performances optimales avec 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 srun et sbatch les commandes pour améliorer la flexibilité de la planification des tâches.

  • Tenez compte de la taille du travail et de la taille du segment :

    • 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.

Lorsque vous songez à segmenter, tenez compte des points 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 topology/block plugin présente des limites avec les clusters hétérogènes (clusters avec différents types d'instances) :

  • Seuls les nœuds listés dans des blocs sont planifiables par Slurm

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

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

  • N'utilisez pas le plug-in de blocs 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.