2026-08-05 WAM 필드 서베이에서 나온 4-arm ChronoEdit 설계 이후, "첫+끝 프레임 2개만 생성했을 때의 효율 대비 많이 생성하면 성능이 얼마나 떨어지는가"를 보이는 추론 시 생성 프레임 수(0/1/2/N)를 축으로 한 실험을 별도로 설계하려 했다.
축을 설계하며 각 방법론이 "추론 시 몇 프레임을 생성하는가"의 어디에 위치하는지 원문 초록 수준까지 재확인했다.
| 추론 시 생성량 | 누구 | 비고 |
|---|---|---|
| 0 (video co-train만) | Fast-WAM | 애초 가정과 반대 위치 |
| 1 (target frame만, dynamics 없음) | ImageWAM | |
| 2 (t, t+K) | Cosmos Policy | 미래 프레임 denoising 1 step뿐 |
| N (전체 video) | 고전 imagine-then-execute WAM |
즉 Fast-WAM은 "많이 생성하는" 쪽이 아니라 "Fast"의 이유 자체가 추론에서 생성을 스킵하기 때문이었다. ImageWAM(2606.19531)이 제3자로 측정한 "FastWAM 51.5%"(LIBERO-Plus)는 Fast-WAM 자기 논문에는 없는 수치라 이 숫자에 주장을 걸면 취약하다는 점도 함께 확인.
Fast-WAM 자기 데이터(RoboTwin)가 test-time 생성 유무를 91.8% vs 91.3%로 보고 — 이미 반증되어 있다. 31.6pt 격차는 LIBERO-Plus(perturbation)에서만 나오므로, 어떤 substrate를 쓰든 OOD 축이 1차 제약이라는 것을 확인. RoboCasa로 옮긴다면 쓸 수 있는 진짜 extrapolation 후보를 코드에서 특정:
claude/260805/research-cosmos_policy_latent_layout.md). "중간 프레임 N개 생성"은 매번 Arm B 수준의 수술(num_mid_frames, slot append, state_t 변경)을 요구한다.--num_denoising_steps_future_state 1, action은 5). video WAM의 생성과 같은 축에 놓기 어렵다.claude/260810)이 있어 추가 대형 실험을 정당화하기 어렵다.비용이 큰 실험(4 GPU × 2.2일 × arm × σ sweep)을 던지기 전에 전제부터 검증해 잘못된 가정(Fast-WAM = 생성량 N) 위에서 설계를 진행하는 것을 사전에 차단했다. 이미 619 GPU-h를 날린 프로젝트에서, 이번엔 실행 전에 "깨끗한 벤치마크에서 효과가 안 나온다"는 것까지 데이터로 확인하고 멈췄다는 점이 이전 사고와의 차이다.
Cosmos Policy 자체는 여전히 보류 상태고 이 조사로 상태가 바뀌지 않는다. 다만 이 방향(생성-예산 축)은 Cosmos Policy와 별개의 substrate/세션으로 완전히 분리됐다 — Cosmos Policy가 재개되든 안 되든 독립적으로 진행 가능.
ImageWAM의 FastWAM 51.5 baseline 공정성, Fast-WAM 91.8/91.3/83.8 수치의 본문 표 근거 — 둘 다 아직 원문 표 레벨까지 확인 안 됨. 이관될 substrate에서 착수 전 재확인 필요.
① 단일 백본 위에서 0/1/2/N을 통제 비교하는 sweep(ImageWAM↔FastWAM 비교는 백본·스케일·데이터·text encoder가 전부 달라 교란됨, 아직 없음) ② "t와 t+K 둘 다 쓰면 delta가 표현에 들어온다"는 2-프레임 지점 자체의 ablation(ImageWAM=1, FastWAM=0, 아직 아무도 안 함) ③ σ를 x축으로 한 degradation curve. Arm B 구현이 N-프레임 arm과 기계적으로 동일(추론에서 mid frame을 버리는지 여부 차이뿐)이므로 설계는 재사용 가능. 효율 측정(latency/FLOPs)은 login이 아니라 sbatch로 진행(클러스터 §2).
여전히 보류. 재개 절차는 claude/context.md §재개 절차 참조(Arm A/B 체크포인트 온전, warm-start 수정 완료 확인됨).