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.

Utilisation de la planification tenant compte de la topologie dans Amazon Task Governance SageMaker HyperPod

Présentation de

Topology-aware la planification dans Amazon SageMaker HyperPod Task Governance optimise l'efficacité de la formation des charges de travail de machine learning distribuées en plaçant des modules en fonction de la topologie du réseau physique de vos instances Amazon EC2. En tenant compte de la structure hiérarchique de l' AWS infrastructure, y compris les zones de disponibilité, les blocs réseau et les baies physiques, la planification tenant compte de la topologie garantit que les pods nécessitant des communications fréquentes sont planifiés à proximité afin de minimiser la latence du réseau. Ce placement intelligent est particulièrement utile pour les tâches d’entraînement de machine learning à grande échelle qui impliquent une communication intensive entre pods, ce qui se traduit par une réduction des temps d’entraînement et une utilisation plus efficace des ressources au sein de votre cluster.

Topology-aware la planification prend en charge les types d'instances suivants :

Topology-aware la planification s'intègre à vos HyperPod flux de travail existants tout en fournissant des préférences de topologie flexibles via les fichiers YAML kubectl et la CLI. HyperPod HyperPod la gouvernance des tâches configure automatiquement les nœuds de cluster avec des étiquettes de topologie et fonctionne avec les politiques de gouvernance des HyperPod tâches et les mécanismes d'emprunt de ressources, garantissant ainsi que la planification tenant compte de la topologie ne perturbe pas vos processus opérationnels actuels. Grâce à la prise en charge intégrée des spécifications topologiques préférées et requises, vous pouvez optimiser le placement des charges de travail en fonction de vos exigences de performances spécifiques tout en conservant la flexibilité nécessaire pour revenir à une planification standard lorsque les contraintes topologiques ne peuvent pas être satisfaites.

En tirant parti des étiquettes tenant compte de la topologie HyperPod, vous pouvez améliorer leurs charges de travail d'apprentissage automatique grâce à un placement intelligent des modules qui tient compte de l'infrastructure réseau physique. HyperPod la gouvernance des tâches optimise automatiquement la planification des pods en fonction de la topologie hiérarchique du centre de données, ce qui se traduit directement par une réduction de la latence du réseau et une amélioration des performances d'entraînement pour les tâches de machine learning distribuées. Cette prise en compte de la topologie est particulièrement utile pour les charges de travail de machine learning à grande échelle, car elle minimise les frais de communication en rapprochant stratégiquement les pods associés dans la hiérarchie du réseau. Il en résulte une latence du réseau de communication optimisée entre les pods, une utilisation plus efficace des ressources et de meilleures performances globales pour les AI/ML applications gourmandes en calcul, le tout sans que vous ayez à gérer manuellement des configurations de topologie réseau complexes.

Les libellés suivants indiquent les couches de réseau topologiques disponibles dans lesquelles la gouvernance des HyperPod tâches peut planifier les modules :

Pour utiliser l’ordonnancement topologique, incluez les étiquettes suivantes dans votre fichier YAML :

Si les ressources ne partagent pas la même étiquette topologique, la tâche sera suspendue. La tâche figurera sur la liste d’attente. Une fois que Kueue aura constaté qu’il y a suffisamment de ressources, il admettra et exécutera la tâche.

L’exemple suivant montre comment utiliser les étiquettes dans vos fichiers YAML :

apiVersion: batch/v1
kind: Job
metadata:
  name: test-tas-job
  namespace: hyperpod-ns-team-name
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
    kueue.x-k8s.io/priority-class: PRIORITY_CLASS-priority
spec:
  parallelism: 10
  completions: 10
  suspend: true
  template:
    metadata:
      labels:
        kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
      annotations:
        kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
        or
        kueue.x-k8s.io/podset-preferred-topology: "topology.k8s.aws/network-node-layer-3"
    spec:
      nodeSelector:
        topology.k8s.aws/network-node-layer-3: TOPOLOGY_LABEL_VALUE
      containers:
        - name: dummy-job
          image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
          args: ["3600s"]
          resources:
            requests:
              cpu: "100"
      restartPolicy: Never

Le tableau suivant explique les nouveaux paramètres que vous pouvez utiliser dans le fichier YAML kubectl.

Vous pouvez également utiliser l' HyperPod interface de ligne de commande pour exécuter votre tâche et utiliser une planification tenant compte de la topologie. Pour plus d'informations sur l' HyperPod interface de ligne de commande, consultezSageMaker HyperPod Commandes CLI.

hyp create hyp-pytorch-job \                                            
  --version 1.1 \
  --job-name sample-pytorch-job \
  --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
  --pull-policy "Always" \
  --tasks-per-node 1 \
  --max-retry 1 \
  --priority high-priority \
  --namespace hyperpod-ns-team-name \
  --queue-name hyperpod-ns-team-name-localqueue \
  --preferred-topology-label topology.k8s.aws/network-node-layer-1

Voici un exemple de fichier de configuration que vous pouvez utiliser pour exécuter un PytorchJob avec des étiquettes de topologie. Le fichier est largement similaire si vous souhaitez exécuter des tâches MPI et Tensorflow. Si vous souhaitez exécuter ces tâches à la place, n'oubliez pas de modifier le fichier de configuration en conséquence, par exemple en utilisant la bonne image à la place de PyTorchJob. Si vous utilisez un PyTorchJob, vous pouvez attribuer différentes topologies aux nœuds master et worker. PyTorchJob possède toujours un nœud principal. Nous vous recommandons donc d'utiliser la topologie pour prendre en charge les pods de travail à la place.

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  annotations: {}
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
  name: tas-test-pytorch-job
  namespace: hyperpod-ns-team-name
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      restartPolicy: OnFailure
      template:
        metadata:
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
    Worker:
      replicas: 10
      restartPolicy: OnFailure
      template:
        metadata:
          # annotations:
            # kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: 1
              requests:
                memory: 200Mi
                cpu: 1
          #nodeSelector:
          #  topology.k8s.aws/network-node-layer-3: xxxxxxxxxxx

Pour voir les topologies de votre cluster, utilisez l'opération DescribeInstanceTopology API. Par défaut, les topologies sont masquées dans Console de gestion AWS Amazon SageMaker Studio. Suivez ces étapes pour les afficher dans l’interface que vous utilisez.

SageMaker Studio

Console de gestion AWS

Topology-aware planification avec Karpenter

Topology-aware la planification (TAS) n'est pas prise en charge avec la mise à l'échelle automatique de Karpenter. Le TAS est activé par défaut dans la gouvernance des HyperPod tâches. Si vous envisagez d'utiliser Karpenter pour le provisionnement des nœuds, désactivez TAS en suivant ces étapes :

Pour réactiver le TAS, inversez ces étapes en rétablissant TopologyAwareScheduling le contrôleur true et en le redémarrant.