AWS PCS에서 다중 인스턴스 GPU(MIG) 구성

NVIDIA 다중 인스턴스 GPU(MIG)는 지원되는 GPU를 각각 자체 메모리 및 컴퓨팅 리소스가 있는 격리된 GPU 인스턴스로 분할합니다. Slurm은 각 MIG 프로파일을 자체 일반 리소스(GRES) 유형으로 예약하므로 여러 작업이 하드웨어 격리와 함께 물리적 GPU 하나를 공유할 수 있습니다.

MIG 디바이스는에서 정적으로 설명할 수 없습니다gres.conf. 디바이스 파일 및 UUIDs는 부팅된 노드에서 MIG 인스턴스가 생성된 후에만 존재하므로 미리 구성할 File 또는 Type 값이 없습니다. AWS PCS에서는 프로파일을 선언하는 Gres 설정과 AutoDetect함께 만 활성화하는 gres.conf 레코드로 MIG를 구성합니다. slurmd 그러면는 노드가 부팅될 때 MIG 디바이스를 검색AutoDetect하므로 Slurm 버전 25.11 이상에서 MIG를 AWS 지원합니다.

MIG를 구성하려면 각 노드에서 GPUs를 분할하고 결과 프로파일을 컴퓨팅 노드 그룹의 Slurm으로 선언해야 합니다. 둘 다 단독으로 작동하지 않으므로 한 번의 변경으로 둘 다 적용합니다. Slurm이 노드의 파티션에 대해 모르는 경우 노드에는 예약 가능한 GRES가 없습니다. 선언된 프로파일을 생성하는 노드가 없는 경우 노드는 등록할 때 드레이닝됩니다. 권장 노드 수명 주기 작업을 사용하면 하나의 컴퓨팅 노드 그룹 업데이트에 파티셔닝 스크립트와 GRES 설정이 모두 포함됩니다.

사전 조건

부팅할 때마다 MIG 노드에 있어야 하는 사항

MIG 모드 및 MIG 인스턴스는 디스크가 아닌 GPU에 상주하므로 사용자 지정 AMI는 이를 전달할 수 없으며 인스턴스가 중지, 일시 중지 또는 종료될 때마다 손실됩니다. 부팅할 때마다가 slurmd 시작되기 전에 다음 사항이 모두 true여야 합니다.

MIG 모드가 활성화되었지만 MIG 인스턴스가 없는 경우는 상위 GPUs를 찾지만 MIG 디바이스는 slurmd 찾지 못합니다. 그러면 선언된 각 프로파일Discarding the following config-only GPU due to lack of File specification에 대해 MIG mode is enabled, but no MIG devices were found를 로깅합니다. 노드가 Gres 선언보다 적은 GPUs를 보고하기 때문에 컨트롤러는 등록을 거부하고 이유와 함께 노드를 비웁니다gres/gpu count reported lower than configured. 노드에서 GPU를 요청하는 작업은 로 실패합니다Required node not available. 이후에 MIG 인스턴스를 생성해도 노드가 풀리지 않으므로 노드를 재개하거나 교체해야 합니다. 에 설명된 노드 수명 주기 작업은 노드를 등록하기 전에 노드에 장애가 발생하여 이를 노드 수명 주기 작업을 사용하여 구성 적용 방지합니다.

인스턴스에서 MIG 구성

인스턴스를 구성하려면 다음 두 가지 작업을 수행합니다. 노드 수명 주기 작업에서 실행하여 다시 빌드해야 하는 AMI 대신 컴퓨팅 노드 그룹에 로직을 유지합니다. 노드 수명 주기 작업을 사용하여 구성 적용 섹션을 참조하세요. 다른 프로세스에 이미 GPU가 있는 경우 사용자 지정 AMI의 cloud-init 부트후크 또는 systemd 유닛에서 먼저 GPUs를 실행합니다. MIG 모드가 보류 상태로 유지되는 경우 섹션을 참조하세요. 명령에 대한 자세한 내용은 NVIDIA 다중 인스턴스 GPU 사용 설명서를 참조하세요.

노드 수명 주기 작업을 사용하여 구성 적용

다음과 같이 노드 수명 주기 작업을 구성합니다. 컴퓨팅 노드 그룹에 추가하는 방법은 단원을 참조하십시오AWS PCS에서 노드 수명 주기 작업 구성.

부팅할 때마다 실행되는 스크립트는 멱등성이어야 합니다. 다음 개요에서는 GPU당 레이아웃을 첫 번째 인수로 사용하고 한 번에 하나의 GPU를 처리합니다. 이미 해당 레이아웃이 있는 GPU를 건너뛰고, 다른 GPU를 재분할하고, 완료할 수 없는 경우 0이 아닌 GPU를 종료하여 노드에 실패합니다. 노드를 재부팅하지 않습니다. 인수가 스크립트에 도달하는 방법은 섹션을 참조하세요스크립트에 인수 전달.

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

한 번의 호출로 스크립트와 GRES 설정을 설정하려면의 예제를 참조하세요Slurm에 MIG 프로파일 선언.

스크립트를 조정하는 경우 두 검사를 모두 유지합니다. 모드 확인이 없으면 MIG 모드가 되지 않은 노드Enabled가 MIG 디바이스 없이 등록되며, 원인은 slurmd 로그에만 표시됩니다. 레이아웃 검사가 없으면 잘못된 프로파일을 생성하는 노드가 정상적으로 등록되고 선언된 프로파일을 요청하는 작업만 실패합니다. 스크립트의 출력이 기록되는 위치는 섹션을 참조하세요로깅 및 디버깅.

MIG 모드가 보류 상태로 유지되는 경우

MIG 모드 활성화는 모든 프로세스에 GPUs 열려 있는 동안 실패합니다.는 예를 들어를 사용하여 활성화를 보류 중으로 nvidia-smi 보고하며In use by another client, 해당 프로세스가 종료되거나 노드가 재부팅된 후에만 적용됩니다. AWS PCS 컴퓨팅 노드에서 프로세스는 일반적으로 NVIDIA DCGM 또는 AMI에 제공되는 에이전트와 같은 GPU 모니터링 에이전트이거나 시작 후 MIG가 구성된 경우 slurmd 자체입니다slurmd. 수명 주기 작업에서 재부팅할 수 없으므로 다음 수정 사항 중 하나를 사용합니다.

Slurm에 MIG 프로파일 선언

컴퓨팅 노드 그룹에서 두 GRES 설정을 모두 선언합니다.

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

두 설정 간의 제약 조건은 섹션을 참조하세요gres.conf와 Gres 설정 간의 제약 조건. AWS PCS는 부팅 시 검색된 디바이스를 계산할 수 없으므로 Gres 설정에서 만 활성화하는 레코드에 대한 프로필 이름과 개수를 수락합니다AutoDetect. 실제 MIG 인스턴스와의 일관성은 노드가 등록될 때만 확인됩니다.

노드가 부팅되고 등록되면와 같이 소켓 선호도로 검색된 프로파일을 알립니다Gres=gpu:3g.20gb:8(S:0),gpu:1g.5gb:28(S:1). 와 같이 프로필을 요청하는 작업은 단일 MIG 인스턴스에 배치--gres=gpu:3g.20gb:1되고에서 UUID를 가져오므로CUDA_VISIBLE_DEVICES(예: MIG-e7aa6185-06d5-53e9-a4d9-00f7670f741e) CUDA는 작업을 해당 MIG 인스턴스로 제한합니다.

제한 사항

MIG 구성은 디바이스 이름을 지정하지 않으므로 컨트롤러는 노드가 부팅되고 등록된 후에만 노드의 실제 GRES를 알고 있습니다. 노드가 한 번 등록될 때까지 컨트롤러는 Gres 설정의 프로필 수만 보유합니다. 이로 인해 다음과 같은 제한이 발생합니다. 만 활성화하는 모든 GPU 레코드에 적용AutoDetect되므로 모든 MIG 컴퓨팅 노드 그룹에 적용됩니다.

노드가 처음 등록되기 전에 할당된 작업은 GPU 없이 시작할 수 있습니다.

전원이 꺼지고 새로 생성된 컴퓨팅 노드 그룹의 첫 부팅과 같이 등록된 적이 없는 노드에 할당된 작업에는 프로파일 수가 부여되지만 디바이스를 아직 알 수 없기 때문에 특정 디바이스가 부여되지 않습니다. 노드가 부팅되고 작업이 시작되면 작업에 MIG 디바이스가 할당되지 않습니다. CUDA_VISIBLE_DEVICES는 설정되지 않으며, AWS PCS는 cgroup을 통한 디바이스 액세스를 제한하지 않으므로 작업은 노드의 모든 MIG 디바이스를 사용할 수 있습니다. Slurm은 작업을 RUNNING 마치처럼 보고하며, 작업이 계수된 MIG 인스턴스는 해당 프로파일을 요청하는 다음 작업에 할당되므로 두 작업이 동일한 MIG 인스턴스에 도달할 수 있습니다. 이후 전원 끄기 및 전원 켜기 주기 이후를 포함하여 노드가 한 번 등록된 후 노드에 할당된 작업은 예상대로 디바이스를 가져옵니다.

이 조건을 감지하려면 CUDA_VISIBLE_DEVICES 설정된 작업이 시작될 때 확인하고, 그렇지 않은 경우 작업을 종료하거나 다시 대기열에 넣습니다.

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

다시 대기열에 추가된 작업은 스케줄requeue_delay러 파라미터 이후 기본적으로 5초 동안 다시 실행할 수 있습니다. 그러면 노드가 등록되므로 작업은 다음 시작 시 디바이스를 가져옵니다.