기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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 지원 인스턴스 유형을 사용하는 컴퓨팅 노드 그룹입니다.
+ Slurm 버전 25.11 이상.
+ 구성된 CPU 토폴로지입니다. GPU 자동 감지에는 노드의 소켓 레이아웃이 필요합니다. Slurm 25.11에서는 컴퓨팅 노드 그룹에 `Sockets` 대해를 설정하고, Slurm 26.05 이상에서는 AWS PCS가 자동으로 구성합니다. 자세한 내용은 [AWS PCS에서 하드웨어 토폴로지 구성](hardware-topology.md) 섹션을 참조하세요.
## 부팅할 때마다 MIG 노드에 있어야 하는 사항
MIG 모드 및 MIG 인스턴스는 디스크가 아닌 GPU에 상주하므로 사용자 지정 AMI는 이를 전달할 수 없으며 인스턴스가 중지, 일시 중지 또는 종료될 때마다 손실됩니다. 부팅할 때마다가 `slurmd` 시작되기 전에 다음 사항이 모두 true여야 합니다.
1. **MIG 모드는 MIG 인스턴스를 제공하는 모든 GPU에서 활성화됩니다**.는 `Current` 및 `Pending` 모드를 `nvidia-smi -q` 보고하며 여야 `Current` 합니다`Enabled`.
1. **MIG 인스턴스는** 컴퓨팅 노드 그룹 `Gres` 설정의 모든 프로파일에 대해 GPU 인스턴스와 컴퓨팅 인스턴스 모두 존재합니다.
1. **프로필과 개수는 설정과 일치**합니다. `Gres`
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-configuration-instances-nla) 방지합니다.
## 인스턴스에서 MIG 구성
인스턴스를 구성하려면 다음 두 가지 작업을 수행합니다. 노드 수명 주기 작업에서 실행하여 다시 빌드해야 하는 AMI 대신 컴퓨팅 노드 그룹에 로직을 유지합니다. [노드 수명 주기 작업을 사용하여 구성 적용](#mig-configuration-instances-nla) 섹션을 참조하세요. 다른 프로세스에 이미 GPU가 있는 경우 사용자 지정 AMI의 `cloud-init` 부트후크 또는 `systemd` 유닛에서 먼저 GPUs를 실행합니다. [MIG 모드가 보류 상태로 유지되는 경우](#mig-configuration-instances-pending) 섹션을 참조하세요. 명령에 대한 자세한 내용은 [NVIDIA 다중 인스턴스 GPU 사용 설명서를 참조하세요](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/).
1. GPUs에서 MIG 모드를 활성화합니다.
```
nvidia-smi -mig 1
```
프로세스가 GPUs를 사용하는 동안에는 모드 변경이 적용될 수 없습니다. `nodeBootstrapped` 스테이지`slurmd`가 시작되지 않았으므로 다른 GPU 서비스를 실행하지 않는 노드에서는 재부팅 없이 변경 사항이 적용됩니다. 적용된 모드가를 사용하는 모든 GPU`Enabled`에 있는지 확인합니다`nvidia-smi --query-gpu=mig.mode.current --format=csv`.
**중요**
MIG 모드가 로 유지되는 경우 `Pending`다른 프로세스에 GPU가 GPUs. [MIG 모드가 보류 상태로 유지되는 경우](#mig-configuration-instances-pending) 섹션을 참조하세요.
1. 원하는 프로파일에 대한 GPU 인스턴스 및 컴퓨팅 인스턴스를 생성합니다. 예를 들어 8GPUs를 각각 하나의 `3g.20gb`, 하나의 `2g.10gb`, 두 개의 `1g.5gb` 인스턴스로 분할하려면
```
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`는 숫자 프로필 IDs도 허용하지만, 동일한 ID는 다른 GPU 모델에서 다른 프로필을 의미합니다. `9,14,19,19`는 `p4d` 인스턴스의 40GB A100에서이 레이아웃이고 `3g.40gb`, `2g.20gb`및 80GB 파트`1g.10gb`의 2입니다. 프로필 이름을 사용하여 `Gres` 설정과 일치하고 해당 프로필이 없는 GPU에서 생성이 실패하도록 합니다.
예제와 같이 가장 큰 프로파일을 먼저 생성합니다. MIG 배치는 고정되어 있으므로 작은 프로파일이 큰 프로파일이 필요한 조각을 가져오는 경우에도 적합한 레이아웃이 생성되지 않을 수 있습니다.
### 노드 수명 주기 작업을 사용하여 구성 적용
다음과 같이 노드 수명 주기 작업을 구성합니다. 컴퓨팅 노드 그룹에 추가하는 방법은 단원을 참조하십시오[AWS PCS에서 노드 수명 주기 작업 구성](cng-node-lifecycle-actions-configure.md).
| **필드** | **값** | **이유** |
| --- | --- | --- |
| 수명 주기 단계 | `nodeBootstrapped` | 가 GPUs를 `slurmd` 열고 노드를 등록하기 전에 실행됩니다. |
| `executionPolicy` | `EVERY_BOOT` | MIG 상태는 중지, 일시 중지 또는 종료 후에도 유지되지 않습니다. |
| `arguments` | `["3g.20gb,2g.10gb,1g.5gb,1g.5gb"]` | 각 GPU에서 이름별로 생성할 MIG 프로파일입니다. 그러면 스크립트 하나가 레이아웃이 다른 컴퓨팅 노드 그룹을 제공합니다. |
| `onError` | `TERMINATE` | MIG 디바이스 없이 등록하는 대신 파티셔닝할 수 없는 노드를 대체합니다. 디버깅하는 동안 `STOP_SEQUENCE`를 사용하여 검사를 위해 인스턴스를 유지합니다. |
부팅할 때마다 실행되는 스크립트는 멱등성이어야 합니다. 다음 개요에서는 GPU당 레이아웃을 첫 번째 인수로 사용하고 한 번에 하나의 GPU를 처리합니다. 이미 해당 레이아웃이 있는 GPU를 건너뛰고, 다른 GPU를 재분할하고, 완료할 수 없는 경우 0이 아닌 GPU를 종료하여 노드에 실패합니다. 노드를 재부팅하지 않습니다. 인수가 스크립트에 도달하는 방법은 섹션을 참조하세요[스크립트에 인수 전달](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
```
한 번의 호출로 스크립트와 GRES 설정을 설정하려면의 예제를 참조하세요[Slurm에 MIG 프로파일 선언](#mig-configuration-slurm).
스크립트를 조정하는 경우 두 검사를 모두 유지합니다. 모드 확인이 없으면 MIG 모드가 되지 않은 노드`Enabled`가 MIG 디바이스 없이 등록되며, 원인은 `slurmd` 로그에만 표시됩니다. 레이아웃 검사가 없으면 잘못된 프로파일을 생성하는 노드가 정상적으로 등록되고 선언된 프로파일을 요청하는 작업만 실패합니다. 스크립트의 출력이 기록되는 위치는 섹션을 참조하세요[로깅 및 디버깅](cng-node-lifecycle-actions-configure.md#cng-node-lifecycle-actions-configure-logging).
### MIG 모드가 보류 상태로 유지되는 경우
MIG 모드 활성화는 모든 프로세스에 GPUs 열려 있는 동안 실패합니다.는 예를 들어를 사용하여 활성화를 보류 중으로 `nvidia-smi` 보고하며`In use by another client`, 해당 프로세스가 종료되거나 노드가 재부팅된 후에만 적용됩니다. AWS PCS 컴퓨팅 노드에서 프로세스는 일반적으로 NVIDIA DCGM 또는 AMI에 제공되는 에이전트와 같은 GPU 모니터링 에이전트이거나 시작 후 MIG가 구성된 경우 `slurmd` 자체입니다`slurmd`. 수명 주기 작업에서 재부팅할 수 없으므로 다음 수정 사항 중 하나를 사용합니다.
+ **GPUs.** 사용자 지정 AMI에서 MIG 구성이 실행되기 전에 GPUs를 여는 데몬을 비활성화하거나 제거합니다. 또한 MIG 자체를 구성하는 데몬도 제거합니다. 동일한 GPUs를 분할하는 두 구성 요소는 `Gres` 설정과 일치하지 않는 레이아웃을 생성합니다.
+ **부트후크에서 MIG를 구성합니다.** 프로세스를 중지할 수 없는 경우 MIG 모드 변경 및 프로필 생성을 시작 템플릿 사용자 데이터의 `cloud-init` 부트후크로 이동합니다. 부트후크는 AWS PCS 부트스트랩 전과 AMI의 서비스가 시작되기 전에 실행되므로 모드 변경은 재부팅 없이 적용됩니다. 작성 방법은 단원을 참조하십시오[예: cloud-init 부트후크를 사용하여 조기 부팅 작업 실행](working-with_ec2-user-data_early-boot.md). 수명 주기 작업을 검사로 유지합니다. 부팅할 때마다 레이아웃을 확인하고 부트후크가 이를 적용하지 않은 경우 노드에 실패합니다.
## Slurm에 MIG 프로파일 선언
컴퓨팅 노드 그룹에서 두 GRES 설정을 모두 선언합니다.
+ 에서는 만 활성화하는 `gresCustomSettings`GPU 레코드입니다`AutoDetect`. `Name`, `Type`또는를 설정하지 마십시오`File`. MIG 디바이스는 노드에서 검색됩니다.
+ 에서 MIG 프로파일을 선언하고 작업이 요청할 수 있는 수를 계산하는 `slurmCustomSettings` `Gres` 설정입니다. 프로필 이름과 수는 노드에서 생성된 MIG 인스턴스와 일치해야 합니다.
**Example - 한 번의 업데이트로 두 부분 모두 적용(각각 하나의 `3g.20gb`, 하나의 `2g.10gb`, 두 개의 로 분할된 GPUs 8개`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"
}
]
}
}'
```
이 예제에서는 `Gres` 값에 쉼표가 포함되어 있으므로 두 파라미터를 모두 JSON으로 전달합니다. 이러한 CLI 간편 구문에는 이스케이프가 필요합니다.
`arguments` 일관성 유지`Gres`: 8GPUs 각각`3g.20gb,2g.10gb,1g.5gb,1g.5gb`에서는 `gpu:3g.20gb:8,gpu:2g.10gb:8,gpu:1g.5gb:16` 선언하는 8, 8 및 16개의 인스턴스를 제공합니다.
두 설정 간의 제약 조건은 섹션을 참조하세요[gres.conf와 Gres 설정 간의 제약 조건](gres-custom-settings.md#gres-custom-settings-constraints). 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 레코드와 같은 경고`Ignoring file-less GPU gpu:3g.20gb from final GRES list`를 로깅합니다. 이는 다음과 같이 예상됩니다. 신뢰할 수 있는 GRES는 노드 등록에서 가져옵니다.
## 제한 사항
MIG 구성은 디바이스 이름을 지정하지 않으므로 컨트롤러는 노드가 부팅되고 등록된 후에만 노드의 실제 GRES를 알고 있습니다. 노드가 한 번 등록될 때까지 컨트롤러는 `Gres` 설정의 프로필 수만 보유합니다. 이로 인해 다음과 같은 제한이 발생합니다. 만 활성화하는 모든 GPU 레코드에 적용`AutoDetect`되므로 모든 MIG 컴퓨팅 노드 그룹에 적용됩니다.
**참고**
가장 좋은 방법은 MIG에 정적 컴퓨팅 노드 그룹을 사용하는 것입니다. 조정 구성`maxInstanceCount`에서를 `minInstanceCount`로 설정하는 것입니다. 그런 다음 노드가 시작될 때 작업이 할당되기 전에 노드가 등록되므로 제한이 발생하지 않습니다.
### 노드가 처음 등록되기 전에 할당된 작업은 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초 동안 다시 실행할 수 있습니다. 그러면 노드가 등록되므로 작업은 다음 시작 시 디바이스를 가져옵니다.