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 ingres.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 abilitareAutoDetect, insieme a un'impostazione che dichiara i profili. Gres slurmdquindi rileva i dispositivi MIG all'avvio del nodo. AWS PCS supportaAutoDetect, 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

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

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 foundDiscarding 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 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. 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. Per ulteriori informazioni sui comandi, consulta la NVIDIA GPU Multi-Instance User Guide.

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

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, consultaPassaggio di argomenti agli script.

#!/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 inDichiara i profili MIG a 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, vedereRegistrazione e debug.

Se la modalità MIG rimane in sospeso

L'attivazione della modalità MIG non riesce quando qualsiasi processo ha le GPU aperte. nvidia-smiriporta l'abilitazione come in sospeso, ad esempio conIn 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:

Dichiara i profili MIG a Slurm

Dichiarate entrambe le impostazioni GRES sul gruppo di nodi di calcolo:

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"
          }
        ]
      }
    }'

Per i vincoli tra le due impostazioni, consulta. Vincoli tra gres.conf e l'impostazione Gres Poiché il AWS PCS non è in grado di contare i dispositivi rilevati all'avvio, accetta qualsiasi nome di profilo e conta nell'Gresimpostazione 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 esempioMIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e), quindi CUDA limita il lavoro a quell'istanza MIG.

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.

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.