Recovery fine-tune 선점 손실과 재제출

TL;DR

193004(recovery)와 193005(대조군)가 extra QOS에서 첫 checkpoint(500 step) 전에 선점됐고(2:30 / 2:03 경과, step 370 / 310), 자동 재제출도 실패했다.
재제출 실패 원인은 원래 sbatch 인자의 --dependency=afterok:192079(:193006). 이미 끝난 job이라 Job dependency problem으로 거부됐다.
--qos=own, SAVE_EVERY 500→250, dependency 제거로 재제출. 04:41경 둘 다 RUNNING.

~2.5 h×8

GPU 손실

0.04

step/s

3.5 h→1.7 h

저장 간격

~21 h

3000 step ETA

1배경/목적

10/14 18:09에 시작한 193004(recovery 1:1)와 193005(대조군)가 둘 다 첫 checkpoint 전에 선점됐고, 자동 재제출도 실패해 밤새 아무것도 돌지 않았다. 원인을 고쳐 다시 제출해야 했다.

2작업 내용

원인 분석

monitor.log: REQUEUE sbatch FAILED: lineage=orig-193005 rc=1 sbatch: error: Batch job submission failed: Job dependency problem (20:12; 193004는 20:38 동일)

sbmr requeue는 원래 sbatch 인자를 그대로 재사용한다. 의존 job이 이미 끝났으므로 재제출 자체가 거부됐다. sbmr에는 --dependency를 넣지 않는다.

작업 손실: extra에서 선점(193005 2:03 / step 310, 193004 2:30 / step 370). SAVE_EVERY=500, 0.04 step/s라 첫 저장까지 3.5 h가 필요해 checkpoint 없이 전부 잃었다.

조치

sbmr-stop으로 옛 lineage 제거 193353 lwam_fb_rec_ft / 193354 lwam_fb_ctrl_ft: --qos=own (4+4 = core own 상한 8 GPU), dependency 없음, --time 1-08:00:00 SAVE_EVERY 500 → 250 (약 1.7 h, state 35 GB × keep 2) 동일: INIT step_013690.pt, p48 norm stats, p768, 4 GPU × batch 2 × accum 8 = 64, 3000 step, lr 5e-5

3결과

run	상태	loss	action loss
193004 rec (손실)	step 370 선점	0.222 (video 0.188)	0.27 → 0.034
193005 ctrl (손실)	step 310 선점	0.158 (video 0.123)	0.19 → 0.035
193353 rec (own)	RUNNING, step 20	0.562	0.191
193354 ctrl (own)	RUNNING, step 20	0.571	0.207

속도 0.04 step/s (2.7 samples/s), 3000 step ETA 10/16 01:30 UTC경.

두 run이 core own 메모리(800 GB × 2)를 차지해 다른 own job(193358–193360 fb_insert_vid)이 QOSMaxMemoryPerUser로 대기 중이다.

4Takeaway

약 2.5 h × 8 GPU를 잃었다. 0.04 step/s의 p768 학습을 extra에서 돌리면 저장 간격(3.5 h) 안에 선점될 확률이 높다.

own QOS + 250 step 저장으로 선점 손실이 없고 최대 손실 간격이 약 1.7 h로 줄었다.

5Next

속도와 loss 추이 확인(ETA 약 21 h). 그동안 p768 평가 경로(rollout에서 768 frame history 유지)를 준비한다.

Recovery fine-tune (p48 → p768) 선점 손실과 재제출