Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo della pianificazione basata sulla topologia nella governance delle attività di Amazon SageMaker HyperPod

Panoramica di

Topology-aware la pianificazione in Amazon SageMaker HyperPod Task Governance ottimizza l'efficienza di formazione dei carichi di lavoro di machine learning distribuiti posizionando i pod in base alla topologia di rete fisica delle tue istanze Amazon EC2. Considerando la struttura gerarchica dell' AWS infrastruttura, comprese le zone di disponibilità, i blocchi di rete e i rack fisici, la pianificazione basata sulla topologia garantisce che i pod che richiedono comunicazioni frequenti siano programmati nelle immediate vicinanze per ridurre al minimo la latenza di rete. Questo posizionamento intelligente è particolarmente utile per i job di addestramento di machine learning su larga scala che implicano un’intensa comunicazione da pod a pod e si traduce in una conseguente riduzione dei tempi di addestramento e in un utilizzo più efficiente delle risorse in tutto il cluster.

Topology-aware la pianificazione supporta i seguenti tipi di istanza:

Topology-aware la pianificazione si integra con i HyperPod flussi di lavoro esistenti fornendo al contempo preferenze topologiche flessibili tramite i file YAML di kubectl e la CLI. HyperPod HyperPod la governance delle attività configura automaticamente i nodi del cluster con etichette topologiche e funziona con le politiche di governance delle HyperPod attività e i meccanismi di prestito delle risorse, assicurando che la pianificazione basata sulla topologia non interrompa i processi operativi correnti. Grazie al supporto integrato per le specifiche di topologia preferite e richieste, puoi eseguire il fine-tuning del posizionamento dei carichi di lavoro in base a specifici requisiti delle prestazioni, mantenendo al contempo la flessibilità necessaria per tornare alla pianificazione standard se i vincoli della topologia non possono essere soddisfatti.

Sfruttando le etichette compatibili con la topologia HyperPod, puoi potenziarne i carichi di lavoro di machine learning attraverso un posizionamento intelligente dei pod che tiene conto dell'infrastruttura fisica di rete. HyperPod la governance delle attività ottimizza automaticamente la pianificazione dei pod in base alla topologia gerarchica del data center, il che si traduce direttamente in una riduzione della latenza di rete e in un miglioramento delle prestazioni di formazione per le attività di machine learning distribuite. La consapevolezza della topologia è particolarmente utile per carichi di lavoro di machine learning su larga scala, perché riduce al minimo il sovraccarico di comunicazione avvicinando strategicamente i pod correlati all’interno della gerarchia di rete. Il risultato è una latenza di rete di comunicazione ottimizzata tra i pod, un utilizzo più efficiente delle risorse e migliori prestazioni complessive per le AI/ML applicazioni ad alta intensità di calcolo, il tutto ottenuto senza la necessità di gestire manualmente configurazioni complesse di topologia di rete.

Di seguito sono riportate le etichette per i livelli di rete topologici disponibili in cui la governance delle attività può pianificare i pod: HyperPod

Per utilizzare la pianificazione basata sulla topologia, includi le etichette seguenti nel tuo file YAML:

Se le risorse non condividono la stessa etichetta di topologia, il processo viene sospeso. Il processo viene inserito in lista d’attesa. Quando Kueue rileva una quantità di risorse sufficiente, accetta ed esegue processo.

L’esempio seguente illustra come utilizzare le etichette nei file 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

La tabella seguente spiega i nuovi parametri che puoi utilizzare nel file YAML kubectl.

Puoi anche utilizzare la HyperPod CLI per eseguire il tuo lavoro e utilizzare la pianificazione basata sulla topologia. Per ulteriori informazioni sulla HyperPod CLI, vedere. SageMaker HyperPod Comandi 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

Di seguito è riportato un esempio di file di configurazione che è possibile utilizzare per eseguire un file PytorchJob con etichette di topologia. Se desideri eseguire processi MPI e TensorFlow, il file è sostanzialmente uguale. Se invece desideri eseguire questi processi, ricordati di modificare il file di configurazione di conseguenza, ad esempio utilizzando l'immagine corretta anziché PyTorchJob. Se stai eseguendo un PyTorchJob, puoi assegnare topologie diverse ai nodi master e worker. PyTorchJob ha sempre un nodo master, quindi ti consigliamo di utilizzare la topologia per supportare invece i worker pod.

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

Per visualizzare le topologie per il tuo cluster, utilizza l' DescribeInstanceTopologyoperazione API. Per impostazione predefinita, le topologie sono nascoste in Amazon Console di gestione AWS SageMaker Studio. Segui questa procedura per visualizzarle nell’interfaccia che stai utilizzando.

SageMaker Studio

Console di gestione AWS

Topology-aware pianificazione con Karpenter

Topology-aware la pianificazione (TAS) non è supportata con Karpenter autoscaling. Il TAS è abilitato per impostazione predefinita nella governance delle attività. HyperPod Se prevedi di utilizzare Karpenter per il provisioning dei nodi, disabilita TAS seguendo questi passaggi:

Per riattivare il TAS, inverti questi passaggi ripristinando true e TopologyAwareScheduling riavviando il controller.