Multi-GPU Programming

PyTorch 의 자동 multi-GPU 추상 (DDP, FSDP) 이 너무 잘 도는 시대 — 그래서 사람들이 multi-GPU 프로그래밍의 기본 모델을 잊는다. 이 강의는 “PyTorch 가 우리 대신 무엇을 하고 있는가” 를 한 단계 아래에서 본다 — CUDA P2P, stream + event, NCCL collectives 의 layer 가 어떻게 쌓이는지.

강의 transcript 가 비어 있으므로 본 노트는 NVIDIA 의 multi-GPU programming 자료 (CUDA programming guide ch. 6, NCCL docs, GTC 강의), PyTorch distributed 자료, 그리고 일반적 GPU systems 자료 위에서 재구성한다. Markus 가 강의에서 강조한 정확한 demo / 코드는 영상 검증 필요.

single-GPU 프로그래밍의 가장 큰 추상 — host/device 의 두 메모리. multi-GPU 에서는 — 각 GPU 가 자기 HBM. 한 GPU 의 데이터를 다른 GPU 가 읽으려면 명시적 transfer. 이게 모든 distributed training / inference 의 cost 를 결정한다.

multi-GPU 통신은 layered. 같은 “GPU A 의 데이터를 GPU B 로” 가 — 어떤 layer 의 API 를 쓰느냐에 따라 다른 모양. 강의의 핵심 frame 중 하나가 이 layer 의 분리.

CUDA stream 은 order constraint 의 단위. 같은 stream 안의 일은 순서대로, 다른 stream 끼리는 병렬. multi-GPU 에서는 각 GPU 가 자기 stream 을 갖는다. cross-GPU 동기화를 위해 event 를 쓴다.

# GPU 0 의 결과를 GPU 1 이 기다린다
with torch.cuda.device(0):
    out0 = layer0(x)
    e0 = torch.cuda.Event()
    e0.record()                  # GPU0 stream 에 마커

with torch.cuda.device(1):
    e0.wait()                    # GPU1 stream 이 e0 끝까지 대기
    # 이 시점부터 out0 는 GPU1 위에 visible
    out1 = layer1(out0.to(1))

CUDA 의 UVA (Unified Virtual Addressing) 가 깐 추상 — 같은 process 안의 모든 GPU 메모리 + host 메모리가 한 가상 주소 공간. cudaMemcpyAsync 가 src/dst 의 device 를 자동 추론. cudaIPC 가 다른 process 의 GPU 메모리를 우리 process 가 보게 해줌 — vLLM 같은 multi-process 시스템의 기반.

• UVA: 한 process 안에서 device 0, 1, …, host 가 같은 64-bit 주소 공간. cudaPointerGetAttributes(ptr) 로 어디 주소인지 확인 가능. peer access 가 켜진 GPU 끼리는 서로의 주소를 직접 dereference.
• cudaIPC handle: 다른 process 가 우리의 GPU buffer 를 보게 하는 token. cudaIpcGetMemHandle / cudaIpcOpenMemHandle. socket 으로 주고받음.
• CUDA 12.3+ 의 multicast: Hopper 에서 NVLink + NVSwitch 의 multicast support. 한 GPU 의 data 가 N GPU 에 broadcast 될 때 BW × N 효과.

UVA / IPC 는 — distributed training 의 high-level NCCL 위로 잘 안 보이지만, KV transfer / disaggregation / inference 시스템에서 자주 등장. 한 단계 더 들어가면 직접 만지게 되는 자리.

실제 production 모델 학습은 거의 항상 — DP × TP × PP 의 hybrid. 예를 들어 H100 256-GPU 클러스터에서 70B Llama 학습 — DP=8 × TP=8 × PP=4. 각 axis 가 다른 collective 패턴.

• deadlock — collective 호출 mismatch: rank 0 가 all_reduce(A), rank 1 이 all_reduce(B). 두 텐서 shape 다름. NCCL 이 영원히 대기. 해결 — 모든 rank 가 같은 collective 를 같은 shape 로 호출.
• cross-GPU stale data: cudaMemcpyPeer 후 sync 없이 다음 커널 launch. 새 GPU 가 옛 데이터를 본다. 해결 — event 로 dependency 표현.
• default stream 의 blocking: 같은 GPU 의 default stream 과 사용자 stream 이 implicit sync. comm 이 직렬화. 해결 — 사용자 stream 만 사용 (PYTORCH_NO_CUDA_MEMORY_CACHING 등 환경변수).
• NCCL 의 hidden host sync: 일부 collective 는 host 동기화를 자동 호출. timeline 위에 보이지 않게 latency 추가. 해결 — NCCL_DEBUG=TRACE 로 확인.
• topology mismatch: NCCL 이 PCIe 로 통신해야 할 때 (peer access 미설정) — NVLink 가 있는데도 PCIe 사용. 10× 느림. 해결 — nvidia-smi topo -m 으로 topology 확인.
• memory fragmentation: 많은 small allocation 후 큰 alloc 실패. 해결 — caching allocator (PYTORCH_CUDA_ALLOC_CONF 튜닝).
• cudaIPC 의 process lifetime: handle 이 source process 보다 오래 살면 dangling. 해결 — handle 의 명시적 close.

# NCCL 의 표준 micro-benchmark
$ NCCL_DEBUG=INFO mpirun -np 8 ./build/all_reduce_perf -b 8 -e 256M -f 2

# 출력 (대략)
   size    count   busbw (peak)   time(us)
       8        2        0.00         12.5
   1024K    256K       145.34        720.8
  16384K   4194K       210.50       19200    # peak 의 87%
 268435K   67108K      218.34      230000

• NVLink (intra-node) 900 GB/s → InfiniBand NDR (inter-node) 50 GB/s. 거의 18×. 같은 collective 가 cross-node 면 18× 느림.
• GPUDirect RDMA — GPU 의 HBM 이 InfiniBand HCA 로 직접 DMA. CPU memory 거치지 않음. 표준 multi-node training 의 baseline. 안 켜져 있으면 host memory 우회로 50% 더 느림.
• SHARP (Scalable Hierarchical Aggregation and Reduction Protocol) — InfiniBand switch 안에서 reduce 의 일부를 수행. 8 GPU 가 16 GPU 로 all-reduce 할 때 switch 가 일부 합쳐줘서 BW 효율 향상.
• topology-aware collective — NCCL 이 자동으로 ring / tree algorithm 선택. 작은 메시지는 LL (low-latency), 큰 건 ring 으로.
• fault tolerance — multi-node 면 한 node 가 죽을 가능성. NCCL 의 default 는 fail-stop. fault-tolerant 학습은 직접 checkpointing.

손에 새기기 — 실습 시퀀스

1. nvidia-smi topo -m — 자기 시스템의 GPU topology 확인. NVLink 연결, NUMA 도메인, PCIe path.
2. nccl-tests all-reduce — 자기 시스템의 baseline BW. peak 의 80%+ 도달 못 하면 topology 문제.
3. P2P memcpy 직접 — cudaMemcpyPeerAsync 로 GPU 0 → GPU 1 transfer. nsys 로 NVLink 사용 확인.
4. DDP toy training — 4-GPU 로 ResNet 학습. NCCL_DEBUG=INFO 로 collective trace.
5. FSDP 70B 시도 — 8-GPU 로 70B Llama. param shard / gather pattern 의 timeline 확인.
6. TP × DP hybrid — 8 GPU 를 4 TP × 2 DP. Megatron-LM 또는 PyTorch native 로.
7. cross-node 시도 — 두 노드 사이 InfiniBand. 같은 collective 가 노드 안 vs 노드 사이 BW 비교.
8. collective mismatch deadlock 재현 — rank 별 다른 shape 의 all-reduce 호출. 의도적으로 deadlock. NCCL 의 timeout / hang 동작 확인.

• 강의의 정확한 demo / code — Markus 가 강의에서 보여준 구체 예제는 transcript 없어 미확인. NVIDIA 의 multi-GPU sample (cuda-samples 의 simpleP2P 등) 후보.
• NVLink 의 정확한 BW 수치 — 본 노트의 900 GB/s 는 H100. B200 은 1800 GB/s, 그 위 generation 은 더. 정확한 수치는 generation 마다 검증.
• NCCL 2.x 의 새 기능 — SHARP, multi-node optimization, NIXL 통합 — 강의 시점의 NCCL 버전이 어디까지 다뤘는지 미확인.
• PyTorch 2.x 의 native parallel API — DTensor, FSDP2 같은 새 추상 — 강의에서 언급 정도 미확인.
• fault tolerance — 강의에서 fail-recover / elastic 학습 frame 까지 갔는지. 큰 cluster 에서 점점 중요해지는 자리.
• 실제 production 사례 — Markus 가 어떤 customer 의 production 학습 시스템 디버깅 경험을 공유했는지 — vendor talk 의 가치.
• multi-node 의 실전 디테일 — InfiniBand 세대 (HDR/NDR/XDR), GPUDirect Storage, NCCL_NET_PLUGIN 등 — 강의 깊이 미확인.