TL;DR
- DreamZero-DROID (Wan2.2-TI2V-5B) 1×B200 단독 추론 레이턴시 측정 — 표준 cross-model 비교 프로토콜 (warmed-up, cuda-synced, n=30)
- Eager: action_call median 2529 ms, full4D 2622 ms, effective action Hz 9.5 Hz
- Compiled (torch.compile + pytorch:25.04-py3 컨테이너): action_call 2473 ms, 9.7 Hz — 개선 2.3% (marginal)
- action chunk 24개 → action당 레이턴시 105 ms, policy call Hz 0.4 Hz
2529
action_call ms (eager)
2473
action_call ms (compiled)
9.5 Hz
eff. action Hz (eager)
1 배경 / 목적 (왜)
DreamZero-DROID (Wan2.2-TI2V-5B 백본)의 실제 추론 레이턴시를 표준 프로토콜로 측정해 cross-model 비교표 (X-WAM, Cosmos-Policy, pi0.5 등)에 합산하기 위한 벤치마크.
DreamZero는 video + action을 하나의 causal joint-diffusion pass로 동시 예측한다. action_call이 이미 16-step joint denoise + action unnormalize 전체를 포함하므로, full4D (RGB 비디오)의 추가 비용은 VAE decode뿐이다. 이 구조는 Cosmos-Policy-RoboCasa (action 353ms → +VAE → full 459ms)와 동일한 분해 방식.
또한 운영 환경(default ubuntu:22.04 worker)에서 torch.compile이 없는 eager 모드가 실제 serving 경로이므로, compiled와의 갭을 정량화했다.
2 작업 내용 (어떻게)
벤치마크 스크립트
tmp/bench_dreamzero_latency.py — eval_utils/serve_dreamzero_wan22.DreamZeroWan225BPolicy serving 경로를 직접 구동. 합성 obs (랜덤 RGB 3뷰 + proprio)로 shape 결정 레이턴시 측정.
실행 프로토콜
hw: 1× B200 GPU (--gres=gpu:1, --qos=own)
batch: 1
warmup: 5 calls (KV-cache 초기화 + 컴파일 포함)
timed: 30 calls (cuda.synchronize 후 시각 기록)
precision: bf16
resolution: 180×320
num_inference_steps: 16
num_frame_per_block: 2
decoupled_inference: false
실행 방식 (3 jobs)
| Job | 모드 | 컨테이너 | 경과 |
| 14931 | Eager (TORCHDYNAMO_DISABLE=1) | ubuntu:22.04 (기본) | 8m 12s |
| 14948 | Eager (재측정) | ubuntu:22.04 (기본) | 6m 44s |
| 14949 | Compiled (BENCH_COMPILE=1) | nvcr.io/nvidia/pytorch:25.04-py3 | 13m 32s |
Eager 첫 실행(14931)이 8m인 이유: 이미지 pull + KV-cache 첫 초기화 overhead. 14948 재실행 6m 44s는 캐시 히트.
측정 대상 분해
- action_call:
wrapper.infer(obs) → joint 16-step denoise + action unnormalize. 로봇이 실제 기다리는 레이턴시.
- vae_decode: 예측된 video latent → RGB 디코딩 (시각화용).
- full4D: action_call + vae_decode.
3 결과 (수치)
주요 레이턴시 비교 (median, n=30)
| 모드 | action_call (ms) | vae_decode (ms) | full4D (ms) | eff. action Hz | policy Hz |
| Eager (ubuntu:22.04) |
2529 |
93.6 |
2622 |
9.5 Hz |
0.4 Hz |
| Compiled (pytorch:25.04-py3) |
2473 |
93.4 |
2566 |
9.7 Hz |
0.42 Hz |
Eager 상세 통계 (n=30)
| 지표 | action_call (ms) | vae_decode (ms) |
| min | 2230 | 93.3 |
| p10 | 2247 | 93.3 |
| median | 2529 | 93.6 |
| p90 | 2781 | 93.7 |
| max | 2801 | 94.2 |
| std | 204 | 0.17 |
action_call std 204ms (8%): 16-step flow-matching diffusion의 내부 스케줄 분산으로 보임. vae_decode는 std 0.17ms로 안정적이라 diffusion step이 주범.
파생 지표 (Eager 기준)
9.5 Hz
effective action Hz
VAE decode 비중: 93.6ms / 2622ms = 3.6%. full4D의 비용은 거의 전부 joint diffusion이다. 비디오 생성을 끄더라도 레이턴시는 사실상 동일.
torch.compile 효과
| 지표 | Eager | Compiled | 개선 |
| action_call median | 2529 ms | 2473 ms | −56 ms (−2.3%) |
| full4D median | 2622 ms | 2566 ms | −56 ms (−2.1%) |
| eff. action Hz | 9.5 Hz | 9.7 Hz | +0.2 Hz |
compile 개선 2.3%: 16-step diffusion 루프에서 torch.compile이 효과를 거의 못 봤다. B200 memory bandwidth에서 bottle-neck이 없고 flow-step 자체가 compute-bound이라 dynamo graph break 없이 전부 커버해도 marginal.
4 Takeaway
- DreamZero-DROID는 1×B200에서 action_call 2.5s, effective 9.5 Hz로 동작. chunk=24이므로 action당 105ms는 실용적인 수준
- 실제 serving 환경(ubuntu:22.04, no compiler)에서 eager 모드가 사실상 기준값. compile은 개발 overhead 대비 2.3% 개선이므로 운영 우선순위 낮음
- VAE decode (93ms, 3.6%)는 레이턴시에서 무시 가능한 수준 — video 생성 on/off는 latency에 영향 없음
cross-model 위치
Cosmos-Policy-RoboCasa (action 353ms, full4D 459ms)와 비교하면 DreamZero-DROID는 action_call이 7× 더 느리다. 이는 Wan2.2-5B (16 diffusion steps) vs Cosmos-Policy의 flow-matching step 차이에서 기인한다. effective action Hz는 chunk 크기 (DreamZero=24 vs Cosmos=N/A)가 다르므로 단순 비교는 어렵고, 실제 로봇 제어에서 end-to-end SR이 더 중요한 지표다.
5 Next Steps
- cross-model latency 표 완성: Cosmos-Policy(353ms/9.5Hz), DreamZero(2529ms/9.5Hz) — pi0.5 측정 추가 필요
- decoupled inference 옵션 측정:
use_decoupled_inference=true 설정 시 레이턴시 변화 확인 (현재 false)
- tiled 추론:
tiled=true, tile_size_hw=[34,34] 활성화 시 메모리·레이턴시 trade-off 확인
- num_inference_steps 감소 실험: 16 → 8 → 4 steps 시 action quality vs latency curve
- 한계: synthetic obs (random RGB)로 측정 — 실제 카메라 이미지와 shape는 동일하나, content에 따른 분산은 미측정