Wave Forcing streams video at 134.8 FPS on 8 H200 GPUs

Researchers at SJTU-DENG-Lab posted Wave Forcing on October 31, a method for streaming video generation that reaches 134.81 frames per second end to end on eight NVIDIA H200 GPUs. That is 7.07 times the 19.06 FPS the authors measure for the same model on one GPU, with quality close to the best comparable long-video baseline. The code and 1.3B checkpoints are public.

Most video models make a clip and hand it over when it is done. Streaming models produce video continuously, so the viewer can watch while the model is still generating. Wave Forcing is about making that fast enough, and stable enough over minutes, to be useful.

The problem: two forward passes per chunk

Chunk-wise autoregressive video models, such as Self Forcing, Rolling Forcing and Causal Forcing, generate video a few frames at a time. Each chunk is cleaned up from noise in a small number of denoising steps, and the chunk depends on the chunks before it.

The paper points out a hidden cost. After a chunk is finished, the model has to run again on the clean result to refresh its cache of past frames, which the authors call the "store" step. So even a one-step model needs two forward passes for every chunk it outputs. Long rollouts also tend to drift: the subject changes appearance or the camera framing slides.

What the team did

Wave Forcing changes the schedule. Instead of finishing one chunk before starting the next, it runs different denoising stages for different chunks at the same time, like a pipeline. Each chunk looks at cleaner earlier chunks and never at later, noisier ones. Once the pipeline is full, one chunk comes out per forward round, and no denoising step is dropped.

Three parts make it work, according to the paper:

• A causal wavefront. Denoising stages and the store step run along diagonals, each on its own full copy of the model on its own GPU. The authors call this wave parallelism.
• Three-stage training on Wan2.1-T2V-1.3B, using distribution matching distillation (DMD). It starts from a mix of noise patterns, adds an off-policy stage with an image-similarity loss (LPIPS) on re-noised teacher chunks, then trains on the model's own rollouts.
• WaveRT, a runtime built on SGLang Diffusion. It passes cached keys and values between GPUs early, overlaps communication with compute, uses SageAttention and W8A8 (8-bit weight and activation) kernels, and decodes video in a load-balanced stream.

Results

The evaluation uses 832x480 video at 16 FPS. Short clips use VBench prompts. Long clips are 100 seconds, generated from 200 MovieGen prompts.

The 5-step version has the highest VBench total here and much more motion than Rolling Forcing. Causal Forcing scores highest on motion, but the authors say it loses the subject and drifts the camera, which they judge unusable. Subject preservation and camera drift are the authors' own metrics, computed on a 100-prompt subset.

On speed, the 4-step model runs at 147.58 FPS for the diffusion transformer alone and 134.81 FPS end to end. The 5-step model reaches 96.46 FPS end to end. The authors also ran 14B-parameter configurations and got up to 33.50 FPS, a 6.08 times gain over 5.51 FPS on one GPU. Wave parallelism beat Ulysses and Ring context parallelism, two standard ways to split one model across GPUs, by up to 2.53 times in the 8-bit (Sage plus W8A8) setting. In BF16 it trailed Ulysses by 1.53% at the 9B scale.

An ablation shows why all three training branches stay: removing any one leaves at least one metric weak, such as drift of 6.24 without the Rolling Forcing branch or dynamic degree of 15.73 without off-policy training.

Limits

The authors list several. The 14B throughput numbers use randomly initialized weights, because no pretrained model was available to them, so they measure speed and not video quality. Only the 1.3B model has quality results.

Wave parallelism is bounded by the number of denoising steps, and its edge over context parallelism narrows at larger sizes. The speedup needs eight H200s, which is far from a consumer setup. Latency to the first visible frame, live prompt or camera changes and serving many streams at once are not tested. The authors also say VBench does not fully capture long-stream quality, and that their own metrics are not yet proven reliable. All numbers come from the authors, with no independent replication yet.

What is released

The GitHub repository contains the WaveRT inference code under Apache 2.0 and reference training code for the three stages. The training code derives from Rolling Forcing and carries an academic-use license. Both the 4-step and 5-step 1.3B checkpoints are on Hugging Face as BF16 weights. They hold only the distilled transformer, so you also need the Wan2.1-T2V-1.3B base model for the text encoder and VAE. The README says more checkpoints are coming. See the project page for videos.

The practical point is that the bottleneck in streaming video is partly scheduling, not only model size. Whether the approach holds at 14B with real weights is the open question to watch.