X-WAM_MoT — 게이트 중간 평가 (step 10k, RoboCasa 24×10)

TL;DR

SR 37.1% (89/240, 24 task × 10 rollout) — mot_v1b 게이트 학습(job 86008)이 20k step 중 10k(절반) 지점에서의 스냅샷 평가
붕괴 패턴 아님: X-WAM 이력상 레시피 실패 시 SR 15.6%로 PnP 계열이 전부 0~6%로 무너지는데, 이번엔 Close/Open/Turn 계열 60~100%로 정상 분포하고 PnP도 0~50%로 흩어짐
PnP가 상대적으로 뒤처짐: PnP(8task) 20.0% vs non-PnP(16task) 45.6%, 비 0.45 vs 0.66 — cosine LR 후반 anneal이 정밀 조작 스킬에 크게 기여한다는 기존 관찰과 방향 일치
MoT 평가 경로 최초 검증: policy_server 로드 경로(state dict missing=0/unexpected=0, generate() 2.6s)가 이번에 처음 정상 확인됨
⚠️ arm A 최종(61.0%)과 직접 비교 불가 — arm A는 20k 완주 시점 수치이고 이번은 10k 중간. 같은 시점 비교 데이터 자체가 없음

37.1%

SR ALL (10k)

20.0%

SR PnP

45.6%

SR non-PnP

240

Rollout (24×10)

1 배경 / 목적

mot_v1b 게이트 학습(job 86008, 4-GPU own, 20k step)이 절반(10k)을 지난 시점에서 붕괴 여부를 조기에 확인하기 위한 헬스체크. X-WAM 이력상 레시피가 잘못되면 SR이 15.6%로 주저앉고 PnP 계열이 전부 0~6%로 붕괴하는 특징적 패턴이 나왔기 때문에, 지금 학습이 그 패턴을 밟고 있는지 조기에 걸러내는 것이 목적. 10 rollout이라 통계적 오차(SE)가 커서 최종 판정용은 아니다.

부수 목적: MoT 모델이 평가 경로(policy_server 로드 방식)를 통과한 적이 한 번도 없었으므로 그 경로 자체의 정상 동작 검증.

기존 한계: 08-19까지 MoT 모델은 학습 loop 안에서만 forward를 거쳤을 뿐, 저장된 체크포인트를 XWAMRunner가 로드해서 generate()까지 완주하는 평가 경로는 한 번도 검증되지 않은 상태였다.

2 작업 내용

절반 지점(step 10000) 체크포인트를 별도로 스냅샷한 뒤, 로그인에서 로드 경로만 스모크로 검증하고, 실제 SR 측정은 sbatch로 분리했다.

1) tmp/snapshot_10k_v1b.sh - job 86008의 step-10000 체크포인트를 mid10k.ckpt로 하드링크 스냅샷 - save_top_k=1이라 30분 뒤 자동 삭제되는 체크포인트를 붙잡기 위함 (디스크 비용 ~0, 학습 무간섭) 2) 로그인 스모크: tmp/smoke_eval_load.py (GPU 1, 수 분) - experiment config.yaml → XWAMRunner(use_mot=True) - mid10k.ckpt/checkpoint/mp_rank_00_model_states.pt 로드 → generate() - §1 debug threshold 준수: 로드+생성 1회만 (전체 SR 측정은 로그인 금지 — 240 rollout ≈ 1.6 GPU-h) 3) 본 평가: sbatch job 87854, own 2 GPU EVALS=10 STEPS=mid10k SAVE_ROOT=... (requeue 함정 회피 위해 명시) cfg=0 / denoise 50 step / action 10 — arm A~D와 동일 프로토콜

10 rollout으로 잡은 이유: 20k 완주 후 24×50(1200 rollout) 최종 평가와 별개로, "학습이 정상 궤도인지"만 빠르게 확인하는 것이 목적이라 SE가 큰 대신 GPU 비용을 최소화했다.

3 결과

로드 검증 통과: state dict missing=0 / unexpected=0, generate() 2.6s, actions shape (1,32,14) 전부 finite, std 0.70 → MoT 평가 경로 정상 동작 최초 확인.

subset	mid10k (step 10k)	arm A 최종 (step 20k)	비
ALL (24 task)	37.1% (89/240)	61.0%	0.61
PnP (8 task)	20.0% (16/80)	44.0%	0.45
non-PnP (16 task)	45.6% (73/160)	69.6%	0.66

태스크 분포(발췌): CloseDrawer 100%, TurnOffSinkFaucet 80%, OpenDrawer 70%, CloseDoubleDoor / CoffeePressButton / OpenSingleDoor / TurnOffMicrowave 60% … PnPCabToCounter · PnPSinkToCounter · CoffeeSetupMug 0%.

붕괴 패턴 아님: 과거 15.6% 실패 사례는 PnP 전부 0~6% + 전 태스크 붕괴였는데, 이번엔 Close/Open/Turn 계열이 60~100%로 정상 분포하고 PnP도 0~50%로 흩어져 있다 — 레시피(eff 128 / lr 3e-5 / 4 GPU accum 8)가 정상적으로 작동 중이라는 신호.

비교 주의: mid10k 수치를 arm A(61.0%)와 직접 비교하면 안 된다 — arm A는 20k 완주 시점, 이번은 10k 중간 스냅샷이라 학습 진행률 자체가 다르다. arm A의 10k 중간 SR은 측정된 적이 없어(체크포인트 미보관) 같은 시점 비교 자체가 불가능하다.

4 Takeaway

의미

mot_v1b가 절반 지점에서 정상 궤도에 있다는 것을 확인했다는 점에서, 4-GPU own으로 전환하며 감수한 ETA 손실(~19.4h→~38h, 전날 카드 참고)이 무의미한 시간 소모가 아니라는 근거가 생겼다. 동시에 PnP 계열이 non-PnP보다 명확히 뒤처지는 패턴(비 0.45 vs 0.66)이 관찰됐는데, 이는 cosine LR 스케줄의 후반 anneal이 정밀 조작 스킬 학습에 특히 중요하다는 기존 관찰과 일치한다 — 최종 20k 완주 후 후반 10k에서 PnP가 얼마나 따라잡는지가 arm A 대비 판정을 좌우할 핵심 변수로 좁혀졌다.

5 Next Steps

미해결 한계

10 rollout 기반이라 SE가 커서 태스크별 수치(특히 0%/100% 극단값)의 신뢰도가 낮다. arm A와의 "같은 시점" 비교가 불가능한 것도 구조적 한계 — arm A 쪽에 중간 step 체크포인트가 남아있지 않아 사후 재현이 안 됨.

다음 실험

1) mot_v1b 완주(step 20k, 08-21 새벽 예상) 후 24×50 최종 평가 → arm A 61.0%와 정식 비교 (밴드: ≥65% 개선 / 57~65% 동등 / <57% 회귀). 특히 PnP subset이 non-PnP만큼 anneal 효과를 받는지 확인. 2) 그 다음 frame sparsity 2 arm(dropmid → mae25) 4-GPU 순차 진행 (사용자 확정 순서).

게이트 중간 평가 (step 10k / 20k, RoboCasa 24×10)