Building resilient ML Engineering skills

강의의 출발점은 ML 엔지니어가 마주치는 비대칭성이다. 회의실에서 자랑하는 건 모델 아키텍처지만, 학습이 실제로 멈추는 자리는 거의 항상 그 바깥 — HBM ECC 에러, NCCL hang, NFS 한도, SLURM job preemption, 스토리지 inode 고갈. Stas 가 BLOOM-176B 를 굴릴 때 잡은 통계가 강의의 frame 을 잡는다.

강의는 실패의 면적 자체를 ML 엔지니어링의 1차 대상으로 본다. 모델은 부품 하나일 뿐이고, resilience 는 그 모든 부품 사이의 인터페이스에서 나온다.

그래서 이 강의의 끝에 손에 잡혀 있어야 하는 건 5개의 운영 패턴과 1개의 진단 사다리다 — checkpoint cadence, spare-node provisioning, NaN guard, divide-and-conquer 디버깅, kill/save switch. 그리고 “이 증상이 보이면 어디부터 의심하는가” 의 순서표.

강의의 첫 큰 시각화는 스택 단면이다. 사용자 레벨의 model 코드 한 줄이 GPU 위에서 실제로 도는 데까지, 거쳐야 하는 층들이 무엇이고 각각이 어떤 모드로 망가지는지를 한 화면에 깔아둔다.

이 그림이 강의 전반의 정신적 지도다. 어떤 증상이 보였을 때 “모델 버그” 부터 의심하는 건 거의 항상 시간을 낭비한다. 가장 흔한 실패 층부터 거꾸로 훑는 게 효율적이다.

특히 py-spy 의 가치는 분산 학습에서 빛난다. NCCL all-reduce 안에서 한 rank 가 멈추면 다른 모든 rank 가 같은 collective 위에서 영원히 대기한다. py-spy dump 를 모든 rank 에 한꺼번에 던져 stack trace 를 비교하면 — 다수와 다른 stack 에 있는 rank 가 곧 범인이다.

초보 ML 엔지니어가 가장 자주 빠지는 함정 중 하나. 모든 step 이 비트 단위로 동일하게 재현되어야 한다는 가정. 강의는 이 가정의 비용을 정면으로 다룬다 — 결정론을 강제하면 throughput 이 얼마나 떨어지고, 그 비용이 회수되는 자리는 어디인지.

# 결정론을 “디버깅 모드” 로 토글하는 패턴
import os, torch

def set_determinism(strict: bool):
    if not strict:
        # 평상시 — 빠른 모드
        torch.backends.cudnn.benchmark = True
        return

    # 회귀 디버깅 모드
    os.environ["CUBLAS_WORKSPACE_CONFIG"] = ":4096:8"
    os.environ["NCCL_ALGO"]  = "Ring"
    torch.use_deterministic_algorithms(True)
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark     = False
    # seed 는 rank 마다 동일하게 (data loader 는 rank 별 offset)
    torch.manual_seed(42)
    torch.cuda.manual_seed_all(42)

강의의 또 다른 강조점 — checksum based reproducibility. 비트 단위 동일이 아니라, “학습이 끝났을 때 eval metric 이 같은 분포에 들어오는가” 를 reproducibility 로 본다. 이 정의가 실용적이다. seed 만 다르고 코드는 동일한 두 run 이 final loss 0.001 이내로 들어오면 — 그 시스템은 reproducible 한 것이다.

분산 학습 디버깅의 첫 단계는 항상 scope 를 좁히는 것. 강의에서 Stas 가 거듭 강조하는 패턴 — 한 번에 한 변수만 움직이고, 항상 더 작은 reproducer 로 줄여간다.

강의 안에서 등장하는 isolate 도구들의 우선순위.

1. single-node single-GPU 재현 — 분산 코드의 99% 는 1 GPU 에서도 돈다. torchrun --nproc_per_node=1 로 떨어뜨린 뒤 같은 데이터 같은 seed 로 돌려본다. 여기서 재현되면 distributed 가 아닌 모델/데이터 버그.
2. data 일정화 — random data 는 디버깅의 적. 같은 batch 를 반복해서 먹인다 (repeat_dataloader 패턴). 결과가 달라지면 model 안에 비결정성이 숨어 있다.
3. step 별 차이 dump — 두 run 의 weight/grad/loss 를 step 마다 dump 하고 diff. 처음 차이가 나는 step 의 처음 차이가 나는 layer — 그게 범인.
4. py-spy + bt all — 모든 rank 에 py-spy 를 던져 stack trace 를 비교. 다수와 다른 stack 의 rank 가 답.
5. NCCL_DEBUG=INFO + NCCL_DEBUG_SUBSYS=ALL — 통신 hang 일 때 어떤 ring 에서 멈췄는지가 로그로 떨어진다.

강의의 큰 비중이 운영 인프라 에 할애된다. ML 엔지니어가 자주 “인프라 팀의 일” 로 미루는 영역이지만, Stas 의 입장은 분명하다 — 학습이 며칠 단위로 죽는 환경에서, 모델 엔지니어가 이 운영 패턴을 모르면 학습은 절대 끝나지 않는다.

그리고 강의에서 자주 빠뜨리는 디테일 하나 — checkpoint 저장 자체도 실패할 수 있다. NFS write 중 네트워크 잠시 끊김, 부분적으로 쓰여진 file 이 다음 resume 때 corrupt 로 발견. 패턴은 항상 atomic rename: tmp/ 에 저장 후 fsync 후 final path 로 rename. 그리고 마지막 N 개의 checkpoint 를 keep 해 한두 개가 부서져도 회복 가능하게.

강의의 가장 실무적인 섹션. 학습이 망가지는 세 모드 — NaN, hang, divergence — 각각이 보일 때 의심해야 할 layer 의 순서표.

이 사다리들의 공통점 — cheap 한 진단부터 expensive 한 진단으로. nvidia-smi · dmesg · df 같은 명령은 1초가 안 걸린다. 한 줄로 무엇이 보이고 안 보이는지가 결정된다. 코드 안 디버거를 띄우는 건 한참 뒤의 일이다.

예산을 GPU 시간 × 단가로만 잡으면 30–40% 가 사라진다. 실제 학습 비용의 분포는 그보다 복잡하다.

• 실패 buffer: 큰 학습엔 1.3× 의 GPU-hour 예산. 첫 학습은 1.5× 까지 버퍼 잡기.
• storage 비용: 가끔 잊는다. checkpoint 가 PB 단위가 되는 순간 monthly storage 가 GPU 비용의 5–10% 까지.
• 네트워크 egress: cross-region checkpoint 백업. 한 번에 PB 옮기면 네트워크 청구서가 따로 온다.
• 사람 시간: 24/7 운영을 한 사람이 못 한다. 최소 2명 rotation. 야간 페이저 대응을 1인이 매일 받게 두면 한 달 안에 사람이 망가진다.

강의 후반부의 부드러운 섹션. 그러나 Stas 가 책에서 가장 자주 인용하는 운영 실패의 원인 — 같은 정보가 여러 사람에게 다른 형태로 전달돼 두 명이 다른 가정으로 디버깅하는 것.

• 학습 wiki / runbook: 한 페이지에 “이 학습의 현재 상태, 알려진 문제, 진행 중인 디버깅” 을 적는다. 매일 갱신. 새로 합류한 사람이 5분 안에 배경을 잡을 수 있어야.
• incident log: 학습 중 발생한 모든 실패를 시간 순으로 기록. 같은 incident 가 두 번 나면 자동화 대상.
• blameless postmortem: incident 가 끝나면 30분짜리 회고. “누가 잘못했나” 가 아니라 “이 incident 가 다시 나지 않으려면 무엇이 바뀌어야 하나”.
• rotation: 24/7 학습은 최소 2명 rotating on-call. 4명이면 더 좋다. 한 사람이 내내 페이저 받으면 한 달 안에 무너진다.
• “stop the line” 문화: 학습 중 의심스러운 metric 이 보이면, junior 도 학습을 멈출 권한이 있어야. 멈췄다가 false alarm 이어도 처벌 없음 — 진짜 문제를 6시간 늦게 잡는 게 더 비싸다.

그리고 강의에서 가볍게 — 그러나 중요하게 — 등장하는 한 마디. “ML 엔지니어로 오래 살아남는 사람은 모델 코드를 잘 짜는 사람이 아니라, 자기 결정의 자취를 다른 사람이 읽을 수 있게 적어두는 사람.”

강의가 끝난 뒤 실제로 손을 움직이게 만드는 자료들.

실습 시퀀스

1. SLURM job array + auto-resume — 작은 학습 코드 (1 GPU 도 OK) 로 sbatch array 짜기. SIGUSR1 핸들러로 5분 전 checkpoint. 일부러 죽여보고 다음 슬롯이 자동으로 이어 받는지 확인.
2. kill switch 구현 — 학습 루프 안에 “특정 파일이 있으면 다음 step 후 안전 종료” 패턴. touch STOP 으로 5초만에 멈추는 경험.
3. NaN guard + grad norm 추세 로깅 — 일부러 LR 을 너무 높게 설정해 NaN 을 발생시켜본다. NaN 직전의 grad norm 그래프를 wandb 에 올려놓고 패턴을 본다.
4. py-spy dump 비교 워크플로 — 작은 multi-rank 학습을 띄우고 한 rank 에 일부러 sleep 을 박아 hang 을 만든다. py-spy dump --pid <PID> 를 모든 rank 에 실행 후 어떤 stack 이 다른지 비교.
5. checkpoint atomic write — tmp/ 에 저장 → fsync → rename 패턴 구현. 학습 중간에 노드를 강제 reboot 했을 때 corrupt checkpoint 가 안 생기는지 검증.

L090 의 운영 마인드는 시리즈 안에서 데이터/통신/체크포인팅 강의들과 짝을 이룬다.

• transcript 가 실패해서, 본 노트의 비율 수치(BLOOM 의 62% utilization 등)는 Stas 의 책에서 인용한 BLOOM/IDEFICS 회고를 정성적으로 옮긴 값이다. 강의 영상에서 직접 들은 다른 수치가 있을 수 있다 — 시청 후 보강 필요.
• 강의 안에서 다뤘을 가능성이 있는 추가 주제: GPU error correction · MIG 분할 운영 · NIXL/NVLink-Sharp 사용 · ElasticTraining(노드 동적 추가/제거). 영상 시청 후 § 추가 검토.
• 최근 추세: torch.distributed elastic, torchtitan 의 checkpoint pipelining, async checkpointing 의 표준화. 강의 시점이 어디인지에 따라 이 중 일부가 본문에 등장했을 가능성.
• 책과의 mapping: 강의에서 어떤 chapter 를 어떤 순서로 깔았는지가 transcript 없이는 정확히 안 보인다. 영상에서 직접 확인 후 본 노트의 § 02–§ 08 의 순서 조정 가능.
• 미언급 주제: 이 노트는 inference 운영을 거의 다루지 않는다 — 강의의 비중이 어느 쪽이었는지에 따라 inference 섹션이 추가될 필요.