Nous avons récemment introduit la possibilité de créer et de gérer des Amazon SageMaker Spaces sur des clusters Amazon SageMaker HyperPod EKS directement depuis l'interface utilisateur d'Amazon SageMaker Studio. Les data scientists et les ingénieurs en apprentissage automatique (ML) peuvent désormais lancer des environnements JupyterLab et Code Editor sur des clusters HyperPod sans quitter leur navigateur ni utiliser d'outils en ligne de commande, réduisant le temps entre l'accès au cluster et un développement productif à quelques clics.
Contexte
Amazon SageMaker HyperPod fournit une infrastructure conçue sur mesure pour l'entraînement et l'inférence des modèles de fondation (FM) à grande échelle. Avec Amazon Elastic Kubernetes Service (Amazon EKS) l'orchestration, les équipes peuvent exécuter des tâches d'entraînement distribué sur des centaines d'accélérateurs avec une résilience intégrée et une récupération automatique en cas de panne. En plus de l'entraînement, HyperPod étend cette infrastructure orchestrée par EKS pour servir l'inférence à faible latence et évolutive de modèles de fondation à plusieurs milliards de paramètres.
Plus tôt cette année, nous avons lancé Amazon SageMaker Spaces pour HyperPod, un module complémentaire que les développeurs ML peuvent utiliser pour créer des environnements de développement interactifs directement sur les clusters HyperPod EKS. Les organisations pouvaient ainsi maximiser leurs investissements GPU en exécutant des charges de travail interactives aux côtés des tâches d'entraînement et du déploiement de modèles sur la même infrastructure, avec prise en charge des allocations fractionnaires de GPU.
Auparavant, la création et la gestion des Spaces reposaient principalement sur la HyperPod CLI ou kubectl commandes. Bien que cette approche offre un contrôle puissant et granulaire aux administrateurs d'infrastructure, les data scientists qui préfèrent une interface visuelle peuvent désormais utiliser cette nouvelle capacité de SageMaker Studio pour se passer des outils en ligne de commande et se consacrer entièrement au développement de modèles.
Quoi de neuf
Grâce à cette nouvelle capacité, les data scientists peuvent désormais créer, configurer, démarrer, arrêter et ouvrir des Spaces directement depuis SageMaker Studio. Le nouvel onglet IDE et Notebooks sur la page de détails du cluster HyperPod fournit une interface utilisateur complète pour la gestion des Spaces, éliminant le besoin d'outils CLI pour les opérations quotidiennes sur les Spaces.
Les principales capacités disponibles via Studio comprennent :
- Créer des Spaces avec des ressources de calcul, des namespaces, du stockage configurables, HyperPod Task Governance pour la gestion des quotas de calcul et les paramètres d'image via un formulaire guidé.
- Afficher tous les Spaces dans un tableau avec recherche montrant le nom, le type d'application, le statut, le type d'accès, le stockage et les allocations de GPU et de vCPU.
- Démarrer et arrêter des Spaces en une seule sélection pour libérer des ressources de calcul lorsque les Spaces ne sont pas utilisés.
- Ouvrir les Spaces directement dans le navigateur (JupyterLab ou Code Editor) ou s'y connecter via un IDE distant de votre choix (par exemple, VS Code).
Figure 1 : L'onglet IDE et Notebooks sur la page de détails du cluster HyperPod affiche tous les Spaces avec leur statut, leur allocation de calcul et des actions rapides pour arrêter, ouvrir ou ouvrir dans un IDE distant
Premiers pas
La configuration implique deux rôles : les administrateurs préparent le cluster, et les data scientists créent et ouvrent les Spaces. Les sections suivantes couvrent chacun de ces rôles.
Pour les administrateurs
Les administrateurs installent le module complémentaire SageMaker Spaces sur leur cluster HyperPod EKS en utilisant soit l’option Installation rapide (en un clic avec des paramètres par défaut optimisés), soit l’option Installation personnalisée (nécessaire pour configurer l’accès à l’interface web), depuis l’onglet IDE et notebooks de leur cluster SageMaker HyperPod EKS. Une fois le module installé, l’administrateur peut configurer des espaces de noms, créer des modèles d’espace (Space) et gérer les accès via les entrées d’accès EKS.
La configuration suivante doit être effectuée une seule fois par les administrateurs :
- Installez le module complémentaire Spaces : Dans la console Amazon SageMaker AI, ouvrez votre cluster HyperPod, accédez à l’onglet IDE et notebooks et choisissez soit Installation rapide soit Installation personnalisée (l’installation personnalisée est requise pour activer l’accès via navigateur web). Consultez la documentation AWS pour des instructions complètes.
- Configurez les entrées d’accès EKS : Associez les trois politiques gérées
AmazonSagemakerHyperpodSpacePolicy,AmazonSagemakerHyperpodUserClusterPolicy, etAmazonSagemakerHyperpodSpaceTemplatePolicyaux rôles AWS Identity and Access Management (IAM) utilisés par vos data scientists. - Activez la propagation d'identité par utilisateur sur le domaine Studio : Si votre domaine Studio a été créé avant le déploiement de l'intégration entre SageMaker Studio et HyperPod Spaces, vous devez activer la propagation d'identité par utilisateur vers le cluster EKS HyperPod. Cela garantit que les actions de chaque utilisateur Studio sur le cluster (créer, arrêter ou supprimer un Space) sont attribuées à son profil utilisateur dans les entrées d'accès EKS et dans AWS CloudTrail. De plus, ce mappage d'identité applique une propriété stricte des Spaces. Il suit quel utilisateur a créé l'environnement et détermine si le Space est privé ou partagé sur le domaine SageMaker Studio.
Exécutez la commande suivante une fois par domaine Studio :
aws sagemaker update-domain \
--domain-id $DOMAIN_ID \
--default-user-settings '{
"StudioWebPortalSettings": {
"ExecutionRoleSessionNameMode": "USER_IDENTITY"
}
}'Après la mise à jour du domaine, vérifiez que la commande suivante renvoie « USER_IDENTITY » :
aws sagemaker describe-domain --domain-id $DOMAIN_ID \
--query 'DefaultUserSettings.StudioWebPortalSettings.ExecutionRoleSessionNameMode'Les applications en cours d'exécution ne sont pas affectées. Les utilisateurs prendront en compte le nouveau paramètre lors de leur prochaine connexion.
- Activez éventuellement des fonctionnalités supplémentaires : Activez l'une des fonctionnalités du tableau Optional capabilities suivant.
Pour les data scientists
Une fois l'extension installée et l'accès configuré, les data scientists accèdent à leur cluster HyperPod dans SageMaker Studio sous Compute → HyperPod et sélectionnent l'onglet IDE and Notebooks pour voir l'interface de gestion des Spaces (voir Figure 1). Apprenez-en plus sur la création et la gestion des Spaces : Créer et gérer des Spaces sur HyperPod.
Une fois que le statut du Space affiche Running (généralement quelques minutes sur un cluster à froid, environ 30–40 secondes avec sur-provisionnement), choisissez Open pour lancer JupyterLab ou Code Editor dans votre navigateur (Figures 2 et 3), ou Open in VS Code pour vous connecter depuis votre éditeur local via SSH-over-SSM (Figure 4).
Figure 2 : Un Space JupyterLab accessible via le navigateur web, montrant le Launcher avec les noyaux de notebook disponibles, les consoles et l'accès au terminal
Travailler dans un Space JupyterLab
Après avoir ouvert un Space JupyterLab, vous disposez d'un environnement de développement entièrement configuré avec un accès à :
- Des notebooks Python 3 avec ipykernel.
- Les consoles Glue PySpark et Glue Spark.
- Les noyaux SparkMagic PySpark et Spark.
- Un accès au terminal pour exécuter des commandes.
- Un navigateur de fichiers avec stockage persistant.
- Un chat intégré et une aide contextuelle.
Votre travail persiste sur le volume Amazon Elastic Block Store (Amazon EBS) attaché, vous pouvez donc arrêter et redémarrer les Spaces sans perdre votre progression.
Figure 3 : Un Space Code Editor s'exécutant sur HyperPod, montrant l'interface web de style VS Code avec l'explorateur de fichiers, l'éditeur et le terminal intégré
Travailler dans un Space Code Editor
Pour les développeurs qui préfèrent une expérience de style VS Code dans le navigateur, les Spaces Code Editor offrent un IDE léger basé sur le web avec :
- Édition complète des fichiers avec coloration syntaxique et IntelliSense.
- Terminal intégré pour exécuter des commandes shell, soumettre des travaux d'entraînement ou interagir avec des ressources de cluster.
- Prise en charge des extensions pour les serveurs de langage, les linters et les formateurs.
- Intégration Git pour les flux de travail de gestion de versions.
- Accès direct au système de fichiers du cluster et aux volumes Amazon FSx montés.
Les Code Editor Spaces sont parfaitement adaptés à l'écriture et au débogage de scripts d'entraînement, à la gestion des configurations d'expériences et au travail avec des dépôts de code, le tout sans quitter le navigateur.
Figure 4 : Une instance locale de VS Code connectée à distance à un HyperPod Space, montrant l'indicateur de connexion à distance et toutes les capacités IDE s'exécutant sur la puissance de calcul du cluster
Connexion à un IDE distant (VS Code)
Choisissez Open in VS Code dans le tableau des Spaces pour connecter votre Visual Studio Code local au Space exécuté sur HyperPod. Cela utilise en interne un tunneling SSH sur SSM, offrant une connexion sécurisée sans que vous ayez à gérer des clés SSH ni à exposer le port 22.
Vous bénéficiez de toute la puissance de votre environnement VS Code local, y compris les extensions, les thèmes et les raccourcis clavier, tout en exécutant le code sur la puissance de calcul du cluster HyperPod.
Vous pouvez également vous connecter à l'aide de l'AWS Toolkit for Visual Studio Code, qui répertorie vos Spaces sous SageMaker AI > HyperPod, et vous pouvez démarrer, arrêter et vous connecter aux Spaces directement depuis le panneau du toolkit.
Capacités optionnelles
Chaque capacité décrite ci-dessous est optionnelle et composable. Activez toute combinaison correspondant aux besoins de votre équipe.
| Capacité | Description |
| Accès par navigateur web | AWS Application Load Balancer et DNS personnalisé via Amazon Route 53 pour acheminer le trafic du navigateur vers les Spaces. Non requis pour l'accès à un IDE distant (VS Code via SSM). |
| Modèles de Space | Modèles définis par l'administrateur qui préconfigurent le calcul, les images, le stockage et les scripts de cycle de vie pour des configurations de Space cohérentes entre les équipes. |
| Task Governance | Quotas de calcul au niveau des namespaces, files d'attente et admission basée sur les priorités via Kueue pour les clusters multi-locataires. |
| Autoscaling Karpenter | Mise à l'échelle dynamique des nœuds (augmentation/réduction) en fonction de la demande des Spaces. |
| Sur-provisionnement Karpenter | Nœuds préchauffés avec des images pré-téléchargées qui réduisent le démarrage d'un Space de 5–7 minutes à environ 30–40 secondes. Consultez la section Astuce de pro suivante. |
| Volumes persistants (EFS / FSx) | Répertoires utilisateurs partagés et jeux de données d'équipe qui persistent d'un Space à l'autre. |
| Images personnalisées (ECR) | Environnements d'exécution et bibliothèques propres à l'équipe intégrés dans des images de conteneurs hébergées dans Amazon Elastic Container Registry (Amazon ECR). |
| Arrêt en cas d'inactivité | Résiliation automatique des Spaces inactifs pour se prémunir contre les coûts de calcul incontrôlés. |
| NVIDIA MIG | Allocation fractionnaire de GPU pour des charges de travail interactives économiques sur le matériel A100/H100. |
Astuce de pro : réduire le temps de démarrage des Spaces grâce au sur-provisionnement des nœuds
Par défaut, SageMaker Spaces sur les clusters HyperPod EKS utilisant l'autoscaling Karpenter entraîne un délai de démarrage à froid de 5–7 minutes lors de la première création d'un Space sur un cluster scale-to-zero, principalement dû à :
- Le lancement d'instance Amazon Elastic Compute Cloud (Amazon EC2).
- L'enregistrement du nœud Kubernetes.
- Le téléchargement de l'image SageMaker Distribution (SMD).
Pour les charges de travail interactives sensibles à la latence (JupyterLab, Code Editor), vous pouvez maintenir un pool de nœuds préchauffés avec images en cache en utilisant le schéma standard de sur-provisionnement Kubernetes. Cela fait passer le temps de démarrage d'un Space de plusieurs minutes à environ 30–40 secondes.
Comment ça fonctionne
- Un Deployment de substitution à basse priorité (
-1000) maintient un pod Kubernetes sur chaque nœud chaud. Ces pods demandent le même CPU/mémoire qu'un véritable Space. - Un
initContainersur chaque placeholder pré-télécharge l'image SageMaker Distribution sur le nœud lorsque Karpenter le provisionne. - Lorsqu'un utilisateur crée un Space (priorité par défaut
0), l'ordonnanceur Kubernetes préempte le placeholder (priorité-1000). Le Space se retrouve alors sur le nœud déjà chaud, avec l'image en cache, en quelques secondes, sans téléchargement d'image ni attente de lancement de nœud. - Karpenter provisionne en arrière-plan un nœud de remplacement pour le placeholder déplacé.
En savoir plus sur le déploiement Pro tip : Overprovisioning pour HyperPod Spaces.
Latences de démarrage vérifiées sur ml.m5.12xlarge (24 vCPU allouables, 2 vCPU placeholder, 8 GiB de mémoire placeholder) avec l'image sagemaker-distribution:latest-cpu SMD, qui fait environ 3.5 Go :
| Chemin | Latence |
| Le Space s'installe à côté du placeholder (coexistence) | ~14 s |
| Le Space préempte le placeholder | ~35 s |
| Démarrage à froid (pas de pool préchauffé) | 5-7 min |
Remarque : Ces chiffres concernent uniquement le CPU. Les GPU Spaces ont besoin de leur propre Deployment de placeholder demandant nvidia.com/gpu avec l'image GPU pré-téléchargée. Sinon, les nœuds GPU restent froids, et à environ 10 Go, l'image GPU coûte bien plus cher à télécharger que l'image CPU de 3.5 Go.
Remarque : Chaque nœud préchauffé conserve une instance EC2 à l'état Running. Pour les nœuds à la demande, cela représente un coût supplémentaire pour maintenir les nœuds préchauffés actifs et opérationnels.
Pour plus d'informations sur l'installation du module complémentaire HyperPod Spaces et la prise en main, consultez la documentation AWS.
Tarification
La configuration du module complémentaire SageMaker Spaces n'entraîne pas de frais supplémentaires. Vous payez pour le calcul du cluster HyperPod sous-jacent consommé par vos Spaces, ainsi qu'une facturation horaire pour l'AWS Systems Manager Advanced On-Premises Instance utilisé pour la connectivité distante SSH-over-SSM. Consultez la tarification AWS Systems Manager pour plus de détails.
Si vous utilisez le sur-provisionnement décrit précédemment, notez qu'il y a un coût supplémentaire pour les nœuds préchauffés. Selon le type et la taille d'instance, ces nœuds restent à l'état d'exécution en attendant de provisionner des Spaces.
Conclusion
La gestion des HyperPod Spaces avec SageMaker Studio comble le fossé entre les data scientists et l'infrastructure de calcul haute performance. Les équipes peuvent désormais passer de l'accès au cluster à un environnement JupyterLab ou Code Editor en cours d'exécution en quelques minutes, sans avoir à apprendre les outils en ligne de commande ou les concepts Kubernetes. Combiné à des fonctionnalités comme HyperPod Task Governance, la prise en charge des GPU fractionnés et l'arrêt en cas d'inactivité, les organisations peuvent offrir un accès en libre-service à des clusters partagés tout en maîtrisant les coûts et l'équité d'utilisation des ressources.
Pour commencer, accédez à votre cluster HyperPod EKS dans la console SageMaker AI et sélectionnez l'onglet IDE and Notebooks. Pour plus d'informations, consultez la documentation SageMaker HyperPod Spaces.