Configurazione di partizioni GPU su 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à.

Configurazione di partizioni GPU su Amazon SageMaker HyperPod

Prerequisiti

  • HyperPod Cluster Amazon EKS con istanze GPU supportate

  • NVIDIA GPU Operator installato

  • Autorizzazioni IAM appropriate per la gestione dei cluster

Creazione di un cluster con configurazione MIG

Usando AWS CLI

aws sagemaker create-cluster \ --cluster-name my-mig-cluster \ --orchestrator 'Eks={ClusterArn=arn:aws:eks:region:account:cluster/cluster-name}' \ --instance-groups '{ "InstanceGroupName": "gpu-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 1, "LifeCycleConfig": { "SourceS3Uri": "s3://my-bucket", "OnCreate": "on_create_script.sh" }, "KubernetesConfig": { "Labels": { "nvidia.com/mig.config": "all-1g.5gb" } }, "ExecutionRole": "arn:aws:iam::account:role/execution-role", "ThreadsPerCore": 1 }' \ --vpc-config '{ "SecurityGroupIds": ["sg-12345"], "Subnets": ["subnet-12345"] }' \ --node-provisioning-mode Continuous

Usando CloudFormation

{ "ClusterName": "my-mig-cluster", "InstanceGroups": [ { "InstanceGroupName": "gpu-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 1, "KubernetesConfig": { "Labels": { "nvidia.com/mig.config": "all-2g.10gb" } }, "ExecutionRole": "arn:aws:iam::account:role/execution-role" } ], "Orchestrator": { "Eks": { "ClusterArn": "arn:aws:eks:region:account:cluster/cluster-name" } }, "NodeProvisioningMode": "Continuous" }

Aggiungere un operatore GPU a un cluster esistente

Installa GPU Operator

Sostituisci {$AWS_REGION} con la regione del tuo cluster (ad es. us-east-1, us-west-2).

helm install gpuo helm_chart/HyperPodHelmChart/charts/gpu-operator \ -f helm_chart/HyperPodHelmChart/charts/gpu-operator/regional-values/values-{$AWS_REGION}.yaml \ -n kube-system

Verifica l'installazione (attendi 2-3 minuti)

Verifica che tutti i pod dell'operatore della GPU siano in funzione:

kubectl get pods -n kube-system | grep -E "(gpu-operator|nvidia-)"

Pod previsti:

  • gpu-operator-* - 1 istanza (controller del cluster)

  • nvidia-device-plugin-daemonset-* - 1 per nodo GPU (tutte le istanze GPU)

  • nvidia-mig-manager-* - 1 per nodo compatibile con MiG (A100/H100)

Rimuovi il vecchio plug-in del dispositivo

Disabilita l'esistente nvidia-device-plugin:

helm upgrade dependencies helm_chart/HyperPodHelmChart \ --set nvidia-device-plugin.devicePlugin.enabled=false \ -n kube-system

Verifica le risorse della GPU

Conferma che i nodi mostrino la capacità della GPU. Dovrebbe mostrare: nvidia.com/gpu: 8 (o il numero effettivo di GPU).

kubectl describe nodes | grep "nvidia.com/gpu"

Aggiornamento della configurazione MIG

Preparazione dei nodi prima degli aggiornamenti MIG

Prima di aggiornare le configurazioni MIG sul gruppo di istanze, è necessario preparare i nodi per evitare interruzioni del carico di lavoro. Segui questi passaggi per drenare in sicurezza i carichi di lavoro dai nodi che verranno riconfigurati.

Fase 1: Identifica i nodi nel gruppo di istanze

Innanzitutto, identifica tutti i nodi che appartengono al gruppo di istanze che desideri aggiornare:

# List all nodes in the instance group kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME # Example: kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=p4d-group

Questo comando restituisce un elenco di tutti i nodi nel gruppo di istanze specificato. Prendi nota del nome di ogni nodo per i seguenti passaggi.

Fase 2: cordonare e drenare ogni nodo

Per ogni nodo identificato nel passaggio 1, esegui le seguenti azioni:

Cordone il nodo

Il cordonamento impedisce la pianificazione di nuovi pod sul nodo:

# Cordon a single node kubectl cordon NODE_NAME # Example: kubectl cordon hyperpod-i-014a41a7001adca60

Svuota i Workload Pods dal nodo

Svuota il nodo per eliminare tutti i pod del carico di lavoro preservando al contempo i pod di sistema:

# Drain the node (ignore DaemonSets and evict pods) kubectl drain NODE_NAME \ --ignore-daemonsets \ --delete-emptydir-data \ --force \ --grace-period=300 # Example: kubectl drain hyperpod-i-014a41a7001adca60 \ --ignore-daemonsets \ --delete-emptydir-data \ --force \ --grace-period=300

Spiegazione delle opzioni di comando:

  • --ignore-daemonsets- Consente di continuare l'operazione di scarico anche in presenza di DaemonSet cialde

  • --delete-emptydir-data- Elimina i pod utilizzando i volumi EmptyDir (necessario per il corretto drenaggio)

  • --force- Forza l'eliminazione dei pod non gestiti da un controller (usare con cautela)

  • --grace-period=300- Dà ai pod 5 minuti per terminare correttamente

Importante
  • L'operazione di scarico può richiedere diversi minuti a seconda del numero di pod e dei relativi periodi di tolleranza

  • I pod di sistema nei seguenti namespace rimarranno in esecuzione:kube-system,,,,cert-manager,kubeflow,hyperpod-inference-system,, kube-publicmpi-operator, e gpu-operator aws-hyperpod jupyter-k8s-system hyperpod-observability kueue-system keda

  • DaemonSet i pod rimarranno sul nodo (vengono ignorati in base alla progettazione)

Passaggio 3: verifica che i pod del carico di lavoro non siano in esecuzione

Dopo il drenaggio, verifica che nessun pod del carico di lavoro rimanga sui nodi (esclusi i namespace di sistema):

# Check for any remaining pods outside system namespaces kubectl get pods --all-namespaces --field-selector spec.nodeName=NODE_NAME \ | grep -v "kube-system" \ | grep -v "cert-manager" \ | grep -v "kubeflow" \ | grep -v "hyperpod-inference-system" \ | grep -v "kube-public" \ | grep -v "mpi-operator" \ | grep -v "gpu-operator" \ | grep -v "aws-hyperpod" \ | grep -v "jupyter-k8s-system" \ | grep -v "hyperpod-observability" \ | grep -v "kueue-system" \ | grep -v "keda" # Example: kubectl get pods --all-namespaces --field-selector spec.nodeName=hyperpod-i-014a41a7001adca60 \ | grep -v "kube-system" \ | grep -v "cert-manager" \ | grep -v "kubeflow" \ | grep -v "hyperpod-inference-system" \ | grep -v "kube-public" \ | grep -v "mpi-operator" \ | grep -v "gpu-operator" \ | grep -v "aws-hyperpod" \ | grep -v "jupyter-k8s-system" \ | grep -v "hyperpod-observability" \ | grep -v "kueue-system" \ | grep -v "keda"

Output previsto: se il nodo è drenato correttamente, questo comando non dovrebbe restituire alcun risultato (o mostrare solo la riga di intestazione). Se alcuni pod sono ancora in funzione, scoprite perché non sono stati rimossi ed eliminateli manualmente, se necessario.

Fase 4: Verifica dello stato di preparazione del nodo

Prima di procedere con l'aggiornamento MIG, verificate che tutti i nodi siano isolati:

# Check node status - should show "SchedulingDisabled" kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME

I nodi devono essere visualizzati SchedulingDisabled nella colonna STATUS, a indicare che sono isolati e pronti per l'aggiornamento MIG.

Aggiorna il profilo MIG sul cluster esistente

È possibile modificare i profili MIG sui cluster esistenti:

aws sagemaker update-cluster \ --cluster-name my-mig-cluster \ --instance-groups '{ "InstanceGroupName": "gpu-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 1, "KubernetesConfig": { "Labels": { "nvidia.com/mig.config": "all-3g.20gb" } }, "ExecutionRole": "arn:aws:iam::account:role/execution-role" }'
Nota

Se i lavori sono già in esecuzione su un nodo, il partizionamento MIG avrà esito negativo. L'utente riceverà un messaggio di errore per svuotare i nodi prima di tentare nuovamente il partizionamento MIG.

Verifica della configurazione MIG

Dopo la creazione o l'aggiornamento del cluster, verifica la configurazione MIG:

# Update kubeconfig aws eks update-kubeconfig --name your-eks-cluster --region us-east-2 # Check MIG labels kubectl get node NODE_NAME -o=jsonpath='{.metadata.labels}' | grep mig # Check available MIG resources kubectl describe node NODE_NAME | grep -A 10 "Allocatable:"

Comandi comuni per il debug della configurazione MIG

Utilizzate i seguenti comandi per risolvere i problemi e convalidare la configurazione MIG nel cluster:

# Check GPU Operator status kubectl get pods -n gpu-operator-resources # View MIG configuration kubectl exec -n gpu-operator-resources nvidia-driver-XXXXX -- nvidia-smi mig -lgi # Check device plugin configuration kubectl logs -n gpu-operator-resources nvidia-device-plugin-XXXXX # Monitor node events kubectl get events --field-selector involvedObject.name=NODE_NAME
Nota

Sostituisci nvidia-driver-XXXXX e nvidia-device-plugin-XXXXX con i nomi effettivi dei pod del cluster e NODE_NAME con il nome del nodo.

Utilizzo della console SageMaker AI

Creazione di un nuovo cluster con MIG

  1. Passa ad Amazon SageMaker AI > HyperPod Clusters > Gestione dei cluster > Crea HyperPod cluster

  2. Seleziona Orchestrated by EKS

  3. Scegli Configurazione personalizzata e verifica che GPU Operator sia abilitato per impostazione predefinita

  4. Nella sezione Gruppi di istanze, fai clic su Aggiungi gruppo

  5. Configura il gruppo di istanze e vai a Configurazione avanzata per attivare l'opzione Usa partizione GPU e scegli la configurazione MIG desiderata dal menu a discesa

  6. Fai clic su Aggiungi gruppo di istanze e completa la configurazione del cluster rimanente

  7. Fai clic su Invia per creare il cluster

Aggiornamento della configurazione MIG su un cluster esistente

  1. Passa ad Amazon SageMaker AI > HyperPod Clusters > Gestione dei cluster

  2. Seleziona il cluster esistente e fai clic su Modifica sul gruppo di istanze che desideri modificare

  3. In Configurazione avanzata, attiva Usa la partizione GPU se non è già abilitata e seleziona una configurazione MIG diversa dal menu a discesa

  4. Fai clic su Salva modifiche