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

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

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' AWS infrastruttura, 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.

Nota

Per utilizzare la pianificazione basata sulla topologia, assicurati che la tua versione di HyperPod task governance sia la v1.2.2-eksbuild.1 o successiva.

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

  • ml.p3dn.24xlarge

  • ml.p4d.24xlarge

  • ml.p4de.24xlarge

  • ml.p5.48xlarge

  • ml.p5e.48 xlarge

  • ml.p5en.48xlarge

  • ml.p6e-gb200,36 xlarge

  • ml.trn 1,2xlarge

  • ml.trn1,32xlarge

  • ml.trn1n.32xlarge

  • ml.trn 2,48 x large

  • ml.trn2u.48xlarge

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 topologiche preferite e richieste, è possibile ottimizzare il posizionamento dei carichi di lavoro in base ai requisiti prestazionali specifici, mantenendo al contempo la flessibilità necessaria per tornare alla pianificazione standard quando i vincoli della topologia non possono essere soddisfatti.

Sfruttando le etichette basate sulla topologia HyperPod, è possibile potenziare i carichi di lavoro di machine learning di tali etichette 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. Questa conoscenza della topologia è particolarmente utile per carichi di lavoro di machine learning su larga scala, in quanto riduce al minimo il sovraccarico di comunicazione posizionando strategicamente i pod correlati più vicini tra loro nella 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

  • topology.k8s.aws/ -1 network-node-layer

  • network-node-layertopologia.k8s.aws/ -2

  • network-node-layertopologia.k8s.aws/ -3

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

  • kueue.x-k8s.io/ podset-required-topology - indica che questo job deve avere i pod richiesti e che tutti i pod nei nodi devono essere programmati all'interno dello stesso livello di topologia.

  • kueue.x-k8s.io/ podset-preferred-topology - indica che questo job deve avere i pod, ma che la pianificazione dei pod all'interno dello stesso livello di topologia è preferibile ma non obbligatoria. HyperPod task governance proverà a pianificare i pod all'interno di un livello prima di provare il livello di topologia successivo.

Se le risorse non condividono la stessa etichetta di topologia, il lavoro verrà sospeso. Il lavoro sarà in lista d'attesa. Una volta che Kueue vedrà che ci sono risorse sufficienti, ammetterà e gestirà il lavoro.

L'esempio seguente mostra 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 usare nel file Kubectl YAML.

Parametro Descrizione
kueue.x-k8s.io/queue-name Il nome della coda da usare per eseguire il lavoro. Il formato di questo nome di coda deve essere. hyperpod-ns-team-name-localqueue
kueue.x-k8s.io/priority-class Consente di specificare una priorità per la pianificazione dei pod. Questa specifica è facoltativa.
annotations Contiene l'annotazione topologica allegata al lavoro. Le topologie disponibili sono kueue.x-k8s.io/ e podset-required-topologykueue.x-k8s.io/. podset-preferred-topology È possibile utilizzare un'annotazione o un NodeSelector, ma non entrambi contemporaneamente.
NodeSelector Speciifica il livello di rete che rappresenta il livello di posizionamento delle EC2 istanze Amazon. Utilizza questo campo o un'annotazione, ma non entrambi contemporaneamente. Nel tuo file YAML, puoi anche usare il parametro NodeSelector per scegliere il livello esatto per i tuoi pod. Per ottenere il valore della tua etichetta, utilizza l'operazione API. DescribeInstanceTopology

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. Il file è in gran parte simile se si desidera eseguire lavori MPI e Tensorflow. Se invece desideri eseguire questi lavori, 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 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 AWS Management Console e Amazon SageMaker Studio. Segui questi passaggi per visualizzarle nell'interfaccia che stai utilizzando.

SageMaker Studio

  1. In SageMaker Studio, accedi al tuo cluster.

  2. Nella vista Attività, scegli il menu delle opzioni nella colonna Nome, quindi scegli Gestisci colonne.

  3. Seleziona Topologia richiesta e Vincolo di topologia per aggiungere le colonne per visualizzare le informazioni sulla topologia nell'elenco dei pod Kubernetes.

AWS Management Console

  1. Apri la console Amazon SageMaker AI all'indirizzo https://console.aws.amazon.com/sagemaker/.

  2. In HyperPod Cluster, scegli Cluster management.

  3. Scegli la scheda Attività, quindi scegli l'icona a forma di ingranaggio.

  4. In Attributi dell'istanza, attiva Topologia richiesta e Vincolo di topologia.

  5. Scegli Conferma per visualizzare le informazioni sulla topologia nella tabella.