한 강의 안에 NCCL · NVSHMEM · MSCCL · MPI · Gloo · UCC · GPUDirect · IBGDA 가 모두 들어간다. Didem Unat 의 이 강의는 — 개별 라이브러리의 깊이가 아니라 — GPU 중심 통신 생태계의 좌표계를 그린다. 어디에 무엇이 있는지, 무엇이 무엇을 대체하지 않고 보완하는지, 어떤 axis 로 비교해야 하는지. 학술 survey 의 정신으로 깐 강의.
2024-2025 시스템 페이퍼를 읽다 보면 라이브러리 이름이 폭발적으로 늘어난다. NCCL · MSCCL · NVSHMEM · UCC · UCX · Gloo · MPI · oneCCL · RCCL · NCCL-Net · IBGDA · GPUDirect Storage. 각자 정확히 어디에 있고 무엇을 약속하는가? 강의의 답은 한 장의 좌표계다.
Didem 이 깐 좌표계의 두 축.
communication shape — collective (모두 참여) vs P2P / one-sided (한 쪽 참여)
스택 레이어 — application API → algorithm → transport → hardware
이 두 축 위에 모든 라이브러리가 정확한 위치를 가진다. 같은 점에 두 라이브러리가 있으면 경쟁, 다른 점에 있으면 상보. 이 분리 자체가 강의의 가장 큰 가치.
강의의 인지적 frame
“라이브러리 이름이 너무 많다” 는 사실 중요한 신호다 — 해결되지 않은 trade-off 가 많다는 뜻. 한 도구로 모두 풀리면 다른 도구가 안 만들어진다. 따라서 각 라이브러리가 어떤 trade-off 의 어느 쪽에 서 있는지 보면, 도메인의 미해결 문제가 보인다.
“같은 NVLink 위에 4-5개 라이브러리가 도는 건 비효율이 아니다 — 다른 패턴을 약속하는 다른 추상이 필요하다는 신호다.”강의 §1 재구성
§ 02collective vs P2P 정리· Two communication shapes
모든 GPU 통신은 결국 두 모양 중 하나로 환원된다
다양한 라이브러리가 등장해도 본질적으로 약속하는 communication shape 는 두 가지. collective — 미리 정해진 그룹의 모든 GPU 가 같은 일에 참여. P2P / one-sided — 한 GPU 가 다른 한 GPU 에 직접 access.
미리 컴파일된 알고리즘 그래프. MSCCL / MSCCL++ 가 대표 — 사용자가 directed graph 로 알고리즘을 적고 NCCL 위에 올림. 표준 collective 가 못 잡는 패턴 (e.g., latency-critical alltoall).
shape 2.5 · streaming P2P
async-capable P2P
cudaMemcpyPeerAsync, GPUDirect P2P, NVLink direct load/store. hardware-supported P2P 의 가장 raw 한 형태. 라이브러리 추상이 거의 없음.
왜 두 개를 모두 가지는가
collective 는 “비슷한 패턴이 반복” 인 경우의 BW 효율을, P2P 는 “불규칙하거나 작은 메시지” 의 latency 효율을 제공한다. ML workload 의 양면이 모두 등장하기 때문에 둘 다 필요하다 — 학습 루프의 gradient sync 는 collective, MoE expert dispatch 는 P2P.
“collective 는 ‘버스 시간표’, P2P 는 ‘우버’. 둘 다 같은 도시에서 도는 이유와 같은 이유로 GPU 클러스터에 둘 다 있다.”학습 노트
collective 한 shape 안에서도 라이브러리 별로 약속이 다르다. NCCL 의 자동 topology 최적화, MSCCL 의 사용자 정의 알고리즘, MPI 의 multi-vendor 호환성, Gloo 의 CPU fallback. 같은 함수 시그너처라도 안에서 무엇을 하는지가 다르다.
FIG · collective 라이브러리 11 차원 비교같은 shape, 다른 trade-off
라이브러리벤더backend강점위치
NCCLNVIDIACUDA속도, topology기본
RCCLAMDHIPNCCL API 호환AMD 의 NCCL
MSCCL / MSCCL++MS / NVIDIACUDA사용자 정의 알고리즘NCCL 위 layer
PyTorch 에서 backend='nccl' 또는 'gloo' 또는 'mpi' 를 고르면 그 backend 의 collective 가 호출된다. PyTorch 는 추상이고, NCCL/Gloo/MPI 는 구현. 같은 all_reduce 호출이 backend 마다 다른 알고리즘으로 풀린다.
MSCCL — collective 를 코드처럼 적는 시도
MSCCL 의 의의는 — collective 알고리즘이 더 이상 라이브러리에 박힌 black box 가 아니라, 사용자가 작성하는 그래프가 된다는 점. chunk → connection → step 으로 각 단계의 데이터 이동을 명시적으로 적는다. NCCL 이 자동으로 골라주지 못하는 패턴 (예: 비대칭 토폴로지 위의 alltoall) 을 직접 짤 수 있다. Microsoft 의 large-scale 학습 인프라에서 시작해 NVIDIA 가 MSCCL++ 로 흡수.
실전 가이드
처음에는 NCCL 만 쓴다. 토폴로지가 표준 (DGX, single rail IB) 이면 NCCL 이 자동으로 잘 푼다. 비표준 토폴로지나 NCCL 이 잘 못 푸는 패턴이 등장하면 그때 MSCCL 또는 NVSHMEM. 처음부터 다 쓰지 말 것.
§ 04RDMA · GPUDirect · NVSHMEM 의 위치· The transport stack
“라이브러리” 와 “transport” 를 헷갈리지 않는다 — 4 layer stack
또 다른 흔한 혼동 — NCCL 과 RDMA 와 GPUDirect 가 같은 레벨인가? 답은 아니다. 셋은 서로 다른 layer 에 있다. 강의의 큰 frame: application API → collective algorithm → transport → hardware 의 4 layer.
FIG · GPU communication 의 4 layer stack매핑이 명확해진다
NCCL 은 L2 에 있고, GPUDirect/RDMA 는 L3에 있다. NCCL 이 GPUDirect RDMA 를 transport 로 “쓴다”. 같은 NCCL 호출이 노드 안에서는 GPUDirect P2P, 노드 사이는 GPUDirect RDMA 를 자동 선택.
이 stack 의 핵심 통찰 — 같은 layer 안에서는 라이브러리들이 경쟁, 다른 layer 사이에서는 의존. NCCL 은 NVSHMEM 과 같은 layer 에서 다른 약속을 한다 (L2). NCCL 은 GPUDirect (L3) 위에 의존한다.
GPUDirect 가 정확히 무엇인가
GPUDirect 는 단일 라이브러리가 아니라 NVIDIA driver 의 기능 모음. 세 가지 주요 변종 — P2P (같은 PCIe root 의 GPU 사이 직접 transfer), RDMA (NIC 가 host CPU 우회 GPU 메모리 access), Async / IBGDA (GPU 가 직접 IB verbs 발행). 각자 transport layer 의 일부.
§ 05DGX topology 매핑· Where the wires are
같은 “8 GPU 노드” 안에서도 link 의 모양이 다르다
topology 는 algorithm 의 전제. 같은 8 GPU 노드라도 — DGX-1 (P100, ring NVLink), DGX-2 (V100, NVSwitch), DGX-A100 (A100, fully-connected NVSwitch), DGX-H100 (NVLink 4 + NVSwitch), DGX B200 (NVLink 5 + 더 큰 NVSwitch), GB200 NVL72 (72 GPU 의 NVLink fabric) — 모두 다르다.
GB200 NVL72 (2025)B200 ×72rack-scale NVLink~1.8 TB/s 가능노드/랙 경계 흐려짐
NVL72 의 의미 — 72 GPU 가 “한 노드” 처럼 보임. 기존 “노드 내부 = NVLink, 노드 사이 = IB” 의 이분법이 깨진다. 알고리즘은 “rail 한 개로 큰 메시지” 를 가정하던 것에서 “여러 NVLink 도메인 + 그 사이 IB” 의 hierarchical 패턴으로 이동.
SHARP — in-network reduction
NVSwitch 3 (H100+) 부터 추가된 기능 — switch 자체가 reduction 을 수행. 8 GPU 의 gradient 를 NVSwitch 가 합산해서 한 번에 broadcast. ring 의 2(N-1) 단계를 1 단계로 압축. NCCL 이 자동으로 사용 (확인 필요, 환경에 따라 명시적 enable 필요).
“하드웨어가 algorithm 을 흡수한다 — SHARP 는 ring 알고리즘의 한 step 을 switch 안으로 이동시킨 일이다.”학습 노트 · §5
§ 06다중 노드 패턴· Cross-rail · IB · Ethernet
“노드 내부” 와 “노드 사이” 의 BW 차이가 30배 — 이게 모든 distributed algorithm 의 출발점
노드 내부의 NVLink 는 ~450 GB/s, 노드 사이의 InfiniBand 는 ~50 GB/s (NDR 400Gb 기준). 약 9-10배 차이. RoCE Ethernet 은 더 낮음. 이 비대칭이 모든 multi-node algorithm 의 출발점.
대표 패턴 셋.
hierarchical allreduce — 노드 내부에서 먼저 reduce-scatter (NVLink), 노드 사이에서 ring allreduce (IB), 다시 노드 내부에서 allgather. NCCL 의 표준.
multi-rail aggregation — 한 노드에 IB NIC 8개 (rail 8). 각 rail 이 독립적으로 한 GPU 의 traffic 을 처리. NCCL 의 channel 수가 rail 수에 매칭.
tensor parallel 은 노드 내부, pipeline parallel 은 노드 사이 — TP 는 high-frequency activation 통신, PP 는 low-frequency activation 통신. 통신 빈도가 wire 의 BW 와 정렬되도록 배치.
실전 매핑 룰
"빈번한 통신은 빠른 wire 위에" — TP 는 NVLink, PP 는 IB, DP 는 가장 느려도 무방하면 RoCE. 이 룰이 깨지면 학습 throughput 이 즉각 떨어진다.
FIG · BW 비대칭과 parallelism 매핑30× gap
NVLink (intra-node)
450 GB/s
NVLink (NVL72)
~1.8 TB/s
IB NDR ×8 rail
400 GB/s
IB NDR ×1 rail
50 GB/s
100 GbE
12 GB/s
PCIe 5 ×16
63 GB/s
노드 사이 BW 는 multi-rail aggregation으로 끌어올린다. 한 노드에 IB NIC 8 개를 박아 800 Gb/s × 8 = 6.4 Tb/s ≈ 800 GB/s — NVLink 노드 내부와 비슷한 수준에 근접.
§ 07새 hardware· NVL72 · UALink · ICI
“노드” 의 정의 자체가 바뀌고 있다
2025 의 frontier hardware 는 “노드 = 한 box” 의 정의를 깬다. NVIDIA NVL72 (rack-scale 72 GPU), UALink (open standard), Google TPU 의 ICI (3D torus), AMD MI300x 의 Infinity Fabric. 모두 “NVLink 가 한 rack 을 덮는다” 의 변종.
NVIDIA · NVL72
72 GPU rack-scale NVLink
한 rack 의 72 GPU 가 모두 NVLink 5 로 연결됨. 기존 8-GPU 노드 9 개를 한 노드처럼 다룸. rack 단위가 새 “fast domain”이 됨. NCCL 은 이걸 single-node 로 인식.
UALink (Ultra Accelerator Link)
vendor-neutral fabric
AMD, Intel, Cisco, Meta, MS, Google 이 함께 미는 open standard. NVLink 의 대안. 라이브러리 입장에서는 transport 가 추가될 뿐이지만, vendor lock-in 의 풀림은 큰 의미.
Google TPU · ICI
3D torus / 4D mesh
TPU 의 자체 fabric. all-to-all 패턴이 자연스럽게 빠른 토폴로지. NVLink 의 fully-connected 와 다른 trade-off. JAX / pjit 의 sharding 이 ICI 토폴로지에 매핑.
AMD · Infinity Fabric
MI300X 의 GPU 간 fabric
RCCL 이 NCCL API 호환으로 위에 얹힘. xGMI 라는 transport 가 NVLink 자리. ROCm 의 communication 스택은 점점 NVIDIA 와 비슷한 layer 화 모양으로.
관전 포인트
“노드 안 NVLink, 노드 사이 IB” 의 두 단계가, NVL72 시대에는 “rack 안 NVLink, rack 사이 IB / Ethernet”의 두 단계로 재정의된다. 알고리즘의 hierarchy 는 그대로 유지되지만 도메인 사이즈가 9 배. 같은 알고리즘이 9 배 큰 문제를 같은 BW 로 풀 수 있다가 NVL72 의 약속.
§ 08production trade-off· Debug · stability
“가장 빠른 것” 과 “가장 안정적인 것” 이 항상 같지는 않다
benchmark 위 1.2배 빠른 라이브러리가 production 에서 잘못 갈 수 있다. 실제로 production team 이 라이브러리를 고를 때의 기준은 속도가 아니라 stability + observability.
NCCL_DEBUG=INFO — NCCL 의 첫 디버깅 도구. 어떤 알고리즘을 골랐고 어떤 transport 위에서 도는지 stdout 에 찍힘. production 인시던트의 첫 진입점.
silent corruption — 통신 결과가 틀린 채로 진행되는 경우. NCCL 은 fail-fast 가 default, 일부 transport 는 silent 가능성. checkpoint validation 이 추가 안전망.
timeout tuning — NCCL_TIMEOUT, PyTorch 의 init_process_group(timeout=...). 너무 짧으면 stragglers 에서 hang 으로 오인, 너무 길면 진짜 hang 인 것을 늦게 알아챔.
incremental rollout — 새 라이브러리 (MSCCL, NVSHMEM) 는 일부 워크로드에서만 enable, 천천히 비율 늘림. 한 번에 다 바꾸면 회귀 원인 분석 불가.
“production 의 1순위는 ‘오늘 죽지 않는 것’ 이지 ‘5% 빠른 것’ 이 아니다 — communication library 선택의 거의 모든 결정이 이 줄 위에 있다.”학습 노트 · §8
관찰 가능성
multi-node 학습에서 “왜 step 시간이 갑자기 50% 늘었는가” 의 90% 는 communication 쪽. NCCL 의 channel timeline, IB 의 link counter, NIC 의 retransmit count 셋을 항상 본다. 이게 production GPU systems 엔지니어링의 일상.
§ 09다음 발전· Where the field heads
frontier 는 어디로 — compiler-driven, in-kernel, fault-tolerant
강의의 마무리. communication library 가 향하는 세 방향 — (a) compiler 가 통신을 자동 합성, (b) communication 이 kernel 안으로 들어감, (c) fault tolerance 가 default.
compiler-driven communication — JAX 의 shard_map, PyTorch 의 SPMD compiler 가 사용자 의도 (sharding spec) 만 받아서 collective 호출을 자동 삽입. 사용자가 NCCL 을 직접 안 부름.
in-kernel communication — NVSHMEM device API, NCCL device API. Triton + NVSHMEM 같은 합성 (확인 필요) 으로 kernel 안에서 통신.
fault-tolerant collective — L070 PCCL, NCCL 3.x 의 design. 한 rank 의 죽음이 전체 학습을 죽이지 않는 model.
networked attention — long-context 학습에서 KV cache 의 distributed sharding (Ring Attention, DistAttn). 알고리즘과 communication 의 경계가 흐려짐.
heterogeneous fabric — UALink, NVLink, IB, RoCE 가 한 cluster 안에 섞임. 라이브러리가 자동으로 best path routing.
사용자 입장의 결론
5년 후의 사용자는 “NCCL allreduce 를 부른다” 가 아니라 “이 텐서가 모든 rank 에서 평균이어야 한다” 라고만 적는다. 컴파일러가 토폴로지, 메시지 사이즈, fault profile 을 보고 알고리즘과 transport 를 자동으로 선택. 이 강의의 landscape 가 그 시점에 “컴파일러의 search space”가 된다.
§ 10기억할 메모와 코드· Key takeaways
다시 열었을 때 5분 안에 잡혀야 할 것
두 axis
communication shape (collective vs P2P) × stack layer (API → algo → transport → HW). 모든 라이브러리가 한 점에 위치.
L1-L4 stack
torch.distributed → NCCL/NVSHMEM → GPUDirect/RDMA → NVLink/IB. 헷갈리면 다시 layer 를 분리.
collective 라이브러리들
NCCL · MSCCL · Gloo · MPI · UCC · oneCCL. 같은 shape, 다른 trade-off.