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.

Personnaliser le module complémentaire

Modèle

Les modèles sont des configurations d'espace de travail réutilisables qui servent de modèles contrôlés par l'administrateur pour la création d'espaces de travail. Ils fournissent des valeurs par défaut pour les valeurs de configuration de l'espace de travail et des garde-fous pour contrôler ce que les data scientists peuvent faire. Les modèles existent au niveau du cluster et peuvent être réutilisés dans tous les espaces de noms.

SageMaker Spaces crée deux modèles de système comme point de départ pour les data scientists, l'un pour l'éditeur de code et l'autre pour JupyterLab. Ces modèles de système sont gérés par l'addon et ne peuvent pas être modifiés directement. Au lieu de cela, les administrateurs peuvent créer de nouveaux modèles et les définir par défaut.

Gouvernance des tâches

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-jupyter-template
  namespace: my-namespace
  labels:
    kueue.x-k8s.io/priority-class: <user-input>-priority
spec:
  displayName: "My Custom Jupyter Lab"
  description: "Custom Jupyter Lab with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "jupyterlab"

SMD/Images personnalisées

Les clients peuvent configurer des politiques relatives aux images via des modèles en fournissant une image par défaut et une liste d'images autorisées. En outre, les administrateurs peuvent choisir d'autoriser ou non les data scientists à apporter leurs propres images personnalisées. Le système utilise par défaut la dernière SageMaker distribution, mais si vous souhaitez épingler une version particulière, vous pouvez spécifier la version SMD exacte à utiliser dans un modèle.

Exigences relatives aux images personnalisées :

Exigences relatives à l'IDE distant

Version de VS Code exigée

La version v1.90 ou supérieure de VS Code est requise. Nous vous recommandons d’utiliser la dernière version stable de VS Code.

Système d’exploitation exigé

Vous avez besoin de l’un des systèmes d’exploitation suivants pour vous connecter à distance aux espaces Studio :

Prérequis pour les machines locales

Avant de connecter votre Visual Studio Code local aux espaces Studio, assurez-vous que votre machine locale dispose des dépendances et de l'accès réseau requis.

Dépendances locales requises

Les composants suivants doivent être installés sur votre machine locale :

Platform-specific exigences

Exigences en matière de connectivité réseau

Votre machine locale doit disposer d'un accès réseau aux points de terminaison de Session Manager. Par exemple, dans l'est des États-Unis (Virginie du Nord) (us-east-1), il peut s'agir de :

Exigences relatives aux images

SageMaker Images de distribution

Lorsque vous utilisez SageMaker Distribution avec accès à distance, utilisez SageMaker Distribution version 2.7 ou ultérieure.

Images personnalisées

Lorsque vous utilisez Bring your own image (BYOI) avec accès à distance, assurez-vous de respecter les spécifications d'image personnalisées et assurez-vous que les dépendances suivantes sont installées :

Exigences relatives aux instances

Optimisation du temps de démarrage de Kubernetes à l'aide d'images de conteneurs Pre-Warming

Les performances d'extraction d'images de conteneurs constituent désormais un obstacle majeur pour de nombreux clients d'EKS, d'autant plus que les AI/ML charges de travail reposent sur des images de conteneurs de plus en plus grandes. L'extraction et le déballage de ces grandes images prennent généralement plusieurs minutes lors de leur première utilisation sur chaque nœud EKS. Ce délai ajoute une latence importante lors du lancement de SageMaker Spaces et a un impact direct sur l'expérience utilisateur, en particulier dans les environnements où un démarrage rapide est essentiel, tels que les ordinateurs portables et les tâches de développement interactives.

Le préchauffage des images est une technique utilisée pour précharger des images de conteneurs spécifiques sur chaque nœud du EKS/HyperPod cluster avant qu'elles ne soient nécessaires. Au lieu d'attendre qu'un pod déclenche la première extraction d'une grande image, le cluster télécharge et met en cache les images de manière proactive sur tous les nœuds. Cela garantit que lorsque les charges de travail sont lancées, les images requises sont déjà disponibles localement, éliminant ainsi les longs délais de démarrage à froid. Le préchauffage de l'image améliore la vitesse de démarrage de SageMaker Spaces et fournit une expérience plus prévisible et réactive aux utilisateurs finaux.

Pre-Warming via DaemonSet

Nous vous recommandons d'utiliser un DaemonSet pour précharger les images. A DaemonSet garantit qu'un pod s'exécute sur chaque nœud du cluster. Chaque conteneur à l'intérieur du DaemonSet module fait référence à une image que vous souhaitez mettre en cache. Lorsque Kubernetes démarre le pod, il extrait automatiquement les images, réchauffant ainsi le cache de chaque nœud.

L'exemple suivant montre comment créer une image DaemonSet qui précharge deux images GPU. Chaque conteneur exécute une sleep infinity commande légère pour maintenir le pod actif avec un minimum de frais.

cat <<EOF | kubectl apply -n "namespace_1" -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-preload-ds
spec:
  selector:
    matchLabels:
      app: image-preloader
  template:
    metadata:
      labels:
        app: image-preloader
    spec:
      containers:
      - name: preloader-3-4-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
      - name: preloader-3-3-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.3.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
EOF

Comment ça marche

Stockage par défaut de l'espace (EBS)

Le système utilise le pilote EBS CSI par défaut pour provisionner les volumes de stockage EBS pour chaque espace de travail. SageMaker crée une classe de stockage EBS à utiliser avec les espaces de travail, et les administrateurs peuvent personnaliser la taille par défaut et la taille maximale de ces volumes à l'aide des paramètres du modèle. Pour les utilisateurs avancés utilisant les outils de la CLI, vous pouvez également personnaliser la classe de stockage de l'espace de travail, ce qui permet aux utilisateurs de tirer parti d'autres classes de stockage, notamment en configurant des clés KMS gérées par le client pour leurs volumes EBS.

Notez que les volumes EBS sont liés à une zone de disponibilité particulière, ce qui signifie que les espaces de travail ne peuvent être planifiés que sur des nœuds situés dans la même zone de disponibilité que leur volume de stockage. Cela peut entraîner des échecs de planification si la capacité du cluster existe mais pas dans la zone de disponibilité appropriée.

Rangement supplémentaire

SageMaker Spaces permet d'associer des volumes de stockage supplémentaires tels qu'Amazon EFS, FSx for Lustre ou S3 Mountpoint à vos espaces de développement. Cela vous permet d'accéder à des ensembles de données partagés, de collaborer sur des projets ou d'utiliser un stockage haute performance pour vos charges de travail.

Conditions préalables

Avant d'associer des espaces de stockage supplémentaires à des espaces, vous devez :

Fixation de rangements à des espaces

Une fois PersistentVolumeClaim configuré, vous pouvez le joindre à un espace à l'aide de la HyperPod CLI ou de kubectl.

HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)

hyp create hyp-space \
    --name my-space \
    --display-name "My Space with FSx" \
    --memory 8Gi \
    --volume name=shared-fsx,mountPath=/shared,persistentVolumeClaimName=my-fsx-pvc

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-space
spec:
  displayName: "My Space with FSx"
  desiredStatus: Running
  volumes:
  - name: shared-fsx
    mountPath: /shared
    persistentVolumeClaimName: my-fsx-pvc

Volumes multiples

Vous pouvez associer plusieurs volumes de stockage supplémentaires à un seul espace en spécifiant plusieurs --volume indicateurs avec la CLI ou plusieurs entrées dans le volumes tableau avec kubectl.

HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)

hyp create hyp-space \
    --name my-space \
    --display-name "My Space with Multiple Storage" \
    --memory 8Gi \
    --volume name=shared-efs,mountPath=/shared,persistentVolumeClaimName=my-efs-pvc \
    --volume name=datasets,mountPath=/datasets,persistentVolumeClaimName=my-s3-pvc

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-space
spec:
  displayName: "My Space with Multiple Storage"
  desiredStatus: Running
  volumes:
  - name: shared-efs
    mountPath: /shared
    persistentVolumeClaimName: my-efs-pvc
  - name: datasets
    mountPath: /datasets
    persistentVolumeClaimName: my-s3-pvc

Configuration des ressources

SageMaker Spaces vous permet de configurer les ressources de calcul pour vos environnements de développement, notamment les ressources du processeur, de la mémoire et du GPU afin de répondre aux exigences de votre charge de travail.

Configuration du processeur graphique

SageMaker Spaces prend en charge à la fois l'allocation complète du GPU et le partitionnement du GPU à l'aide de la technologie NVIDIA Multi-Instance GPU (MIG). Cela vous permet d'optimiser l'utilisation du GPU pour différents types de charges de travail d'apprentissage automatique.

Allocation complète du GPU

HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)

hyp create hyp-space \
    --name gpu-space \
    --display-name "GPU Development Space" \
    --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
    --memory 16Gi \
    --gpu 1 \
    --gpu-limit 1

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: gpu-space
spec:
  displayName: "GPU Development Space"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  desiredStatus: Running
  resources:
    requests:
      memory: "16Gi"
      nvidia.com/gpu: "1"
    limits:
      memory: "16Gi"
      nvidia.com/gpu: "1"

Partitionnement GPU (MIG)

Le partitionnement des Multi-Instance GPU à l'aide de la technologie NVIDIA GPU (MIG) vous permet de partitionner un seul GPU en instances isolées plus petites. Votre HyperPod cluster doit disposer de nœuds GPU prenant en charge le protocole MIG et dont les profils MIG doivent être configurés. Pour plus d'informations sur la configuration de MIG sur votre HyperPod cluster, consultez la section Partitionnement du GPU à l'aide de NVIDIA MIG.

HyperPod INTERFACE DE LIGNE DE COMMANDE (CLI)

hyp create hyp-space \
    --name mig-space \
    --display-name "MIG GPU Space" \
    --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
    --memory 8Gi \
    --accelerator-partition-type mig-3g.20gb \
    --accelerator-partition-count 1

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: mig-space
spec:
  displayName: "MIG GPU Space"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  desiredStatus: Running
  resources:
    requests:
      memory: "8Gi"
      nvidia.com/mig-3g.20gb: "1"
    limits:
      memory: "8Gi"
      nvidia.com/mig-3g.20gb: "1"

Cycle de vie

La configuration du cycle de vie fournit des scripts de démarrage qui s'exécutent lorsqu'un espace de travail est créé ou démarré. Ces scripts permettent aux administrateurs de personnaliser l'environnement de l'espace de travail au démarrage. Il s'agit de scripts bash d'une taille maximale de 1 Ko. Si vous avez besoin d'une configuration d'installation plus importante, nous vous recommandons d'ajouter un script à l'image du conteneur et de déclencher le script à partir de la configuration du cycle de vie.

Nous tirons parti des hooks du cycle de vie des conteneurs Kubernetes pour fournir cette fonctionnalité. https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ Notez que Kubernetes ne fournit aucune garantie quant à la date d'exécution du script de démarrage par rapport au point d'entrée du conteneur.

Arrêt d’inactivité

Configurez l'arrêt automatique des espaces de travail inactifs pour optimiser l'utilisation des ressources.

Arrêt d’inactivité

idleShutdown:
  enabled: true
  idleShutdownTimeoutMinutes: 30
  detection:
    httpGet:
      path: /api/idle
      port: 8888
      scheme: HTTP

Parameters

enabled (booléen, obligatoire) : active ou désactive l'arrêt inactif de l'espace de travail.

idle ShutdownTimeoutMinutes (entier, obligatoire) : nombre de minutes d'inactivité avant la fermeture de l'espace de travail. La valeur minimum est de 1.

détection (objet, obligatoire) - Définit comment détecter l'état d'inactivité de l'espace de travail.

Detection.HttpGet (object, facultatif) - Configuration du point de terminaison HTTP pour la détection des inactifs. Utilise la spécification Kubernetes HTTPGetAction.

Emplacements de configuration

Configuration des espaces de travail

Définissez l'arrêt inactif directement dans la spécification de l'espace de travail :

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:

      name: my-workspace
spec:
  displayName: "Development Workspace"
  image:
      jupyter/scipy-notebook:latest
  idleShutdown:
    enabled: true

      idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path:
      /api/idle
        port: 8888

Configuration du modèle

Définissez le comportement d'arrêt au ralenti par défaut dans un WorkspaceTemplate :

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jupyter-template
spec:
  displayName: "Jupyter Template"
  defaultImage: jupyter/scipy-notebook:latest
  defaultIdleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path: /api/idle
        port: 8888
  idleShutdownOverrides:
    allow: true
    minTimeoutMinutes: 60
    maxTimeoutMinutes: 240

Héritage et remplacements des modèles

Les espaces de travail utilisant un modèle héritent automatiquement de la configuration du defaultIdleShutdown modèle. Les espaces de travail peuvent remplacer cette configuration si le modèle le permet.

Ignorer la politique

Les modèles contrôlent le comportement de remplacement par idleShutdownOverrides les moyens suivants :

allow (boolean, default : true) - Indique si les espaces de travail peuvent remplacer la configuration d'arrêt inactif par défaut.

min TimeoutMinutes (entier, facultatif) - Valeur de délai minimale autorisée pour les remplacements dans l'espace de travail.

max TimeoutMinutes (entier, facultatif) - Valeur de délai d'expiration maximale autorisée pour les remplacements dans l'espace de travail.

Exemple d'héritage

Workspace hérite des valeurs par défaut du modèle :

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-workspace
spec:
  displayName: "My Workspace"
  templateRef:
    name: jupyter-template
  # Inherits defaultIdleShutdown from template

Exemple de remplacement

L'espace de travail remplace les valeurs par défaut du modèle :

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-workspace
spec:
  displayName: "My Workspace"
  templateRef:
    name: jupyter-template
  idleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 60  # Must be within template bounds
    detection:
      httpGet:
        path: /api/idle
        port: 8888

Configuration verrouillée

Empêchez les remplacements d'espace de travail :

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: locked-template
spec:
  displayName: "Locked Template"
  defaultImage: jupyter/scipy-notebook:latest
  defaultIdleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path: /api/idle
        port: 8888
  idleShutdownOverrides:
    allow: false  # Workspaces cannot override

Comportement

Lorsque l'arrêt inactif est activé, le système vérifie périodiquement l'activité de l'espace de travail à l'aide du point de terminaison HTTP configuré. Si le point de terminaison indique que l'espace de travail est inactif pendant la durée de temporisation spécifiée, l'espace de travail s'arrête automatiquement. Vous pouvez redémarrer manuellement l'espace de travail si nécessaire.

Mises à jour des modèles

Les outils clients tels que Kubectl ou Hyperpod CLI et SDK peuvent être utilisés pour gérer les espaces au sein du cluster EKS. Les administrateurs peuvent fournir des modèles d'espace pour les configurations d'espace par défaut, tandis que les scientifiques des données peuvent personnaliser leurs environnements de développement intégrés sans avoir à comprendre la complexité sous-jacente de Kubernetes. Pour des instructions d'utilisation détaillées, reportez-vous à la documentation de la CLI et du SDK à l'https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.htmladresse.

Les administrateurs peuvent effectuer des opérations CRUD sur des modèles d'espace, qui servent de configurations de base lors de la création d'un espace. Les data scientists peuvent effectuer des opérations CRUD sur Spaces et modifier divers paramètres, notamment les profils Multi-Instance GPU de nœuds de calcul spécifiques. Ils peuvent démarrer, arrêter et se connecter aux espaces via un accès VSCode à distance et l'interface utilisateur Web. Lorsqu'un modèle d'espace est mis à jour, tout espace créé ultérieurement est configuré avec les paramètres du modèle mis à jour. Des contrôles de conformité seront effectués lorsque les espaces existants seront mis à jour ou démarrés. Si certains paramètres sont hors limites ou ne correspondent pas, les espaces ne pourront pas être mis à jour ou ne démarreront pas.

Utilisation de hyp cli et kubectl

L'utilisateur peut exécuter CRUD sur les modèles à l'aide de la CLI Hyperpod

### 1. Create a Space Template
hyp create hyp-space-template --file template.yaml

### 2. List Space Templates
hyp list hyp-space-template
hyp list hyp-space-template --output json

### 3. Describe a Space Template
hyp describe hyp-space-template --name my-template
hyp describe hyp-space-template --name my-template --output json

### 4. Update a Space Template
hyp update hyp-space-template --name my-template --file updated-template.yaml

### 5. Delete a Space Template
hyp delete hyp-space-template --name my-template

Pour créer des modèles personnalisés, vous pouvez utiliser les modèles de notre système comme point de départ. Ce modèle fonctionnera pour les SMD-like images, mais il peut être personnalisé en fonction des images utilisées par les administrateurs.

Exemple de JupyterLab modèle personnalisé :

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-jupyter-template
  namespace: my-namespace
spec:
  displayName: "My Custom Jupyter Lab"
  description: "Custom Jupyter Lab with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "jupyterlab"

Exemple de modèle d'éditeur de code personnalisé :

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-code-editor-template
  namespace: my-namespace
spec:
  displayName: "My Custom Code Editor"
  description: "Custom Code Editor with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-code-editor"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "code-editor"