∿ STREAMING CWM
ENGINEERING BRIEF · 13 OCTOBER 2026
Inference status
World-model inference · Today's progress

From repository setup to multi-chunk video generation.

A technical overview of the Streaming Code World Model, our setup and inference results, current limitations, and the plan to scale longer rollouts. This is a report on completed experiments, not a live streaming demo.

↗ Source repository ↗ Streaming checkpoints
Best completed
6 chunks
Saved MP4 output
Video duration
4.25 sec
17 frames/chunk at 24 fps
GPU hardware
2 × RTX PRO
Blackwell Server Edition
Scaling issue
VRAM OOM
24-chunk attempt failed

01 · What is this repository?

Purpose, source code, model weights, and the inference approach.

Repository purpose

TingtingLiao/streaming-code-world-model is a research codebase for streaming or chunk-wise world-model video generation built on the Code World Model stack.

  • Generates video in sequential temporal chunks.
  • Uses recent history and key/value (KV) attention cache reuse to condition later chunks.
  • Runs offline inference using prepared example caches and model checkpoints.
  • Our current achievement is saved video generation, not real-time interactive streaming.
Chunk-wise generationKV cache reuseWorld modelOffline inference

Model and checkpoint sources

  • Code: official GitHub repository linked above.
  • Streaming LoRAs: Hugging Face checkpoint repository.
  • Base model asset: minimax_h3_ref2va_bf16.safetensors from the locally installed CWM release assets.
  • Adapter used today: streaming_dmd_4step.safetensors.
  • Other downloaded adapter: streaming_df.safetensors.
  • Supporting assets: video/audio VAEs, Qwen3-VL text encoder and processor assets.

The model runs on our VM. Cloudflare hosts this report page and MP4 files; it does not host the GPU model or provide inference by itself.

02 · Play today's inference outputs

These players load the actual MP4s copied from the VM's inference output folders.

01 · First inference

Single-chunk baseline confirming the end-to-end generation and decode path.

1 chunk~0.709 s24 fps

runs/first_inference/example_01_stream.mp4

02 · Two-GPU run

Two-chunk distributed inference confirms continuation beyond the baseline.

2 chunks~1.417 s24 fps

runs/two_chunk_fsdp/example_01_stream.mp4

03 · Best confirmed run

Six chunks completed with two GPUs and KV reuse. H.264 MP4 was produced successfully.

6 chunks4.25 s2688 × 76824 fps

runs/six_chunk_fsdp/example_01_stream.mp4

If a player cannot load its video, check that the MP4 was copied into the matching videos/ directory before deployment.

03 · What does “chunks” mean?

Chunk count controls the length of the generated rollout.

Chunk layout

The current repo configuration uses 17 video frames per chunk at 24 fps, with 5 latent time steps per chunk. Six chunks decode to approximately 4.25 seconds.

Later chunks can use recent generated history through the attention KV cache. The model's configured span controls how much recent context is retained.

ChunksApprox. durationResult
10.709 sCompleted
21.417 sCompleted
64.25 sCompleted
24~17 seconds targetOOM failure

04 · What we configured and completed today

Progress from repository setup to a reproducible inference path.

STEP 01

Repository setup

Cloned the streaming repo, base CWM repo and Musubi Tuner; installed the streaming package in editable mode.

STEP 02

Attention compatibility

Used PyTorch SDPA fallback because the FlashAttention-3 interface was unavailable in this environment.

STEP 03
Used torchrun with an NCCL Socket networking workaround for the VM's current IB/gIB networking issue.

STEP 04

Inference and checks

Completed 1-, 2- and 6-chunk runs, inspected MP4 properties, and added per-chunk GPU-memory diagnostics.

05 · Current blocker

The inference path works, but long-rollout memory behavior needs investigation.

⚠ 24-chunk attempt failed with CUDA out-of-memory

The failure occurred around chunk 6 in rtcwm/model/attention.py, while concatenating cached and current attention keys using torch.cat. The failed allocation was about 582 MiB with roughly 575 MiB free. Other users' processes were also consuming GPU memory during testing.

Memory observations

  • Our process's allocated GPU memory grew from about 32 GiB after chunk 1 output to about 74 GiB by chunks 5–6.
  • Concurrent GPU jobs affect available free memory and can make results vary between runs.
  • These measurements show memory growth but do not yet prove a single root cause.

Impact

  • Short-rollout inference is demonstrated.
  • Longer rollouts need focused attention-memory profiling and review of output/KV-cache lifetimes.
  • We should not report 24-chunk generation as working until a full run completes.
  • We will not terminate other users' GPU jobs without coordination.

06 · VM specifications and evaluation

Hardware environment and the checks used to verify today's results.

VM specifications

Operating systemUbuntu 22.04.5 LTS
GPU hardware2 × NVIDIA RTX PRO 6000 Blackwell Server Edition
VRAM~97,887 MiB per GPU (about 96 GiB each)
System RAM354 GiB
NVIDIA driver580.159.03
Driver-reported CUDA13.0
Python environmentPython 3.10
PyTorch2.9.1+cu128
Distributed inferencetorchrun, 2 processes; NCCL Socket workaround

How we evaluate currently

  • Functional check: inference command finishes and writes an MP4.
  • Video artifact check: verify codec, resolution, frame rate and duration.
  • Scaling check: compare 1, 2, 6 and attempted 24 chunks.
  • Memory check: log allocated/reserved/free GPU memory by chunk.
  • Unit tests: targeted attention tests passed (2 tests); the full suite had 5 passes and 4 failures related to missing training cache/checkpoint prerequisites.

This is an engineering smoke test and scalability investigation—not yet a formal video-quality or real-time latency benchmark.

07 · Next engineering actions

Prioritized steps to move from a successful short rollout to reliable longer generation.

  1. Pinpoint attention memory usage. Instrument the exact key/value concatenation to log the layer, cache-piece count, tensor shapes and free VRAM at failure.
  2. Keep a known-good baseline. Preserve the six-chunk command, output and memory logs.
  3. Review tensor lifetimes. Investigate GPU-resident output chunks and KV/history retention; evaluate safe CPU offload for completed output chunks.
  4. Scale progressively. Test 8 chunks, then 12, then 24 after checking nvidia-smi and coordinating a suitable GPU window.
  5. Formalize evaluation. Record success, peak VRAM, per-chunk time, output duration/resolution and visual consistency across chunk boundaries.
  6. Improve reproducibility. Store exact commands, environment versions, logs and outputs with the experiment report.

Engineering paths

Local folders used in today's experiments.

Streaming repo/devwork/harsha/streaming-cwm/streaming-code-world-model
Base CWM assets/devwork/harsha/streaming-cwm/code-world-model/release
Streaming checkpointckpt/streaming_dmd_4step.safetensors
Successful 6-chunk MP4runs/six_chunk_fsdp/example_01_stream.mp4
Memory-debug MP4runs/memory_debug_6/example_01_stream.mp4