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 della Multi-Instance GPU (MIG) in AWS 2 PEZZI La Multi-Instance GPU NVIDIA (MIG) partiziona una GPU supportata in istanze GPU isolate, ognuna con la propria memoria e risorse di calcolo. Slurm pianifica ogni profilo MIG come tipo di risorsa generica (GRES), in modo che più lavori possano condividere una GPU fisica con isolamento hardware. I dispositivi MIG non possono essere descritti staticamente in`gres.conf`: i file di dispositivo e gli UUID esistono solo dopo la creazione delle istanze MIG sul nodo avviato, quindi non esiste alcun valore o valore da configurare in anticipo. `File` `Type` Su AWS PCS si configura MIG con un `gres.conf` record che si limita ad abilitare`AutoDetect`, insieme a un'impostazione che dichiara i profili. `Gres` `slurmd`quindi rileva i dispositivi MIG all'avvio del nodo. AWS PCS supporta`AutoDetect`, e quindi MIG, su Slurm versione 25.11 e successive. Configurare MIG significa partizionare le GPU su ciascun nodo e dichiarare i profili risultanti a Slurm sul gruppo di nodi di calcolo. Nessuno dei due funziona da solo, quindi applicali entrambi in un'unica modifica. Se Slurm non conosce le partizioni di un nodo, il nodo non ha un GRES programmabile. Se nessun nodo crea i profili dichiarati, i nodi vengono svuotati al momento della registrazione. Con l'azione consigliata sul ciclo di vita dei nodi, un aggiornamento del gruppo di nodi di calcolo include sia lo script di partizionamento che le impostazioni GRES. ## Prerequisiti + Un gruppo di nodi di calcolo che utilizza un tipo di istanza. MIG-capable + Slurm versione 25.11 o successiva. + Topologia CPU configurata. Il rilevamento automatico della GPU richiede il layout del socket del nodo. Su Slurm 25.11, impostato `Sockets` per il gruppo di nodi di calcolo; su Slurm 26.05 e versioni successive, PCS lo configura automaticamente. AWS Per ulteriori informazioni, consulta [Configurazione della topologia hardware in AWS 2 PEZZI](hardware-topology.md). ## Cosa deve avere un nodo MIG ad ogni avvio La modalità MIG e le istanze MIG risiedono sulla GPU, non su disco, quindi un'AMI personalizzata non può portarle e vengono perse ogni volta che l'istanza viene interrotta, sospesa o terminata. Ad ogni avvio, tutte le seguenti condizioni devono essere vere prima dell'avvio: `slurmd` 1. **La modalità MIG è abilitata ** su tutte le GPU utilizzate per le istanze MIG. `nvidia-smi -q`riporta una `Pending` modalità `Current` e una e deve esserlo. `Current` `Enabled` 1. **Le istanze MIG esistono**, sia istanze GPU che istanze di calcolo, per ogni profilo nelle impostazioni del gruppo di nodi di calcolo. `Gres` 1. **I profili e i conteggi corrispondono all'impostazione. ** `Gres` Se la modalità MIG è abilitata ma non esistono istanze MIG, `slurmd` trova le GPU principali ma nessun dispositivo MIG. Registra, quindi `MIG mode is enabled, but no MIG devices were found``Discarding the following config-only GPU due to lack of File specification`, per ogni profilo dichiarato. Poiché il nodo riporta un numero di GPU inferiore a quello `Gres` dichiarato, il controller rifiuta la registrazione e svuota il nodo con la motivazione. `gres/gpu count reported lower than configured` I processi che richiedono una GPU sul nodo hanno esito negativo. `Required node not available` La successiva creazione delle istanze MIG non comporta l'esaurimento del nodo; è necessario riprenderlo o sostituirlo. L'azione relativa al ciclo di vita del nodo descritta in [Applica la configurazione con un'azione sul ciclo di vita del nodo](#mig-configuration-instances-nla) evita che il nodo venga interrotto prima della registrazione. ## Configura MIG sulle istanze La configurazione delle istanze richiede le due operazioni seguenti. Eseguile da un'azione del ciclo di vita del nodo, che mantiene la logica sul gruppo di nodi di calcolo anziché in un'AMI da ricostruire. Consulta [Applica la configurazione con un'azione sul ciclo di vita del nodo](#mig-configuration-instances-nla). Se un altro processo utilizza già le GPU a quel punto, eseguile prima da un `cloud-init` boothook o da un'unità in un'AMI personalizzata. `systemd` Consulta [Se la modalità MIG rimane in sospeso](#mig-configuration-instances-pending). Per ulteriori informazioni sui comandi, consulta la [ NVIDIA GPU Multi-Instance User Guide. ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) 1. Abilita la modalità MIG sulle GPU: ``` nvidia-smi -mig 1 ``` La modifica della modalità non può avere effetto mentre un processo utilizza le GPU. La `nodeBootstrapped` fase non `slurmd` è ancora iniziata, quindi su un nodo che non esegue nessun altro servizio GPU la modifica ha effetto senza un riavvio. Verifica che la modalità applicata sia presente `Enabled` su tutte le GPU con. `nvidia-smi --query-gpu=mig.mode.current --format=csv` **Importante** Se la modalità MIG rimane attiva`Pending`, le GPU sono aperte in un altro processo. Consulta [Se la modalità MIG rimane in sospeso](#mig-configuration-instances-pending). 1. Crea le istanze GPU e le istanze di calcolo per i profili che desideri. Ad esempio, per partizionare ciascuna delle 8 GPU in una`3g.20gb`, una e due istanze: `2g.10gb` `1g.5gb` ``` for i in 0 1 2 3 4 5 6 7; do nvidia-smi mig -i $i -cgi 3g.20gb,2g.10gb,1g.5gb,1g.5gb -C done ``` `-cgi`accetta anche ID di profilo numerici, ma lo stesso ID indica un profilo diverso su un modello di GPU diverso: questo layout `9,14,19,19` è sull'A100 da 40 GB in una `p4d` istanza e `3g.40gb``2g.20gb`, e due `1g.10gb` su una parte da 80 GB. Usa i nomi dei profili, in modo che corrispondano alle `Gres` impostazioni e la creazione non riesce su una GPU che non dispone di tale profilo. Crea prima i profili più grandi, come nell'esempio. I posizionamenti MIG sono fissi, quindi un layout adatto può comunque non riuscire a creare se i profili piccoli occupano le sezioni necessarie a quelli grandi. ### Applica la configurazione con un'azione sul ciclo di vita del nodo Configurare l'azione del ciclo di vita del nodo come segue. Per informazioni su come aggiungerne uno a un gruppo di nodi di calcolo, consulta. [Configura le azioni del ciclo di vita dei nodi in AWS PEZZI](cng-node-lifecycle-actions-configure.md) | **Campo** | **Valore** | **Perché ** | | --- | --- | --- | | Fase del ciclo di vita | `nodeBootstrapped` | Viene eseguito prima dell'`slurmd`apertura delle GPU e della registrazione del nodo. | | `executionPolicy` | `EVERY_BOOT` | Lo stato MIG non sopravvive a un arresto, una sospensione o una terminazione. | | `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | I profili MIG da creare su ciascuna GPU, per nome. Uno script serve quindi gruppi di nodi di calcolo con layout diversi. | | `onError` | `TERMINATE` | Sostituisce un nodo che non può essere partizionato invece di lasciarlo registrare senza i suoi dispositivi MIG. Durante il debug, `STOP_SEQUENCE` utilizzalo per conservare l'istanza per l'ispezione. | Uno script che viene eseguito a ogni avvio deve essere idempotente. Lo schema seguente utilizza il layout per GPU come primo argomento e gestisce una GPU alla volta. Salta una GPU che ha già quel layout, ne ripartiziona un altro ed esce con un valore diverso da zero se non riesce a terminare, con conseguente fallimento del nodo. Non riavvia mai il nodo. Per sapere come gli argomenti raggiungono uno script, consulta[Passaggio di argomenti agli script](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-arguments). ``` #!/usr/bin/env bash # Partition every GPU as $1 specifies, then verify the result. Expected # nvidia-smi failures are handled inline, so this doesn't use 'set -e'. set -uo pipefail # $1 - per-GPU MIG profile names, comma-separated, largest first, as in Gres. PROFILES="${1:-}" if ! echo "$PROFILES" | grep -Eq '^[0-9]+g\.[0-9]+gb(,[0-9]+g\.[0-9]+gb)*$'; then echo "ERROR: pass the per-GPU MIG profiles as the first argument," >&2 echo " for example 3g.20gb,2g.10gb,1g.5gb,1g.5gb" >&2 exit 1 fi EXPECTED=$(echo "$PROFILES" | tr ',' '\n' | sort) # Fail, rather than exit 0, when there is no GPU to configure. GPUS=$(nvidia-smi --query-gpu=index --format=csv,noheader) || { echo "ERROR: nvidia-smi failed. This node has no usable NVIDIA driver." >&2 exit 1 } if [ -z "$GPUS" ]; then echo "ERROR: no NVIDIA GPUs detected." >&2 exit 1 fi # The MIG profiles on GPU $1, in the same form as EXPECTED. nvidia-smi -L lists # what NVML reports, which is what slurmd autodetects. mig_devices() { nvidia-smi -L | awk -v gpu="$1" ' /^GPU [0-9]+:/ { current = ($2 + 0); next } $1 == "MIG" && current == gpu { print $2 } ' | sort } for i in $GPUS; do # 1. Skip a GPU that already has the requested layout. if [ "$(mig_devices "$i")" = "$EXPECTED" ]; then echo "GPU $i: already configured as $PROFILES" continue fi # 2. Enable MIG mode. Ignore the exit status; step 3 checks the result. enable_output=$(nvidia-smi -i "$i" -mig 1 2>&1) || true # 3. Fail if the mode isn't applied. Don't reboot: that would interrupt # the AWS PCS bootstrap. current=$(nvidia-smi -i "$i" --query-gpu=mig.mode.current --format=csv,noheader) pending=$(nvidia-smi -i "$i" --query-gpu=mig.mode.pending --format=csv,noheader) if [ "$current" != "Enabled" ]; then echo "ERROR: GPU $i MIG mode is '$current', pending '$pending'." >&2 echo "$enable_output" >&2 if [ "$pending" = "Enabled" ]; then echo "The enable is pending, so a process is holding the GPU. Stop it," >&2 echo "or configure MIG mode in a boothook instead." >&2 elif [ "$current" = "[N/A]" ] || [ "$current" = "N/A" ]; then echo "This GPU does not support MIG." >&2 fi exit 1 fi # 4. Recreate the layout from scratch, because instances can't be added to # a partial one. Nothing uses them yet, because slurmd hasn't started. nvidia-smi mig -i "$i" -dci >/dev/null 2>&1 || true nvidia-smi mig -i "$i" -dgi >/dev/null 2>&1 || true if ! nvidia-smi mig -i "$i" -cgi "$PROFILES" -C; then echo "ERROR: MIG instance creation failed on GPU $i" >&2 exit 1 fi # 5. Check which profiles exist, not only how many, so a layout that # doesn't match Gres fails here instead of at job time. actual=$(mig_devices "$i") if [ "$actual" != "$EXPECTED" ]; then echo "ERROR: GPU $i has the wrong MIG layout." >&2 echo " expected: $(echo "$EXPECTED" | tr '\n' ' ')" >&2 echo " found: $(echo "$actual" | tr '\n' ' ')" >&2 exit 1 fi echo "GPU $i: configured as $PROFILES" done ``` Per impostare lo script e le impostazioni GRES in una sola chiamata, vedere l'esempio in[Dichiara i profili MIG a Slurm](#mig-configuration-slurm). Se adattate lo script, mantenete entrambi i controlli. Senza il controllo della modalità, un nodo la cui modalità MIG non è mai stata attivata `Enabled` viene registrato senza i relativi dispositivi MIG e la causa viene visualizzata solo nel `slurmd` registro. Senza il controllo del layout, un nodo che crea i profili sbagliati si registra normalmente e fallisce solo i lavori che richiedono i profili dichiarati. Per sapere dove viene scritto l'output dello script, vedere[Registrazione e debug](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging). ### Se la modalità MIG rimane in sospeso L'attivazione della modalità MIG non riesce quando qualsiasi processo ha le GPU aperte. `nvidia-smi`riporta l'abilitazione come in sospeso, ad esempio con`In use by another client`, e ha effetto solo dopo la chiusura di tali processi o il riavvio del nodo. Su un nodo di calcolo AWS PCS, il processo è in genere un agente di monitoraggio della GPU, come NVIDIA DCGM o un agente incluso nell'AMI, o `slurmd` se stesso se il MIG è configurato dopo l'avvio. `slurmd` Non è possibile riavviare dall'azione del ciclo di vita, quindi utilizza una delle seguenti correzioni: + **Interrompi il processo che contiene le GPU. ** Nell'AMI personalizzata, disabilita o rimuovi qualsiasi demone che apre le GPU prima dell'esecuzione della configurazione MIG. Rimuovete anche qualsiasi demone che configura il MIG stesso. Due componenti che partizionano le stesse GPU producono un layout che non corrisponde all'impostazione. `Gres` + **Configura MIG in un boothook. ** Se non riesci a interrompere il processo, sposta la modifica della modalità MIG e la creazione del profilo in un `cloud-init` boothook nei dati utente del modello di avvio. Un boothook viene eseguito prima del bootstrap del AWS PCS e prima dell'avvio dei servizi dell'AMI, quindi la modifica della modalità ha effetto senza un riavvio. Per sapere come scriverne uno, vedi. [Esempio: eseguire operazioni di avvio anticipato con un boothook cloud-init](working-with_ec2-user-data_early-boot.md) Tieni sotto controllo l'azione del ciclo di vita: a ogni avvio conferma il layout e fallisce il nodo se il boothook non l'ha applicato. ## Dichiara i profili MIG a Slurm Dichiarate entrambe le impostazioni GRES sul gruppo di nodi di calcolo: + In`gresCustomSettings`, un record GPU che abilita solo. `AutoDetect` Non impostare `Name``Type`, o`File`. I dispositivi MIG vengono rilevati sul nodo. + In`slurmCustomSettings`, un'`Gres`impostazione che dichiara i profili MIG e i conteggi che i job possono richiedere. I nomi e i conteggi dei profili devono corrispondere alle istanze MIG create sul nodo. **Example — Applicazione di entrambe le parti in un unico aggiornamento (8 GPU, ciascuna partizionata in una `3g.20gb, una 2g.10gb e due 1g.5gb`) `` ``** ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng-1}} \ --slurm-configuration '{ "gresCustomSettings": [ { "AutoDetect": "nvml" } ], "slurmCustomSettings": [ { "parameterName": "Gres", "parameterValue": "gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16" } ] }' \ --node-lifecycle-actions '{ "stages": { "nodeBootstrapped": [ { "name": "configure-mig", "scriptSource": { "scriptLocation": "s3://{{my-bucket}}/configure-mig.sh" }, "arguments": ["3g.20gb,2g.10gb,1g.5gb,1g.5gb"], "executionPolicy": "EVERY_BOOT", "onError": "TERMINATE" } ] } }' ``` L'esempio passa entrambi i parametri come JSON perché il valore contiene virgole, la cui sintassi abbreviata CLI dovrebbe essere sfuggita. `Gres` Mantieni `arguments` la `Gres` coerenza: `3g.20gb,2g.10gb,1g.5gb,1g.5gb` su ciascuna delle 8 GPU vengono fornite le 8, 8 e 16 istanze che dichiarano. `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` Per i vincoli tra le due impostazioni, consulta. [Vincoli tra gres.conf e l'impostazione Gres](gres-custom-settings.md#gres-custom-settings-constraints) Poiché il AWS PCS non è in grado di contare i dispositivi rilevati all'avvio, accetta qualsiasi nome di profilo e conta nell'`Gres`impostazione solo un record `AutoDetect` abilitato. La coerenza con le istanze MIG effettive viene verificata solo durante la registrazione del nodo. Quando un nodo si avvia e si registra, ad esempio, pubblicizza i profili scoperti con la loro affinità di socket. `Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1)` Un job che richiede un profilo, ad esempio`--gres=gpu:3g.20gb:1`, viene inserito in una singola istanza MIG e ne ottiene l'UUID `CUDA_VISIBLE_DEVICES` (ad esempio`MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e`), quindi CUDA limita il lavoro a quell'istanza MIG. **Nota** Il controller registra gli avvisi, ad esempio per i record MIG. `Ignoring file-less GPU gpu:3g.20gb from final GRES list` Questo è previsto: il GRES autorevole proviene dalla registrazione del nodo. ## Limitazioni Poiché una configurazione MIG non nomina alcun dispositivo, il controller conosce il GRES reale di un nodo solo dopo l'avvio e la registrazione del nodo. Finché un nodo non viene registrato una volta, il controller conserva solo i conteggi dei profili indicati nell'impostazione. `Gres` Ciò causa la seguente limitazione. Si applica a qualsiasi record GPU che abilita `AutoDetect` e quindi a tutti i gruppi di nodi di calcolo MIG. **Nota** Come best practice, utilizzate un gruppo di nodi di calcolo statici per MIG: impostato come `minInstanceCount` uguale nella configurazione di `maxInstanceCount` scalabilità. I nodi si registrano quindi all'avvio, prima che venga loro assegnato qualsiasi lavoro, il che evita la limitazione. ### I job allocati prima della prima registrazione di un nodo possono iniziare senza una GPU A un job assegnato a un nodo che è spento e non è mai stato registrato, ad esempio al primo avvio di un gruppo di nodi di calcolo appena creato, viene assegnato un numero di profili ma nessun dispositivo specifico, poiché i dispositivi non sono ancora noti. Quando il nodo si avvia e il processo inizia, al lavoro non è assegnato alcun dispositivo MIG: non `CUDA_VISIBLE_DEVICES` è impostato e poiché AWS PCS non limita l'accesso al dispositivo tramite cgroups, il lavoro può utilizzare tutti i dispositivi MIG sul nodo. Slurm riporta il job come `RUNNING` tale e l'istanza MIG su cui è stato conteggiato il job viene assegnata al job successivo che richiede quel profilo, in modo che entrambi i job possano finire sulla stessa istanza MIG. I job assegnati al nodo dopo la registrazione, anche dopo successivi cicli di spegnimento e accensione, vengono consegnati al dispositivo come previsto. Per rilevare questa condizione, verificate all'inizio del job impostato e uscite dal job o mettetelo in coda quando non lo `CUDA_VISIBLE_DEVICES` è: ``` if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then scontrol requeue "$SLURM_JOB_ID" exit 1 fi ``` Un processo in coda diventa idoneo per essere eseguito nuovamente dopo il parametro `requeue_delay` scheduler, 5 secondi per impostazione predefinita. A quel punto il nodo è registrato, quindi il processo avvia un dispositivo al successivo avvio.