오래 도는 학습은 반드시 실패를 만난다

single-node 짧은 실험에서는 실패가 드물게 느껴질 수 있다. 하지만 multi-node LLM 학습은 다르다. 장비 장애, 네트워크 흔들림, preemption, 저장소 문제, 코드 배포 실수 등으로 run이 중단될 가능성이 훨씬 크다.

그래서 checkpoint 전략은 부가 기능이 아니라 필수 설계 요소다.

무엇을 저장해야 하는가

좋은 resume를 위해서는 단순히 모델 가중치만 저장해서는 부족하다.

  • model parameters
  • optimizer state
  • scheduler state
  • global step / token count
  • random state
  • data loader progress 또는 재현 가능한 샘플링 정보

이 중 일부라도 빠지면 이어서 돌린다고 해도 정확히 같은 학습 상태가 아닐 수 있다.

sharded training에서 더 어려운 이유

FSDP나 ZeRO처럼 상태가 shard되어 있으면 checkpoint도 그 구조를 고려해야 한다.

  • full state dict를 만들지
  • shard된 상태로 저장할지
  • save/load 시 gather 비용을 감당할지

즉 checkpoint는 저장 포맷과 런타임 비용의 균형 문제이기도 하다.

어떤 전략이 실용적인가

  • 주기적인 full checkpoint
  • 더 자주 저장하는 lightweight progress checkpoint
  • 비동기 저장
  • node failure가 잦은 환경에서는 짧은 주기의 recoverable save

이 전략은 저장소 대역폭과 학습 비용을 함께 고려해야 한다.

resume를 진짜로 믿으려면

resume 경로는 실제로 반복 테스트해야 한다. 많은 팀이 저장은 잘 되지만 복구 시점에 깨지는 문제를 겪는다. 특히 distributed sampler와 RNG state가 꼬이면 loss curve가 미묘하게 달라질 수 있다.

다음 글에서는 분산 학습 디버깅을 본다. deadlock, timeout, OOM, desync 같은 문제를 어떻게 좁혀 가는지가 핵심이다.