Topology-Aware Scheduling의 필요성
HPC나 대규모 GPU 클러스터 환경에서 단순히 “GPU 몇 개”라는 요청만으로 Job을 스케줄링하는 것은 충분하지 않습니다. 특히 NVIDIA NVLink, NVSwitch, CPU의 NUMA(Node-Local Memory Access) 구조가 얽힌 복잡한 하드웨어 토폴로지에서는 **리소스의 위치(Locality)**가 성능을 좌우합니다.
예를 들어 동일한 8개 GPU 서버라도 NVLink로 직접 연결된 GPU 쌍에 Job을 배치하는 경우와 PCIe Root Complex를 여러 번 거쳐야 하는 경우는 통신 지연(latency)과 대역폭 차이에서 20~40% 이상의 성능 차이가 발생합니다.
실제 딥러닝 학습에서는 AllReduce 통신 패턴이 빈번하게 발생합니다. GPU 간 토폴로지를 고려하지 않으면 통신 병목으로 인해 수십 노드 학습이 비효율적으로 동작합니다. 따라서 Topology-Aware Scheduling은 단순한 Job 배치가 아닌 성능 보장을 위한 필수 전략입니다.
NVLink/NVSwitch/NUMA Awareness 구조
현대 GPU 서버는 CPU NUMA 도메인과 GPU 연결 구조가 혼재되어 있습니다. 이를 간단히 정리하면 다음과 같습니다.
| 구성 요소 | 설명 |
| NUMA Node | CPU 소켓 단위로 메모리 접근 속도 차이가 발생하며 GPU가 어느 소켓에 연결되어 있는지가 중요합니다. |
| PCIe Root Complex | GPU가 연결되는 경로이며, 동일 Root Complex 하에 있는 GPU 간 통신이 상대적으로 빠릅니다. |
| NVLink | GPU 간 고속 직결 링크로, P2P 통신에서 PCIe 대비 수 배 높은 대역폭을 제공합니다. |
| NVSwitch | 다수 GPU 간 풀 메쉬(Full Mesh) 연결을 제공하는 스위치로, A100/H100 기반 DGX 시스템의 핵심 요소입니다. |
| NUMA-Aware Placement | CPU와 GPU 자원의 물리적 근접성을 고려한 Job 할당 전략을 의미합니다. |
이 구조를 Slurm 23.x와 같은 최신 스케줄러는 gres.conf, topology.conf를 통해 인식합니다. 또한 NVIDIA의 nvidia-smi topo -m 명령으로 실제 하드웨어 연결 상태를 확인할 수 있습니다.
# GPU Topology 확인
nvidia-smi topo -m
배치 전략과 데이터 흐름
Topology-Aware Scheduling의 핵심은 Job 요청 시 단순히 GPU 개수만 지정하는 것이 아니라, 연결 구조까지 고려한 배치를 수행하는 것입니다. 예를 들어 4개의 GPU가 필요한 학습 Job이라면 NVLink로 완전히 연결된 GPU 그룹을 배정하는 것이 이상적입니다.
# NVLink로 연결된 4-GPU 그룹 배정 예시
srun --gres=gpu:4 \
--ntasks=4 \
--cpus-per-task=8 \
--distribution=block:cyclic \
--hint=nomultithread \
python train.py이 경우 Slurm은 topology.conf에 정의된 GPU 간 연결성을 참고해 최적 조합을 찾습니다. 또한 NUMA-Aware Placement를 위해 --mem-bind 옵션을 활용하면 CPU 메모리 접근 지연을 줄일 수 있습니다.
실제 적용 사례
- NVIDIA DGX A100 시스템: NVSwitch 기반으로 8개 GPU가 모두 풀 메쉬로 연결되어 있어 배치 제약이 적습니다. 다만 CPU NUMA 도메인을 고려해 메모리 접근을 최적화해야 합니다.
- 하이브리드 GPU 서버: 일부 GPU만 NVLink로 연결된 환경(예: PCIe GPU + NVLink GPU 혼합)에서는 분산 학습 Job을 실행할 때 반드시 NVLink 그룹을 우선 배정해야 성능 저하를 방지할 수 있습니다.
- 대규모 연구기관: 기상 예측 모델 학습에서 1,000개 이상의 GPU를 사용하는 사례에서는 노드 내부 NVLink 최적화와 노드 간 InfiniBand Topology Awareness를 결합하여 효율성을 극대화합니다.
장점과 단점
장점
- GPU 통신 효율을 극대화하여 학습 시간을 단축합니다.
- NUMA-Aware 배치를 통해 CPU 메모리 병목을 줄입니다.
- 자원 활용률을 높여 동일한 자원으로 더 많은 Job을 소화합니다.
단점
- 스케줄러 설정 복잡도가 증가합니다 (topology.conf, gres.conf 관리 필요).
- 특정 토폴로지를 선호하면 Job 대기 시간이 길어질 수 있습니다.
- 이기종 클러스터 환경(서버별 NVLink 구조 상이)에서는 정책 설계가 까다롭습니다.
실무 팁과 주의사항
- Topology Mapping 필수화
- 클러스터 도입 시 nvidia-smi topo -m 결과를 문서화하고 Slurm topology.conf에 반영하는 것이 중요합니다.
- 테스트 벤치마크 수행
- 단순 배치와 Topology-Aware 배치의 성능 차이를 nccl-tests로 검증하면 운영팀과 사용자 모두 납득할 수 있습니다.
- Job 대기 시간 관리
- 특정 토폴로지 그룹만 선호하면 Queue가 길어질 수 있으므로, QoS와 Fairshare 정책을 병행해 사용자 기대치를 관리해야 합니다.
- NUMA + GPU Placement 동시 고려
- GPU만 최적화하고 CPU 메모리를 무시하면 성능이 제한됩니다. --mem-bind와 --cpu-bind를 적절히 조합해야 합니다.
# NUMA와 GPU Placement 동시 고려 예시
srun --gres=gpu:2 \
--cpus-per-task=16 \
--mem-bind=local \
--cpu-bind=cores \
python inference.py
정리하며
Topology-Aware Scheduling은 HPC/GPU 클러스터에서 성능을 보장하는 핵심 전략입니다. NVLink와 NVSwitch, NUMA 구조를 올바르게 인지하고 배치 전략을 수립하지 않으면 고가의 GPU 자원이 제 성능을 발휘하지 못합니다.
운영자는 스케줄러 설정과 Job 제출 정책을 최적화하고, 사용자에게 올바른 가이드라인을 제공함으로써 토폴로지 기반 최적화를 체계적으로 정착시켜야 합니다. 이는 단순한 Job 스케줄링을 넘어 **클러스터 전체 TCO(Total Cost of Ownership)**를 낮추는 운영 전략으로 이어집니다.