During multi-node HPL burn-in, GPUs show uneven utilization.
Which configuration ensures balanced workload distribution?
- A. HPL_RUN_GEMM_TESTS to skip validation
- B. Set --gpu-affinity and --cpu-affinity to align GPU and NUMA nodes
- C. HPL_OOC_TILE_M to 8192 for larger blocks
- D. Enable HPL_USE_NVSHMEM=1 for shared memory acceleration
멀티노드 HPL 번인 테스트 중 GPU 사용률이 고르지 않게 나타납니다.
어떤 구성이 균형 잡힌 워크로드 분배를 보장할까요?
- A. HPL_RUN_GEMM_TESTS를 사용하여 유효성 검사를 건너뛰세요 .
- B. GPU 및 NUMA 노드를 정렬하려면 --gpu-affinity 및 --cpu-affinity 옵션을 설정하십시오.
- C. 더 큰 블록의 경우 HPL_OOC_TILE_M을 8192로 변경
- D. 공유 메모리 가속을 위해 HPL_USE_NVSHMEM=1을 활성화합니다.
정답은 B. --gpu-affinity와 --cpu-affinity를 맞춰 GPU와 NUMA 노드를 정렬하는 것입니다. ✅
이 문제는 멀티노드 HPL burn-in에서 GPU 사용률이 들쭉날쭉할 때, workload를 어떻게 균형 있게 배치하느냐를 묻습니다.
NVIDIA HPL 문서도 --gpu-affinity, --cpu-affinity, --mem-affinity 옵션을 제공하고, GPU당 MPI process 1개를 기대한다고 설명합니다. 또한 NUMA locality가 맞지 않으면 성능 저하가 생길 수 있습니다. NVIDIA Docs
쉽게 말하면
서버 안에는 CPU와 GPU가 그냥 랜덤하게 연결된 게 아닙니다.
예를 들어:
NUMA Node 0
├─ CPU Core 0~55
├─ GPU0
├─ GPU1
├─ GPU2
└─ GPU3
NUMA Node 1
├─ CPU Core 56~111
├─ GPU4
├─ GPU5
├─ GPU6
└─ GPU7
이런 식으로 GPU마다 가까운 CPU/메모리 영역이 있습니다.
그런데 프로세스가 이렇게 배치되면:
GPU0 ← 멀리 있는 CPU Core 사용
GPU1 ← 가까운 CPU Core 사용
GPU2 ← 멀리 있는 CPU Core 사용
GPU3 ← 가까운 CPU Core 사용
GPU별 데이터 공급 속도가 달라질 수 있습니다.
그러면:
GPU0 Util 95%
GPU1 Util 70%
GPU2 Util 98%
GPU3 Util 65%
처럼 uneven utilization이 발생할 수 있습니다.
그래서 Affinity를 맞춥니다
Affinity는 쉽게 말하면:
“이 GPU 작업은 이 CPU 코어 쪽에서 처리해.”
라고 위치를 고정하는 것입니다.
예를 들어 DGX H100에서 NVIDIA는 CPU affinity 예시를 다음과 같이 제공합니다.
GPU0 → CPU 0-13
GPU1 → CPU 14-27
GPU2 → CPU 28-41
GPU3 → CPU 42-55
GPU4 → CPU 56-69
GPU5 → CPU 70-83
GPU6 → CPU 84-97
GPU7 → CPU 98-111
이렇게 topology에 맞춰 CPU/GPU를 매핑하면 불필요한 NUMA crossing을 줄이고 workload를 더 균등하게 처리할 수 있습니다. NVIDIA Docs
NUMA가 뭐야?
NUMA = Non-Uniform Memory Access
초보자식으로는:
CPU마다 가까운 메모리와 먼 메모리가 있는 구조
라고 이해하면 됩니다.
CPU 0 ─ 가까움 ─ Memory 0
│
└──── 멀리 ─── Memory 1
CPU 1 ─ 가까움 ─ Memory 1
가까운 메모리를 쓰는 게 더 빠릅니다.
GPU도 마찬가지로 특정 CPU/NUMA node와 더 가깝습니다.
그래서:
CPU
+
Memory
+
GPU
를 topology에 맞춰 묶어주는 게 중요합니다.
✅ B가 정답인 이유
B:
Set --gpu-affinity and --cpu-affinity to align GPU and NUMA nodes
즉:
GPU 위치 확인
↓
가까운 CPU/NUMA 확인
↓
GPU ↔ CPU affinity 설정
↓
MPI rank 균형 배치
↓
GPU utilization 균형 개선
입니다.
NVIDIA 문서도 NUMA 시스템에서 프로세스 placement가 잘못되면 성능에 심각한 영향을 줄 수 있다고 설명합니다. NVIDIA Docs
❌ A. HPL_RUN_GEMM_TESTS
GEMM test를 실행하거나 검증하는 설정이지 GPU workload placement를 조정하는 옵션이 아닙니다.
즉:
GEMM Test
≠
GPU/CPU Affinity
입니다.
❌ C. HPL_OOC_TILE_M=8192
HPL_OOC_TILE_M은 HPL의 Out-of-Core row blocking factor입니다.
NVIDIA 문서상 기본값은 4096이며 OOC 연산의 tile 크기를 조정하는 옵션입니다. NVIDIA Docs
즉:
메모리 처리 block 크기
와 관련된 것이지:
GPU별 workload 균형
을 직접 해결하는 설정은 아닙니다.
❌ D. HPL_USE_NVSHMEM=1
NVSHMEM은 GPU 간 통신/메모리 접근을 가속하는 기술입니다.
하지만 문제는:
GPU마다 utilization이 불균형하다
입니다.
이럴 때 먼저 확인해야 하는 건:
GPU ↔ CPU ↔ NUMA topology
입니다.
NVSHMEM을 켜는 것만으로 CPU/GPU affinity 문제를 해결할 수는 없습니다.
시험용 암기
이 문제에서는:
Uneven GPU Utilization
을 보면 바로:
Affinity
↓
CPU / GPU / NUMA
를 떠올리세요.
한 줄 암기
HPL에서 GPU 사용률 불균형 → --gpu-affinity + --cpu-affinity로 NUMA locality 맞추기
Question #15 정답: B ✅
특히 NCP-AII에서는 NUMA, CPU affinity, GPU affinity가 같이 나오면 거의 항상 **“가까운 자원을 서로 묶어서 성능 균형을 맞춘다”**는 방향으로 이해하면 됩니다.
==============================
실제 운영에서는 보통 Slurm srun + NVIDIA hpl.sh + GPU/CPU/Memory affinity를 한 번에 지정합니다.
먼저 중요한 점은 DGX H100의 공식 affinity 값과 일반 H200 8-GPU 서버의 값은 다를 수 있다는 것입니다. CPU 코어 수, NUMA 구성, PCIe/NVLink topology가 서버마다 다르므로 운영 장비에서는 topology를 확인한 뒤 넣어야 합니다.
1. DGX H100 1대라면 예시는 이렇게 됩니다
srun -N 1 \
--ntasks-per-node=8 \
--cpu-bind=none \
--mpi=pmix \
./hpl.sh \
--dat ./HPL.dat \
--gpu-affinity 0:1:2:3:4:5:6:7 \
--cpu-affinity 0-13:14-27:28-41:42-55:56-69:70-83:84-97:98-111 \
--mem-affinity 0:0:0:0:1:1:1:1
NVIDIA가 DGX H100에 제시하는 공식 CPU/Memory affinity 예시는 다음과 같습니다. 또한 HPL은 GPU 하나당 MPI process 하나를 사용하는 구조를 전제로 합니다. NVIDIA Docs
핵심은:
GPU0 → CPU 0-13 → NUMA 0
GPU1 → CPU 14-27 → NUMA 0
GPU2 → CPU 28-41 → NUMA 0
GPU3 → CPU 42-55 → NUMA 0
GPU4 → CPU 56-69 → NUMA 1
GPU5 → CPU 70-83 → NUMA 1
GPU6 → CPU 84-97 → NUMA 1
GPU7 → CPU 98-111→ NUMA 1
이렇게 맞춰주는 겁니다.
2. 명령어를 하나씩 보면
-N 1
-N 1
노드 1대를 사용합니다.
멀티노드 4대라면:
-N 4
가 됩니다.
--ntasks-per-node=8
--ntasks-per-node=8
노드당 MPI process를 8개 실행합니다.
DGX H100은 GPU가 8장이므로:
MPI Rank 0 → GPU0
MPI Rank 1 → GPU1
...
MPI Rank 7 → GPU7
의 구조를 만드는 겁니다.
NVIDIA HPL은 1 GPU = 1 MPI process를 권장합니다. NVIDIA Docs
3. --gpu-affinity
--gpu-affinity 0:1:2:3:4:5:6:7
뜻은 간단합니다.
Rank 0 → GPU0
Rank 1 → GPU1
Rank 2 → GPU2
Rank 3 → GPU3
Rank 4 → GPU4
Rank 5 → GPU5
Rank 6 → GPU6
Rank 7 → GPU7
즉:
MPI 작업 하나당 GPU 하나를 고정한다.
라고 이해하면 됩니다.
4. --cpu-affinity
이게 Question #15에서 가장 중요한 부분입니다.
--cpu-affinity \
0-13:14-27:28-41:42-55:56-69:70-83:84-97:98-111
콜론 : 기준으로 8개 그룹입니다.
GPU0 작업 → CPU 0~13
GPU1 작업 → CPU 14~27
GPU2 작업 → CPU 28~41
GPU3 작업 → CPU 42~55
GPU4 작업 → CPU 56~69
GPU5 작업 → CPU 70~83
GPU6 작업 → CPU 84~97
GPU7 작업 → CPU 98~111
즉 GPU마다 자기 근처 CPU Core를 전담 배정하는 겁니다.
5. --mem-affinity도 같이 쓰는 게 좋습니다
실제 운영에서는 CPU affinity만 맞추기보다 NUMA Memory까지 같이 맞추는 게 더 정확합니다.
DGX H100 공식 예:
--mem-affinity 0:0:0:0:1:1:1:1
뜻은:
GPU0 → NUMA Memory 0
GPU1 → NUMA Memory 0
GPU2 → NUMA Memory 0
GPU3 → NUMA Memory 0
GPU4 → NUMA Memory 1
GPU5 → NUMA Memory 1
GPU6 → NUMA Memory 1
GPU7 → NUMA Memory 1
입니다. NVIDIA도 DGX H100/B200에 이 CPU/Memory affinity mapping을 예제로 제공합니다. NVIDIA Docs
그래서 실제 구조는:
MPI Rank 0
├─ GPU0
├─ CPU 0-13
└─ NUMA 0
MPI Rank 1
├─ GPU1
├─ CPU 14-27
└─ NUMA 0
...
MPI Rank 7
├─ GPU7
├─ CPU 98-111
└─ NUMA 1
이 됩니다.
6. 4개 노드라면?
노드당 H100/H200 8장이고 4개 노드를 사용하는 경우라면:
srun -N 4 \
--ntasks-per-node=8 \
--cpu-bind=none \
--mpi=pmix \
./hpl.sh \
--dat ./HPL.dat \
--gpu-affinity 0:1:2:3:4:5:6:7 \
--cpu-affinity 0-13:14-27:28-41:42-55:56-69:70-83:84-97:98-111 \
--mem-affinity 0:0:0:0:1:1:1:1
그러면 전체적으로:
4 Nodes
×
8 GPUs
= 32 GPU
= 32 MPI ranks
가 됩니다.
각 노드 내부에서는 동일한 affinity mapping이 적용됩니다.
7. 그런데 H200 × 8 서버에서는 그대로 쓰면 안 됩니다 ⚠️
이 부분이 중요합니다.
사용 중인 환경이 H200 × 8 / node, 해당 서버가 DGX H100과 CPU/NUMA topology가 같다는 보장은 없습니다.
먼저 아래 세 가지를 확인하는 게 좋습니다.
GPU ↔ CPU ↔ NIC topology
nvidia-smi topo -m
예:
GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7 CPU Affinity NUMA
GPU0 X NV NV NV SYS SYS SYS SYS 0-31 0
GPU1 NV X NV NV SYS SYS SYS SYS 0-31 0
...
GPU4 SYS SYS SYS SYS X NV NV NV 32-63 1
여기서 특히:
CPU Affinity
NUMA Affinity
를 봅니다.
NUMA 구조
numactl -H
예:
available: 2 nodes (0-1)
node 0 cpus: 0-55
node 1 cpus: 56-111
CPU topology
lscpu -e=CPU,NODE,SOCKET,CORE
이 세 가지 결과를 기준으로 affinity를 만들어야 합니다.
8. 예를 들어 H200 서버가 이런 구조라면
가정:
NUMA 0
CPU 0-63
GPU0 GPU1 GPU2 GPU3
NUMA 1
CPU 64-127
GPU4 GPU5 GPU6 GPU7
그렇다면 예를 들어:
--gpu-affinity 0:1:2:3:4:5:6:7
와:
--cpu-affinity \
0-15:16-31:32-47:48-63:64-79:80-95:96-111:112-127
그리고:
--mem-affinity \
0:0:0:0:1:1:1:1
처럼 구성할 수 있습니다.
다만 이건 예시일 뿐, 실제 H200 노드에서 nvidia-smi topo -m 결과를 보고 맞춰야 합니다.
🎯 실제 운영 절차는 이렇게 생각하면 됩니다
1. nvidia-smi topo -m
↓
GPU ↔ CPU ↔ NUMA 위치 확인
2. numactl -H
↓
NUMA별 CPU 확인
3. GPU별 CPU Core 배분
↓
4. --gpu-affinity
--cpu-affinity
--mem-affinity 설정
↓
5. HPL 실행
↓
6. nvidia-smi / DCGM으로
GPU Util 균형 확인
시험용 한 줄
HPL 불균형 → GPU/CPU/NUMA topology 확인 → --gpu-affinity + --cpu-affinity + --mem-affinity
NVIDIA 공식 hpl.sh가 이 세 옵션을 모두 지원하며, DGX H100 기준 CPU affinity는 0-13:14-27:...:98-111, memory affinity는 0:0:0:0:1:1:1:1 예시를 제공합니다. NVIDIA Docs
댓글