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.
SageMaker HyperPod références
Vous trouverez plus d'informations et de références sur l'utilisation SageMaker HyperPod dans les rubriques suivantes.
Rubriques
SageMaker HyperPod tarification
Les rubriques suivantes fournissent des informations sur la SageMaker HyperPod tarification. Pour en savoir plus sur le prix horaire d'utilisation des SageMaker HyperPod instances, consultez également Amazon SageMaker Pricing
Demandes de capacité
Vous pouvez allouer des capacités de calcul à la demande ou réservées avec SageMaker l'IA pour une utilisation sur SageMaker HyperPod. On-demand la création d'un cluster alloue la capacité disponible à partir du pool de capacités à la demande de l' SageMaker IA. Vous pouvez également demander une capacité réservée pour garantir l’accès en soumettant un ticket pour une augmentation du quota. Les demandes de capacité entrantes sont hiérarchisées par l' SageMaker IA et vous recevez une estimation du temps nécessaire à l'allocation de capacité.
Facturation du service
Lorsque vous allouez une capacité de calcul sur SageMaker HyperPod, vous êtes facturé pour la durée de l'allocation de capacité. SageMaker HyperPod la facturation apparaît sur vos factures d'anniversaire avec un poste correspondant au type d'allocation de capacité (à la demande, réservée), au type d'instance et au temps passé à utiliser l'instance.
Pour soumettre un ticket pour une augmentation de quota, consultez SageMaker HyperPod quotas.
SageMaker HyperPod APIs
La liste suivante est un ensemble complet d' SageMaker HyperPod API permettant de soumettre des demandes d'action au format JSON à SageMaker AI via AWS CLI ou AWS SDK pour Python (Boto3).
SageMaker HyperPod Configuration du Slurm
HyperPod prend en charge deux approches pour configurer Slurm sur votre cluster. Choisissez l'approche qui répond le mieux à vos besoins.
| Approche | Description | Recommandé pour |
| API-driven configuration | Définissez la configuration de Slurm directement dans les requêtes CreateCluster et API UpdateCluster | Nouveaux clusters ; gestion simplifiée |
| Configuration héritée | Utiliser un provisioning_parameters.json fichier distinct stocké dans Amazon S3 |
Clusters existants ; rétrocompatibilité |
API-driven Configuration Slurm (recommandée)
Avec API-driven la configuration, vous définissez les types de nœuds Slurm, les assignations de partitions et les montages de systèmes de fichiers directement dans les CreateCluster requêtes d'API et. UpdateCluster Cette approche permet de :
-
Source de vérité unique : toutes les configurations sont incluses dans la demande d'API
-
Pas de gestion de fichiers S3 : pas besoin de créer ou de maintenir
provisioning_parameters.json -
Built-in validation — L'API valide la topologie de Slurm avant la création du cluster
-
Détection de dérive — Détecte les modifications non autorisées apportées à
slurm.conf -
Per-instance-group stockage — Configurer différents systèmes de fichiers FSx pour différents groupes d'instances
-
Support de FSx pour OpenZFS — Montez des systèmes de fichiers OpenZFS en plus de FSx for Lustre
SlurmConfig (par groupe d'instances)
Ajoutez SlurmConfig à chaque groupe d'instances pour définir le type de nœud Slurm et l'attribution de partition.
"SlurmConfig": { "NodeType": "Controller | Login | Compute", "PartitionNames": ["string"] }
Paramètres :
-
NodeType: obligatoire. Type de nœud Slurm pour ce groupe d'instances. Valeurs valides :-
Controller— Nœud du contrôleur Slurm (tête). Exécute leslurmctlddaemon. Un seul groupe d'instances doit avoir ce type de nœud. -
Login— Nœud de connexion pour l'accès des utilisateurs. Facultatif. Au maximum un groupe d'instances peut avoir ce type de nœud. -
Compute— Nœuds de travail qui exécutent des tâches. Il peut y avoir plusieurs groupes d'instances avec ce type de nœud.
Important
NodeTypeest immuable. Une fois défini lors de la création du cluster, il ne peut pas être modifié. Pour utiliser un autre type de nœud, créez un nouveau groupe d'instances. -
-
PartitionNames— Conditionnel. Un tableau de noms de partitions Slurm. Obligatoire pour les types deComputenœuds ; non autorisé pour lesControllertypes deLoginnœuds. Supporte actuellement un seul nom de partition par groupe d'instances.Note
Tous les nœuds sont automatiquement ajoutés à la
devpartition universelle en plus de la partition spécifiée.
Exemple :
{ "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-bucket/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole" }
Orchestrator.Slurm (au niveau du cluster)
Ajoutez Orchestrator.Slurm à la configuration du cluster pour spécifier le mode HyperPod de gestion du slurm.conf fichier.
"Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed | Overwrite | Merge" } }
Paramètres :
-
SlurmConfigStrategy— Obligatoire lorsqu'Orchestrator.Slurmil est fourni. Contrôle la façon dont leslurm.conffichier est HyperPod géré sur le nœud du contrôleur. Valeurs valides :-
Managed(par défaut) : contrôle HyperPod entièrement les mappages partition-nœud dans.slurm.confLa détection de dérive est activée : si le courantslurm.confdiffère de la configuration attendue, elle UpdateCluster échoue avec une erreur. Utilisez cette stratégie lorsque vous HyperPod souhaitez être la seule source fiable pour la configuration de Slurm. -
Overwrite— HyperPod force l'application de la configuration de l'API, en remplaçant toute modification manuelle apportée àslurm.conf. La détection de dérive est désactivée. Utilisez cette stratégie pour récupérer après une dérive ou remettre le cluster dans un état connu. -
Merge— HyperPod préserveslurm.confles modifications manuelles et les fusionne avec la configuration de l'API. La détection de dérive est désactivée. Utilisez cette stratégie si vous devez apporter des modifications manuelles à la configuration de Slurm qui devraient persister d'une mise à jour à l'autre.
-
Note
S'il Orchestrator.Slurm n'est pas indiqué dans la demande, le comportement par défaut est la Managed stratégie.
Astuce
Vous pouvez le modifier SlurmConfigStrategy à tout moment en utilisant UpdateCluster. Il n'y a aucun lien avec une stratégie spécifique.
Exemple :
{ "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [...], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } }
SlurmConfigStrategy comparaison
| Stratégie | Détection de dérive | Modifications manuelles | Cas d'utilisation |
Managed |
Activé : bloque les mises à jour en cas de dérive détectée | Bloqué | HyperPod géré |
Overwrite |
Désactivé | Remplacé | Restauration après une dérive ; remise à un état connu |
Merge |
Désactivé | préservé | Utilisateurs avancés ayant des slurm.conf besoins personnalisés |
Configuration de FSx via InstanceStorageConfigs
Avec API-driven la configuration, vous pouvez configurer les systèmes de fichiers FSx par groupe d'instances à l'aide de. InstanceStorageConfigs Cela permet à différents groupes d'instances de monter différents systèmes de fichiers.
Prérequis :
-
Votre cluster doit utiliser un VPC personnalisé (via
VpcConfig). Les systèmes de fichiers FSx résident dans votre VPC, et le VPC géré par la plateforme ne peut pas les atteindre. -
Au moins un groupe d'instances doit avoir
SlurmConfigavecNodeType: Controller.
FsxLustreConfig
Configurez le montage du système de fichiers FSx for Lustre pour un groupe d'instances.
"InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "string", "MountPath": "string", "MountName": "string" } } ]
Paramètres :
-
DnsName: obligatoire. Nom DNS du système de fichiers FSx for Lustre. Exemple :fs-0abc123def456789.fsx.us-west-2.amazonaws.com -
MountPath: facultatif. Le chemin de montage local sur l'instance. Valeur par défaut :/fsx -
MountName: obligatoire. Nom de montage du système de fichiers FSx for Lustre. Vous pouvez le trouver dans la console Amazon FSx ou en exécutant.aws fsx describe-file-systems
FsxOpenZfsConfig
Configurez FSx pour le montage du système de fichiers OpenZFS pour un groupe d'instances.
"InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "string", "MountPath": "string" } } ]
Paramètres :
-
DnsName: obligatoire. Nom DNS du système de fichiers FSx pour OpenZFS. Exemple :fs-0xyz987654321.fsx.us-west-2.amazonaws.com -
MountPath: facultatif. Le chemin de montage local sur l'instance. Valeur par défaut :/home
Note
Chaque groupe d'instances peut en comporter au maximum un FsxLustreConfig et unFsxOpenZfsConfig.
Exemple avec plusieurs systèmes de fichiers :
{ "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 4, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } }, { "FsxOpenZfsConfig": { "DnsName": "fs-0xyz987654321.fsx.us-west-2.amazonaws.com", "MountPath": "/shared" } }, { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-bucket/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole" }
Important
Les modifications de configuration de FSx ne s'appliquent que lors du provisionnement des nœuds. Les nœuds existants conservent leur configuration FSx d'origine. Pour appliquer la nouvelle configuration FSx à tous les nœuds, réduisez le groupe d'instances à 0, puis redimensionnez-le.
Exemple API-driven de configuration complet
L'exemple suivant montre une CreateCluster demande complète utilisant la configuration de API-driven Slurm :
{ "ClusterName": "ml-training-cluster", "InstanceGroups": [ { "InstanceGroupName": "controller", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2 }, { "InstanceGroupName": "login", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2 }, { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2, "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"] }, { "InstanceGroupName": "cpu-compute", "InstanceType": "ml.c5.18xlarge", "InstanceCount": 4, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["cpu-preprocessing"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2 } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "VpcConfig": { "SecurityGroupIds": ["sg-0abc123def456789a"], "Subnets": ["subnet-0abc123def456789a", "subnet-0abc123def456789b"] }, "Tags": [ { "Key": "Project", "Value": "ML-Training" } ] }
Pour en savoir plus sur l'utilisation API-driven de la configuration, consultezPersonnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie.
Configuration héritée : provisioning_parameters.json
Note
provisioning_parameters.jsonCette approche est la méthode traditionnelle pour configurer Slurm sur. HyperPod Pour les nouveaux clusters, nous recommandons d'utiliser l'approche API-driven de configuration décrite ci-dessus. L'ancienne approche reste entièrement prise en charge pour des raisons de rétrocompatibilité.
Avec l'approche traditionnelle, vous créez un fichier de configuration Slurm nommé provisioning_parameters.json et vous le chargez sur Amazon S3 dans le cadre de vos scripts de cycle de vie. HyperPod lit ce fichier lors de la création du cluster pour configurer les nœuds Slurm.
Formulaire de configuration pour provisioning_parameters.json
Le code suivant est le formulaire de configuration de Slurm que vous devez préparer pour configurer correctement les nœuds Slurm sur votre cluster. HyperPod Vous devez remplir ce formulaire et le charger dans le cadre d’un ensemble de scripts de cycle de vie lors de la création du cluster. Pour savoir comment ce formulaire doit être préparé tout au long des processus de création de HyperPod clusters, voirPersonnalisation des SageMaker HyperPod clusters à l'aide de scripts de cycle de vie.
// Save as provisioning_parameters.json. { "version": "1.0.0", "workload_manager": "slurm", "controller_group": "string", "login_group": "string", "worker_groups": [ { "instance_group_name": "string", "partition_name": "string" } ], "fsx_dns_name": "string", "fsx_mountname": "string" }
Paramètres :
-
version: obligatoire. Il s'agit de la version du formulaire des paramètres HyperPod d'approvisionnement. Conservez1.0.0. -
workload_manager: obligatoire. Cela permet de spécifier le gestionnaire de charge de travail à configurer sur le HyperPod cluster. Conservezslurm. -
controller_group: obligatoire. Cela permet de spécifier le nom du groupe d'instances de HyperPod cluster que vous souhaitez attribuer au nœud du contrôleur (tête) Slurm. -
login_group: facultatif. Cela permet de spécifier le nom du groupe d'instances de HyperPod cluster que vous souhaitez attribuer au nœud de connexion Slurm. -
worker_groups: obligatoire. Cela permet de configurer les nœuds de travail (de calcul) Slurm sur le HyperPod cluster.-
instance_group_name: obligatoire. Cela permet de spécifier le nom du groupe d' HyperPod instances que vous souhaitez attribuer au nœud de travail (de calcul) de Slurm. -
partition_name: obligatoire. Cela permet de spécifier le nom de partition au nœud.
-
-
fsx_dns_name: facultatif. Si vous souhaitez configurer vos nœuds Slurm sur le HyperPod cluster pour communiquer avec Amazon FSx, spécifiez le nom DNS de FSx. -
fsx_mountname: facultatif. Si vous souhaitez configurer vos nœuds Slurm sur le HyperPod cluster pour communiquer avec Amazon FSx, spécifiez le nom du montage FSx.
Comparaison entre la configuration API-driven traditionnelle et la configuration existante
| Fonctionnalité | API-driven (Recommandé) | Héritage (provisioning_parameters.json) |
| Emplacement de configuration | CreateCluster Demande d'API | Fichier S3 |
| FSx pour Lustre | Oui — Par groupe d'instances | Oui — Cluster-wide uniquement |
| FSx pour OpenZFS | Oui — Par groupe d'instances | Non — Non pris en charge |
| Built-in validation | Oui | Non |
| Détection des écarts | Oui — (Stratégie gérée) | Non |
| Gestion des fichiers S3 | Facultatif | Obligatoire |
| Complexité des scripts de cycle | Simplifié | Configuration complète du SLURM requise |
SageMaker HyperPod DLAMI
SageMaker HyperPod exécute un DLAMI basé sur :
-
AWS AMI GPU Deep Learning Base (Ubuntu 20.04)
pour l'orchestration avec Slurm. -
AMI basée sur Amazon Linux 2 pour l’orchestration avec Amazon EKS.
Le SageMaker HyperPod DLAMI est fourni avec des packages supplémentaires pour prendre en charge les outils open source tels que Slurm, Kubernetes, les dépendances et les packages logiciels de cluster pour prendre en charge les fonctionnalités de résilience telles que le contrôle de l'état du cluster SageMaker HyperPod et la reprise automatique. Pour suivre les mises à jour HyperPod logicielles distribuées par l'équipe de HyperPod service via DLamis, voir. Notes de SageMaker HyperPod publication d'Amazon
SageMaker HyperPod Référence des autorisations d'API
Important
Les politiques IAM personnalisées qui permettent à Amazon SageMaker Studio ou Amazon SageMaker Studio Classic de créer des SageMaker ressources Amazon doivent également accorder des autorisations pour ajouter des balises à ces ressources. L’autorisation d’ajouter des balises aux ressources est requise, car Studio et Studio Classic balisent automatiquement toutes les ressources qu’ils créent. Si une politique IAM autorise Studio et Studio Classic à créer des ressources mais n'autorise pas le balisage, des erreurs « AccessDenied » peuvent se produire lors de la tentative de création de ressources. Pour de plus amples informations, veuillez consulter Fournir des autorisations pour le balisage des ressources d' SageMaker IA.
AWS politiques gérées pour Amazon SageMaker AIqui donnent des autorisations pour créer des SageMaker ressources incluent déjà des autorisations pour ajouter des balises lors de la création de ces ressources.
Lorsque vous configurez le contrôle d'accès pour autoriser l'exécution d'opérations d' SageMaker HyperPod API et que vous rédigez une politique d'autorisation que vous pouvez associer aux utilisateurs IAM pour les administrateurs du cloud, utilisez le tableau suivant comme référence.
| Opérations de SageMaker l'API Amazon | Autorisations requises (actions d'API) | Ressources |
| CreateCluster | sagemaker:CreateCluster |
arn:aws:sagemaker: |
| DeleteCluster | sagemaker:DeleteCluster |
arn:aws:sagemaker: |
| DescribeCluster | sagemaker:DescribeCluster |
arn:aws:sagemaker: |
| DescribeClusterNode | sagemaker:DescribeClusterNode |
arn:aws:sagemaker: |
| ListClusterNodes | sagemaker:ListClusterNodes |
arn:aws:sagemaker: |
| ListClusters | sagemaker:ListClusters |
arn:aws:sagemaker: |
| UpdateCluster | sagemaker:UpdateCluster |
arn:aws:sagemaker: |
| UpdateClusterSoftware | sagemaker:UpdateClusterSoftware |
arn:aws:sagemaker: |
Pour obtenir la liste complète des autorisations et des types de ressources pour les SageMaker API, consultez la section Actions, ressources et clés de condition pour Amazon SageMaker AI dans le AWS Service Authorization Reference.
SageMaker HyperPod commandes dans AWS CLI
Les AWS CLI commandes suivantes permettent d'exécuter SageMaker HyperPod les principales opérations de HyperPod l'API.
SageMaker HyperPod Modules Python dans AWS SDK pour Python (Boto3)
Voici les méthodes utilisées par le AWS SDK pour Python (Boto3) client pour que l' SageMaker IA exécute les principales opérations de HyperPod l'API.