Checkpointing의 한계
대규모 분산 학습에서 Checkpoint가 왜 필수인지, 그리고 왜 그것이 병목이 되는지 심층 분석합니다.
1. Checkpointing이란?
Checkpoint는 학습 도중의 모델 상태를 스토리지에 저장하는 메커니즘입니다. 학습이 중단되더라도 저장된 시점부터 재개할 수 있게 해주는 Fault Tolerance(장애 허용)의 핵심입니다.
Checkpoint 없이 학습을 진행한다면, 단 한 번의 GPU 장애로도 수일~수주간의 학습 진행 상황을 모두 잃게 됩니다. 이는 수백만 달러의 컴퓨팅 비용 손실로 직결됩니다.
2. Checkpoint 구성 요소
학습을 완벽하게 복원(Resuming)하기 위해 Checkpoint에는 단순히 모델 가중치뿐만 아니라 학습의 "맥락"이 모두 저장되어야 합니다.
Model Parameters
현재 시점의 모델 가중치. BF16 또는 FP32 정밀도로 저장합니다. 모델의 "두뇌"에 해당하는 핵심 데이터입니다.
Optimizer States
가장 용량이 큽니다. Adam 옵티마이저의 경우 파라미터별 1차 모멘텀(Momentum), 2차 모멘텀(Variance), 누적 스텝 수를 저장합니다. 이를 잃어버리면 학습 재개 시 Loss 스파이크가 발생합니다.
LR Scheduler State
현재 어느 에포크/스텝인지, 현재 Learning Rate 값은 얼마인지 저장합니다. Warmup이나 Cosine Decay 스케줄을 정확히 이어가기 위해 필수입니다.
RNG States
PyTorch, CUDA, NumPy 등의 난수 생성기(Random Number Generator) 시드 및 현재 상태. 데이터 셔플링 순서나 Dropout 등이 정확히 이전 시점과 이어지도록 하기 위해 필수입니다.
Data Loader Position
수백만 개의 문서를 처리하는 도중 끊겼다면, 어느 파일의 몇 번째 배치까지 처리했는지 인덱스를 저장합니다. 같은 데이터를 중복 학습하거나 누락하는 것을 방지합니다.
3. Checkpoint 크기 계산
3.1 크기 계산 공식
학습 Checkpoint(Full Training Checkpoint)의 크기를 계산할 때는 Mixed Precision 환경을 가정합니다.
3.2 Adam Optimizer 메모리 구성
Adam 옵티마이저와 Mixed Precision 학습을 사용할 때, 파라미터 하나당 필요한 저장 공간:
| 구성 요소 | 정밀도 | Bytes | 설명 |
|---|---|---|---|
| Model Weights | BF16/FP16 | 2 | 실제 학습에 사용되는 가중치 |
| Master Weights | FP32 | 4 | 누적 오차 방지용 고정밀 가중치 |
| Momentum (m) | FP32 | 4 | Adam의 1차 모멘트 |
| Variance (v) | FP32 | 4 | Adam의 2차 모멘트 |
| 합계 | - | 14 | 파라미터당 총 14 bytes |
3.3 대표 모델별 Checkpoint 크기
| 모델 | 파라미터 수 | 추론용 (BF16 only) | 학습용 Full Checkpoint |
|---|---|---|---|
| Llama 3 8B | 8 Billion | 16 GB | 112 GB |
| Llama 3 70B | 70 Billion | 140 GB | 980 GB (~1 TB) |
| Llama 3 405B | 405 Billion | 810 GB | 5,670 GB (~5.7 TB) |
| DeepSeek R1 671B | 671 Billion | 1.34 TB | ~5 TB |
4. Checkpoint I/O 아키텍처
4.1 Synchronous vs Asynchronous Checkpointing
Synchronous Checkpointing
학습을 완전히 멈추고 모든 노드가 동시에 Checkpoint를 저장합니다.
- 구현이 단순하고 일관성 보장
- 저장 완료까지 GPU 유휴 상태
- 수 TB 저장 시 10-20분 학습 중단
Asynchronous Checkpointing
백그라운드에서 Checkpoint를 저장하며 학습은 계속 진행합니다.
- 학습 중단 시간 최소화
- 메모리 복사본 필요 (메모리 오버헤드)
- 구현 복잡도 증가
4.2 PyTorch DCP (Distributed Checkpoint)
PyTorch 2.0+에서 제공하는 분산 Checkpoint 라이브러리로, 대규모 모델을 효율적으로 저장/로드합니다.
from torch.distributed.checkpoint import save, load
from torch.distributed.checkpoint.state_dict import get_state_dict, set_state_dict
# 분산 저장 - 각 Rank가 자신의 샤드만 저장
state_dict = get_state_dict(model, optimizer)
save(state_dict, checkpoint_dir="/fsx/checkpoints/step_1000")
# 분산 로드 - 자동으로 샤딩된 데이터 매핑
set_state_dict(model, optimizer, load(checkpoint_dir))4.3 Storage Tiers
Checkpoint는 성능과 비용에 따라 다양한 스토리지 계층에 저장됩니다.
| Storage Tier | 속도 | 용량 | 비용 | 용도 |
|---|---|---|---|---|
| Local NVMe | 7+ GB/s | ~30 TB/node | 인스턴스 포함 | 임시 저장, 빠른 복구 |
| FSx for Lustre | ~1 GB/s/TiB | 확장 가능 | 중간 | 공유 스토리지, 중간 Checkpoint |
| Amazon S3 | ~100 MB/s | 무제한 | 저렴 | 장기 보관, 최종 Checkpoint |
5. 기존 복구 프로세스: 6단계 순차 실행
전통적인 Checkpoint 기반 복구는 다음 6단계를 순차적으로 실행해야 합니다.
장애 감지
~30초
전체 Job Kill
~1분
노드 교체
~3-5분
통신 초기화
~2-5분
수 TB 다운로드
~5-20분
학습 재개
~1분
각 단계 상세 분석
1. Detect (장애 감지) - ~30초
Health check 주기에 따라 장애를 감지합니다. GPU hang, CUDA error, heartbeat timeout 등 다양한 신호를 모니터링합니다.
2. Terminate All (전체 프로세스 종료) - ~1분
하나의 GPU에서 장애가 발생하면 전체 클러스터의 모든 프로세스를 강제 종료합니다. 1,000개 이상의 노드에서 동시에 프로세스를 정리하는 데 시간이 소요됩니다.
3. Replace Hardware (노드 교체) - ~3-5분
결함이 있는 노드를 클러스터에서 제거하고, Hot Spare 노드를 투입하거나 새 인스턴스를 프로비저닝합니다.
4. Re-init NCCL (통신 재설정) - ~2-5분
TCPStore 기반 Rendezvous를 다시 수행합니다. 수천 개의 프로세스가 서로의 존재를 확인하고 통신 그룹을 재구성하는 데 상당한 시간이 소요됩니다.
5. Load from S3 (Checkpoint 로드) - ~5-20분 (병목!)
수 TB의 Checkpoint 데이터를 S3에서 다운로드합니다. 네트워크 대역폭과 스토리지 IOPS가 병목이 됩니다. 이 단계가 전체 복구 시간의 대부분을 차지합니다.
6. Resume Training (학습 재개) - ~1분
모델과 옵티마이저 상태를 GPU에 로드하고, DataLoader를 초기화하여 학습을 재개합니다.
6. 실제 장애 통계
6.1 Meta Llama 3 405B 학습 사례
54일간의 학습 기록
| 총 장애 횟수 | 466회 |
| 평균 장애 간격 | ~3시간 |
| GPU 장애 | 30% |
| HBM3 메모리 오류 | 17% |
| 기타 (네트워크, 소프트웨어 등) | 53% |
6.2 Google Gemini 학습 사례
Google은 Gemini Ultra 학습 중 "machine failures are commonplace"라고 밝혔습니다.
- Silent Data Corruption (SDC): 1-2주마다 발생
- SDC는 명시적 오류 없이 잘못된 계산 결과를 생성하여 감지가 어려움
- Checksum 검증 등 추가적인 데이터 무결성 검사 필요
6.3 MTBF at Scale
Mean Time Between Failures (MTBF)는 클러스터 규모에 반비례합니다.
MTBF 계산 예시
단일 GPU의 MTBF가 10,000시간(약 14개월)이라고 가정할 때:
| 클러스터 규모 | GPU 수 | 예상 MTBF |
|---|---|---|
| Small | 64 | ~156시간 (6.5일) |
| Medium | 512 | ~19.5시간 |
| Large | 4,096 | ~2.4시간 |
| Frontier | 16,000+ | ~37분 |
16,000개 GPU 클러스터에서는 37분마다 장애가 발생할 수 있습니다!
7. GPU 장애 유형
| 장애 유형 | 빈도 | 증상 | 복구 가능성 |
|---|---|---|---|
| HBM3 Memory Errors | 높음 | CUDA OOM, ECC 오류 | 재부팅으로 일시 해결, 반복 시 교체 |
| Thermal Throttling | 중간 | 성능 저하, 클럭 다운 | 쿨링 개선, 워크로드 조정 |
| NVLink Failures | 중간 | 노드 내 GPU 간 통신 실패 | 노드 교체 필요 |
| Network Failures | 높음 | NCCL timeout, 노드 간 통신 실패 | 네트워크 재설정, 노드 교체 |
| Silent Data Corruption | 낮음 (치명적) | 오류 메시지 없음, 잘못된 계산 결과 | 감지 어려움, Checksum 검증 필요 |
8. 비용 분석
8.1 p5.48xlarge 인스턴스 비용
| 항목 | 값 |
|---|---|
| GPU | 8x NVIDIA H100 80GB |
| On-Demand 시간당 가격 | ~$98.32 |
| 분당 비용 | ~$1.64 |
8.2 복구 시간당 비용 손실
256 노드 클러스터, 20분 복구 시나리오
단 한 번의 장애 복구에 약 1천만원의 비용이 발생합니다.
8.3 월간 비용 추정
하루 8회 장애 발생 가정 (3시간마다):
| 항목 | 계산 | 비용 |
|---|---|---|
| 일일 복구 비용 | $8,397 x 8회 | $67,176 |
| 월간 복구 비용 | $67,176 x 30일 | $2,015,280 |
8.4 Goodput 분석
Goodput은 실제 유효 학습에 사용된 시간의 비율입니다.
| 시나리오 | Checkpoint 주기 | 복구 시간 | 예상 Goodput |
|---|---|---|---|
| 보수적 | 1시간 | 30분 | 60-70% |
| 일반적 | 2시간 | 20분 | 70-80% |
| 공격적 | 4시간 | 15분 | 80-85% |
9. Checkpoint 빈도 트레이드오프
자주 저장하면...
- 장애 시 손실되는 학습량 감소
- I/O 오버헤드 증가
- 스토리지 비용 증가
- 학습 중단 빈도 증가 (동기식)
드물게 저장하면...
- I/O 오버헤드 감소
- 스토리지 비용 절감
- 장애 시 더 많은 학습량 손실
- 복구 후 진행 상황 후퇴
9.1 최적 Checkpoint 주기 계산
최적의 Checkpoint 주기는 다음 요소들의 균형점입니다:
최적 주기 계산 예시
가정:
- Checkpoint 저장 시간: 10분
- 클러스터 MTBF: 180분 (3시간)
계산:
이 시나리오에서는 1시간마다 Checkpoint를 저장하는 것이 최적입니다.
9.2 현실적인 권장 사항
| 클러스터 규모 | 예상 MTBF | 권장 Checkpoint 주기 |
|---|---|---|
| Small (64 GPU) | ~6일 | 4-6시간 |
| Medium (512 GPU) | ~20시간 | 2-4시간 |
| Large (4,096 GPU) | ~2.5시간 | 30분-1시간 |
| Frontier (16,000+ GPU) | ~40분 | 15-30분 |