Day 2 - 분산 학습: 데이터 병렬과 모델 병렬

데이터 병렬 vs 모델 병렬

모델이 한 장비에 안 들어가거나 데이터가 너무 많아 한 GPU로는 며칠이 걸릴 때 학습을 여러 장비·GPU로 쪼갠다. 두 패러다임을 먼저 명확히 구분한다.

• 핵심 직관: 데이터 병렬은 "모델은 들어가는데 느릴 때", 모델 병렬은 "모델 자체가 안 들어갈 때" 쓴다.
• 시험 키워드 "out of memory / 모델이 너무 커서" → 모델 병렬. "학습이 너무 오래 걸림 / 데이터가 큼" → 데이터 병렬.

GPU 메모리는 무엇으로 차는가

"안 들어간다"를 정확히 이해하려면 GPU 메모리를 무엇이 차지하는지 알아야 한다. 파라미터만 세면 오판한다.

• 데이터 병렬은 이 중 아무것도 줄이지 않는다 — 각 GPU에 전체 복제본이 그대로 올라가기 때문이다. OOM에 데이터 병렬이 무력한 이유가 여기 있다.
• 메모리를 당장 줄이는 저비용 수단: 혼합 정밀도, 배치 축소 + 그래디언트 누적, 활성값 체크포인팅(연산을 더 하고 메모리를 아낌).

💡 관련 이론: 데이터 병렬의 수학적 근거는 미니배치 그래디언트의 선형성이다. 전체 배치의 그래디언트는 각 GPU가 계산한 부분 배치 그래디언트의 평균과 같다. 그래서 GPU마다 모델 복제본으로 부분 배치를 처리한 뒤 all-reduce로 그래디언트를 합쳐 평균하면, 한 대로 큰 배치를 처리한 것과 수학적으로 동등한 업데이트가 된다. 모델 병렬은 다르다. 연산 그래프 자체를 잘라 한 GPU의 출력(활성값)이 다음 GPU의 입력이 되므로, GPU 간 의존성과 통신 비용이 본질적으로 더 크다.

데이터 병렬: 처리량을 늘린다

데이터 병렬은 가장 흔한 분산 방식이다. 각 GPU(혹은 장비)가 모델 전체 복제본을 갖고, 서로 다른 데이터 조각으로 forward/backward를 수행한 뒤 그래디언트를 모아 평균한다.

[GPU 0]  배치 조각 0  →  그래디언트 g0  ┐
[GPU 1]  배치 조각 1  →  그래디언트 g1  ├─ all-reduce → 평균 ḡ → 모든 GPU 동일 갱신
[GPU 2]  배치 조각 2  →  그래디언트 g2  ┘

from sagemaker.pytorch import PyTorch
 
estimator = PyTorch(
    entry_point='train.py',
    instance_type='ml.p4d.24xlarge',
    instance_count=2,                       # 여러 장비
    framework_version='2.0', py_version='py310',
    distribution={                          # SageMaker 데이터 병렬 활성화
        'smdistributed': {'dataparallel': {'enabled': True}}
    }
)

SageMaker Distributed Data Parallel (SMDDP)은 AWS 네트워크(EFA 등)에 최적화된 all-reduce를 제공해, 표준 PyTorch DDP보다 통신 효율이 좋다. 데이터 병렬을 늘리면 처리량이 거의 선형으로 증가하지만, 통신 오버헤드 때문에 무한히 선형은 아니다.

데이터 병렬 백엔드 고르기

같은 데이터 병렬이라도 SageMaker에서 여러 백엔드를 distribution 인자로 선택한다.

시험 관점: "AWS 인프라에 최적화된 분산 학습 라이브러리"라는 표현이 보이면 SMDDP다. 반대로 "기존 코드를 거의 그대로"면 네이티브 분산/MPI 쪽이 답이 된다.

배치가 커지면 따라오는 것들

⚠️ 함정: 데이터 병렬로 GPU 수를 N배 늘리면 유효 배치 크기도 N배가 된다. 이때 학습률을 그대로 두면 수렴이 나빠질 수 있어 보통 학습률을 함께 조정(예: linear scaling)한다. "GPU만 늘리면 자동으로 더 잘 학습된다"는 오해를 시험이 노린다.

모델 병렬: 모델을 쪼갠다

모델 병렬은 모델 자체가 한 GPU 메모리에 안 들어갈 때 쓴다. 수십억~수천억 파라미터의 거대 언어 모델이 대표적이다. 모델 병렬에는 두 결이 있다.

• 텐서/파이프라인 분할: 레이어들을 여러 GPU에 나눠 배치. 한 GPU의 출력이 다음 GPU의 입력이 됨(파이프라인 병렬), 혹은 한 레이어의 텐서 연산 자체를 쪼갬(텐서 병렬).
• 샤딩(sharding): 옵티마이저 상태·그래디언트·파라미터를 GPU 간에 분산 저장해 메모리를 절약(ZeRO/FSDP 계열).

estimator = PyTorch(
    entry_point='train.py',
    instance_type='ml.p4d.24xlarge', instance_count=2,
    framework_version='2.0', py_version='py310',
    distribution={
        'smdistributed': {
            'modelparallel': {                 # SageMaker 모델 병렬
                'enabled': True,
                'parameters': {'partitions': 4, 'tensor_parallel_degree': 2}
            }
        }
    }
)

SageMaker Distributed Model Parallel (SMP)은 모델 분할·파이프라인 실행·샤딩을 자동화한다. 사용자가 수작업으로 레이어를 GPU에 배치하지 않아도 라이브러리가 메모리에 맞게 분할 전략을 잡아준다.

네 가지 병렬 축 한눈에

실무의 대규모 학습은 아래 축을 조합한다. 각 축이 "무엇을 쪼개고 무엇을 얻는지"가 시험의 구분 지점이다.

하이브리드 병렬 — 통신 비용을 토폴로지에 맞춘다
 
 노드 0 [GPU0 GPU1 GPU2 GPU3]  ← 노드 안: 텐서/파이프라인 병렬 (빠른 NVLink)
    │
   EFA  ← 노드 간: 데이터 병렬 (상대적으로 느린 네트워크, all-reduce만)
    │
 노드 1 [GPU0 GPU1 GPU2 GPU3]

개념: 샤딩은 "메모리와 통신의 교환"이다. 파라미터를 GPU마다 조각내 두면 평소 메모리는 크게 줄지만, 계산 직전에 필요한 조각을 모아야(gather) 하고 끝나면 다시 흩는다. 그래서 샤딩 단계를 올릴수록(옵티마이저 상태만 → +그래디언트 → +파라미터) 메모리는 더 줄고 통신은 더 늘어난다. "가장 강한 샤딩이 최선"이 아니라 모델이 들어가는 선에서 가장 약한 샤딩이 보통 가장 빠르다.

거대 모델을 쪼갤 때 핵심 트레이드오프는 "메모리 절약 vs 통신 비용"이다. 모델을 잘게 쪼갤수록 GPU당 메모리는 줄지만 GPU 간 활성값·파라미터 전송이 늘어 느려진다. 그래서 실무에서는 데이터 병렬·텐서 병렬·파이프라인 병렬·샤딩을 조합한 "하이브리드 병렬"을 쓴다. 예를 들어 노드 안에서는 텐서 병렬(빠른 NVLink), 노드 간에는 데이터 병렬(상대적으로 느린 네트워크)로 통신 패턴을 토폴로지에 맞춘다.

대규모 학습 인프라

분산 학습 성능은 알고리즘뿐 아니라 인프라가 좌우한다.

• EFA (Elastic Fabric Adapter): 노드 간 저지연 고대역 네트워크. 분산 학습의 all-reduce 통신 병목을 줄인다. p4d/p5 같은 GPU 인스턴스에서 활성화.
• FSx for Lustre: 고처리량 병렬 파일시스템. 대용량 학습 데이터를 S3보다 빠르게 GPU에 공급해 데이터 로딩 병목을 줄인다.
• 인스턴스 선택: 다중 GPU 단일 노드(예: p4d.24xlarge = 8 GPU)면 노드 내 NVLink로 빠르다. 노드를 여러 개 쓰면 EFA로 노드 간 통신.

S3 (원천 데이터)
   └─ FSx for Lustre (고속 캐시) → 여러 학습 노드에 빠르게 공급
학습 노드들 ── EFA(저지연 네트워크) ── all-reduce / 모델 병렬 통신

병목이 어디냐에 따라 손대는 곳이 다르다.

개념: 스케일링 효율(scaling efficiency). GPU를 N배 늘렸을 때 처리량이 N배가 되면 효율 100%다. 현실은 통신·동기화 때문에 항상 100% 미만이고, 노드를 늘릴수록 떨어진다. 그래서 "GPU 8장짜리 노드 1대"가 "GPU 2장짜리 노드 4대"보다 대체로 빠르다 — 같은 GPU 수라도 노드 안 통신(NVLink)이 노드 간 통신보다 훨씬 빠르기 때문이다. 먼저 노드를 키우고, 그다음에 노드를 늘린다가 순서다.

한 연구팀이 70억 파라미터 모델을 단일 ml.g5 인스턴스에서 학습하려다 GPU OOM에 부딪혔다. 데이터 병렬로 노드를 늘려도 복제본이 여전히 한 GPU에 안 들어가 소용없었다. SMP의 모델 병렬+샤딩으로 파라미터·옵티마이저 상태를 GPU 간에 분산하자 메모리에 들어갔고, 노드 간엔 EFA를, 데이터 공급엔 FSx for Lustre를 붙여 학습 시간을 크게 줄였다. 교훈: OOM은 GPU 추가(데이터 병렬)가 아니라 모델 병렬로 푼다.

장시간 학습의 생존성

분산 학습은 오래 돌기 때문에 "중간에 죽으면 어떻게 되는가"가 실무 비용을 좌우한다.

estimator = PyTorch(
    entry_point='train.py', source_dir='src', role=role,
    framework_version='2.0', py_version='py310',
    instance_type='ml.p4d.24xlarge', instance_count=4,
    distribution={'torch_distributed': {'enabled': True}},
    checkpoint_s3_uri='s3://my-bucket/ckpt/',   # 컨테이너의 체크포인트 경로를 S3와 동기화
    use_spot_instances=True,
    max_run=86400,
    max_wait=172800,
)

• 체크포인트는 랭크 0(대표 프로세스)만 저장하게 해야 파일이 서로 덮어쓰지 않는다.
• 저장 주기가 너무 잦으면 그 자체가 병목이 된다 — 학습 시간과 손실 허용치를 보고 정한다.
• 수십 대 규모의 장기 학습을 반복한다면 SageMaker HyperPod 같은 지속 클러스터 옵션을 검토한다(노드 장애 시 자동 교체·재개 지향).

어떻게 고르는가

모델 복제본 하나가 GPU 1장에 들어가는가?
 ├─ 들어간다
 │    ├─ 그런데 느리다 / 데이터가 크다   → 데이터 병렬 (SMDDP·torch_distributed)
 │    └─ 데이터 공급이 못 따라간다        → FSx for Lustre + 로더 워커·프리페치
 └─ 안 들어간다 (OOM)
      ├─ 조금 모자란다                   → 혼합 정밀도 · 배치↓+그래디언트 누적 · 활성값 체크포인팅
      ├─ 많이 모자란다                   → 샤딩(ZeRO/FSDP) → 텐서/파이프라인 병렬 (SMP)
      └─ 노드 여러 대로도 커버 안 됨       → 하이브리드 병렬 + EFA

• "더 빨리" → 데이터 병렬. "안 들어가서" → 모델 병렬. 이 한 줄이 시험 대응의 핵심이다.
• OOM에 GPU를 추가하는 보기, 느린 학습에 모델 병렬을 켜는 보기는 모두 오답 패턴이다.

다음 글에서는 학습이 잘 돌아가는지, 어디서 느려지고 어디서 망가지는지 들여다보는 디버깅·프로파일링을 본다.

📖 용어

• 분산 학습 : 한 대로 감당이 안 되는 학습을 여러 GPU·장비에 나눠 돌리는 것.
• 데이터 병렬 : 데이터를 쪼개 GPU마다 같은 모델 복제본으로 학습시키는 방식. 빨라지지만 메모리는 안 줄어든다.
• 모델 병렬 : 모델 자체를 여러 GPU에 나눠 얹는 방식. 한 GPU에 안 들어가는 모델을 학습할 때 쓴다.
• all-reduce : GPU마다 계산한 값을 서로 주고받아 하나로 합친 뒤(보통 평균) 전원이 같은 결과를 갖게 하는 통신 연산.
• 샤딩(sharding) : 파라미터·그래디언트·옵티마이저 상태를 조각내 GPU들에 나눠 보관하는 것. 메모리는 줄고 통신은 는다.
• 유효 배치 크기 : GPU 하나의 배치 × GPU 수. 실제로 한 번의 갱신에 쓰이는 총 샘플 수다.
• 그래디언트 누적 : 작은 배치 여러 번의 그래디언트를 모았다가 한 번에 갱신하는 기법. 메모리를 안 늘리고 큰 배치 효과를 낸다.
• 활성값 체크포인팅 : 순전파 중간 결과를 버렸다가 역전파 때 다시 계산하는 기법. 연산을 더 쓰고 메모리를 아낀다.
• EFA / FSx for Lustre : EFA는 노드 간 저지연·고대역 네트워크 인터페이스로 분산 학습의 통신 병목을 줄인다. FSx for Lustre는 고성능 병렬 파일시스템으로 S3 데이터를 여러 학습 노드에 빠르게 공급한다.
• 스케일링 효율 : GPU를 N배 늘렸을 때 실제 처리량이 몇 배가 되는지의 비율. 통신 때문에 항상 N배에는 못 미친다.