제4부 데이터센터와 스케일

4.14 NCCL II — 병렬화 매핑·튜닝

4.14.1 이 장에서 배우는 것 / 선수 지식

4.13에서 집합연산(all-reduce 등)과 그 알고리즘을 익혔다. 이 장은 그것을 실제 분산 학습 병렬화 전략에 매핑한다 — 데이터·텐서·파이프라인·전문가 병렬이 각각 어떤 집합연산·통신량을 만들고, 그것을 토폴로지(NVLink 도메인·IB)에 어떻게 배치·튜닝하는가. 핵심 원리 하나: 통신 집약 병렬화는 빠른 인터커넥트(NVLink 도메인)에, 통신 드문 병렬화는 느린 쪽(IB)에 매핑한다(4.5~4.7의 매핑 원칙을 직접 적용). 실습 장이다.

배우는 것:

• 4대 병렬화 — 데이터·텐서·파이프라인·전문가(+ZeRO/FSDP·시퀀스) — 의 통신 패턴(집합연산·빈도·양)을 구분한다.
• 매핑 원리: 통신 빈도·양에 따라 병렬화를 인터커넥트 계층에 배치하는 법(3D/4D 병렬).
• 64-GPU 같은 실제 클러스터에 $\mathrm{TP}\times\mathrm{PP}\times\mathrm{DP}$ 레이아웃을 직접 설계하고 통신을 추정한다.
• NCCL 환경변수·오버랩·버킷팅으로 튜닝하고 확장 효율을 진단한다.
• 장애 허용성: 대규모 잡에서 랭크 하나의 고장이 왜 전체를 멈추는지, 체크포인트·재시작·elastic 재구성으로 어떻게 대응하는지(4.14.5).

선수 지식: 4.13(집합연산·ring/tree·계층 매핑 — 이 장의 토대), 4.5~4.7(NVLink 도메인·토폴로지·bisection), 4.11~4.12(IB·GPUDirect), 2.10(스트림·오버랩), 6.3(NeMo 병렬화 — 이 매핑의 프레임워크 구현). 환경은 0.3. 통신량·성능은 모델·토폴로지·시점 의존 — 이 장은 추정·매핑 방법에 집중, 정확한 수치는 실측.

4.14.2 병렬화별 통신 패턴

각 병렬화가 만드는 통신을 집합연산·빈도·양으로 정리한다 — 이것이 매핑의 근거다.

참고: EP의 all-to-all은 토큰마다 목적지 전문가가 달라 불규칙한 통신 패턴이다. NCCL의 집합연산 API로도 구현되지만, 이런 지연 민감·불규칙 패턴엔 NVSHMEM(GPU가 커널 안에서 직접 발행하는 one-sided PGAS 통신 라이브러리)을 쓰는 구현도 있다 — 호스트 개입 없이 GPU가 통신을 스스로 트리거해 작은 메시지의 지연을 줄인다. 이 책은 NCCL 중심으로 다루며, NVSHMEM은 존재와 용도만 짚는다(API·채택 여부는 프레임워크·버전 의존, 확인 필요).

핵심 구분 — 통신 빈도:

이 한 줄이 매핑의 전부다: 잦은 통신은 NVLink 도메인 안, 드문 통신은 노드 간 IB.

4.14.3 매핑 원리 — 통신을 위계에 맞춘다

4.5~4.7의 대역 위계(NVLink ≫ IB)에 병렬화의 통신 빈도를 맞춘다:

왜: TP를 노드 간 IB로 흩으면 매 레이어 all-reduce가 느린 IB를 타 스텝을 지배(확장 실패). DP를 IB에 두면 스텝당 1회뿐이라 오버랩·SHARP로 은닉할 수 있다. 잘못 매핑하면 같은 GPU 수로도 몇 배 느려진다 — 이것이 분산 학습 성능의 핵심 레버.

3D(또는 4D) 병렬. 실전 대규모 학습은 이들을 조합한다: 전체 GPU = TP × PP × DP(+ EP). 각 차원을 토폴로지 계층에 매핑한다:

4.14.4 워크스루 — 64-GPU 레이아웃 설계

시나리오: 8노드 × 8GPU = 64 GPU(각 노드는 NVLink 8-도메인, 노드 간 IB). 큰 트랜스포머를 학습한다. 레이아웃을 설계한다.

1) 텐서 병렬(TP) = 8 — 노드 내. 한 레이어를 8-GPU NVLink 도메인 안에서 분할. 매 레이어 all-reduce가 NVLink 고대역으로. (TP를 8 초과로 설정해 노드를 넘기면 IB로 새 → 금지.)

2) 파이프라인 병렬(PP) = 4 — 노드 간. 모델 레이어를 4 스테이지로 나눠 4개 노드 그룹에. 스테이지 경계 P2P(활성화)만 노드 간 IB — 드문 통신이라 IB로 견딤. (파이프라인 버블 주의, 4.14.6.)

3) 데이터 병렬(DP) = 2 — 복제 간. 위 4노드(한 모델 복제)를 2벌 두고, 스텝당 1회 grad all-reduce를 복제 간 IB로(SHARP·오버랩으로 가림).

$64 = \mathrm{TP}8 \times\mathrm{PP}4 \times\mathrm{DP}2$:

4) 통신 추정(정성).

→ 매 레이어 통신(TP)이 느린 IB에 안 닿게 한 것이 핵심.

잘못된 매핑(반례): TP를 16(노드 넘김)으로 잡으면 매 레이어 all-reduce가 노드 간 IB를 타 스텝이 통신에 지배 → 64 GPU인데 확장 안 됨. TP는 NVLink 도메인 크기(8, NVL72면 72)까지만. 이것이 4.5의 "큰 NVLink 도메인이 TP를 더 키울 여지"의 실제 의미.

4.14.5 워크스루 — NCCL 튜닝·진단

1) 확장 효율 측정. 1·2·4·8·…노드로 늘리며 스텝 시간·throughput을 잰다.

2) 통신·연산 오버랩 확인(2.13). Nsight Systems 타임라인에서 NCCL 커널이 연산과 겹치는지. DP all-reduce가 backward와 안 겹치면 그대로 스텝에 더해진다.

# PyTorch DDP는 기본으로 grad all-reduce를 backward와 오버랩(버킷 단위)
model = torch.nn.parallel.DistributedDataParallel(model, bucket_cap_mb=25)
# 버킷 크기: 작으면 오버랩 잘 되나 호출 잦음(지연), 크면 반대 — 튜닝

3) NCCL 환경변수(핵심).

NCCL_DEBUG=INFO                 # 알고리즘·전송·토폴로지 로그(4.13)
NCCL_IB_HCA=mlx5_0,mlx5_2       # 사용할 IB NIC(친화도에 맞춰, 4.12)
NCCL_P2P_LEVEL=NVL              # P2P를 NVLink로 (토폴로지 강제)
NCCL_ALGO=Ring                  # 또는 Tree/CollnetChain(실험·특수)
NCCL_NTHREADS / NCCL_BUFFSIZE   # 스레드·버퍼 튜닝(고급, 기본이 대개 적절)
NCCL_IB_TIMEOUT / NCCL_IB_QPS_PER_CONNECTION  # IB 안정·성능(환경 의존)

대부분 NCCL 기본값이 좋다. 환경변수는 busbw가 낮거나 특정 토폴로지·NIC 문제일 때 신중히. 바꾸면 반드시 nccl-tests·실학습으로 효과 검증(추측 금지).

4) 진단 흐름.

5) 장애 허용성 — 수백~수천 GPU 규모에선 고장이 일상이다. 집합연산(all-reduce 등)은 참여하는 모든 랭크(GPU)가 함께 도착해야 끝난다 — 노드 하나·GPU 하나가 죽거나 느려지면(하드웨어 결함·네트워크 단절·프로세스 크래시), 그 통신에 물린 모든 랭크가 함께 멈춘다(hang). 랭크 수가 클수록 어느 하나가 고장 날 확률이 커져, 이는 이론적 우려가 아니라 대규모 학습의 일상적 운영 이슈다.

• 탐지: 위 표의 NCCL_IB_TIMEOUT 같은 타임아웃 설정 + 워치독/하트비트(프레임워크·오케스트레이션 레이어, 버전 의존)로 "멈춘 job"을 능동적으로 감지 — 안 그러면 죽은 job이 눈치 못 채고 GPU를 계속 점유한다.
• 복구: 정기적인 체크포인트(옵티마이저 상태 포함, 6.3의 메모리 항목들)를 저장해 두고, 실패 감지 시 마지막 체크포인트에서 재시작한다. 체크포인트 주기는 트레이드오프다 — 잦으면 저장 오버헤드(I/O), 뜸하면 실패 시 잃는 학습량이 커진다.
• elastic(탄력적) 재구성: 죽은 노드를 빼고(또는 대체 노드를 넣고) 월드 크기(world size)를 바꿔 재시작하는 접근도 있다 — 큰 클러스터의 가동률을 지킨다. 구현·프레임워크 지원은 버전 의존(확인 필요).
• 이 장·6.3과의 관계: 장애 허용성은 통신 알고리즘(이 장)·병렬화 설계(6.3)와 직교하는 운영 축이다 — 어떤 TP/PP/DP 구성이든 체크포인트·재시작 전략이 따로 필요하다.

4.14.6 파이프라인 버블·로드밸런스(보충)

파이프라인 병렬(PP)은 통신은 적지만 버블(bubble) — 스테이지가 차고 비는 동안 GPU 유휴 시간 — 이 고유 비용이다.

매핑 시 PP 스테이지 수와 마이크로배치 수를 균형을 맞춰 버블을 줄인다(6.3에서 프레임워크 구현). 로드밸런스(스테이지별 연산량 균등)도 중요 — 한 스테이지가 부하가 크면 전체가 기다린다.

4.14.7 중간 점검 (체크포인트)

• [ ] 4대 병렬화의 통신(집합연산·빈도·양)을 구분하고, 잦은 통신(TP·EP) vs 드문 통신(DP·PP) 을 가른다.
• [ ] 매핑 원리(잦은 통신은 NVLink 도메인, 드문 통신은 IB)를 적용해 $\mathrm{TP}\times\mathrm{PP}\times\mathrm{DP}$ 레이아웃을 설계한다.
• [ ] TP를 NVLink 도메인 크기 이내로 설정해야 함을, 넘기면 왜 확장이 깨지는지 설명한다.
• [ ] 확장 효율·오버랩·버블을 진단하고 NCCL 환경변수·버킷팅으로 튜닝한다.

증상→의심: 노드 늘려도 확장 안 됨 → TP가 노드 넘김(IB로 매 레이어 통신) 또는 DP all-reduce 미오버랩. 파이프라인인데 GPU 유휴 → 버블(마이크로배치↑·로드밸런스). MoE 느림 → all-to-all이 NVLink 도메인 밖(EP 재매핑). busbw 낮음 → GPUDirect·친화도·토폴로지(4.12·4.7).

4.14.8 트레이드오프 — 병렬화 선택

견해: 작은 모델은 DP만으로 충분(단순·확장 쉬움). 모델이 커져 레이어가 GPU에 안 들어가면 TP(NVLink 도메인 내), 모델이 노드에 안 들어가면 PP(노드 간), 그래도 크면 DP로 복제해 데이터 확장. MoE면 EP. 메모리가 부족하면 ZeRO/FSDP. 실전은 이들의 조합(3D/4D)이고, 각 차원을 올바른 인터커넥트 계층에 매핑하는 것이 성능의 8할. 프레임워크(NeMo·Megatron, 6.3)가 이 매핑을 설정으로 받지만, 왜 그렇게 매핑하는지(이 장)를 알아야 튜닝·디버깅이 된다.

비NVIDIA 정직: 3D 병렬·ZeRO·파이프라인 스케줄은 NVIDIA 고유가 아니라 분산 딥러닝의 공통 기법(DeepSpeed·Megatron·FSDP·여러 프레임워크). NCCL은 그 통신 계층의 NVIDIA 구현이고, 같은 자리를 다른 가속기의 집합연산 라이브러리가 채운다. 매핑 원리(통신 빈도↔인터커넥트 위계)는 벤더 불문 공통 — 익히면 어디서나 쓴다.

4.14.9 흔한 함정

• TP를 NVLink 도메인 밖으로. 가장 흔하고 치명적. TP는 매 레이어 통신이라 노드(또는 NVLink 도메인)를 넘으면 IB 병목으로 확장성이 저하된다. TP ≤ NVLink 도메인 크기(8 또는 NVL72면 72).
• DP all-reduce 미오버랩. backward와 안 겹치면 통신이 스텝에 그대로 더해진다. DDP·프레임워크 오버랩을 켜고 Nsight로 확인(2.10·2.13).
• 파이프라인 버블 방치. 마이크로배치가 적으면 버블이 커 GPU가 유휴 상태다. 마이크로배치↑·로드밸런스로 버블 비율↓.
• 매핑을 토폴로지와 무관하게. 프레임워크 기본 매핑이 내 토폴로지(비균일·클라우드)에 안 맞을 수 있다. topo -m·busbw로 확인하고 TP/PP/DP를 토폴로지에 정렬.
• NCCL 환경변수 남발. 검증 없이 NCCL_*를 바꾸면 더 느려질 수 있다. 기본값이 대개 좋다 — 문제를 측정으로 좁힌 뒤 한 번에 하나씩, nccl-tests로 검증.
• 메모리만 보고 ZeRO 과용. ZeRO/FSDP는 메모리를 줄이지만 통신(all-gather/reduce-scatter)을 늘린다. 통신 바운드면 오히려 느려질 수 있어 메모리·통신 균형으로(6.3).
• 확장 효율 미측정. "GPU 늘렸으니 빠를 것"이라 가정 말고, 노드별 스케일링 곡선을 그려 어디서 꺾이는지 본다.
• 장애 허용성 없이 대규모로. 체크포인트·재시작·타임아웃 감지 없이 수백~수천 GPU 잡을 실행하면, 랭크 하나가 비정상 종료됐을 때 전체가 조용히 멈춰서 GPU-시간을 낭비한다(4.14.5 "5) 장애 허용성"). 규모가 커질수록 필수.

4.14.10 연습문제

연습 1 (통신 빈도 분류). 텐서·데이터·파이프라인·전문가 병렬을 "통신 빈도(레이어마다 vs 스텝/경계)"로 분류하고, 각각을 NVLink 도메인과 노드 간 IB 중 어디에 매핑할지.

연습 2 (레이아웃 설계). 16노드 × 8GPU = 128 GPU(노드=NVLink 8-도메인, 노드 간 IB). 한 레이어가 4 GPU에 들어가고 모델 전체가 한 노드에 안 들어가는 트랜스포머. $\mathrm{TP}\times\mathrm{PP}\times\mathrm{DP}$ 레이아웃을 제안하고 각 차원의 매핑·통신을 설명하라.

연습 3 (반례 진단). 어떤 팀이 128 GPU에서 TP=16으로 잡았더니 64 GPU(TP=8)보다도 느리다. 원인과 수정.

연습 4 (튜닝 절차). 32노드 데이터 병렬 학습의 확장 효율이 70%에서 정체다(이상 대비). 병목을 좁히는 진단 단계를 순서대로 쓰라.

4.14.11 요약 · 다음 장

• 병렬화는 서로 다른 통신을 만든다: 데이터(스텝당 all-reduce)·텐서(매 레이어 all-reduce)·파이프라인(경계 P2P)·전문가(매 레이어 all-to-all)·ZeRO(all-gather+reduce-scatter).
• 매핑 원리: 잦은 통신(TP·EP)은 NVLink 도메인 안, 드문 통신(DP·PP)은 노드 간 IB. 잘못 매핑하면(특히 TP가 도메인 초과) 같은 GPU로도 몇 배 느려진다.
• 실전은 $\mathrm{TP}\times\mathrm{PP}\times\mathrm{DP}$(+EP) 3D/4D 조합이고, 각 차원을 인터커넥트 계층에 정렬하는 것이 성능의 핵심. 파이프라인은 버블을 마이크로배치로 관리.
• 튜닝: 확장 효율 측정 → busbw·오버랩·TP 매핑·버블·SHARP를 순서로 진단. NCCL 기본값이 대개 좋고, 환경변수는 측정으로 검증하며 신중히.

제4부(데이터센터와 스케일, 4.1~4.14) 완료. 한 GPU에서 세대·폼팩터(4.1) → Hopper·Blackwell(4.2~4.5) → NVLink·Grace·랙스케일(4.6~4.9) → MIG(4.10) → 네트워크·GPUDirect·NCCL(4.11~4.14)까지, "GPU를 묶고·나누고·잇는" 스케일의 전 계층을 손에 익혔다.

다음 장: 5.1 추론 최적화 개관 — 제5부(추론 최적화·서빙)의 시작. 지금까지의 학습 중심에서 추론으로 무게를 옮긴다. 지연·처리량·정밀도·메모리의 사면체 트레이드오프를 세우고, 이후 TensorRT·TRT-LLM·Triton으로 추론 스택을 쌓는다.