As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Configurando a Multi-Instance GPU (MIG) em AWS PEÇAS A Multi-Instance GPU NVIDIA (MIG) particiona uma GPU compatível em instâncias de GPU isoladas, cada uma com sua própria memória e recursos de computação. O Slurm agenda cada perfil MIG como seu próprio tipo de recurso genérico (GRES), para que vários trabalhos possam compartilhar uma GPU física com isolamento de hardware. Os dispositivos MIG não podem ser descritos estaticamente em`gres.conf`: seus arquivos de dispositivo e UUIDs só existem depois que as instâncias MIG são criadas no nó inicializado, portanto, não há `Type` valor `File` ou valor para configurar com antecedência. No AWS PCS, você configura o MIG com um `gres.conf` registro que só habilita`AutoDetect`, junto com uma `Gres` configuração que declara os perfis. `slurmd`em seguida, descobre os dispositivos MIG quando o nó é inicializado. AWS O PCS suporta e`AutoDetect`, portanto, MIG, no Slurm versão 25.11 e posterior. Configurar o MIG significa particionar as GPUs em cada nó e declarar os perfis resultantes para o Slurm no grupo de nós de computação. Nenhum deles funciona sozinho, então aplique os dois em uma única alteração. Se o Slurm não conhece as partições de um nó, o nó não tem GRES programável. Se nenhum nó criar os perfis declarados, os nós serão drenados quando forem registrados. Com a ação recomendada do ciclo de vida do nó, uma atualização do grupo de nós de computação carrega o script de particionamento e as configurações do GRES. ## Pré-requisitos + Um grupo de nós de computação que usa um tipo de MIG-capable instância. + Slurm versão 25.11 ou posterior. + Topologia de CPU configurada. A detecção automática de GPU requer o layout do soquete do nó. No Slurm 25.11, definido `Sockets` para o grupo de nós de computação; no Slurm 26.05 e versões posteriores, o PCS o configura automaticamente. AWS Para obter mais informações, consulte [Configurando a topologia de hardware em AWS PEÇAS](hardware-topology.md). ## O que um nó MIG deve ter em cada inicialização O modo MIG e as instâncias MIG residem na GPU, não no disco, portanto, uma AMI personalizada não pode carregá-las e elas são perdidas sempre que a instância é interrompida, suspensa ou encerrada. Em cada inicialização, todos os itens a seguir devem ser verdadeiros antes de `slurmd` iniciar: 1. **O modo MIG é ativado ** em cada GPU que serve instâncias MIG. `nvidia-smi -q`relata `Current` os `Pending` modos a e a, e `Current` deve ser`Enabled`. 1. **As instâncias MIG existem**, tanto instâncias de GPU quanto instâncias de computação, para cada perfil na configuração do grupo de nós de computação. `Gres` 1. **Os perfis e as contagens correspondem ** à `Gres` configuração. Se o modo MIG estiver ativado, mas não houver instâncias MIG, `slurmd` localizará as GPUs principais, mas nenhum dispositivo MIG. Ele registra`MIG mode is enabled, but no MIG devices were found`, então, `Discarding the following config-only GPU due to lack of File specification` para cada perfil declarado. Como o nó relata menos GPUs do que o `Gres` declarado, o controlador rejeita o registro e drena o nó com o motivo. `gres/gpu count reported lower than configured` Os trabalhos que solicitam uma GPU no nó falham com`Required node not available`. A criação posterior das instâncias MIG não esgota o nó; você precisa retomá-lo ou substituí-lo. A ação do ciclo de vida do nó descrita em [Aplique a configuração com uma ação de ciclo de vida do nó](#mig-configuration-instances-nla) evita isso ao falhar no nó antes de ele se registrar. ## Configurar o MIG nas instâncias A configuração das instâncias exige as duas operações a seguir. Execute-os a partir de uma ação do ciclo de vida do nó, que mantém a lógica no grupo de nós de computação em vez de em uma AMI que você precisa reconstruir. Consulte [Aplique a configuração com uma ação de ciclo de vida do nó](#mig-configuration-instances-nla). Se outro processo já tiver as GPUs nesse ponto, execute-as mais cedo a partir de um `cloud-init` boothook ou de uma `systemd` unidade em uma AMI personalizada. Consulte [Se o modo MIG permanecer pendente](#mig-configuration-instances-pending). Para obter mais informações sobre os comandos, consulte o Guia do usuário da Multi-Instance GPU [ NVIDIA. ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) 1. Ative o modo MIG nas GPUs: ``` nvidia-smi -mig 1 ``` A alteração do modo não pode entrar em vigor enquanto um processo estiver usando as GPUs. Como o `nodeBootstrapped` estágio `slurmd` ainda não começou, em um nó que não executa nenhum outro serviço de GPU, a alteração entra em vigor sem uma reinicialização. Verifique se o modo aplicado está `Enabled` em todas as GPU com`nvidia-smi --query-gpu=mig.mode.current --format=csv`. **Importante** Se o modo MIG permanecer`Pending`, outro processo abrirá as GPUs. Consulte [Se o modo MIG permanecer pendente](#mig-configuration-instances-pending). 1. Crie as instâncias de GPU e compute as instâncias para os perfis que você deseja. Por exemplo, para particionar cada uma das 8 GPUs em uma `3g.20gb``2g.10gb`, uma e duas `1g.5gb` instâncias: ``` 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`também aceita IDs de perfil numéricos, mas o mesmo ID significa um perfil diferente em um modelo de GPU diferente: esse layout `9,14,19,19` está no A100 de 40 GB em uma `p4d` instância e `3g.40gb``2g.20gb`, e dois `1g.10gb` em uma peça de 80 GB. Use os nomes dos perfis para que eles correspondam à `Gres` configuração e a criação falhe em uma GPU que não tenha esse perfil. Crie os maiores perfis primeiro, como no exemplo. Os posicionamentos do MIG são fixos, portanto, um layout adequado ainda pode falhar na criação se os perfis pequenos usarem as fatias de que os grandes precisam. ### Aplique a configuração com uma ação de ciclo de vida do nó Configure a ação do ciclo de vida do nó da seguinte forma. Para saber como adicionar um a um grupo de nós de computação, consulte[Configure as ações do ciclo de vida do nó no AWS PEÇAS](cng-node-lifecycle-actions-configure.md). | **Campo** | **Valor** | **Por que ** | | --- | --- | --- | | Estágio do ciclo de vida | `nodeBootstrapped` | É executado antes de `slurmd` abrir as GPUs e registrar o nó. | | `executionPolicy` | `EVERY_BOOT` | O estado MIG não sobrevive a uma parada, suspensão ou rescisão. | | `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | Os perfis MIG a serem criados em cada GPU, por nome. Em seguida, um script serve grupos de nós de computação com diferentes layouts. | | `onError` | `TERMINATE` | Substitui um nó que não pode ser particionado em vez de permitir que ele se registre sem seus dispositivos MIG. Durante a depuração, use `STOP_SEQUENCE` para manter a instância para inspeção. | Um script executado em cada inicialização deve ser idempotente. O esboço a seguir usa o layout por GPU como primeiro argumento e lida com uma GPU por vez. Ele ignora uma GPU que já tem esse layout, reparticiona qualquer outra e sai diferente de zero se não conseguir terminar, o que falha no nó. Ele nunca reinicia o node. Para saber como os argumentos chegam a um script, consulte[Passando argumentos para 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 ``` Para definir o script e as configurações de GRES em uma chamada, veja o exemplo em[Declare os perfis MIG para Slurm](#mig-configuration-slurm). Se você adaptar o script, mantenha as duas verificações. Sem a verificação de modo, um nó cujo modo MIG nunca `Enabled` se tornou é registrado sem seus dispositivos MIG, e a causa aparece apenas no `slurmd` registro. Sem a verificação do layout, um nó que cria os perfis errados se registra normalmente e falha somente nas tarefas que solicitam os perfis declarados. Para saber onde a saída do script é gravada, consulte[Registro e depuração](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging). ### Se o modo MIG permanecer pendente A ativação do modo MIG falha enquanto qualquer processo tem as GPUs abertas. `nvidia-smi`relata a ativação como pendente, por exemplo`In use by another client`, com, e ela entra em vigor somente após a saída desses processos ou a reinicialização do nó. Em um nó de computação AWS PCS, o processo geralmente é um agente de monitoramento de GPU, como o NVIDIA DCGM ou um agente fornecido na AMI, ou ele mesmo, `slurmd` se o MIG for configurado após a inicialização. `slurmd` Você não pode reinicializar a partir da ação do ciclo de vida, então use uma das seguintes correções: + **Pare o processo que mantém as GPUs. ** Na AMI personalizada, desative ou remova qualquer daemon que abra as GPUs antes da execução da configuração MIG. Remova também qualquer daemon que configure o próprio MIG. Dois componentes que particionam as mesmas GPUs produzem um layout que não corresponde à configuração. `Gres` + **Configure o MIG em um boothook. ** Se você não conseguir interromper o processo, mova a alteração do modo MIG e a criação do perfil para um `cloud-init` boothook nos dados do usuário do modelo de lançamento. Um boothook é executado antes da inicialização do AWS PCS e antes do início dos serviços da AMI, portanto, a alteração do modo entra em vigor sem uma reinicialização. Para saber como escrever um, consulte[Exemplo: Execute operações de inicialização antecipada com um boothook cloud-init](working-with_ec2-user-data_early-boot.md). Mantenha a ação do ciclo de vida como uma verificação: em cada inicialização, ela confirma o layout e falha no nó se o boothook não o aplicar. ## Declare os perfis MIG para Slurm Declare as duas configurações de GRES no grupo de nós de computação: + Em`gresCustomSettings`, um registro de GPU que só habilita`AutoDetect`. Não defina `Name``Type`, ou`File`. Os dispositivos MIG são descobertos no nó. + Em`slurmCustomSettings`, uma `Gres` configuração que declara os perfis MIG e as contagens que os trabalhos podem solicitar. Os nomes e contagens do perfil devem corresponder às instâncias MIG criadas no nó. **Example — Aplicação de ambas as partes em uma atualização (8 GPUs, cada uma particionada em uma de `3g.20gb`, uma de `` 2g.10gb e duas 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" } ] } }' ``` O exemplo passa os dois parâmetros como JSON porque o `Gres` valor contém vírgulas, cuja sintaxe abreviada da CLI precisaria escapar. Mantenha `arguments` e `Gres` seja consistente: `3g.20gb,2g.10gb,1g.5gb,1g.5gb` em cada uma das 8 GPUs, forneça as 8, 8 e 16 instâncias que `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` declara. Para as restrições entre as duas configurações, consulte[Restrições entre gres.conf e a configuração Gres](gres-custom-settings.md#gres-custom-settings-constraints). Como o AWS PCS não pode contar os dispositivos descobertos na inicialização, ele aceita qualquer nome de perfil e conta na `Gres` configuração de um registro que só é ativado`AutoDetect`. A consistência com as instâncias MIG reais só é verificada quando o nó é registrado. Quando um nó é inicializado e registrado, ele anuncia os perfis descobertos com sua afinidade de soquete, por exemplo. `Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1)` Um trabalho que solicita um perfil, como`--gres=gpu:3g.20gb:1`, é colocado em uma única instância MIG e recebe seu UUID `CUDA_VISIBLE_DEVICES` (por exemplo,`MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e`), então o CUDA restringe o trabalho a essa instância MIG. **nota** O controlador registra avisos, como `Ignoring file-less GPU gpu:3g.20gb from final GRES list` para registros MIG. Isso é esperado: o GRES oficial vem do registro de nós. ## Limitações Como uma configuração MIG não nomeia nenhum dispositivo, o controlador só conhece o GRES real de um nó depois que o nó é inicializado e registrado. Até que um nó seja registrado uma vez, o controlador retém somente as contagens de perfis da `Gres` configuração. Isso causa a seguinte limitação. Ele se aplica a qualquer registro de GPU que só habilite e`AutoDetect`, portanto, a cada grupo de nós de computação MIG. **nota** Como prática recomendada, use um grupo estático de nós de computação para MIG: definido como `minInstanceCount` igual a `maxInstanceCount` na configuração de escalabilidade. Os nós então se registram quando são iniciados, antes que qualquer trabalho seja alocado para eles, o que evita a limitação. ### Os trabalhos alocados antes do primeiro registro de um nó podem começar sem uma GPU Um trabalho alocado para um nó que está desligado e nunca foi registrado, por exemplo, na primeira inicialização de um grupo de nós de computação recém-criado, recebe uma contagem de perfis, mas nenhum dispositivo específico, porque os dispositivos ainda não são conhecidos. Quando o nó é inicializado e o trabalho é iniciado, o trabalho não tem nenhum dispositivo MIG atribuído: não `CUDA_VISIBLE_DEVICES` está definido e, como o AWS PCS não restringe o acesso ao dispositivo por meio de cgroups, o trabalho pode usar todos os dispositivos MIG no nó. O Slurm relata o trabalho como `RUNNING` se fosse, e a instância MIG com a qual o trabalho foi contado é atribuída ao próximo trabalho que solicita esse perfil, para que os dois trabalhos possam terminar na mesma instância MIG. Os trabalhos alocados para o nó após ele ter sido registrado uma vez, inclusive após ciclos posteriores de desligamento e inicialização, recebem o dispositivo conforme o esperado. Para detectar essa condição, verifique no início do trabalho `CUDA_VISIBLE_DEVICES` definido e saia ou recoloque o trabalho na fila quando não estiver: ``` if [ -z "${CUDA_VISIBLE_DEVICES-}" ]; then scontrol requeue "$SLURM_JOB_ID" exit 1 fi ``` Um trabalho em fila se torna elegível para ser executado novamente após o parâmetro do `requeue_delay` agendador, 5 segundos por padrão. Até lá, o nó está registrado, então o trabalho recebe um dispositivo em sua próxima inicialização.