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. # Offres d'emploi sur SageMaker HyperPod des clusters Les rubriques suivantes fournissent des procédures et des exemples d'accès aux nœuds de calcul et d'exécution de charges de travail ML sur des clusters provisionnés SageMaker HyperPod . Selon la façon dont vous avez configuré l'environnement sur votre HyperPod cluster, il existe de nombreuses manières d'exécuter des charges de travail ML sur des HyperPod clusters. Des exemples d'exécution de charges de travail ML sur des HyperPod clusters sont également fournis dans le référentiel [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/). Les rubriques suivantes vous expliquent comment vous connecter aux HyperPod clusters provisionnés et vous aident à exécuter des exemples de charges de travail ML. **Astuce** Pour trouver des exemples pratiques et des solutions, consultez également l'[SageMaker HyperPodatelier](https://catalog.workshops.aws/sagemaker-hyperpod). **Topics** + [Accès aux nœuds SageMaker HyperPod de votre cluster](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md) + [Planification d'une tâche Slurm sur un cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm-schedule-slurm-job.md) + [Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md) + [Exécution de charges de travail de formation distribuées avec Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md) # Accès aux nœuds SageMaker HyperPod de votre cluster Vous pouvez accéder à votre **InService**cluster via AWS Systems Manager (SSM) en exécutant la AWS CLI commande `aws ssm start-session` avec le nom d'hôte du SageMaker HyperPod cluster au format de`sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. Vous pouvez récupérer l'ID du cluster, l'ID de l'instance et le nom du groupe d'instances depuis la [SageMaker HyperPod console](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) ou en exécutant `describe-cluster` et `list-cluster-nodes` depuis les [AWS CLI commandes pour SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes). Par exemple, si votre ID de cluster est `aa11bbbbb222`, le nom du nœud de cluster `controller-group` et l’ID du nœud de cluster `i-111222333444555aa`, la commande SSM `start-session` doit être la suivante. **Note** Le fait d'accorder aux utilisateurs l'accès aux nœuds HyperPod du cluster leur permet d'installer et d'utiliser des logiciels gérés par les utilisateurs sur les nœuds. Assurez-vous de respecter le principe des autorisations de moindre privilège pour les utilisateurs. Si vous ne l'avez pas encore configuré AWS Systems Manager, suivez les instructions fournies à l'adresse[Configuration AWS Systems Manager et exécution en tant que pour le contrôle d'accès des utilisateurs du cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm). ``` $ aws ssm start-session \ --target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \ --region us-west-2 Starting session with SessionId: s0011223344aabbccdd root@ip-111-22-333-444:/usr/bin# ``` Notez que cela vous connecte initialement en tant qu’utilisateur racine. Avant d’exécuter des tâches, basculez vers l’utilisateur `ubuntu` en exécutant la commande suivante. ``` root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu ubuntu@ip-111-22-333-444:/usr/bin# ``` Pour les paramètres avancés permettant une utilisation pratique des HyperPod clusters, consultez les rubriques suivantes. **Topics** + [Conseils supplémentaires pour accéder aux nœuds de votre SageMaker HyperPod cluster](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-tips) + [Configurez un environnement multi-utilisateurs via l'espace FSx partagé Amazon](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-fxs-shared-space) + [Configuration d'un environnement multi-utilisateurs en intégrant des HyperPod clusters à Active Directory](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-active-directory) ## Conseils supplémentaires pour accéder aux nœuds de votre SageMaker HyperPod cluster **Utilisez le `easy-ssh.sh` script fourni par HyperPod pour simplifier le processus de connexion** Pour transformer le processus précédent en une seule ligne de commande, l' HyperPod équipe fournit le [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh)script qui récupère les informations de votre cluster, les agrège dans la commande SSM et se connecte au nœud de calcul. Il n'est pas nécessaire de rechercher manuellement les informations de HyperPod cluster requises car ce script s'exécute `describe-cluster` et `list-cluster-nodes` commande et analyse les informations nécessaires pour exécuter la commande SSM. Les exemples de commandes suivants montrent comment exécuter le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh). S’il s’exécute correctement, vous serez connecté au cluster en tant qu’utilisateur racine. Il imprime également un extrait de code pour configurer SSH en ajoutant le HyperPod cluster en tant qu'hôte distant via un proxy SSM. En configurant SSH, vous pouvez connecter votre environnement de développement local tel que Visual Studio Code au HyperPod cluster. ``` $ chmod +x easy-ssh.sh $ ./easy-ssh.sh -c Cluster id: Instance id: Node Group: Add the following to your ~/.ssh/config to easily connect: $ cat <> ~/.ssh/config Host User ubuntu ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" EOF Add your ssh keypair and then you can do: $ ssh aws ssm start-session --target sagemaker-cluster:_- Starting session with SessionId: s0011223344aabbccdd root@ip-111-22-333-444:/usr/bin# ``` Notez que cela vous connecte initialement en tant qu’utilisateur racine. Avant d’exécuter des tâches, basculez vers l’utilisateur `ubuntu` en exécutant la commande suivante. ``` root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu ubuntu@ip-111-22-333-444:/usr/bin# ``` **Configuration pour un accès facile avec SSH en utilisant le nœud de HyperPod calcul comme hôte distant** Pour simplifier davantage l'accès au nœud de calcul via SSH depuis une machine locale, le `easy-ssh.sh` script génère un extrait de code expliquant comment configurer le HyperPod cluster en tant qu'hôte distant, comme indiqué dans la section précédente. L’extrait de code est généré automatiquement pour vous aider à l’ajouter directement au fichier `~/.ssh/config` sur votre appareil local. La procédure suivante explique comment configurer un accès facile à l'aide de SSH via le proxy SSM, afin que vous ou les utilisateurs de votre cluster puissiez directement vous connecter `ssh ` au nœud du HyperPod cluster. 1. Sur votre appareil local, ajoutez le nœud de HyperPod calcul avec un nom d'utilisateur en tant qu'hôte distant au `~/.ssh/config` fichier. La commande suivante indique comment ajouter au fichier `~/.ssh/config` l’extrait de code généré automatiquement à partir du script `easy-ssh.sh`. Assurez-vous de le copier à partir de la sortie générée automatiquement du script `easy-ssh.sh` contenant les informations de cluster correctes. ``` $ cat <> ~/.ssh/config Host User ubuntu ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" EOF ``` 1. Sur le nœud de HyperPod cluster, ajoutez la clé publique de votre appareil local au `~/.ssh/authorized_keys` fichier sur le nœud de HyperPod cluster. 1. Imprimez le fichier de clé publique sur votre ordinateur local. ``` $ cat ~/.ssh/id_rsa.pub ``` Cela devrait renvoyer votre clé. Copiez la sortie de cette commande. (Facultatif) Si vous n’avez pas de clé publique, créez-en une en exécutant la commande suivante. ``` $ ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N "" ``` 1. Connectez-vous au nœud du cluster et basculez vers l’utilisateur pour ajouter la clé. La commande suivante est un exemple d’accès en tant qu’utilisateur `ubuntu`. Remplacez `ubuntu` par le nom de l’utilisateur pour lequel vous souhaitez configurer l’accès facile avec SSH. ``` $ ./easy-ssh.sh -c $ sudo su - ubuntu ubuntu@ip-111-22-333-444:/usr/bin# ``` 1. Ouvrez le fichier `~/.ssh/authorized_keys` et ajoutez la clé publique à la fin du fichier. ``` ubuntu@ip-111-22-333-444:/usr/bin# vim ~/.ssh/authorized_keys ``` Une fois la configuration terminée, vous pouvez vous connecter au nœud du HyperPod cluster en tant qu'utilisateur en exécutant une commande SSH simplifiée comme suit. ``` $ ssh ubuntu@ip-111-22-333-444:/usr/bin# ``` Vous pouvez également utiliser l’hôte pour le développement à distance à partir d’un environnement IDE sur votre appareil local, tel que [Visual Studio Code Remote - SSH](https://code.visualstudio.com/docs/remote/ssh). ## Configurez un environnement multi-utilisateurs via l'espace FSx partagé Amazon Vous pouvez utiliser l'espace FSx partagé Amazon pour gérer un environnement multi-utilisateurs dans un cluster Slurm sur. SageMaker HyperPod Si vous avez configuré votre cluster Slurm avec Amazon FSx lors de la création du HyperPod cluster, c'est une bonne option pour configurer un espace de travail pour les utilisateurs de votre cluster. Créez un nouvel utilisateur et configurez le répertoire personnel de l'utilisateur sur le système de fichiers FSx partagé Amazon. **Astuce** Pour permettre aux utilisateurs d’accéder à votre cluster par le biais de leur nom d’utilisateur et de répertoires dédiés, vous devez également les associer à des rôles ou à des utilisateurs IAM en les balisant comme indiqué dans l’**option 2** de l’étape 5 de la procédure **Pour activer la prise en charge de l’option Exécuter en tant que pour les nœuds gérés sous Linux et macOS** fournie dans [Activation de la prise en charge de l’option Exécuter en tant que pour les nœuds gérés sous Linux et macOS](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) dans le Guide de l’utilisateur AWS Systems Manager . Consultez également [Configuration AWS Systems Manager et exécution en tant que pour le contrôle d'accès des utilisateurs du cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm). **Pour configurer un environnement multi-utilisateurs lors de la création d'un cluster Slurm sur SageMaker HyperPod** L'équipe SageMaker HyperPod de service fournit un script dans le [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)cadre des exemples de script de cycle de vie de base. 1. Préparez un fichier texte nommé `shared_users.txt` que vous devez créer au format suivant. La première colonne est destinée aux noms d'utilisateur, la deuxième colonne aux utilisateurs IDs uniques et la troisième aux annuaires des utilisateurs de l'espace FSx partagé Amazon. ``` username1,uid1,/fsx/username1 username2,uid2,/fsx/username2 ... ``` 1. Assurez-vous de télécharger les [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)fichiers `shared_users.txt` et dans le compartiment S3 pour les scripts de HyperPod cycle de vie. Lorsque la création du cluster, la mise à jour du cluster ou la mise à jour logicielle du cluster est en cours, [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) lit dans `shared_users.txt` et configure correctement les répertoires des utilisateurs. **Pour créer de nouveaux utilisateurs et les ajouter à un cluster Slurm existant exécuté sur SageMaker HyperPod ** 1. Sur le nœud principal, exécutez la commande suivante pour enregistrer un script qui aide à créer un utilisateur. Assurez-vous de l’exécuter avec les autorisations sudo. ``` $ cat > create-user.sh << EOL #!/bin/bash set -x # Prompt user to get the new user name. read -p "Enter the new user name, i.e. 'sean': " USER # create home directory as /fsx/ # Create the new user on the head node sudo useradd \$USER -m -d /fsx/\$USER --shell /bin/bash; user_id=\$(id -u \$USER) # add user to docker group sudo usermod -aG docker \${USER} # setup SSH Keypair sudo -u \$USER ssh-keygen -t rsa -q -f "/fsx/\$USER/.ssh/id_rsa" -N "" sudo -u \$USER cat /fsx/\$USER/.ssh/id_rsa.pub | sudo -u \$USER tee /fsx/\$USER/.ssh/authorized_keys # add user to compute nodes read -p "Number of compute nodes in your cluster, i.e. 8: " NUM_NODES srun -N \$NUM_NODES sudo useradd -u \$user_id \$USER -d /fsx/\$USER --shell /bin/bash; # add them as a sudoer read -p "Do you want this user to be a sudoer? (y/N): " SUDO if [ "\$SUDO" = "y" ]; then sudo usermod -aG sudo \$USER sudo srun -N \$NUM_NODES sudo usermod -aG sudo \$USER echo -e "If you haven't already you'll need to run:\n\nsudo visudo /etc/sudoers\n\nChange the line:\n\n%sudo ALL=(ALL:ALL) ALL\n\nTo\n\n%sudo ALL=(ALL:ALL) NOPASSWD: ALL\n\nOn each node." fi EOL ``` 1. Exécutez le script avec la commande suivante. Il vous sera demandé d’ajouter le nom d’un utilisateur et le nombre de nœuds de calcul auxquels vous souhaitez autoriser l’utilisateur à accéder. ``` $ bash create-user.sh ``` 1. Testez l’utilisateur en exécutant les commandes suivantes. ``` $ sudo su - && ssh $(srun hostname) ``` 1. Ajoutez les informations utilisateur au fichier `shared_users.txt`, afin que l’utilisateur soit créé sur tout nouveau nœud de calcul ou nouveau cluster. ## Configuration d'un environnement multi-utilisateurs en intégrant des HyperPod clusters à Active Directory Dans les cas pratiques, les HyperPod clusters sont généralement utilisés par plusieurs utilisateurs : chercheurs en apprentissage automatique (ML), ingénieurs logiciels, scientifiques des données et administrateurs de clusters. Ils modifient leurs propres fichiers et exécutent leurs propres tâches sans affecter le travail des autres. Pour configurer un environnement multi-utilisateur, utilisez le mécanisme des utilisateurs et des groupes Linux pour créer de manière statique plusieurs utilisateurs sur chaque instance via les scripts de cycle de vie. Toutefois, l’inconvénient de cette approche est que vous devez dupliquer les paramètres des utilisateurs et des groupes sur plusieurs instances du cluster afin de conserver une configuration cohérente dans toutes les instances lorsque vous effectuez des mises à jour, telles que l’ajout, la modification et la suppression d’utilisateurs. Pour résoudre ce problème, vous pouvez utiliser le [protocole LDAP (Lightweight Directory Access Protocol)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) et le protocole [LDAP over TLS/SSL (LDAPS)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) pour intégrer un service d'annuaire tel que [AWS Directory Service pour Microsoft](https://aws.amazon.com/directoryservice/) Active Directory. Pour en savoir plus sur la configuration d'Active Directory et d'un environnement multi-utilisateurs dans un HyperPod cluster, consultez le billet de blog [Intégrer les HyperPod clusters à Active Directory pour une connexion multi-utilisateurs fluide](https://aws.amazon.com/blogs/machine-learning/integrate-hyperpod-clusters-with-active-directory-for-seamless-multi-user-login/). # Planification d'une tâche Slurm sur un cluster SageMaker HyperPod Vous pouvez lancer des tâches d’entraînement à l’aide des commandes Slurm `sbatch` ou `srun` standard. Par exemple, pour lancer une tâche de formation à 8 nœuds, vous pouvez exécuter une formation de `srun -N 8 --exclusive train.sh` SageMaker HyperPod support dans différents environnements, notamment`conda`, `venv``docker`, et`enroot`. Vous pouvez configurer un environnement ML en exécutant des scripts de cycle de vie sur vos SageMaker HyperPod clusters. Vous avez également la possibilité de joindre un système de fichiers partagé tel qu'Amazon FSx, qui peut également être utilisé comme environnement virtuel. L'exemple suivant montre comment exécuter une tâche pour former Llama-2 à l'aide de la technique FSDP (Fully Sharded Data Parallelism) sur un cluster SageMaker HyperPod doté d'un système de fichiers partagé Amazon. FSx Vous pouvez également trouver d'autres exemples dans le [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). **Astuce** Tous les SageMaker HyperPod exemples sont disponibles dans le `3.test_cases` dossier du [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). 1. Clonez le [ GitHub référentiel Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/) et copiez les exemples de tâches de formation dans votre système de FSx fichiers Amazon. ``` $ TRAINING_DIR=/fsx/users/my-user/fsdp $ git clone https://github.com/aws-samples/awsome-distributed-training/ ``` 1. Exécutez le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh). Cela crée un `conda` environnement sur votre système de FSx fichiers Amazon. Assurez-vous que le système de fichiers est accessible à tous les nœuds du cluster. 1. Créez l’environnement Conda virtuel en lançant une tâche Slurm à nœud unique comme suit. ``` $ srun -N 1 /path_to/create_conda_env.sh ``` 1. Une fois l’environnement généré, vous pouvez lancer une tâche d’entraînement en pointant sur le chemin de l’environnement sur le volume partagé. Vous pouvez lancer des tâches d’entraînement à nœud unique ou à nœuds multiples avec la même configuration. Pour lancer une tâche, créez un script de lancement de tâches (également appelé script de point d’entrée), comme suit. ``` #!/usr/bin/env bash set -ex ENV_PATH=/fsx/users/my_user/pytorch_env TORCHRUN=$ENV_PATH/bin/torchrun TRAINING_SCRIPT=/fsx/users/my_user/pt_train.py WORLD_SIZE_JOB=$SLURM_NTASKS RANK_NODE=$SLURM_NODEID PROC_PER_NODE=8 MASTER_ADDR=(`scontrol show hostnames \$SLURM_JOB_NODELIST | head -n 1`) MASTER_PORT=$(expr 10000 + $(echo -n $SLURM_JOBID | tail -c 4)) DIST_ARGS="--nproc_per_node=$PROC_PER_NODE \ --nnodes=$WORLD_SIZE_JOB \ --node_rank=$RANK_NODE \ --master_addr=$MASTER_ADDR \ --master_port=$MASTER_PORT \ " $TORCHRUN $DIST_ARGS $TRAINING_SCRIPT ``` **Astuce** Si vous souhaitez améliorer la résilience de votre formation face aux pannes matérielles en utilisant la fonctionnalité de reprise automatique de SageMaker HyperPod, vous devez configurer correctement la variable d'environnement `MASTER_ADDR` dans le script du point d'entrée. Pour en savoir plus, veuillez consulter la section [Restauration automatique des nœuds et reprise automatique](sagemaker-hyperpod-resiliency-slurm-auto-resume.md). Ce didacticiel suppose que ce script est enregistré sous `/fsx/users/my_user/train.sh`. 1. Avec ce script dans le volume partagé à l’adresse `/fsx/users/my_user/train.sh`, exécutez la commande `srun` suivante pour planifier la tâche Slurm. ``` $ cd /fsx/users/my_user/ $ srun -N 8 train.sh ``` # Exécution de conteneurs Docker sur un nœud de calcul Slurm sur HyperPod [Pour exécuter des conteneurs Docker avec Slurm activé SageMaker HyperPod, vous devez utiliser [Enroot](https://github.com/NVIDIA/enroot) et Pyxis.](https://github.com/NVIDIA/pyxis) Le package Enroot permet de convertir les images Docker en un environnement d’exécution compréhensible par Slurm, tandis que Pyxis permet de planifier l’exécution en tant que tâche Slurm via une commande `srun` `srun --container-image=docker/image:tag`. **Astuce** Les packages Docker, Enroot et Pyxis doivent être installés lors de la création du cluster dans le cadre de l’exécution des scripts de cycle de vie, comme indiqué dans [Scripts de cycle de vie de base fournis par HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md). Utilisez les [scripts de cycle de vie de base](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) fournis par l'équipe HyperPod de service lors de la création d'un HyperPod cluster. Ces scripts de base sont configurés pour installer les packages par défaut. Dans le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py), il y a la classe `Config` avec le paramètre de type booléen pour installer les packages définis sur `True` (`enable_docker_enroot_pyxis=True`). Ceci est appelé et analysé dans le script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py), qui appelle les scripts `install_docker.sh` et `install_enroot_pyxis.sh` depuis le dossier [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils). Les scripts d’installation sont l’emplacement où les installations réelles des packages ont lieu. En outre, les scripts d'installation déterminent s'ils peuvent détecter les chemins de NVMe stockage à partir des instances sur lesquelles ils sont exécutés et définissent les chemins racines vers lesquels Docker et Enroot doivent accéder. `/opt/dlami/nvme` Le volume racine par défaut de toute nouvelle instance est monté `/tmp` uniquement sur un volume EBS de 100 Go, qui s'épuise si la charge de travail que vous prévoyez d'exécuter implique un entraînement LLMs et donc des conteneurs Docker de grande taille. Si vous utilisez des familles d'instances telles que P et G avec un NVMe stockage local, vous devez vous assurer que vous utilisez le NVMe stockage rattaché à`/opt/dlami/nvme`, et les scripts d'installation prennent en charge les processus de configuration. **Pour vérifier si les chemins racines sont correctement configurés** Sur un nœud de calcul de votre cluster Slurm activé SageMaker HyperPod, exécutez les commandes suivantes pour vous assurer que le script de cycle de vie fonctionne correctement et que le volume racine de chaque nœud est défini sur. `/opt/dlami/nvme/*` Les commandes suivantes montrent des exemples de vérification du chemin d’exécution Enroot et du chemin racine des données pour 8 nœuds de calcul d’un cluster Slurm. ``` $ srun -N 8 cat /etc/enroot/enroot.conf | grep "ENROOT_RUNTIME_PATH" ENROOT_RUNTIME_PATH /opt/dlami/nvme/tmp/enroot/user-$(id -u) ... // The same or similar lines repeat 7 times ``` ``` $ srun -N 8 cat /etc/docker/daemon.json { "data-root": "/opt/dlami/nvme/docker/data-root" } ... // The same or similar lines repeat 7 times ``` Après avoir confirmé que les chemins d’exécution sont correctement définis sur `/opt/dlami/nvme/*`, vous êtes prêt à générer et à exécuter des conteneurs Docker avec Enroot et Pyxis. **Pour tester Docker avec Slurm** 1. Sur votre nœud de calcul, essayez les commandes suivantes pour vérifier si Docker et Enroot sont correctement installés. ``` $ docker --help $ enroot --help ``` 1. Testez si Pyxis et Enroot sont correctement installés en exécutant l’une des images [NVIDIA CUDA Ubuntu](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda). ``` $ srun --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY nvidia-smi pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY DAY MMM DD HH:MM:SS YYYY +-----------------------------------------------------------------------------+ | NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ ``` Vous pouvez également le tester en créant un script et en exécutant une commande `sbatch` comme suit. ``` $ cat <> container-test.sh #!/bin/bash #SBATCH --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY nvidia-smi EOF $ sbatch container-test.sh pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY DAY MMM DD HH:MM:SS YYYY +-----------------------------------------------------------------------------+ | NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ ``` **Pour exécuter une tâche Slurm de test avec Docker** Une fois que vous avez terminé de configurer Slurm avec Docker, vous pouvez apporter toutes les images Docker prédéfinies et exécuter avec Slurm on. SageMaker HyperPod Voici un exemple de cas d'utilisation qui explique comment exécuter une tâche de formation à l'aide de Docker et de Slurm on. SageMaker HyperPod Il montre un exemple de travail d'apprentissage parallèle du modèle Llama 2 avec la bibliothèque de parallélisme des modèles SageMaker AI (SMP). 1. Si vous souhaitez utiliser l'une des images ECR prédéfinies distribuées par SageMaker AI ou DLC, assurez-vous d'autoriser votre HyperPod cluster à extraire des images ECR via le. [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Si vous utilisez votre propre image Docker ou une image Docker open source, vous pouvez ignorer cette étape. Ajoutez les autorisations suivantes au [Rôle IAM pour SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). Dans ce didacticiel, nous utilisons l’[image Docker SMP](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2) prépackagée avec la bibliothèque SMP. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr-public:*", "ecr:GetDownloadUrlForLayer", "ecr:GetAuthorizationToken", "sts:*" ], "Resource": "*" } ] } ``` ------ 1. Sur le nœud de calcul, clonez le référentiel et accédez au dossier contenant les exemples de scripts d’entraînement avec SMP. ``` $ git clone https://github.com/aws-samples/awsome-distributed-training/ $ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2 ``` 1. Dans ce didacticiel, exécutez l’exemple de script [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh) qui extrait l’image Docker SMP, crée le conteneur Docker et l’exécute en tant qu’environnement d’exécution Enroot. Vous pouvez modifier cela comme vous le souhaitez. ``` $ cat docker_build.sh #!/usr/bin/env bash region=us-west-2 dlc_account_id=658645717510 aws ecr get-login-password --region $region | docker login --username AWS --password-stdin $dlc_account_id.dkr.ecr.$region.amazonaws.com docker build -t smpv2 . enroot import -o smpv2.sqsh dockerd://smpv2:latest ``` ``` $ bash docker_build.sh ``` 1. Créez un script de commandes pour lancer une tâche d’entraînement à l’aide de `sbatch`. Dans ce didacticiel, l’exemple de script fourni [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh) lance une tâche d’entraînement parallèle du modèle Llama 2 de 70 milliards de paramètres avec un jeu de données synthétique sur 8 nœuds de calcul. Un ensemble de scripts d’entraînement sont fournis dans [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts), et `launch_training_enroot.sh` prend `train_external.py` comme script de point d’entrée. **Important** Pour utiliser un conteneur Docker sur SageMaker HyperPod, vous devez monter le `/var/log` répertoire depuis la machine hôte, qui est le nœud de HyperPod calcul dans ce cas, sur le `/var/log` répertoire du conteneur. Vous pouvez le configurer en ajoutant la variable suivante pour Enroot. ``` "${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}" ``` ``` $ cat launch_training_enroot.sh #!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # SPDX-License-Identifier: MIT-0 #SBATCH --nodes=8 # number of nodes to use, 2 p4d(e) = 16 A100 GPUs #SBATCH --job-name=smpv2_llama # name of your job #SBATCH --exclusive # job has exclusive use of the resource, no sharing #SBATCH --wait-all-nodes=1 set -ex; ########################### ###### User Variables ##### ########################### ######################### model_type=llama_v2 model_size=70b # Toggle this to use synthetic data use_synthetic_data=1 # To run training on your own data set Training/Test Data path -> Change this to the tokenized dataset path in Fsx. Acceptable formats are huggingface (arrow) and Jsonlines. # Also change the use_synthetic_data to 0 export TRAINING_DIR=/fsx/path_to_data export TEST_DIR=/fsx/path_to_data export CHECKPOINT_DIR=$(pwd)/checkpoints # Variables for Enroot : "${IMAGE:=$(pwd)/smpv2.sqsh}" : "${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}" # This is needed for validating its hyperpod cluster : "${TRAIN_DATA_PATH:=$TRAINING_DIR:$TRAINING_DIR}" : "${TEST_DATA_PATH:=$TEST_DIR:$TEST_DIR}" : "${CHECKPOINT_PATH:=$CHECKPOINT_DIR:$CHECKPOINT_DIR}" ########################### ## Environment Variables ## ########################### #export NCCL_SOCKET_IFNAME=en export NCCL_ASYNC_ERROR_HANDLING=1 export NCCL_PROTO="simple" export NCCL_SOCKET_IFNAME="^lo,docker" export RDMAV_FORK_SAFE=1 export FI_EFA_USE_DEVICE_RDMA=1 export NCCL_DEBUG_SUBSYS=off export NCCL_DEBUG="INFO" export SM_NUM_GPUS=8 export GPU_NUM_DEVICES=8 export FI_EFA_SET_CUDA_SYNC_MEMOPS=0 # async runtime error ... export CUDA_DEVICE_MAX_CONNECTIONS=1 ######################### ## Command and Options ## ######################### if [ "$model_size" == "7b" ]; then HIDDEN_WIDTH=4096 NUM_LAYERS=32 NUM_HEADS=32 LLAMA_INTERMEDIATE_SIZE=11008 DEFAULT_SHARD_DEGREE=8 # More Llama model size options elif [ "$model_size" == "70b" ]; then HIDDEN_WIDTH=8192 NUM_LAYERS=80 NUM_HEADS=64 LLAMA_INTERMEDIATE_SIZE=28672 # Reduce for better perf on p4de DEFAULT_SHARD_DEGREE=64 fi if [ -z "$shard_degree" ]; then SHARD_DEGREE=$DEFAULT_SHARD_DEGREE else SHARD_DEGREE=$shard_degree fi if [ -z "$LLAMA_INTERMEDIATE_SIZE" ]; then LLAMA_ARGS="" else LLAMA_ARGS="--llama_intermediate_size $LLAMA_INTERMEDIATE_SIZE " fi if [ $use_synthetic_data == 1 ]; then echo "using synthetic data" declare -a ARGS=( --container-image $IMAGE --container-mounts $HYPERPOD_PATH,$CHECKPOINT_PATH ) else echo "using real data...." declare -a ARGS=( --container-image $IMAGE --container-mounts $HYPERPOD_PATH,$TRAIN_DATA_PATH,$TEST_DATA_PATH,$CHECKPOINT_PATH ) fi declare -a TORCHRUN_ARGS=( # change this to match the number of gpus per node: --nproc_per_node=8 \ --nnodes=$SLURM_JOB_NUM_NODES \ --rdzv_id=$SLURM_JOB_ID \ --rdzv_backend=c10d \ --rdzv_endpoint=$(hostname) \ ) srun -l "${ARGS[@]}" torchrun "${TORCHRUN_ARGS[@]}" /path_to/train_external.py \ --train_batch_size 4 \ --max_steps 100 \ --hidden_width $HIDDEN_WIDTH \ --num_layers $NUM_LAYERS \ --num_heads $NUM_HEADS \ ${LLAMA_ARGS} \ --shard_degree $SHARD_DEGREE \ --model_type $model_type \ --profile_nsys 1 \ --use_smp_implementation 1 \ --max_context_width 4096 \ --tensor_parallel_degree 1 \ --use_synthetic_data $use_synthetic_data \ --training_dir $TRAINING_DIR \ --test_dir $TEST_DIR \ --dataset_type hf \ --checkpoint_dir $CHECKPOINT_DIR \ --checkpoint_freq 100 \ $ sbatch launch_training_enroot.sh ``` *Pour trouver les exemples de code téléchargeables, voir [Exécuter une tâche d'entraînement parallèle à un modèle à l'aide de la bibliothèque de parallélisme de modèles SageMaker AI, Docker et Enroot with Slurm](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot) dans le référentiel Awsome Distributed Training. GitHub * Pour plus d'informations sur l'entraînement distribué avec un cluster Slurm activé SageMaker HyperPod, passez à la rubrique suivante à l'adresse. [Exécution de charges de travail de formation distribuées avec Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md) # Exécution de charges de travail de formation distribuées avec Slurm on HyperPod SageMaker HyperPod est spécialisé pour les charges de travail liées à la formation de grands modèles linguistiques (LLMs) et de modèles de base (FMs). Ces charges de travail nécessitent souvent l’utilisation de plusieurs techniques de parallélisme et d’opérations optimisées pour l’infrastructure et les ressources ML. En utilisant SageMaker HyperPod, vous pouvez utiliser les frameworks de formation distribués SageMaker basés sur l'IA suivants : + La [bibliothèque de parallélisme distribué des données (SMDDP) basée sur l'SageMaker IA](data-parallel.md) qui propose des opérations de communication collective optimisées pour. AWS + La [bibliothèque de parallélisme des modèles SageMaker AI (SMP)](model-parallel-v2.md) qui implémente diverses techniques de parallélisme des modèles. **Topics** + [Utilisation de SMDDP sur un SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smddp) + [Utilisation du protocole SMP sur un cluster SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smp) ## Utilisation de SMDDP sur un SageMaker HyperPod La [bibliothèque SMDDP](data-parallel.md) est une bibliothèque de communication collective qui améliore les performances de calcul lors de l’entraînement parallèle des données distribuées. La bibliothèque SMDDP fonctionne avec les cadres d’entraînement distribué open source suivants : + [PyTorchDistributed Data Parallel (DDP)](https://pytorch.org/docs/stable/notes/ddp.html) + [PyTorch parallélisme de données entièrement segmenté (FSDP)](https://pytorch.org/docs/stable/fsdp.html) + [DeepSpeed](https://github.com/microsoft/DeepSpeed) + [Mégatron- DeepSpeed](https://github.com/microsoft/Megatron-DeepSpeed) La bibliothèque SMDDP prend en charge la surcharge de communication liée aux principales opérations de communication collective en proposant ce qui suit pour. SageMaker HyperPod + La bibliothèque propose des offres `AllGather` optimisées pour AWS. `AllGather`est une opération clé utilisée dans le cadre du sharded data parallel training, une technique de parallélisme de données économe en mémoire proposée par des bibliothèques populaires. Il s'agit notamment de la bibliothèque de parallélisme des modèles d' SageMaker IA (SMP), de DeepSpeed Zero Redundancy Optimizer (Zero) et de PyTorch Fully Sharded Data Parallelism (FSDP). + La bibliothèque optimise la node-to-node communication en utilisant pleinement l'infrastructure AWS réseau et la topologie d'instance SageMaker AI ML. **Pour exécuter des exemples de tâches d’entraînement de parallélisme des données** Explorez les exemples d’entraînement distribué suivants mettant en œuvre des techniques de parallélisme des données à l’aide de la bibliothèque SMDDP. + [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP) + [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed) **Pour configurer un environnement d'utilisation de la bibliothèque SMDDP sur SageMaker HyperPod** Vous trouverez ci-dessous les exigences relatives à l'environnement de formation pour utiliser la bibliothèque SMDDP sur. SageMaker HyperPod + PyTorch v2.0.1 et versions ultérieures + CUDA v11.8 et versions ultérieures + Version de l’environnement d’exécution `libstdc++` supérieure à 3 + Python v3.10.x et versions ultérieures + `ml.p4d.24xlarge` et `ml.p4de.24xlarge`, qui sont des types d’instances pris en charge par la bibliothèque SMDDP + `imdsv2` activé sur l’hôte d’entraînement Selon la manière dont vous souhaitez exécuter la tâche d’entraînement distribuée, deux options s’offrent à vous pour installer la bibliothèque SMDDP : + Installation directe à l’aide du fichier binaire SMDDP. + Utilisation des SageMaker AI Deep Learning Containers (DLCs) préinstallés avec la bibliothèque SMDDP. Les images Docker préinstallées avec la bibliothèque SMDDP ou dans les fichiers binaires SMDDP sont répertoriées dans la section [Frameworks pris en charge](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) dans la documentation de la bibliothèque SMDDP. URLs **Pour installer la bibliothèque SMDDP sur le DLAMI SageMaker HyperPod** + `pip install --no-cache-dir https://smdataparallel.s3.amazonaws.com/binary/pytorch//cuXYZ/YYYY-MM-DD/smdistributed_dataparallel-X.Y.Z-cp310-cp310-linux_x86_64.whl` **Note** Si vous travaillez dans un environnement Conda, veillez à installer PyTorch en utilisant `conda install` plutôt que. `pip` ``` conda install pytorch==X.Y.Z torchvision==X.Y.Z torchaudio==X.Y.Z pytorch-cuda=X.Y.Z -c pytorch -c nvidia ``` **Pour utiliser la bibliothèque SMDDP sur un conteneur Docker** + La bibliothèque SMDDP est préinstallée sur les SageMaker AI Deep Learning Containers (). DLCs Pour trouver la liste des frameworks d' SageMaker IA compatibles PyTorch avec la bibliothèque SMDDP, consultez la section DLCs [Frameworks pris en charge](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) dans la documentation de la bibliothèque SMDDP. Vous pouvez également apporter votre propre conteneur Docker avec les dépendances requises installées pour utiliser la bibliothèque SMDDP. Pour en savoir plus sur la configuration d’un conteneur Docker personnalisé pour utiliser la bibliothèque SMDDP, consultez également [Créez votre propre conteneur Docker avec la bibliothèque SageMaker AI distributed data parallel library](data-parallel-bring-your-own-container.md). **Important** Pour utiliser la bibliothèque SMDDP dans un conteneur Docker, montez le répertoire `/var/log` depuis la machine hôte sur `/var/log` dans le conteneur. Cela peut être fait en ajoutant l’option suivante lors de l’exécution de votre conteneur. ``` docker run -v /var/log:/var/log ... ``` Pour savoir comment exécuter des tâches d’entraînement de parallélisme des données avec SMDDP en général, consultez [Formation distribuée avec la bibliothèque de parallélisme de données distribué basée sur l' SageMaker IA](data-parallel-modify-sdp.md). ## Utilisation du protocole SMP sur un cluster SageMaker HyperPod La [bibliothèque de parallélisme des modèles SageMaker AI (SMP)](model-parallel-v2.md) propose différentes techniques de [parallélisme des state-of-the-art modèles](model-parallel-core-features-v2.md), notamment : + parallélisme des données pleinement partitionnées + parallélisme expert + entraînement de précision mixte avec les types FP16/BF16 et de FP8 données + parallélisme de tenseur La bibliothèque SMP est également compatible avec les frameworks open source tels que PyTorch FSDP, NVIDIA Megatron et NVIDIA Transformer Engine. **Pour exécuter un exemple de charge de travail d’entraînement de parallélisme des modèles** Les équipes du service d' SageMaker intelligence artificielle proposent des exemples de tâches de formation mettant en œuvre le parallélisme des modèles avec la bibliothèque SMP à l'adresse. [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2)