분산 학습 표준 아키텍처

문서 기준: 2026년 9월 | 이 문서는 변동이 빠른 영역으로 분기별 리뷰 대상입니다.

개요

모델과 데이터가 GPU 한 장에 다 들어가면 고민할 게 없습니다. 문제는 요즘 모델이 GPU 한 장의 메모리를 훌쩍 넘긴다는 점입니다. 그래서 일을 여러 GPU에 나눠서 학습하는데, 나누는 방식이 크게 세 가지입니다.

큰 요리를 여러 요리사가 나눠 하는 상황에 비유하면 이해가 쉽습니다.

데이터 병렬(DP) — 같은 레시피(모델 전체)를 요리사마다 한 부씩 갖고, 손님(데이터)만 나눠 받아 각자 만든 뒤 결과를 맞춰봅니다.
텐서 병렬(TP) — 요리 하나가 너무 커서 한 요리사가 못 만들 때, 그 요리 한 접시를 여러 요리사가 동시에 나눠 만듭니다.
파이프라인 병렬(PP) — 조리 단계를 나눠, 요리사 A는 손질, B는 굽기, C는 플레이팅처럼 이어달리기로 처리합니다.

대규모 학습은 이 셋을 겹쳐 쓰는데(3D 병렬화), 각 방식은 “얼마나 자주 서로 통신해야 하나 / 메모리를 얼마나 아끼나 / 구현이 얼마나 복잡한가”에서 장단점이 갈립니다.

데이터 병렬 (Data Parallelism, DP)

모델 전체를 GPU마다 복제하고, 데이터만 나눠 각자 처리한 뒤 결과(그래디언트)를 all-reduce로 동기화합니다. 가장 단순하며, 모델이 GPU 한 장에 들어갈 때 표준으로 씁니다. (비유: 같은 레시피를 요리사마다 한 부씩 들고, 손님만 나눠 받아 각자 만든 뒤 결과를 맞추는 것.)

통신 방식 — 매 학습 단계마다 전 GPU가 그래디언트를 합칩니다. (all-reduce = 모든 GPU의 값을 모아 합산한 뒤 다시 모두에게 나눠주는 통신.)
한계 — 모델 자체가 GPU 한 장 메모리를 넘으면 이 방식만으로는 안 됩니다.
메모리 아끼기(FSDP/ZeRO) — 모델의 파라미터·중간 상태를 GPU들에 잘게 쪼개 나눠 저장(sharding)합니다. 데이터 병렬을 유지하면서도 GPU 한 장 한계를 넘어 더 큰 모델을 학습할 수 있습니다.

텐서 병렬 (Tensor Parallelism, TP)

단일 레이어(모델을 이루는 계산 층)의 가중치를 여러 GPU가 나눠 갖고 동시에 계산합니다. 한 층이 GPU 한 장에 안 들어갈 만큼 클 때 씁니다.

통신 방식 — 층 내부에서 GPU끼리 매우 자주 주고받아 지연에 아주 민감합니다. 그래서 주로 한 서버 안(NVLink로 이어진 GPU들)에서만 씁니다.
효과 — 층 하나가 GPU 메모리를 넘을 때 필수. 통신이 잦아 노드 간으로 넓히면 성능이 급락할 수 있습니다.

파이프라인 병렬 (Pipeline Parallelism, PP)

모델의 층들을 몇 개의 단계(stage)로 나눠 서로 다른 GPU 그룹에 배치하고, 데이터를 작은 조각(마이크로배치)으로 쪼개 이어달리기처럼 흘려보냅니다.

통신 방식 — 단계와 단계가 만나는 경계에서만 결과를 넘겨 통신량이 적습니다. 그래서 여러 서버로 넓히기 쉽습니다.
한계 — 이어달리기 특성상 앞 단계를 기다리며 노는 구간(파이프라인 버블)이 생기며, 데이터 조각 수를 늘려 완화합니다.

3D 하이브리드 병렬화

대규모 사전학습은 세 방식을 계층적으로 조합합니다. 일반적으로 노드 내는 TP, 노드 간은 PP, 그 위에 DP를 얹습니다.

병렬화	통신량	메모리 절감	지연 민감도	권장 배치
데이터 병렬 (DP)	높음 (그래디언트 all-reduce)	없음 (FSDP/ZeRO 사용 시 큼)	중간	클러스터 전체
텐서 병렬 (TP)	매우 높음 (레이어 내부)	큼	매우 높음	노드 내 (NVLink)
파이프라인 병렬 (PP)	낮음 (단계 경계)	큼	낮음	노드 간

분산 학습 프레임워크

프레임워크	주요 병렬화	특징
PyTorch FSDP	DP (sharding)	PyTorch 네이티브, 파라미터/옵티마이저 상태 분산
DeepSpeed	DP(ZeRO) + PP + TP	ZeRO 단계별 메모리 최적화, 오프로딩 지원
Megatron-LM	TP + PP + DP	대규모 Transformer 사전학습에 최적화된 TP 구현

체크포인트 전략

대규모 학습은 수 시간~수 주간 실행되므로, 노드 실패에 대비한 체크포인트가 필수입니다. 체크포인트 설계는 저장 빈도와 스토리지 대역폭의 균형 문제입니다.

빈도 — 너무 잦으면 저장 오버헤드로 GPU가 유휴 상태가 되고, 너무 드물면 실패 시 손실되는 계산량이 커집니다.
스토리지 대역폭 — 수백 GB~수 TB급 체크포인트를 짧은 시간에 써야 하므로, 스토리지 계층의 처리량이 병목이 됩니다.
비동기·분산 저장 — 학습을 멈추지 않고 백그라운드로 저장하거나, 각 GPU가 자신의 샤드만 병렬 저장해 시간을 단축합니다.
자동 재개 — 실패 감지 후 마지막 체크포인트에서 재개하는 흐름은 추론 서빙·안정성·비용 최적화 — 안정성·장애 대응에서 다룹니다.

자주 하는 실수

불필요한 3D 병렬화 도입 — 단일 노드로 충분한 모델에 텐서·파이프라인 병렬을 얹어 복잡도와 디버깅 비용만 증가
텐서 병렬을 노드 간으로 확장 — 지연에 민감한 TP를 NVLink 밖으로 넓혀 통신 병목 발생
체크포인트 빈도만 높임 — 스토리지 대역폭을 함께 늘리지 않아 저장 중 GPU 유휴 시간이 증가
옵티마이저 상태 메모리 간과 — 파라미터 외에 옵티마이저 상태·그래디언트가 차지하는 메모리를 계산하지 않아 OOM 발생

체크리스트

모델·옵티마이저 상태가 단일 GPU/단일 노드 메모리에 들어가는지 계산했는가
단일 노드로 가능하면 FSDP/ZeRO 데이터 병렬을 우선 검토했는가
텐서 병렬을 노드 내(NVLink)로 제한하고 파이프라인 병렬을 노드 간에 배치했는가
체크포인트 빈도와 스토리지 대역폭을 함께 설계했는가
실패 시 자동 재개 흐름을 검증했는가