Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # 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'`File`avance. Sur AWS PCS, vous configurez MIG avec un `gres.conf` enregistrement qui active uniquement`AutoDetect`, ainsi qu'un `Gres` paramètre qui déclare les profils. `slurmd`découvre ensuite les périphériques MIG au démarrage du nœud. AWS PCS prend en charge`AutoDetect`, 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 + Un groupe de nœuds de calcul qui utilise un type d' MIG-capable instance. + Slurm version 25.11 ou ultérieure. + Topologie du processeur configurée. La détection automatique du GPU nécessite la disposition des sockets du nœud. Sur Slurm 25.11, défini `Sockets` pour le groupe de nœuds de calcul ; sur Slurm 26.05 et versions ultérieures, PCS le configure automatiquement. AWS Pour plus d’informations, consultez [Configuration de la topologie matérielle dans AWS PIÈCES](hardware-topology.md). ## 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 : 1. **Le mode MIG est activé ** sur tous les GPU qui desservent des instances MIG. `nvidia-smi -q`indique un `Pending` mode `Current` et un, et `Current` doit l'être`Enabled`. 1. **Les instances MIG existent**, à la fois des instances GPU et des instances de calcul, pour chaque profil dans les `Gres` paramètres du groupe de nœuds de calcul. 1. **Les profils et les dénombrements correspondent ** au `Gres` réglage. 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 enregistre`MIG 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 avec`Required 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](#mig-configuration-instances-nla)é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](#mig-configuration-instances-nla). 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](#mig-configuration-instances-pending). Pour plus d'informations sur les commandes, consultez le Guide de l'utilisateur Multi-Instance du GPU [ NVIDIA](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/). 1. Activez le mode MIG sur les GPU : ``` nvidia-smi -mig 1 ``` Le changement de mode ne peut pas prendre effet lorsqu'un processus utilise les GPU. Au `nodeBootstrapped` stade `slurmd` n'a pas démarré, donc sur un nœud qui n'exécute aucun autre service GPU, la modification prend effet sans redémarrage. Vérifiez que le mode appliqué est `Enabled` sur tous les GPU dotés de`nvidia-smi --query-gpu=mig.mode.current --format=csv`. **Important** Si le mode MIG reste en mode`Pending`, les GPU sont ouverts dans un autre processus. Consultez [Si le mode MIG reste en attente](#mig-configuration-instances-pending). 1. Créez les instances GPU et calculez les instances pour les profils que vous souhaitez. Par exemple, pour partitionner chacun des 8 GPU en une `3g.20gb``2g.10gb`, une et deux `1g.5gb` instances : ``` 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`accepte également les identifiants de profil numériques, mais le même identifiant signifie un profil différent sur un modèle de GPU différent : `9,14,19,19` cette disposition est-elle sur l'A100 de 40 Go dans une `p4d` instance, et `3g.40gb``2g.20gb`, et deux `1g.10gb` sur une partie de 80 Go ? Utilisez les noms des profils afin qu'ils correspondent au `Gres` paramètre. La création échouera sur un GPU qui ne possède pas de profil de ce type. Créez d'abord les profils les plus grands, comme dans l'exemple. Les emplacements MIG sont fixes, de sorte qu'une mise en page adaptée peut toujours ne pas être créée si les petits profils prennent les tranches dont les grands ont besoin. ### 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, consultez[Configurer les actions relatives au cycle de vie des nœuds dans AWS PIÈCES](cng-node-lifecycle-actions-configure.md). | **Champ** | **Valeur** | **Pourquoi ** | | --- | --- | --- | | Étape du cycle de vie | `nodeBootstrapped` | S'exécute avant d'`slurmd`ouvrir les GPU et d'enregistrer le nœud. | | `executionPolicy` | `EVERY_BOOT` | L'état MIG ne survit pas à un arrêt, à une suspension ou à une résiliation. | | `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | Les profils MIG à créer sur chaque GPU, par nom. Un script fournit ensuite des groupes de nœuds de calcul avec différentes dispositions. | | `onError` | `TERMINATE` | Remplace un nœud qui ne peut pas être partitionné au lieu de le laisser s'enregistrer sans ses périphériques MIG. Pendant le débogage, utilisez cette `STOP_SEQUENCE` option pour conserver l'instance pour inspection. | 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, consultez[Transmettre des arguments à des scripts](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 ``` Pour définir le script et les paramètres GRES en un seul appel, consultez l'exemple présenté dans[Déclarer les profils MIG à Slurm](#mig-configuration-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, consultez[Journalisation et débogage](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging). ### Si le mode MIG reste en attente L'activation du mode MIG échoue lorsque les GPU d'un processus sont ouverts. `nvidia-smi`signale l'activation comme étant en attente, par exemple with`In 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 : + **Arrêtez le processus qui contient les GPU. ** Dans l'AMI personnalisée, désactivez ou supprimez tout démon qui ouvre les GPU avant l'exécution de la configuration MIG. Supprimez également tout démon qui configure le MIG lui-même. Deux composants partitionnant les mêmes GPU produisent une disposition qui ne correspond pas au `Gres` réglage. + **Configurez MIG dans un boothook. ** Si vous ne pouvez pas arrêter le processus, déplacez le changement de mode MIG et la création du profil dans un `cloud-init` boothook dans les données utilisateur du modèle de lancement. Un boothook s'exécute avant le bootstrap du AWS PCS et avant le démarrage des services de l'AMI, de sorte que le changement de mode prend effet sans redémarrage. Pour savoir comment en écrire un, voir[Exemple : exécutez des opérations de démarrage anticipées à l'aide d'un boothook d'initialisation cloud](working-with_ec2-user-data_early-boot.md). Gardez l'action du cycle de vie à titre de contrôle : à chaque démarrage, elle confirme la disposition et fait échouer le nœud si le boothook ne l'a pas appliquée. ## Déclarer les profils MIG à Slurm Déclarez les deux paramètres GRES sur le groupe de nœuds de calcul : + Dans`gresCustomSettings`, un enregistrement GPU qui active uniquement`AutoDetect`. Ne définissez pas `Name``Type`, ou`File`. Les périphériques MIG sont découverts sur le nœud. + Dans`slurmCustomSettings`, un `Gres` paramètre qui déclare les profils MIG et les comptes que les jobs peuvent demander. Les noms et le nombre de profils doivent correspondre aux instances MIG créées sur le nœud. **Example — Appliquer les deux parties en une seule mise à jour (8 GPU, chacun partitionné en un `3g.20 Go`, un `` 2g.10 Go et deux 1g.5 Go) ``** ``` 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'exemple transmet les deux paramètres au format JSON car la `Gres` valeur contient des virgules, que la syntaxe abrégée de la CLI devrait éviter. Restez `arguments` `Gres` cohérent : `3g.20gb,2g.10gb,1g.5gb,1g.5gb` sur chacun des 8 GPU se trouvent les 8, 8 et 16 instances qui `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` déclarent. Pour connaître les contraintes entre les deux paramètres, consultez[Contraintes entre gres.conf et le paramètre Gres](gres-custom-settings.md#gres-custom-settings-constraints). 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 exemple`Gres=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 exemple`MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e`). CUDA limite donc la tâche à cette instance MIG. **Note** Le contrôleur enregistre les avertissements, par exemple `Ignoring file-less GPU gpu:3g.20gb from final GRES list` pour les enregistrements MIG. C'est normal : le GRES faisant autorité provient de l'enregistrement des nœuds. ## 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. **Note** Il est recommandé d'utiliser un groupe de nœuds de calcul statique pour MIG : défini `minInstanceCount` égal à `maxInstanceCount` dans la configuration de mise à l'échelle. Les nœuds s'enregistrent ensuite lors de leur lancement, avant qu'une tâche ne leur soit attribuée, ce qui permet d'éviter cette limitation. ### 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_DEVICES`est 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.