중간 프레임은 필요한가 — WAM 서베이와 ChronoEdit 방향

TL;DR

질문 1의 답은 이미 나와 있다: Fast-WAM — test-time 미래 생성은 91.8% vs 91.3%(무의미), 학습 시 video co-training 제거는 91.8% → 83.8%(치명적). 중간 프레임을 추론에서 굴리는 건 비용만 4.3배.
제안의 뼈대는 스쿠핑됨: ImageWAM(2606.19531, 2개월 전)이 image editing backbone + MoT action expert를 이미 검증. RoboTwin 93.38%, LIBERO-Plus 83.1% (FastWAM 51.5%).
그러나 갭이 남는다: ImageWAM의 backbone은 전부 dynamics 없는 generic editor(FLUX.2/OmniGen2). ChronoEdit식 일시적 reasoning token을 action expert와 결합한 사례는 없음.
핵심 nugget: ChronoEdit이 비계로 버리는 reasoning frame이야말로 action head가 원하는 "골까지 어떻게 움직이는가" 신호다. → action expert를 최종 프레임이 아닌 reasoning token에 attend.
Cosmos Policy 진단: video dynamics 이득도, editing prior도 없는 중간 지대.

0.5pt

test-time 생성 이득

8.0pt

학습 video objective 이득

+16%

ChronoEdit reasoning 비용

15+

6개월간 WAM 논문

1 배경 / 목적

Cosmos Policy가 t와 t+K만 쓰고 중간 프레임을 버린다는 걸 코드로 확인한 뒤, 두 가지 의문이 생겼다.

의문 1

중간 프레임 예측을 넣으면 실제로 얼마나 좋아지는가? 직관적으로 필요한 건 중간 프레임 자체가 아니라 "최종 골"과 "거기까지 어떻게 움직이는가"다.

의문 2

ChronoEdit처럼 중간에 reasoning frame을 넣어 denoising하는 image editing 모델을 backbone으로 로봇 데이터에 finetune하고, action transformer를 MoT로 붙여 WAM처럼 쓰면? 이득이 뭘지, 어떻게 더 효율적으로 쓸지.

주의: 조사한 논문 대부분이 2026년 2~7월 발표로 knowledge cutoff 이후다. 웹 fetch 요약 기반이므로 착수 전 원문 직접 확인 필요.

2 질문 1의 답 — 중간 프레임 "생성"은 거의 무의미

Fast-WAM(2603.16666)이 정확히 같은 질문을 던졌다: 성능 향상이 (a) 학습 시 video objective로 좋은 표현을 배워서인가, (b) 추론 시 실제 프레임을 생성해서인가?

RoboTwin	Success	해석
Fast-WAM (test-time 생성 없음)	91.8%	기준
Fast-WAM-IDM (imagine-then-execute)	91.3%	−0.5pt — 노이즈 수준
Fast-WAM (video co-training 제거)	83.8%	−8.0pt — 치명적

실제 towel folding: 75% → 10%(co-training 제거). 지연시간 190ms vs 810ms(4.3배).

결론: 미래 프레임 "생성" 행위 = 0.5pt. 학습 목적함수로서의 video = 8pt. 직관이 데이터와 일치한다.

방증: Efficient-WAM은 미래 latent를 384×320 → 192×160로 낮추고(토큰 240→60) video denoising을 2 step만 써서 30배 speedup, 성능 손실 미미. 미래 프레임이 담아야 할 정보량 자체가 매우 적다.

3 Cosmos Policy 진단 — 두 이득을 모두 놓치는 중간 지대

Fast-WAM 논리대로면 8pt를 주는 건 training-time video objective다. 그런데 Cosmos Policy의 학습 신호는 video가 아니다 — 2프레임 점프 + 손으로 써넣은 raw latent.

	video dynamics 이득	instruction-aligned editing prior
video WAM (FastWAM 등)	O	X
ImageWAM	X	O
Cosmos Policy	X	X

가설(미검증): 사전학습 가중치는 video 모델에서 가져오지만 finetuning 목적함수가 video 구조를 파괴하므로 dynamics 이득을 못 받고, editing 목적함수도 아니라 instruction→change 정렬도 없다.

4 스쿠핑 확인 — 뼈대는 이미 나왔다

ImageWAM: "Do World Action Models Really Need Video Generation, or Just Image Editing?" (2606.19531, 2026-06)

겹치는 부분: - image editing 모델 backbone (OmniGen2 / FLUX.2 4B·9B / Ovis-U1) - 로봇 데이터로 finetune - MoT로 action expert 부착 (language / visual condition / visual prediction / action 4종 joint attention) - action head를 editing 모델 weight 복사·보간으로 초기화 (642M–1.1B) - 단일 target frame 예측 + editing 과정의 intermediate KV cache 활용

Benchmark	ImageWAM	LingBot-VA	FastWAM	π₀
RoboTwin 2.0 (clean+random)	93.38%	92.20%	91.83%	—
LIBERO 포화	98.4%	98.5%	97.6%	—
LIBERO-Plus (perturbation)	83.1%	—	51.5%	—
Real-world (4 task)	84.5%	—	79.0%	55.8%

지연 263ms vs 1081ms(4배), FLOPs 9.72 vs 63.65 TFLOPs(6.5배). backbone 3종 모두 FastWAM 초과.

스쿠핑: "image editing backbone + MoT action expert" 조합은 이미 검증됐고 SOTA를 이겼다. 이 상태로는 부분집합이 된다.

5 남은 갭 — ChronoEdit은 generic editor가 아니다

ImageWAM이 쓴 backbone은 전부 dynamics 개념이 없는 generic editor다. 즉 ImageWAM의 메시지는 "dynamics 버려도 된다"이다. ChronoEdit은 video 모델을 editor로 재목적화하면서 일시적 temporal reasoning token을 넣는다.

항목	값
reasoning frame	latent 6개 (= 픽셀 24프레임), 총 T=8
활성 구간	초기 high-noise step만 — N_r=10 / 전체 N=50
이후	reasoning token drop, 나머지 40 step은 output latent만 refine
비용 (2×H100)	30.4s (N_r=0) → 35.3s (N_r=10, +16%) → 55.5s (전 구간)
효과 (PBench-Edit)	Action Fidelity 4.01 → 4.31, overall 4.43 → 4.53
drop 방식	inference-time only — 학습 시엔 전 구간 concat
base model	14B = Wan2.1-I2V-14B / 2B = Cosmos-Predict2.5-2B

근거: "the first few noisiest steps of a flow/diffusion trajectory determine the global structure."

확인: 검색 결과 ChronoEdit 계열 reasoning token을 로봇 action expert와 결합한 논문은 없다.

6 Takeaway

핵심 nugget — "ChronoEdit이 버리는 것이 우리가 갖고 싶은 것"

ChronoEdit에서 reasoning frame은 버려질 비계(scaffolding)다. 그런데 WAM 관점에서 그 프레임들은 "골까지 어떻게 움직이는가"를 담은, action head가 정확히 원하는 신호다.

→ Action expert를 최종 프레임이 아니라 reasoning token에 attend시킨다.

ImageWAM은 "editing의 표현"을 쓰고, 이 제안은 "editing 과정의 궤적"을 쓴다. 한 문장으로 설명되는 delta이며, 이것이 없으면 ImageWAM의 부분집합이다.

Fast-WAM vs ImageWAM 긴장의 제3의 답: Fast-WAM은 "dynamics는 학습에서 중요"(8pt), ImageWAM은 "생성은 추론에서 낭비"(4배). ChronoEdit 방식은 global structure가 결정되는 high-noise 구간에만 dynamics를 내부에 두고 버린다 — 4배가 아니라 16%.

실무적 이점: ChronoEdit-2B가 Cosmos-Predict2.5-2B 기반이다. Cosmos Policy 백본과 같은 계열 2B라 backbone 고정 후 slot layout만 바꾸는 controlled comparison이 가능하다. RoboCasa 98% 재현 기준선도 이미 확보.

7 효율성 설계

가장 강한 변형 — reasoning frame을 학습에만 쓰고 추론에선 완전 제거

Fast-WAM(생성은 추론에서 무용) + ChronoEdit(reasoning은 학습에 내재)의 자연스러운 합성. 성공 시 추론 비용은 ImageWAM과 동일한데 dynamics-informed 표현을 공짜로 얻는다. ChronoEdit이 이미 "학습 전 구간 / 추론 drop"이므로 한 발만 더 가면 된다.

denoising step 비율 재설계

ChronoEdit은 50 step 중 10인데 action은 5 step이면 끝난다(num_denoising_steps_action=5). 비율이 안 맞음 → Efficient-WAM식 비대칭(video 2 step / action 10 step) 필요.

reasoning frame 저해상도화

Efficient-WAM 선례(384×320→192×160, 토큰 240→60). 비계라면 더 낮춰도 될 가능성. Cosmos Policy의 검은 이미지 슬롯 tokenizer 인코딩 낭비도 이 재설계에서 같이 정리된다.

8 이 아이디어가 죽는 시나리오

1. [가장 유력] reasoning token이 editing엔 되지만 manipulation엔 안 되는 경우. editing은 정적 장면의 물리적 타당성이 목표인데, manipulation은 action chunk supervision에서 이미 dynamics를 받는다. 중복일 수 있다. → 제일 먼저 싸게 테스트.

2. 경쟁 설명: AGRA (2606.12217). "action-grounding gap" — 그럴듯한 예측 ≠ 행동 가능한 표현. video diffusion hidden state를 frozen DINOv2 feature와 정렬만으로 in-distribution 80%(baseline 34%), RoboCasa 66.4%(GR00T +18.8pt), OOD +27~32%. reasoning token 이득이 더 싼 alignment loss로 재현되면 기여가 사라진다. baseline 필수 포함.

3. 필드 포화. 6개월간 WAM 논문 15편 이상(Motus, MaskWAM, MV-WAM, HiMem-WAM, DSWAM, τ₀-WM, ST-WAM, ABot-M0.5, GigaWorld-policy…). ImageWAM 대비 delta가 한 문장으로 안 나오면 안 읽힌다.

4. LIBERO 포화(98.4%). LIBERO-Plus / RoboTwin randomized / real-world 아니면 신호가 안 보인다.

9 Next Steps

1. [1일] 체크포인트 + 원문 검증

ChronoEdit-2B 확보 및 Cosmos-Predict2.5-2B와의 관계 확인. 같은 계열이면 Cosmos Policy config에 그대로 꽂힐 가능성. ImageWAM / Fast-WAM 원문 직접 검증 병행.

2. [가장 싼 kill test] reasoning slot 추가

Cosmos Policy LIBERO에 state_t=9 → 9+R, 중간 프레임 R개를 실제 latent로 넣고 denoise 대상에 포함. 학습에만 쓰고 추론 시 drop. R=2, 4 비교.

가설: 깨끗한 LIBERO에선 차이가 안 나고 LIBERO-Plus(robustness)에서 갈린다.

3. 이기면 → MoT 확장

action expert를 reasoning token에 attend시키는 구조로. 여기가 진짜 기여.

4. 평가 원칙

처음부터 LIBERO-Plus + RoboCasa randomized로. 깨끗한 LIBERO 숫자는 버린다. baseline에 AGRA식 representation alignment 반드시 포함(사망 시나리오 2 차단).

10 업데이트 — reasoning token은 video generation과 무엇이 다른가

질문: reasoning token은 video 생성 대비 얼마나 적게 드는가? 애초에 넣는 것 자체가 video 생성과 같은 것 아닌가?

답: 기계적으로는 동일하다. 별도의 reasoning 모듈은 없다. latent 8개짜리 시퀀스를 denoise할 뿐이고, 학습 시 reasoning frame도 실제 비디오 프레임에 대해 supervise된다. 아키텍처·목적함수·데이터가 전부 video generation과 같다. N_r=50은 문자 그대로 video generation이다.

[input latent] [r1] [r2] [r3] [r4] [r5] [r6] [output latent] └──── reasoning = 픽셀 24프레임 ────┘

차이는 두 가지뿐 — 스케줄과 출력 선택

N_r	총 시간	증분	reasoning step당 한계비용
0	30.4s	—	—
10	35.3s	+4.9s	0.49 s/step
50	55.5s	+25.1s	0.50 s/step

두 계산이 일치 → latent 6개를 더 이고 가는 비용은 step당 약 0.5초. 기본 step 비용 ~0.6 s/step 대비 step당 약 1.8배. 토큰은 4배(T=2→8)인데 1.8배인 건 고정 오버헤드(text encoder, VAE decode)와 attention 구현 때문.

즉 +16%는 step당 싸서가 아니라 50 step 중 10 step만 켜서 나온 숫자다. 두 번째 차이: reasoning latent는 VAE decode를 하지 않고 N_r에서 버려지므로 끝까지 denoise되지도 않는다. 최종 출력이 attend하는 건 선명한 비디오가 아니라 거친 궤적 스케치다.

가장 정확한 명명: coarse-trajectory conditioning

video generation이 아니다. Efficient-WAM이 미래 latent를 저해상도로 낮춘 것과 같은 통찰이며, 축이 공간 해상도가 아니라 노이즈 레벨이다.

이전 판단 정정 — "+16%"는 로봇 정책에 그대로 오지 않는다

Cosmos Policy의 action denoising은 5 step이다(num_denoising_steps_action=5). 같은 20% 비율이면 reasoning은 1 step만 켜진다. ChronoEdit은 global structure를 잡는 데 10번의 joint denoising 반복을 쓴다 — 1번으로 궤적 구조가 잡힐 근거가 없다. 현실적으로 5 step 중 2~3 step은 켜야 하고, 그러면 오버헤드는 +40~60%다(추정치, 측정값 아님). 앞 절의 "4배가 아니라 16%" 프레이밍은 로봇 세팅에서 성립하지 않는다.

결과적으로 살아남는 버전

추론 시 reasoning을 켜는 변형은 효율성 논거가 약하다. 남는 건 “reasoning frame을 학습에만 쓰고 추론에선 아예 없앤다”. 추론 오버헤드가 정확히 0이고, 주장이 순수하게 “이 supervision이 더 나은 표현을 만드는가”로 좁혀진다.

단, 이 버전은 “Fast-WAM이 말한 video co-training을 하라”에 가까워진다. 따라서 delta는 효율성이 아니라 reasoning frame이 무엇이냐에서 나와야 한다:

임의의 미래 비디오가 아니라 현재와 목표를 잇는 bridge
target frame과 함께 joint denoise되는 궤적 (별도 video branch가 아님)

Cosmos Policy의 t/t+K 2프레임 점프도, 일반적인 video co-training도 이 두 성질을 갖지 않는다. 논문 프레이밍은 이 지점에 걸어야 한다.

11 확정 프레이밍과 실험 설계

확정 프레이밍

추론 시에는 ImageWAM과 완전히 동일하다 — t, t+K 2프레임만 생성, reasoning 없음. 다른 것은 backbone이 video 생성 모델(ChronoEdit)이고 학습 때만 reasoning frame을 쓴다는 점. 주장: video dynamics가 표현에 내재되어 image editing보다 physically / geometrically 더 나은 정보를 준다.

추론 아키텍처가 ImageWAM과 같다는 것은 약점이 아니라 최대 강점이다. 추론 비용과 출력 인터페이스를 완전히 맞추면 성능 차이가 오직 표현 차이로 귀속된다.

기여 위치 — 2×2의 빈 칸

	test-time 생성 O	test-time 생성 X
video prior O	FastWAM — LIBERO-Plus 51.5	← 빈 칸 (우리)
video prior X	(의미 없음)	ImageWAM — LIBERO-Plus 83.1

이 배치가 중요한 이유: ImageWAM의 31.6pt 우위와 정면충돌하지 않고 설명할 수 있다. FastWAM이 진 것은 video prior가 나빠서가 아니라 추론 때 생성하기 때문(분포 이동, 오차 누적)이고, ImageWAM은 생성을 없애 이겼지만 dynamics를 같이 버렸다. 우리는 생성만 버리고 prior는 남긴다.

진짜 baseline은 ImageWAM이 아니다 논문 생사

ImageWAM을 이기는 건 쉬운 쪽. 어려운 baseline은 "평범한 video co-training"이다. Fast-WAM이 co-training만으로 8pt를 얻었으므로 리뷰어의 첫 질문은 "그냥 미래 비디오를 co-train하면 되는 것 아닌가?"

답변 포지션

임의의 미래 비디오가 아니라 target frame과 같은 시퀀스 안에서 joint denoise되는 현재→목표 bridge다. 별도 branch의 co-training은 궤적과 목표를 각각 따로 모델링하지만, 여기서는 목표가 궤적의 종점으로 강제된다.

→ baseline에 "동일 프레임 수를 별도 video branch로 co-train한 arm"을 반드시 포함.

4-arm 설계 (backbone 매칭)

ChronoEdit-2B가 Cosmos-Predict2.5-2B 기반이라는 점이 결정적이다. ImageWAM의 FLUX.2 4B와 직접 비교하면 스케일·데이터·text encoder가 모두 달라 "video vs image"를 주장할 수 없다.

Arm	백본	로봇 finetune	분리하는 것
A	Cosmos-Predict2.5-2B	t/t+K만 (≈ Cosmos Policy)	기준선
B	Cosmos-Predict2.5-2B	+ reasoning frame	finetune 단계 reasoning 효과
C	ChronoEdit-2B	+ reasoning frame	editing 사전학습 단계 reasoning 효과
D	ChronoEdit-2B	t/t+K만	C와 대조

+ external baseline: ImageWAM / FastWAM / AGRA (표에만) | + hard baseline: 별도 video branch co-training

구현 필수사항 — reasoning frame dropout 놓치면 실험 불성립

ChronoEdit은 reasoning을 step 0에서 빼지 않는다. N_r=10/50, 즉 궤적의 20%가 지난 뒤에 뺀다. 학습 시에는 항상 전 구간 concat이다. 즉 모델은 "reasoning token 없이 denoise하는 법"을 배운 적이 없다. 제안대로 추론에서 처음부터 빼면 train/test mismatch로 attention 패턴이 바뀌어 그냥 깨질 수 있다.

해결: 학습 시 reasoning frame을 확률적으로 drop (p≈0.5 또는 curriculum). 부수 효과 — 같은 체크포인트 하나로 추론 시 reasoning on/off 토글이 가능해져 별도 학습 run 없이 ablation이 완전히 통제된다. 그 자체로 표 하나.

주장을 벤치마크가 아닌 직접 증거로

"physically, geometrically 더 좋은 정보"는 SR 숫자만으로 증명되지 않는다. 메커니즘: 비디오 모델은 다음 프레임을 맞추려면 occlusion 해소, object permanence, 접촉, 강체 운동을 모델링해야 하지만 image editor는 한 장이 그럴듯하기만 하면 된다.

feature probing 추가

각 arm의 hidden state에서 depth / object pose / contact 여부를 linear probe로 예측해 비교. 학습 불필요, 하루 규모. "geometrically better"를 SR이 아닌 증거로 뒷받침한다.

현재 부족한 것 (우선순위)

#	항목	등급
1	평범한 video co-training 대비 delta 설명 + 해당 baseline arm	논문 생사
2	reasoning frame dropout 구현 — 없으면 추론 시 drop이 동작하지 않음	기술 필수
3	LIBERO-Plus / RoboTwin randomized 환경 셋업 (깨끗한 LIBERO는 포화)	인프라
4	ChronoEdit-2B ↔ Cosmos-Predict2.5-2B 가중치 호환성 실제 확인	확인

12 학습 데이터셋 결정 — RoboCasa (DROID 탈락)

DROID 탈락 — closed-loop eval이 불가능하다. 가설이 "표현이 physically/geometrically 낫다 → robustness"인데, 실제 로봇 없이는 offline action MSE만 잴 수 있다. 그걸로는 증명되지 않는다. 추가로 레포에 DROID dataset class/config가 없고(LIBERO/RoboCasa/ALOHA만), 데이터도 TB급. → DROID의 자리는 나중에 co-training corpus이지 kill test 벡터가 아니다.

RoboCasa 채택 — eval 축이 이미 코드에 있다

# run_robocasa_eval.py:216-218 obj_instance_split: str = "B" # held-out test objects layout_and_style_ids: str = "((1,1),(2,2),(4,4),(6,9),(7,10))" # 5 test scenes randomize_cameras: bool = False # ← 꺼져 있음

기본 eval이 이미 held-out object + held-out scene이고, randomize_cameras 플래그가 off로 놀고 있다. 켜기만 하면 LIBERO-Plus를 새로 셋업하지 않고도 perturbation 축이 생긴다 — §11의 "부족한 것 3번"이 해소된다. 여기에 TurnOffMicrowave 98% 재현 baseline까지 이미 확보.

최대 난관 — 학습 비용

벤치마크	논문 재현 설정	GPU-hours
LIBERO	64 H100 × 48h (40K step, global batch 1920)	3,072
RoboCasa	32 H100 × 48h (45K step, global batch 800)	1,536
ALOHA	8 GPU 1노드로 충분 (50K step)	최저 — 단 real-robot eval이라 불가

4-arm × 1,536 = 6,144 GPU-hours. 그대로는 불가능. README도 "8 GPU로 재현하려면 훨씬 오래 걸린다"고 명시(trainer.grad_accum_iter=4가 그 이유).

해결 — 논문 절대 수치를 재현하지 않고 arm끼리만 맞춘다

grad_accum 없이 8×B200 → global batch 200(논문 800의 1/4). per-GPU 작업량이 동일하므로 벽시계는 32 H100 × 48h와 같은 수준 ≈ 8 GPU × 약 48h(B200이면 24~36h 예상). arm 4개 = job 4개.

방법론적으로 정당하다 — 목적이 상대 비교이고 모든 arm이 동일 예산을 쓴다. 단 "논문 수치 재현"을 포기하는 결정이므로 저자 판단이 필요하다.

실행 형태

# 8 GPU는 template.sh 기본값과 동일 → gres / -c / --mem override 불필요 sbm "bash scripts/train_robocasa_armA.sh" --qos=extra -J cosmos_armA

4 arm × 8 GPU = 32 GPU를 extra로. own은 8 GPU 상한이라 순차 실행만 가능.
preemption 대비 필수 — 24~36h extra job은 거의 확실히 잘린다. save_iter=1000이 이미 있고 resume 시 train state를 불러오므로 스크립트에 SIGTERM self-requeue trap 추가.
이 프로젝트는 conda가 아니라 uv .venv → sbmr의 conda wrapping이 안 맞음. sbm + 스크립트 내부 .venv 절대경로가 안전.
260513의 EGL / libX11 LD_LIBRARY_PATH 픽스는 학습엔 불필요, eval엔 그대로 필요.

착수 전 확인: hf download nvidia/RoboCasa-Cosmos-Policy 용량 미확인. success_only 외에 all_episodes(성공+실패 롤아웃 전체)까지 받아야 하는데 상당히 클 수 있다. NAS 공간 확보 전 크기부터 확인.

확정 계획

데이터셋

RoboCasa 24task×50

Arms

4 + hard baseline

Arm당 예산

8 GPU × ~48h

Global batch

200 (논문 1/4)

Eval 축

held-out + cam rand

Eval 규모

24×3seed×50trial

13 데이터 확보 & eval 축 정정

데이터 위치 — 다운로드/복사 모두 불필요

/home/nas_main/junhahyung/data/RoboCasa-Cosmos-Policy/ export BASE_DATASETS_DIR=/home/nas_main/junhahyung/data

디렉토리	크기	내용
`success_only/`	158G	7 카테고리 → 24 task, task당 hdf5 1개(~5GB)
`all_episodes/`	18G	24 task 전부. JPEG 압축이라 작음
합계	176G	NAS 여유 61T — 문제없음

파일 구조 <category>/<task>/<date>/demo_gentex_im128_randcams.hdf5. 권한 drwxrwxr-x junhahyung:lab이고 우리는 lab 그룹 → 경로만 지정하면 그대로 로드된다. reason1_embeddings.pkl(24.8G)은 Cosmos-Reason1용이라 미사용.

주의: t5_embeddings.pkl.lock이 -rw-r--r-- junhahyung이라 260513에 겪은 permission denied가 재발한다. 남의 데이터이므로 락파일을 건드리지 말고 t5_embeddings.pkl 464MB만 본인 디렉토리로 복사해 경로를 재지정할 것.

정정 — `randomize_cameras`는 OOD 축이 아니다

§12에서 "randomize_cameras=True를 켜면 perturbation 축이 생긴다"고 했으나 틀렸다. 학습 데이터 파일명이 ..._randcams.hdf5이고, dataset_states_to_obs.py:459에서 이 접미사는 데이터 생성 시 --randomize_cameras를 쓴 경우 붙는다. 즉 학습 데이터에 이미 카메라 랜덤화가 포함되어 있다(kitchen.py:992: agentview 위치 σ=0.05m, 회전 σ=3°). eval에서 켜는 것은 in-distribution이다.

더 중요한 함의: obj_instance_split="B"와 5개 test scene은 진짜 held-out이 맞다. 즉 260513의 TurnOffMicrowave 98%는 이미 OOD 조건의 수치였다. RoboCasa 내장 OOD 축이 쉬운 태스크에서는 이미 포화라는 뜻.

신호가 나올 두 지점

(a) per-task breakdown — 평균 금지

논문 평균 ~91%인데 TurnOffMicrowave가 98% → 낮은 태스크들이 평균을 끌어내리고 있다. arm 비교는 태스크별로 봐야 하며, 특히 PnP 계열(접촉 많음, geometry 의존적)이 가장 갈릴 곳이다. "video prior가 physically/geometrically 낫다"는 주장과 정확히 맞는 태스크군.

(b) 새 OOD 축 — 카메라 노이즈 magnitude 확대 주력

kitchen.py:992의 σ가 하드코딩(0.05 / 3.0)이다. 0.15 / 9.0 등으로 키우면 학습 분포 밖으로 나가는 magnitude extrapolation이 된다. 상수 하나 수준의 변경이며, σ를 x축으로 놓은 degradation curve가 나오면 "표현이 physically robust하다"를 가장 직접적으로 보여주는 논문 그림이 그대로 나온다.

부수 축(코드 수정 0): layout_and_style_ids에 기본 5개 밖의 조합 전달.

중간 프레임은 필요한가? — 2026 WAM 필드 서베이와 ChronoEdit 기반 방향 검토