Configuration du Multi-Instance GPU (MIG) dans AWS PIÈCES

Multi-Instance Le GPU NVIDIA (MIG) partitionne un GPU pris en charge en instances GPU isolées, chacune dotée de sa propre mémoire et de ses propres ressources de calcul. Slurm planifie chaque profil MIG comme son propre type de ressource générique (GRES), afin que plusieurs tâches puissent partager un seul GPU physique avec isolation matérielle.

Les périphériques MIG ne peuvent pas être décrits de manière statique dans gres.conf : leurs fichiers de périphériques et leurs UUID n'existent qu'une fois les instances MIG créées sur le nœud démarré. Il n'y a donc aucune Type valeur à configurer à l'Fileavance. Sur AWS PCS, vous configurez MIG avec un gres.conf enregistrement qui active uniquementAutoDetect, ainsi qu'un Gres paramètre qui déclare les profils. slurmddécouvre ensuite les périphériques MIG au démarrage du nœud. AWS PCS prend en chargeAutoDetect, et donc MIG, les versions 25.11 et ultérieures de Slurm.

La configuration de MIG implique de partitionner les GPU de chaque nœud et de déclarer les profils résultants à Slurm sur le groupe de nœuds de calcul. Aucun des deux ne fonctionne seul, alors appliquez les deux en une seule modification. Si Slurm ne connaît pas les partitions d'un nœud, celui-ci ne possède aucun GRES planifiable. Si aucun nœud ne crée les profils déclarés, les nœuds sont vidés lors de leur enregistrement. Avec l'action recommandée sur le cycle de vie des nœuds, une mise à jour d'un groupe de nœuds de calcul contient à la fois le script de partitionnement et les paramètres GRES.

Conditions préalables

Ce qu'un nœud MIG doit avoir à chaque démarrage

Le mode MIG et les instances MIG résident sur le GPU, et non sur le disque. Une AMI personnalisée ne peut donc pas les transporter et elles sont perdues chaque fois que l'instance est arrêtée, suspendue ou résiliée. À chaque démarrage, toutes les conditions suivantes doivent être remplies avant le slurmd démarrage :

Si le mode MIG est activé mais qu'aucune instance MIG n'existe, slurmd recherche les GPU parents mais aucun périphérique MIG. Il enregistreMIG mode is enabled, but no MIG devices were found, puis Discarding the following config-only GPU due to lack of File specification pour chaque profil déclaré. Étant donné que le nœud rapporte moins de GPU que ce Gres qui est déclaré, le contrôleur rejette l'enregistrement et vide le nœud en indiquant la raison. gres/gpu count reported lower than configured Les tâches qui demandent un GPU sur le nœud échouent avecRequired node not available. La création des instances MIG par la suite ne vide pas le nœud ; vous devez le reprendre ou le remplacer. L'action sur le cycle de vie du nœud décrite dans la section permet d'Appliquer la configuration à l'aide d'une action sur le cycle de vie des nœudséviter cela en faisant échouer le nœud avant son enregistrement.

Configurer MIG sur les instances

La configuration des instances nécessite les deux opérations suivantes. Exécutez-les à partir d'une action du cycle de vie des nœuds, qui conserve la logique sur le groupe de nœuds de calcul plutôt que dans une AMI que vous devez reconstruire. Consultez Appliquer la configuration à l'aide d'une action sur le cycle de vie des nœuds. Si un autre processus contient déjà les GPU à ce stade, exécutez-les plus tôt à partir d'un cloud-init boothook ou d'une systemd unité dans une AMI personnalisée. Consultez Si le mode MIG reste en attente. Pour plus d'informations sur les commandes, consultez le Guide de l'utilisateur Multi-Instance du GPU NVIDIA.

Appliquer la configuration à l'aide d'une action sur le cycle de vie des nœuds

Configurez l'action du cycle de vie des nœuds comme suit. Pour savoir comment en ajouter un à un groupe de nœuds de calcul, consultezConfigurer les actions relatives au cycle de vie des nœuds dans AWS PIÈCES.

Un script qui s'exécute à chaque démarrage doit être idempotent. Le schéma suivant prend la disposition par GPU comme premier argument et gère un GPU à la fois. Il ignore un GPU qui possède déjà cette configuration, en répartit tous les autres et quitte une valeur non nulle s'il ne peut pas terminer, ce qui entraîne une défaillance du nœud. Il ne redémarre jamais le nœud. Pour savoir comment les arguments atteignent un script, consultezTransmettre des arguments à des scripts.

#!/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

Pour définir le script et les paramètres GRES en un seul appel, consultez l'exemple présenté dansDéclarer les profils MIG à Slurm.

Si vous adaptez le script, conservez les deux cases. Sans vérification de mode, un nœud dont le mode MIG n'est jamais Enabled devenu s'enregistre sans ses périphériques MIG, et la cause n'apparaît que dans le slurmd journal. Sans vérification de la mise en page, un nœud qui crée les mauvais profils s'enregistre normalement et n'échoue que pour les tâches qui demandent les profils déclarés. Pour savoir où la sortie du script est écrite, consultezJournalisation et débogage.

Si le mode MIG reste en attente

L'activation du mode MIG échoue lorsque les GPU d'un processus sont ouverts. nvidia-smisignale l'activation comme étant en attente, par exemple withIn use by another client, et elle ne prend effet qu'après la fin de ces processus ou le redémarrage du nœud. Sur un nœud de calcul AWS PCS, le processus est généralement un agent de surveillance du GPU, tel que NVIDIA DCGM ou un agent livré dans l'AMI, ou slurmd lui-même si MIG est configuré après slurmd le démarrage. Vous ne pouvez pas redémarrer à partir de l'action du cycle de vie, utilisez donc l'un des correctifs suivants :

Déclarer les profils MIG à Slurm

Déclarez les deux paramètres GRES sur le groupe de nœuds de calcul :

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

Pour connaître les contraintes entre les deux paramètres, consultezContraintes entre gres.conf et le paramètre Gres. Comme AWS PCS ne peut pas compter les périphériques découverts au démarrage, il accepte tous les noms de profil et les compte dans le Gres paramètre pour un enregistrement uniquement activéAutoDetect. La cohérence avec les instances MIG réelles n'est vérifiée que lorsque le nœud s'enregistre.

Lorsqu'un nœud démarre et s'enregistre, il annonce les profils découverts avec leur affinité de socket, par exempleGres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1). Une tâche qui demande un profil, tel que--gres=gpu:3g.20gb:1, est placée sur une seule instance MIG et obtient son UUID CUDA_VISIBLE_DEVICES (par exempleMIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e). CUDA limite donc la tâche à cette instance MIG.

Limitations

Comme une configuration MIG ne nomme aucun périphérique, le contrôleur ne connaît le véritable GRES d'un nœud qu'après le démarrage et l'enregistrement du nœud. Jusqu'à ce qu'un nœud soit enregistré une seule fois, le contrôleur ne conserve que le nombre de profils indiqué dans le Gres paramètre. Cela entraîne la limitation suivante. Elle s'applique à tout enregistrement GPU uniquement activéAutoDetect, et donc à chaque groupe de nœuds de calcul MIG.

Les tâches allouées avant qu'un nœud ne s'enregistre pour la première fois peuvent démarrer sans GPU

Une tâche attribuée à un nœud qui est hors tension et qui n'a jamais été enregistré, par exemple lors du premier démarrage d'un groupe de nœuds de calcul nouvellement créé, se voit attribuer un nombre de profils mais aucun périphérique spécifique, car les périphériques ne sont pas encore connus. Lorsque le nœud démarre et que la tâche démarre, aucun périphérique MIG n'est attribué à la tâche : elle n'CUDA_VISIBLE_DEVICESest pas définie, et comme AWS PCS ne restreint pas l'accès aux périphériques via des groupes de contrôle, la tâche peut utiliser tous les périphériques MIG du nœud. Slurm signale la tâche comme RUNNING si, et l'instance MIG sur laquelle la tâche a été prise en compte est affectée à la tâche suivante qui demande ce profil, afin que les deux tâches puissent se retrouver sur la même instance MIG. Les tâches attribuées au nœud après son enregistrement, y compris après des cycles de mise hors tension et de mise sous tension ultérieurs, obtiennent leur appareil comme prévu.

Pour détecter cette condition, vérifiez au début de la tâche définie, puis quittez la tâche ou mettez-la en file d'attente lorsqu'elle ne l'est pas : CUDA_VISIBLE_DEVICES

if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then
    scontrol requeue "$SLURM_JOB_ID"
    exit 1
fi

Une tâche en file d'attente peut être exécutée à nouveau après le paramètre du requeue_delay planificateur, 5 secondes par défaut. À ce moment-là, le nœud est enregistré, de sorte que la tâche obtient un périphérique lors de son prochain démarrage.