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 emgres.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ó habilitaAutoDetect, junto com uma Gres configuração que declara os perfis. slurmdem seguida, descobre os dispositivos MIG quando o nó é inicializado. AWS O PCS suporta eAutoDetect, 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

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:

Se o modo MIG estiver ativado, mas não houver instâncias MIG, slurmd localizará as GPUs principais, mas nenhum dispositivo MIG. Ele registraMIG 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 comRequired 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ó 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ó. 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. Para obter mais informações sobre os comandos, consulte o Guia do usuário da Multi-Instance GPU NVIDIA.

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, consulteConfigure as ações do ciclo de vida do nó no AWS PEÇAS.

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, consultePassando argumentos para 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

Para definir o script e as configurações de GRES em uma chamada, veja o exemplo emDeclare os perfis MIG para 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, consulteRegistro e depuração.

Se o modo MIG permanecer pendente

A ativação do modo MIG falha enquanto qualquer processo tem as GPUs abertas. nvidia-smirelata a ativação como pendente, por exemploIn 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:

Declare os perfis MIG para Slurm

Declare as duas configurações de GRES no grupo de nós de computação:

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

Para as restrições entre as duas configurações, consulteRestrições entre gres.conf e a configuração Gres. 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ó é ativadoAutoDetect. 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.

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 eAutoDetect, portanto, a cada grupo de nós de computação MIG.

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.