DreamZero × RoboLab end-to-end 평가 — 세션 충돌 규명

1 세션 충돌 — 25%의 진짜 원인

job 51168 (NUM_ENVS=4): 1/4 = 25.0% [95% CI 5.3–71.6]. 낮은 성공률을 정책 한계로 읽기 쉬운 지점이었다. 서버 로그가 답을 줬다.

예측 영상에도 그대로 반영됐다 — 108개 mp4가 전부 _n1(누적 청크 1개)인 ~96KB 조각이었다. 비교 분석에 쓸 수 없는 상태.

2 재실행 결과

세션 리셋 3회는 에피소드 4개 사이의 전환 3회와 정확히 일치한다. 에피소드별로는 run0 성공(434 steps) / run1 실패(750 timeout) / run2 성공(295) / run3 성공(668).

서버 readiness — /healthz가 통하지 않는다

426 Upgrade Required는 WebSocket 엔드포인트에 평범한 HTTP GET을 날렸을 때 나온다. _health_check(socket_test_optimized_AR.py:733)는 WebsocketPolicyServer에만 물려 있고 rank 0이 실제로 띄우는 RoboarenaServer엔 없다. cosmos3처럼 /healthz 200만 기다렸다면 서버가 멀쩡한데도 30분 타임아웃으로 실패했을 것이다.

3 상상 vs 실제 — 실패 원인의 귀속

DreamZero는 액션과 비디오를 함께 예측하므로, 두 영상을 시간 정렬하면 실패를 "상상이 틀렸나 / 상상은 맞았는데 행동이 틀렸나"로 가를 수 있다. 정렬은 청크 크기를 가정하지 않고 두 비디오 길이의 선형 매핑으로 한다 — 실측 청크 cadence(~21 sim step)가 action_horizon=24와 어긋나기 때문.

4 Takeaway

1. 평가 하네스의 결함을 정책 성능으로 오독할 뻔했다. 25%와 75%의 차이는 전부 세션 처리에서 왔다. 숫자만 보고 "DreamZero는 RoboLab에서 약하다"고 결론냈다면 완전히 틀린 판단이 됐다. 낮은 성능을 만나면 정책보다 배선을 먼저 의심해야 한다.
2. num_envs=1은 우회이지 해결이 아니다. 서버가 세션별 상태를 분리하지 않는 한 병렬 평가가 불가능하고, 이는 통계적 검정력에 직접 영향을 준다.
3. 설정값만 보고 결론내지 말 것. 앞선 리포트에서 config의 pretrained_path: null을 "가중치 통합됨 → 별도 다운로드 불필요"로 읽었는데 틀렸다. 실제로는 HF hub에서 Wan2.1 base 28GB를 받아온다. 공유 캐시에 이미 있어 안 막혔을 뿐이다.

5 Next

• 그리퍼 achieved 값 확인 — 파지 성공의 무료 지표(0.37 정지 = 물었음, 1.0 = 허공). 실패가 파지 실패인지 파지 후 낙하인지 확정
• 청크 내부(1.6초 예측 8프레임)까지 봐서 "곧 잡겠다"는 의도 유무 정밀 판정
• SUITE=smoke → SUITE=standard(15 태스크)로 cosmos3와 동일 조건 비교. --qos=own 필수 (다중 시간 규모, extra는 preempt됨)
• 서버 세션 분리를 상류에 제안하거나 로컬 패치

6 업데이트 — hdf5 궤적 분석 (영상 진단을 정정)

run_*.hdf5에 물체 실제 위치(banana/root_pose, bowl/root_pose)가 그대로 있다. 영상 프레임 3~4개로 내린 진단을 이걸로 검증했더니 두 번 뒤집혔다.

정정 1 — 파지 실패가 아니었다

여러 번 성공적으로 집었고 재시도도 계속했다. "파지 실패"도 "복구 행동 부재"도 아니었다. 영상에서 본 "정체 상태"는 놓친 직후의 순간을 포착한 것이었다.

정정 2 — 그리퍼 급변은 충분조건이 아니다

run1에서 그리퍼가 급변한 직후 낙하하는 사례를 찾았다 (step 503→504: 0.75 → 0.02, 정확히 청크 경계). 여기서 "청크 재생성 시 그리퍼 연속성이 깨져 실패한다"고 결론낼 뻔했으나 4개 run을 모두 집계하자 반례가 나왔다.

실제로 성패를 가른 것 — z_end

바나나 시작 높이는 0.021(테이블 위). 성공 3건은 0.076 / 0.096 / 0.112(그릇 안 높이)로 끝나는데, 실패 1건만 0.012 — 시작보다도 낮다.

7 standard 15태스크 (job 51286) & cosmos3 비교

표본을 맞춰도 격차가 유지된다

표본이 2.5배 차이나므로 cosmos3를 태스크당 4개로 20,000회 무작위 추출해 동일 조건으로 맞췄다.

모든 실패가 timeout이다

양쪽 다 조기 종료가 없다. 문제는 "못 한다"가 아니라 "시간 내 못 끝낸다"이다.

실패는 두 갈래 — 단일 원인 가설은 반증됨

"파지 불안정 → 시도 반복 → timeout"을 먼저 검증했으나 반증됐다. 스텝당 정규화하면 낙하가 오히려 실패 쪽이 낮다(1.34 vs 성공 1.92 / 1000 steps). raw 값이 커 보인 건 에피소드가 길어서다.

태스크별로 분해하자 정반대 성격의 두 유형이 드러났다. 앞선 집계에서 신호가 없던 건 둘이 상쇄됐기 때문이다.

8 3-view ablation (07-23) — cam2 가설 반증, 격차는 실재

지금까지 평가는 전부 2-view였다 — 어댑터가 두 번째 exterior를 np.zeros_like(검은 화면)로 채운다(client.py:147). cosmos3는 3-view를 다 쓰므로 42.0% vs 26.7% 비교는 입력 조건이 어긋나 있었다. CAM2_SOURCE=right로 3-view n=10 재실행해 조건을 맞췄다.