step_013400의 rank 0 모델 state가 9.2GB → 510KB로 잘리고 optimizer state는 아예 누락됐다.PytorchStreamReader failed reading zip archive로 죽었고, 이게 PREEMPTED가 아니라 exitcode 1이라 sbmr 자동 requeue가 걸리지 않아 학습 체인이 40분간 조용히 멈췄다.trainer_state.json + latest 존재 확인) 추가로 수정.no-aug 24-task 학습 run(train_robocasa_flux2_4b.sh)이 preempt → 자동 재제출 흐름 중 갑자기 진행이 멈췄다. 큐에는 새 job이 없고 로그도 새로 안 찍히는 상태로 방치돼 있어, resume 체인 자체가 실패한 것으로 의심하고 원인을 추적했다.
extra QOS preempt가 상시 발생하는 환경이라(조직 정책상 5분 grace 후 SIGKILL), checkpoint resume이 안전하지 않으면 장기 학습(24-task, 20K+ step)이 반복적으로 조용히 끊길 수 있다.
preempt 시점 로그와 checkpoint 디렉토리 타임스탬프를 대조해, SIGTERM이 step_013400 DeepSpeed state 쓰기 도중에 들어왔음을 확인했다. mp_rank_00_model_states.pt가 정상이면 9.2GB여야 하는데 510KB로 잘려 있었고, rank 0 optimizer state 파일은 아예 생성되지 않은 채였다.
기존 resume 로직은 checkpoint 디렉토리들 중 step 번호가 가장 큰 것을 그대로 선택했다. 손상된 step_013400이 최신이었기 때문에 그대로 로드를 시도했고, PytorchStreamReader failed reading zip archive로 프로세스가 exitcode 1로 죽었다.
PREEMPTED 상태가 아니라 학습 프로세스 내부의 exitcode 1이다. sbmr의 preempt 자동 requeue는 sacct State가 PREEMPTED/CANCELLED일 때만 재제출을 트리거하므로, 이 케이스는 감지되지 않고 학습 체인이 그대로 멈췄다 (40분간 미발견).같은 조사 과정에서 학습 체인 감시 로직의 오판 2건을 발견했다.
| # | 증상 | 원인 |
|---|---|---|
| 1 | preempt 후 재제출 사이의 빈 큐를 "학습 종료"로 오인 | 자동복구가 꺼진 채로 남음 |
| 2 | 정상 완주(24-task 전부 성공)를 "체인 사망"으로 오보 | 큐가 빈 이유가 완주인지 사망인지 먼저 확인하지 않음 |
| 항목 | Before | After |
|---|---|---|
| resume 대상 선택 기준 | step 번호 최대값만 | step 최대 + 완결성 검사(trainer_state.json + latest) |
| 손상 checkpoint 감지 | 미검사 (로드 시도 후 exitcode 1로 발견) | 선택 단계에서 제외 |
| exitcode 1 정지 시 자동 requeue | 안 걸림 (PREEMPTED 아님) | 여전히 sacct State 기준 — 이번 수정 범위 밖, 별도 확인 필요 |
| 감시 스크립트 종료/사망 오판 | 2건 (그림 참고) | 둘 다 수정 완료 |
이 클러스터에서는 extra QOS preempt가 상시 발생하므로, checkpoint 쓰기 도중 SIGTERM이 들어와 손상되는 것은 "가끔 있는 사고"가 아니라 장기 학습에서 반복적으로 마주칠 정상 케이스로 취급해야 한다. resume 로직이 "가장 최근 것"만 믿고 완결성을 검사하지 않으면, 학습이 실패로 죽는 게 아니라 조용히 멈춘 채 방치되는 게 더 위험하다 — 이번에도 40분 동안 아무도 몰랐다. 감시 스크립트의 종료/사망 판정도 같은 맥락의 문제였다: "큐가 비었다"는 사실만으로는 완주인지 사망인지 구분이 안 되고, 반드시 별도 신호(완주 로그, 최종 step 도달 여부)로 교차 검증해야 한다.
exitcode 1로 죽는 케이스(이번처럼 preempt로 인한 간접 손상 포함)는 sacct State가 PREEMPTED가 아니므로 sbmr의 자동 requeue 트리거에 여전히 걸리지 않는다. 이번 수정은 "손상된 checkpoint를 안 집도록" 예방했을 뿐, exitcode 1 자체에 대한 감시/재시도 정책은 손대지 않았다.
감시 스크립트에 "exitcode 1 + 최근 checkpoint 쓰기 도중 preempt 로그"를 함께 감지해 자동 재제출하는 규칙을 추가할지 검토. 우선순위는 이번 주 no-aug ablation 후속(260817-noaug_ablation.html) 대비 낮음 — 현재는 재발 시 수동 재제출로 대응 가능한 빈도.