Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Configurar la Multi-Instance GPU (MIG) en AWS 2 PIEZAS Multi-Instance La GPU NVIDIA (MIG) divide una GPU compatible en instancias de GPU aisladas, cada una con sus propios recursos de memoria y procesamiento. Slurm programa cada perfil MIG según su propio tipo de recurso genérico (GRES), de modo que varios trabajos pueden compartir una GPU física con aislamiento de hardware. Los dispositivos MIG no se pueden describir de forma estática`gres.conf`: los archivos de sus dispositivos y los UUID solo existen después de crear las instancias MIG en el nodo de arranque, por lo que no es necesario configurar ningún valor con antelación. `File` `Type` En los AWS PCS, se configura MIG con un `gres.conf` registro que solo habilita`AutoDetect`, junto con una `Gres` configuración que declara los perfiles. `slurmd`luego descubre los dispositivos MIG cuando se inicia el nodo. AWS PCS admite `AutoDetect` la versión 25.11 y posteriores de Slurm y, por lo tanto, MIG. La configuración de MIG implica particionar las GPU de cada nodo y declarar los perfiles resultantes a Slurm en el grupo de nodos de procesamiento. Ninguno de los dos funciona por sí solo, así que aplica ambos en un solo cambio. Si Slurm no conoce las particiones de un nodo, el nodo no tiene un GRES programable. Si ningún nodo crea los perfiles declarados, los nodos se agotan cuando se registran. Con la acción recomendada para el ciclo de vida de los nodos, una actualización de un grupo de nodos de procesamiento incluye tanto el script de partición como la configuración del GRES. ## Requisitos previos + Un grupo de nodos de procesamiento que usa un tipo de MIG-capable instancia. + Versión 25.11 de Slurm o posterior. + Topología de CPU configurada. La detección automática de la GPU requiere la disposición de los sockets del nodo. En el Slurm 25.11, se configura `Sockets` para el grupo de nodos de procesamiento; en el Slurm 26.05 y versiones posteriores, PCS lo configura automáticamente. AWS Para obtener más información, consulte [Configuración de la topología de hardware en AWS PC](hardware-topology.md). ## Qué debe tener un nodo MIG en cada arranque El modo MIG y las instancias MIG se encuentran en la GPU, no en el disco, por lo que una AMI personalizada no puede almacenarlos y se pierden cuando la instancia se detiene, suspende o termina. En cada arranque, debe cumplirse todo lo siguiente antes `slurmd` de comenzar: 1. **El modo MIG está habilitado ** en todas las GPU que sirven a las instancias MIG. `nvidia-smi -q`indica un modo `Current` y un `Pending` modo, y `Current` debe estarlo. `Enabled` 1. **Existen instancias MIG**, tanto instancias de GPU como instancias de procesamiento, para cada perfil de la `Gres` configuración del grupo de nodos de procesamiento. 1. **Los perfiles y los recuentos coinciden con ** la `Gres` configuración. Si el modo MIG está habilitado pero no hay instancias MIG, `slurmd` busca las GPU principales pero no el dispositivo MIG. A continuación`MIG mode is enabled, but no MIG devices were found`, registra cada perfil declarado`Discarding the following config-only GPU due to lack of File specification`. Como el nodo notifica menos GPU de las `Gres` declaradas, el controlador rechaza el registro y agota el nodo explicando el motivo. `gres/gpu count reported lower than configured` Los trabajos que solicitan una GPU en el nodo fallan. `Required node not available` La creación posterior de las instancias MIG no desactiva el nodo; hay que reanudarlo o reemplazarlo. La acción del ciclo de vida del nodo que se describe en [Aplica la configuración con una acción del ciclo de vida del nodo](#mig-configuration-instances-nla) evita esto al fallar el nodo antes de que se registre. ## Configure MIG en las instancias La configuración de las instancias requiere las dos operaciones siguientes. Ejecútalas desde una acción del ciclo de vida del nodo, que mantiene la lógica en el grupo de nodos de procesamiento en lugar de en una AMI que tienes que reconstruir. Consulte [Aplica la configuración con una acción del ciclo de vida del nodo](#mig-configuration-instances-nla). Si otro proceso ya contiene las GPU en ese momento, ejecútelas antes desde un `cloud-init` libro de arranque o desde una `systemd` unidad de una AMI personalizada. Consulte [Si el modo MIG permanece pendiente](#mig-configuration-instances-pending). Para obtener más información sobre los comandos, consulta la Guía del usuario de la Multi-Instance GPU de [ NVIDIA. ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) 1. Activa el modo MIG en las GPU: ``` nvidia-smi -mig 1 ``` El cambio de modo no puede tener efecto mientras un proceso esté usando las GPU. Por el `nodeBootstrapped` momento no se `slurmd` ha iniciado, por lo que, en un nodo que no ejecute ningún otro servicio de GPU, el cambio se efectuará sin necesidad de reiniciar. Comprueba que el modo aplicado esté `Enabled` en todas las GPU con`nvidia-smi --query-gpu=mig.mode.current --format=csv`. **importante** Si el modo MIG permanece`Pending`, otro proceso tiene las GPU abiertas. Consulte [Si el modo MIG permanece pendiente](#mig-configuration-instances-pending). 1. Crea las instancias de GPU y computa las instancias de procesamiento para los perfiles que quieras. Por ejemplo, para particionar cada una de las 8 GPU en una `3g.20gb``2g.10gb`, una y dos `1g.5gb` instancias: ``` 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`también acepta identificadores de perfil numéricos, pero el mismo identificador significa un perfil diferente en un modelo de GPU diferente: este diseño `9,14,19,19` se encuentra en la A100 de 40 GB en una `p4d` instancia `3g.40gb``2g.20gb`, y dos `1g.10gb` en una parte de 80 GB. Usa los nombres de los perfiles para que coincidan con la `Gres` configuración y se producirá un error de creación en una GPU que no tenga ese perfil. Crea primero los perfiles más grandes, como en el ejemplo. Las ubicaciones de los MIG son fijas, por lo que es posible que no se pueda crear un diseño que se ajuste si los perfiles pequeños ocupan los cortes que necesitan los grandes. ### Aplica la configuración con una acción del ciclo de vida del nodo Configure la acción del ciclo de vida del nodo de la siguiente manera. Para saber cómo añadir uno a un grupo de nodos de procesamiento, consulta[Configure las acciones del ciclo de vida del nodo en AWS PC](cng-node-lifecycle-actions-configure.md). | **Campo** | **Valor** | **¿Por qué ** | | --- | --- | --- | | Etapa del ciclo de vida | `nodeBootstrapped` | Se ejecuta antes de `slurmd` abrir las GPU y registrar el nodo. | | `executionPolicy` | `EVERY_BOOT` | El estado MIG no sobrevive a una parada, suspensión o finalización. | | `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | Los perfiles MIG que se deben crear en cada GPU, por nombre. Luego, un script sirve grupos de nodos de computación con diferentes diseños. | | `onError` | `TERMINATE` | Sustituye un nodo que no se puede particionar en lugar de permitir que se registre sin sus dispositivos MIG. Durante la depuración, utilízala `STOP_SEQUENCE` para conservar la instancia para su inspección. | Un script que se ejecute en cada arranque debe ser idempotente. El siguiente esquema toma el diseño por GPU como primer argumento y maneja una GPU a la vez. Omite una GPU que ya tiene ese diseño, reparticiona cualquier otra y sale con un valor distinto de cero si no puede terminar, lo que produce un error en el nodo. Nunca reinicia el nodo. Para saber cómo los argumentos llegan a un script, consulte[Pasar argumentos a los guiones](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 ``` Para configurar el script y la configuración del GRES en una llamada, consulte el ejemplo en[Declara los perfiles MIG a Slurm](#mig-configuration-slurm). Si adapta el script, conserve ambas comprobaciones. Sin la comprobación de modo, un nodo cuyo modo MIG nunca haya pasado a estar en modo MIG `Enabled` pasa a registrarse sin sus dispositivos MIG y la causa solo aparece en el `slurmd` registro. Sin la comprobación de diseño, un nodo que crea los perfiles incorrectos se registra normalmente y solo falla en los trabajos que solicitan los perfiles declarados. Para saber dónde se escribe la salida del script, consulte[Registro y depuración](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging). ### Si el modo MIG permanece pendiente La activación del modo MIG falla mientras algún proceso tenga las GPU abiertas. `nvidia-smi`indica que la activación está pendiente, por ejemplo con`In use by another client`, y solo surtirá efecto después de que esos procesos se cierren o el nodo se reinicie. En un nodo de procesamiento AWS PCS, el proceso suele ser un agente de supervisión de la GPU, como NVIDIA DCGM, o un agente que se incluye en la AMI, o por `slurmd` sí mismo si el MIG se configura después de iniciarse. `slurmd` No puedes reiniciar desde la acción del ciclo de vida, así que usa una de las siguientes correcciones: + **Detenga el proceso que contiene las GPU. ** En la AMI personalizada, deshabilite o elimine cualquier demonio que abra las GPU antes de que se ejecute la configuración de MIG. Elimine también cualquier demonio que configure el propio MIG. Dos componentes que particionan las mismas GPU producen un diseño que no coincide con la configuración. `Gres` + **Configura MIG en un libro de arranque. ** Si no puedes detener el proceso, mueve el cambio de modo MIG y la creación del perfil a un `cloud-init` libro de inicio en los datos de usuario de la plantilla de lanzamiento. El boothook se ejecuta antes del arranque del AWS PCS y antes de que se inicien los servicios de la AMI, por lo que el cambio de modo se efectúa sin necesidad de reiniciar el equipo. Para saber cómo escribir uno, consulte. [Ejemplo: ejecutar operaciones de arranque anticipadas con un boothook de inicio en la nube](working-with_ec2-user-data_early-boot.md) Controla la acción del ciclo de vida: en cada arranque, confirma el diseño y falla en el nodo si el gancho de arranque no la aplicó. ## Declara los perfiles MIG a Slurm Declare las dos configuraciones de GRES en el grupo de nodos de procesamiento: + En`gresCustomSettings`, un registro de GPU que solo está habilitado. `AutoDetect` No configure `Name``Type`, o`File`. Los dispositivos MIG se descubren en el nodo. + En`slurmCustomSettings`, una `Gres` configuración que declara los perfiles y recuentos MIG que los trabajos pueden solicitar. Los nombres y recuentos de los perfiles deben coincidir con las instancias de MIG creadas en el nodo. **Example — Aplicar ambas partes en una sola actualización (8 GPU, cada una dividida en una de `3g.20gb, una de 2g.10gb y dos de` 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" } ] } }' ``` En el ejemplo se pasan ambos parámetros como JSON porque el `Gres` valor contiene comas, por lo que la sintaxis abreviada de la CLI tendría que contener una coma. Mantén `arguments` la `Gres` coherencia: `3g.20gb,2g.10gb,1g.5gb,1g.5gb` en cada una de las 8 GPU aparecen las 8, 8 y 16 instancias que declaran. `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` Para conocer las restricciones entre los dos ajustes, consulte[Restricciones entre gres.conf y la configuración de Gres](gres-custom-settings.md#gres-custom-settings-constraints). Como AWS PCS no puede contar los dispositivos que se descubren durante el arranque, acepta todos los nombres de perfil y los contabiliza en la `Gres` configuración para obtener un registro que solo esté habilitado`AutoDetect`. La coherencia con las instancias MIG reales solo se verifica cuando el nodo se registra. Cuando un nodo arranca y se registra, anuncia los perfiles descubiertos con su afinidad de socket, por ejemplo. `Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1)` Un trabajo que solicita un perfil, por ejemplo`--gres=gpu:3g.20gb:1`, se coloca en una única instancia de MIG y obtiene su UUID `CUDA_VISIBLE_DEVICES` (por ejemplo,`MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e`), por lo que CUDA restringe el trabajo a esa instancia de MIG. **nota** El controlador registra las advertencias, por ejemplo, las de los registros MIG. `Ignoring file-less GPU gpu:3g.20gb from final GRES list` Esto es lo esperado: el GRES autorizado proviene del registro de nodos. ## Limitaciones Como una configuración MIG no nombra ningún dispositivo, el controlador solo conoce el GRES real de un nodo después de que el nodo se inicie y se registre. Hasta que un nodo se registre una vez, el controlador solo retiene los recuentos de perfil de la `Gres` configuración. Esto provoca la siguiente limitación. Se aplica a cualquier registro de GPU que solo lo habilite y`AutoDetect`, por lo tanto, a todos los grupos de nodos de procesamiento MIG. **nota** Como práctica recomendada, usa un grupo de nodos de procesamiento estático para MIG: establecido `minInstanceCount` igual a `maxInstanceCount` en la configuración de escalado. Luego, los nodos se registran cuando se lanzan, antes de que se les asigne ningún trabajo, lo que evita la limitación. ### Los trabajos asignados antes de que un nodo se registre por primera vez pueden comenzar sin una GPU Una tarea asignada a un nodo que está apagado y nunca se ha registrado (por ejemplo, en el primer arranque de un grupo de nodos de procesamiento recién creado) recibe un recuento de perfiles, pero no un dispositivo específico, porque los dispositivos aún no se conocen. Cuando el nodo se inicia y se inicia el trabajo, el trabajo no tiene ningún dispositivo MIG asignado: no `CUDA_VISIBLE_DEVICES` está configurado y, dado que AWS PCS no restringe el acceso a los dispositivos a través de cgroups, el trabajo puede usar todos los dispositivos MIG del nodo. `RUNNING`Sin embargo, Slurm informa sobre el trabajo y la instancia de MIG con la que se ha contado el trabajo se asigna al siguiente trabajo que solicita ese perfil, por lo que ambos trabajos pueden terminar en la misma instancia de MIG. Las tareas asignadas al nodo después de que se haya registrado una vez, incluso después de ciclos posteriores de apagado y encendido, obtienen el dispositivo según lo esperado. Para detectar esta condición, comprueba que la tarea `CUDA_VISIBLE_DEVICES` está configurada al principio y sal de la tarea o vuelve a ponerla en cola cuando no lo esté: ``` if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then scontrol requeue "$SLURM_JOB_ID" exit 1 fi ``` Una tarea que se ha vuelto a poner en cola pasa a ser apta para volver a ejecutarse después del parámetro del `requeue_delay` planificador (5 segundos de forma predeterminada). Para entonces, el nodo se habrá registrado, por lo que la tarea recibirá un dispositivo la próxima vez que se inicie.