.pt 체크포인트를 조용히 스킵하는 버그 때문이며, 가설 자체가 “video prior가 더 나은 표현을 준다”이므로 검증이 성립하지 않습니다. 경위: random-init 사고 리포트TurnOnMicrowave 하나(A 40 / B 0).state_t=13 학습 → state_t=11 추론 로딩이 실제로 동작한다.학습이 arm당 45K step / 약 2.5일이라, 끝에서야 결과를 보면 (a) 파이프라인 버그를 뒤늦게 발견하거나 (b) 이미 실패한 arm에 GPU를 이틀 더 쓴다.
| 수단 | 상태 |
|---|---|
run_validation | False — validation loop 없음 |
every_n_sample_reg | every_n=100000 — 45K까지 가도 한 번도 안 돎 |
per-component 지표(action_l1_loss 등) | 코드엔 있으나 wandb로만 전송 → 워커 TLS 문제로 껐기 때문에 소실 |
Loss:뿐인데, 이건 arm 간 비교가 불가능하다 — B는 mid-frame denoise 항이 추가되고 dropout에 따라 slot 수가 11/13으로 바뀐다. 그래서 실제 태스크 성공률로 중간 곡선을 뽑기로 했다.| 파일 | 역할 |
|---|---|
scripts/dcp_to_pt.py | DCP → .pt 변환. 덮어쓰기 거부, 재실행 안전 |
scripts/eval_ckpt_job.sh | 체크포인트 1개: 변환 → 6 task × 20 trial |
scripts/submit_ckpt_evals.sh | 멱등 드라이버. 마커 파일로 중복 방지 — 워처가 죽어도 재실행하면 따라잡는다 |
30분 주기 워처(PID 40487)가 5K/15K/30K/45K 도달 시 자동 제출한다.
Arm 0 수치만 보고 정했다. 포화 task(TurnOffMicrowave 99.3, CloseDrawer 98.7)는 어느 쪽으로도 차이가 안 보여 제외. 진단용이며 최종 판정에 쓰지 않는다.
학습은 DCP 샤드 디렉토리(.metadata + __N_0.distcp)를 쓰는데, model_loader.py:218이 load_from_local = True를 하드코딩해 모든 비-s3 경로가 easy_io.load()로 간다. easy_io는 파일 확장자로 포맷을 판단하므로 확장자 없는 디렉토리에서 죽는다. 바로 아래 DCP 네이티브 분기는 s3://에서만 실행되어 도달 불가능한 죽은 코드다.
state_t=13 학습 가중치를 state_t=11 설정으로 로드하는 것이 설계의 핵심인데 한 번도 실행된 적이 없었다. 2500 체크포인트로 확인: 687키가 공식 715키의 완전한 부분집합(빠진 28개는 전부 _extra_state), shape 불일치 0, 공식 대비 mean|Δ| 0.012~0.030 → 실제 학습된 별개 모델. 행동도 NaN 0건 / 고유 action 2371개로 정상. 0%는 로딩 실패가 아니라 미학습(5.6% 지점).| iter | Arm A (stock) | Arm B (mid-frame) | Δ |
|---|---|---|---|
| 5K | 0.0 | 0.0 | 0 |
| 15K | 19.2 | 10.0 | −9.2 |
| 30K | 대기 (~7.5h 후) — 판별 지점 | ||
| task | A | B | Δ |
|---|---|---|---|
| TurnOnMicrowave | 40 | 0 | −40 |
| OpenSingleDoor | 65 | 55 | −10 |
| PnPCounterToSink | 5 | 0 | −5 |
| PnPCounterToCab | 5 | 5 | 0 |
| PnPStoveToCounter | 0 | 0 | 0 |
| CoffeeSetupMug | 0 | 0 | 0 |
전반적 열화가 아니다. B는 TurnOnMicrowave에서 20회 전부 500스텝 타임아웃(A는 평균 399스텝) — 아직 이 태스크를 못 여는 상태다.
| Arm | Job | iter | 속도 | GPU util | 45K까지 |
|---|---|---|---|---|---|
| A | 72438 (n21) | ~23,900 | 4.26 s/it | 95~100% | ~25h |
| B | 72439 (n2) | ~24,400 | 5.06 s/it | 99~100% | ~28.6h |
sjob 진단 무경고. 920~940W/1000W, GPU 메모리 105/178 GiB(40% 여유 — batch 50이 가능했다는 뜻), CPU 23~24% throttle 0%.
(a) 늦게 배우는 중 — B의 목적함수는 엄격히 더 어렵다(denoise 대상 13개 vs 11개, dropout으로 절반은 11개). 같은 step 수에서 뒤처지는 것은 예측되는 바이며, 이런 정책은 태스크가 0→40→70 계단식으로 풀리므로 B가 아직 못 열었을 뿐일 수 있다.
(b) 그냥 더 나쁘다 — mid-frame slot이 용량·gradient만 가져가고 아무것도 돌려주지 않는다. 설계 당시 적어둔 사망 시나리오 1번(action chunk supervision이 이미 dynamics를 준다)이다.
프로브는 1 seed × 20 trial이라 6-task 평균 노이즈가 ±3.6pt. 9.2pt는 시사적이나 결정적이지 않다.
state_t 전환 전제를 45K가 아니라 2500에서 잡았다.격차 좁혀짐 → (a). B를 45K까지 계속
유지·확대 → (b) 유력. scancel 72439로 B 중단, 4 GPU 반환. 45K 전체 평가 불필요
Arm A는 어떤 경우에도 45K까지 계속한다 — baseline 자체로 가치가 있고, 축소 batch(global 200 = 논문의 1/4)가 논문 67.1%에 얼마나 근접하는지 보여준다.
DCP 변환 → 24 task × 3 seed 전체 → 사전 등록 지표로 판정: 1차 24-task 평균(kill criterion 5pt, 노이즈 0.79pt) / 2차 PnP 8-task 평균 / 개별 task는 15pt 미만 주장 금지.
max_iter=1000000이라 45K에서 자동 정지하지 않는다. 학습을 돌려둔 채 평가하고 결과를 본 뒤 취소한다 — 곡선이 아직 가파르면 90K까지 계속하는 선택지가 살아있다(A 4.4일 / B 4.9일, 7일 제한 안).
wandb를 꺼서 per-component 지표가 없다. 되살리려면 job.wandb_mode=offline + 재시작이나, 현 시점 손실이 커서 이번 실험에서는 포기한다.