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

La pianificazione basata sulla topologia in SageMaker HyperPod Amazon 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'AWSinfrastruttura, tra cui zone di disponibilità, blocchi di rete e rack fisici, la pianificazione basata sulla topologia garantisce che i pod che richiedono comunicazioni frequenti siano pianificati in prossimità per ridurre al minimo la latenza di rete. Questo posizionamento intelligente è particolarmente utile per i lavori di formazione sull'apprendimento automatico su larga scala che implicano una pod-to-pod comunicazione intensiva, con conseguente riduzione dei tempi di formazione e un utilizzo più efficiente delle risorse in tutto il cluster.

La pianificazione basata sulla topologia supporta i tipi di istanze seguenti:

La pianificazione basata sulla topologia si integra con i HyperPod flussi di lavoro esistenti fornendo al contempo preferenze di topologia flessibili tramite i file Kubectl YAML e la CLI. HyperPod HyperPod la governance delle attività configura automaticamente i nodi del cluster con etichette di topologia e funziona con le politiche di governance delle HyperPod attività e i meccanismi di prestito delle risorse, garantendo 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 con riconoscimento della topologia HyperPod, è possibile potenziare i carichi di lavoro di machine learning di tali dispositivi mediante 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 migliori 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 della rete di comunicazione ottimizzata tra i pod, un utilizzo più efficiente delle risorse e migliori prestazioni complessive per le AI/ML applicazioni a elaborazione intensiva, il tutto senza la necessità di gestire manualmente configurazioni di topologia di rete complesse.

Di seguito sono riportate le etichette per i livelli di rete topologici disponibili in cui Task Governance 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 desiderate eseguire questi lavori, ricordatevi 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 invece la topologia per supportare 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 Console di gestione AWS e Amazon SageMaker Studio. Segui questa procedura per visualizzarle nell’interfaccia che stai utilizzando.

SageMaker Studio

Console di gestione AWS