260818에 제출한 MoT 게이트 학습(job 84180, mot_v1_nodepth, 8-GPU extra QOS, 20k step)이 RUNNING으로 전환된 뒤에도 클러스터가 붐빌 때마다 다른 사용자의 own 작업에 의해 계속 preempt됐다. extra QOS는 CANCEL 모드로 즉시 종료되며(재큐 없음), 매번 sbmr이 자동 재제출은 하지만 PENDING 대기까지 포함하면 완주까지 실질적인 시간이 계속 늘어나는 상황이라, 안정적으로 20k step을 끝까지 돌릴 수 있는 GPU 배정 전략을 다시 정해야 했다.
extra QOS는 preempt 시 requeue가 아니라 CANCEL이라 진행 중이던 step이 그대로 소실되고, 재제출된 job은 큐 맨 뒤에서 다시 PENDING 대기를 거쳐야 한다.sacct 기준 260818~260819 사이 6개 job의 실제 이력을 재구성:
| Job | QOS/GPU | 시작 | 결과 | Elapsed |
|---|---|---|---|---|
| 84180 | extra / 8 | 08-18 04:53 | PREEMPTED | 42m34s |
| 84245 | extra / 8 | 08-18 10:04 | PREEMPTED | 1h26m59s |
| 84543 | extra / 8 | 08-18 19:17 | PREEMPTED | 3h39m31s |
| 85289 | extra / 8 | — (PENDING) | CANCELLED (user) | 0s |
| 85692 | own / 8 | 08-19 11:28 | CANCELLED (user) | 5h15m56s |
| 86008 | own / 4 | 08-19 16:45 | RUNNING | 16h47m+ (진행중) |
84180/84245/84543는 다른 사용자의 own job 도착으로 preempt(CANCEL). 84543 종료 후 재제출한 85289는 시작도 못 하고 사용자가 직접 취소 — 이 시점에 extra 경로를 포기하고 own으로 전환 시도. 85692는 own으로 8 GPU 전부를 확보해 5h15m 정상 실행됐지만, context.md에 명시된 대로 own 쿼터(core 그룹 8 GPU 상한) 전체를 MoT 하나가 쓰면 병행 중인 다른 프로젝트가 own GPU를 못 받는 문제가 있어 사용자가 직접 취소했다.
GPU 수를 8→4로 줄이면서도 유효 배치(eff 128)는 동일하게 유지 — GATE_GPUS=4로 per-GPU micro-batch/accum을 재계산해 4×bs4×accum8로 재구성했고, lr 3e-5 등 나머지 레시피는 손대지 않았다. 단, 8-rank DeepSpeed ZeRO 체크포인트는 4-rank로 재개할 수 없다는 제약 때문에 84543까지 쌓인 진행분(약 4,700 step)은 그대로 폐기하고 86008을 step 0부터 새로 시작했다.
context.md 기준 체감 대기는 약 12.5h.epoch=3-step=8000.ckpt 저장 확인 (20000 step 중 40% 진행), 속도 0.144 it/s. 이전 8-GPU 레짐(0.286 it/s, ETA 19.4h)과 비교하면 처리량은 절반 수준이라 총 ETA는 ~38h로 거의 2배 늘었지만, own QOS라 완주까지 preempt 위험은 없다.| 지표 | 8-GPU extra (84180계열) | 4-GPU own (86008) |
|---|---|---|
| 처리량 | 0.286 it/s | 0.144 it/s |
| ETA (20k step) | ~19.4h | ~38h |
| Preempt 위험 | 있음 (실측 3회) | 없음 |
| 이번 세션 실측 완주 | 0/4 시도 | 진행중 (8000/20000) |
20k step(~19~38h) 규모의 게이트 학습에는 extra QOS가 구조적으로 부적합하다는 것이 이번에 실측으로 확인됐다 — preempt 3연속으로 실행분 5h48m을 그냥 날렸고, 매 재제출마다 큐 대기가 추가된다. own으로 옮기면 GPU 수를 줄인 만큼(8→4) 처리량이 정확히 절반 근처로 떨어져 ETA가 거의 2배(19.4h→38h)가 되지만, "언젠가 끝난다"는 보장을 얻는 트레이드오프다. 8-rank ZeRO 체크포인트가 4-rank에서 재개 불가능하다는 것도 이번에 확인된 제약 — 앞으로 GPU 수를 바꿀 계획이 있다면 체크포인트 호환성을 먼저 확인해야 한다.
86008이 preempt는 면했지만 own 4-GPU라 처리량이 낮아 ETA가 38h로 늘어났다 — 08-20 밤 완주 예상. 완주 전까지는 RoboCasa 평가를 시작할 수 없어 arm A(61.0%) 대비 판정이 그만큼 밀린다.
1) tmp/watch_mot_v1b.sh로 86008 완주 감시, step 20000 도달 확인. 2) 완주 후 RoboCasa 24×50 평가 → arm A 61.0% 대비 판정(밴드: ≥65% 개선/57~65% 동등/<57% 회귀). 3) frame sparsity 게이트 2 arm(dropmid→mae25)도 순차 제출 예정인데, 이번 preemption 이력을 감안하면 처음부터 own QOS(4 GPU, 나머지 4 GPU는 병행 프로젝트용)로 제출하는 편이 재시작 낭비를 피할 수 있다.