Index
2026-08-17 — Research

추론 시 생성량 축(0/1/2/N 프레임) 실험 — Cosmos Policy base 폐기, 다른 substrate로 이관

Cosmos Policy | 실험 설계 검토 → 오해 정정 → kill decision

TL;DR

0.5pt
Fast-WAM clean bench 효과
31.6pt
LIBERO-Plus에서만 나옴
619
GPU-h 기소실 (배경)
3
살아남는 델타 후보

1 배경 / 목적

2026-08-05 WAM 필드 서베이에서 나온 4-arm ChronoEdit 설계 이후, "첫+끝 프레임 2개만 생성했을 때의 효율 대비 많이 생성하면 성능이 얼마나 떨어지는가"를 보이는 추론 시 생성 프레임 수(0/1/2/N)를 축으로 한 실험을 별도로 설계하려 했다.

출발점의 문제: 이 프로젝트는 현재 random-init 사고로 보류 중이다(A/B 3일치, 619 GPU-h 무효). 새 실험을 설계하기 전에 — 특히 비용이 큰 축이라면 — 전제부터 검증할 필요가 있었다.

2 작업 내용

축을 설계하며 각 방법론이 "추론 시 몇 프레임을 생성하는가"의 어디에 위치하는지 원문 초록 수준까지 재확인했다.

추론 시 생성량누구비고
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 원문(arXiv 2603.16666) 재확인

"Most existing WAMs follow an imagine-then-execute paradigm, incurring substantial test-time latency from iterative video denoising, yet it remains unclear whether explicit future imagination is actually necessary for strong action performance." Fast-WAM: "retains video co-training during training but skips future prediction at test time" — 190ms, imagine-then-execute 대비 4x 빠름 "removing video co-training causes a much larger performance drop"

즉 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 후보를 코드에서 특정:

robocasa-cosmos-policy/robocasa/environments/kitchen/kitchen.py:999-1000 pos_noise = self.rng.normal(loc=0, scale=0.05, size=(1,3))[0] euler_noise = self.rng.normal(loc=0, scale=3, size=(1,3))[0] # agentview만 흔들림, eye_in_hand는 0 (:1002). σ를 x축으로 한 degradation curve 후보

3 결과 — Cosmos Policy base 폐기 사유 3가지

1. 생성량이 자연스러운 knob이 아니다. DiT의 temporal 축이 시간이 아니라 slot ID로 재목적화되어 있고, action/proprio/value 슬롯은 VAE를 안 거친 손으로 써넣은 raw latent다(claude/260805/research-cosmos_policy_latent_layout.md). "중간 프레임 N개 생성"은 매번 Arm B 수준의 수술(num_mid_frames, slot append, state_t 변경)을 요구한다.
2. 2-프레임 지점 자체가 이미 "생성"이라 부르기 어렵다. 추론에서 미래 프레임은 denoising step을 1번만 쓴다(--num_denoising_steps_future_state 1, action은 5). video WAM의 생성과 같은 축에 놓기 어렵다.
3. 비용. arm당 45K step ≈ 4 GPU × 2.2일. 여기에 σ sweep까지 곱하면 감당 불가. 이 repo는 이미 warm-start 버그로 619 GPU-h를 날린 이력(claude/260810)이 있어 추가 대형 실험을 정당화하기 어렵다.
재확인이 안 끝난 것 (아직 미완): ImageWAM이 보고한 FastWAM 51.5가 공정하게 설정된 baseline인지 — 제3자 측정이라 원문 표·설정 직접 확인 필요. Fast-WAM의 91.8/91.3/83.8은 초록 수준까지만 재확인됨(본문 표 미확인).

4 Takeaway

의미

비용이 큰 실험(4 GPU × 2.2일 × arm × σ sweep)을 던지기 전에 전제부터 검증해 잘못된 가정(Fast-WAM = 생성량 N) 위에서 설계를 진행하는 것을 사전에 차단했다. 이미 619 GPU-h를 날린 프로젝트에서, 이번엔 실행 전에 "깨끗한 벤치마크에서 효과가 안 나온다"는 것까지 데이터로 확인하고 멈췄다는 점이 이전 사고와의 차이다.

Cosmos Policy 자체는 여전히 보류 상태고 이 조사로 상태가 바뀌지 않는다. 다만 이 방향(생성-예산 축)은 Cosmos Policy와 별개의 substrate/세션으로 완전히 분리됐다 — Cosmos Policy가 재개되든 안 되든 독립적으로 진행 가능.

5 Next Steps

미해결 한계

ImageWAM의 FastWAM 51.5 baseline 공정성, Fast-WAM 91.8/91.3/83.8 수치의 본문 표 근거 — 둘 다 아직 원문 표 레벨까지 확인 안 됨. 이관될 substrate에서 착수 전 재확인 필요.

이관 시 살릴 것 (별도 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).

Cosmos Policy 프로젝트 자체

여전히 보류. 재개 절차는 claude/context.md §재개 절차 참조(Arm A/B 체크포인트 온전, warm-start 수정 완료 확인됨).