Commencer à SageMaker HyperPod utiliser le AWS CLI - Amazon SageMaker AI

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.

Commencer à SageMaker HyperPod utiliser le AWS CLI

Créez votre premier SageMaker HyperPod cluster à l'aide des AWS CLI commandes pour HyperPod.

Créez votre premier SageMaker HyperPod cluster avec Slurm

Le didacticiel suivant explique comment créer un nouveau SageMaker HyperPod cluster et le configurer avec Slurm à l'aide des AWS CLI commandes pour. SageMaker HyperPod À la suite du didacticiel, vous allez créer un HyperPod cluster avec trois nœuds Slurm : my-controller-groupmy-login-group, et. worker-group-1

Avec l'approche de configuration pilotée par API, vous définissez les types de nœuds Slurm et les assignations de partitions directement dans la demande d'API à l' CreateCluster aide de. SlurmConfig Cela élimine le besoin d'un provisioning_parameters.json fichier distinct et fournit une validation, une détection de dérive et une per-instance-group FSx configuration intégrées.

  1. Tout d’abord, préparez et chargez des scripts de cycle de vie dans un compartiment Amazon S3. Lors de la création du cluster, HyperPod exécutez-les dans chaque groupe d'instances. Chargez des scripts de cycle de vie sur Amazon S3 à l’aide de la commande suivante.

    aws s3 sync \ ~/local-dir-to-lifecycle-scripts/* \ s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src
    Note

    Le chemin du compartiment S3 doit commencer par un préfixesagemaker-, car le rôle IAM pour SageMaker HyperPod with autorise AmazonSageMakerClusterInstanceRolePolicy uniquement l'accès aux compartiments Amazon S3 commençant par le préfixe spécifique.

    Si vous partez de zéro, utilisez des exemples de scripts de cycle de vie fournis dans le GitHub référentiel Awsome Distributed Training. Les sous-étapes suivantes montrent comment télécharger et charger les exemples de scripts de cycle de vie dans un compartiment Amazon S3.

    1. Téléchargez une copie des exemples de scripts de cycle de vie dans un répertoire de votre ordinateur local.

      git clone https://github.com/aws-samples/awsome-distributed-training/
    2. Accédez au répertoire 1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config, où vous trouverez un ensemble de scripts de cycle de vie.

      cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

      Pour en savoir plus sur les exemples de scripts de cycle de vie, consultez Personnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie.

    3. Chargez les scripts dans s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src. Vous pouvez le faire en utilisant la console Amazon S3 ou en exécutant la commande de l’ AWS CLI Amazon S3 suivante.

      aws s3 sync \ ~/local-dir-to-lifecycle-scripts/* \ s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src
    Note

    Avec la configuration pilotée par API, il n'est pas nécessaire de créer ou de télécharger un provisioning_parameters.json fichier. La configuration de Slurm est définie directement dans la demande CreateCluster d'API à l'étape suivante.

  2. Préparez un fichier de CreateClusterdemande au format JSON et enregistrez-le souscreate_cluster.json.

    Avec la configuration pilotée par API, vous spécifiez le type de nœud Slurm et l'attribution de partition pour chaque groupe d'instances à l'aide du champ. SlurmConfig Vous configurez également les paramètres Slurm au niveau du cluster à l'aide de. Orchestrator.Slurm

    Pour ExecutionRole, fournissez l’ARN du rôle IAM que vous avez créé avec la politique AmazonSageMakerClusterInstanceRolePolicy gérée dans Conditions préalables à l'utilisation SageMaker HyperPod.

    { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::<account-id>:role/HyperPodExecutionRole", "InstanceStorageConfigs": [ { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ] }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::<account-id>:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::<account-id>:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } }

    SlurmConfig champs :

    Champ Description
    NodeType Le rôle Slurm pour le groupe d'instances. Valeurs valides : Controller, Login, Compute
    PartitionNames La ou les partitions Slurm auxquelles attribuer les nœuds de calcul. Valable uniquement pour le type de Compute nœud.

    Champs Orchestrator.Slurm :

    Champ Description
    SlurmConfigStrategy Contrôle la façon dont il HyperPod gèreslurm.conf. Valeurs valides : Managed (par défaut)Overwrite, Merge

    SlurmConfigStrategy options :

    • Managed(recommandé) : gère slurm.conf et détecte HyperPod entièrement les modifications non autorisées (détection de dérive). Les mises à jour échouent si une dérive est détectée.

    • Overwrite: HyperPod remplace slurm.conf lors des mises à jour, en ignorant les modifications manuelles.

    • Merge: HyperPod préserve les modifications manuelles et les fusionne avec la configuration de l'API.

    Ajout FSx pour Lustre (facultatif) :

    Pour monter un système de fichiers FSx for Lustre sur vos nœuds de calcul, ajoutez-le FsxLustreConfig au groupe d'instances InstanceStorageConfigs for the. Cela nécessite une configuration VPC personnalisée.

    { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::<account-id>:role/HyperPodExecutionRole" }

    Ajout FSx pour OpenZFS (facultatif) :

    Vous pouvez également effectuer un montage FSx pour les systèmes de fichiers OpenZFS :

    "InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com", "MountPath": "/shared" } } ]
    Note

    Chaque groupe d'instances peut en avoir au maximum un FSx pour la configuration Lustre et un FSx pour la configuration OpenZFS. Différents groupes d'instances peuvent monter différents systèmes de fichiers.

    Ajout d'une configuration VPC (obligatoire pour FSx) :

    Si vous l'utilisez FSx, vous devez spécifier une configuration VPC personnalisée :

    { "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::<account-id>:role/HyperPodExecutionRole" }, ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "VpcConfig": { "SecurityGroupIds": ["sg-0abc123def456789a"], "Subnets": ["subnet-0abc123def456789a"] } }
  3. Exécutez la commande suivante pour créer le cluster.

    aws sagemaker create-cluster --cli-input-json file://complete/path/to/create_cluster.json

    Elle devrait renvoyer l’ARN du cluster créé.

    { "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster" }

    Si vous recevez un message d’erreur dû à des limites de ressources, assurez-vous de remplacer le type d’instance par un type avec des quotas suffisants sur votre compte, ou demandez des quotas supplémentaires en suivant la section SageMaker HyperPod quotas.

    Erreurs de validation courantes :

    Erreur Résolution
    « Le cluster doit en avoir exactement un InstanceGroup avec le type de nœud Controller » Assurez-vous qu'un seul groupe d'instances possède les éléments SlurmConfig.NodeType suivants : "Controller"
    « Les partitions ne peuvent être attribuées qu'aux types de nœuds de calcul » Supprimer PartitionNames des groupes d'Logininstances Controller ou des groupes d'instances
    « les FSx configurations ne sont prises en charge que pour les VPC personnalisés » Ajoutez VpcConfig à votre demande lorsque vous utilisez FSx
  4. Exécutez describe-cluster pour vérifier le statut du cluster.

    aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster

    Exemple de réponse :

    { "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster", "ClusterName": "my-hyperpod-cluster", "ClusterStatus": "Creating", "InstanceGroups": [ { "InstanceGroupName": "my-controller-group", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "CurrentCount": 0, "TargetCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<bucket>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" }, { "InstanceGroupName": "my-login-group", "InstanceType": "ml.m5.4xlarge", "InstanceCount": 1, "CurrentCount": 0, "TargetCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<bucket>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" }, { "InstanceGroupName": "worker-group-1", "InstanceType": "ml.trn1.32xlarge", "InstanceCount": 1, "CurrentCount": 0, "TargetCount": 1, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["partition-1"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-<bucket>/src", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole" } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "CreationTime": "2024-01-15T10:30:00Z" }

    Une fois que le statut du cluster passe à InService, passez à l’étape suivante. La création d'un cluster prend généralement 10 à 15 minutes.

  5. Exécutez list-cluster-nodes pour vérifier les détails des nœuds du cluster.

    aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster

    Exemple de réponse :

    { "ClusterNodeSummaries": [ { "InstanceGroupName": "my-controller-group", "InstanceId": "i-0abc123def456789a", "InstanceType": "ml.c5.xlarge", "InstanceStatus": { "Status": "Running", "Message": "" }, "LaunchTime": "2024-01-15T10:35:00Z" }, { "InstanceGroupName": "my-login-group", "InstanceId": "i-0abc123def456789b", "InstanceType": "ml.m5.4xlarge", "InstanceStatus": { "Status": "Running", "Message": "" }, "LaunchTime": "2024-01-15T10:35:00Z" }, { "InstanceGroupName": "worker-group-1", "InstanceId": "i-0abc123def456789c", "InstanceType": "ml.trn1.32xlarge", "InstanceStatus": { "Status": "Running", "Message": "" }, "LaunchTime": "2024-01-15T10:36:00Z" } ] }

    InstanceIdC'est ce dont les utilisateurs de votre cluster ont besoin pour s'y connecter (aws ssm). Pour plus d’informations sur la connexion aux nœuds du cluster et l’exécution de charges de travail ML, consultez Offres d'emploi sur SageMaker HyperPod des clusters.

  6. Connectez-vous à votre cluster à l'aide du gestionnaire de AWS Systems Manager session.

    aws ssm start-session \ --target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \ --region us-west-2

    Une fois connecté, vérifiez que Slurm est correctement configuré :

    # Check Slurm nodes sinfo # Check Slurm partitions sinfo -p partition-1 # Submit a test job srun -p partition-1 --nodes=1 hostname

Suppression du cluster et nettoyage des ressources

Une fois que vous avez testé avec succès la création d'un SageMaker HyperPod cluster, celui-ci continue de fonctionner tel quel InService jusqu'à ce que vous le supprimiez. Nous vous recommandons de supprimer tous les clusters créés à l'aide de capacités d' SageMaker IA à la demande lorsqu'ils ne sont pas utilisés afin d'éviter de devoir payer des frais de service continus basés sur la tarification à la demande. Dans ce didacticiel, vous avez créé un cluster composé de trois groupes d'instances. Assurez-vous de supprimer le cluster en exécutant la commande suivante.

aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster

Pour nettoyer les scripts de cycle de vie du compartiment Amazon S3 utilisé pour ce didacticiel, accédez au compartiment Amazon S3 que vous avez utilisé lors de la création du cluster et supprimez complètement les fichiers.

aws s3 rm s3://sagemaker-<unique-s3-bucket-name>/<lifecycle-script-directory>/src --recursive

Si vous avez testé l'exécution de charges de travail de formation de modèles sur le cluster, vérifiez également si vous avez téléchargé des données ou si votre tâche a enregistré des artefacts dans différents buckets Amazon S3 ou services de système de fichiers tels qu'Amazon FSx for Lustre et Amazon Elastic File System. Pour éviter d’encourir des frais, supprimez tous les artefacts et toutes les données du stockage ou du système de fichiers.