Summary
- Combining vLLM-Omni with FastVideo's FastH3, a team generated a 10.1-second MiniMax H3 video, complete with audio, in just 8.7 seconds.
- The speedup comes from two approaches: Turbo LoRA, a sidecar that can switch per request, and the FastH3 preview, which fuses weights at load time.
- Both methods cut denoising down to four DiT computations across five sigma points, but they trade flexibility for speed in opposite directions.
A 10.1-second video, finished in 8.7 seconds
According to a benchmark the vLLM project published on September 1, a 10.1-second MP4 made with MiniMax's video model H3 — including audio synced to the footage — took just 8.7 seconds to generate. In other words, the time it took to create the video was shorter than the video itself. The result came from running FastVideo's open-source acceleration technique, FastH3, on top of vLLM-Omni serving.
To break that down: MiniMax H3 is a video generation model that takes text or images as input and produces synchronized video and audio. vLLM-Omni is the serving infrastructure the vLLM project runs to make models like this fast enough for real-world deployment. FastH3, built by the FastVideo team, is an open-source acceleration technique that speeds things up by cutting the number of iterative computations H3 needs to run. Put those three pieces together, and you get this result.
MiniMax H3 makes headlines again — this time for speed
MiniMax H3 launched as an open-weight video generation model on August 3. METAL LAB confirmed at the time that its defining feature was generating video and 32kHz stereo audio together in a single inference pass — though back then, producing a 15-second clip on an RTX 4070 laptop took 45 minutes. Just five days later, on August 8, Luma announced it had added H3 to its Luma Agents platform. From running locally on consumer PCs to landing on cloud platforms to now getting a serving-side speed boost, the news around H3 hasn't slowed down in the span of a month.
How does it get to 8.7 seconds
Video generation models typically start from a screen full of noise and run a diffusion transformer (DiT) — a neural network that progressively strips away noise to render the finished image — through many iterations to produce a complete video. According to materials the vLLM project published, this speedup implements a few-step schedule that cuts those iterations down to just four DiT computations across five noise-intensity points, known as sigma points. Two separate implementations achieve this.
The first is called "Turbo LoRA." It uses LoRA — a low-cost fine-tuning method that trains a small add-on module instead of the full model — to leave the base weights (W) untouched while attaching a small sidecar module, A/B, chosen per incoming request. Mathematically, this is expressed as y=Wx+B(Ax). With the DLO configuration, the base blocks are streamed while only the A/B buffers stay resident on the accelerator.
The second is "FastH3 Preview," released by the FastVideo team. Here, the weights are fully merged at model-load time — a fused weight, W*=W+BA+Δ, is computed in advance before sharding, and every request runs on that same fixed four-step weight set. This is faster, but it comes at a cost: requests can't swap between different adapters, and the vLLM project notes that VSA variants and offloading aren't supported yet.
Comparing the two approaches
| Item | Turbo LoRA | FastH3 Preview |
|---|---|---|
| Weight fusion timing | Per request (dynamic) | At model load (fixed) |
| Server type | General-purpose server + sidecar | Dedicated server |
| Supported modes | FL2VA / T2VA | T2VA (dense) only |
| Per-request switching | Supported | Not supported |
| Offloading | Base blocks streamed via DLO | Not supported |
This table summarizes what's specified in vLLM-Omni PRs #6476 (Turbo), #6550 (Turbo+DLO), and #6714 (FastH3 Preview). Both approaches share the same goal — finishing a video in four DiT computations — but they take different paths to get there, trading flexibility against raw speed in opposite ways.
Editor's take
What's worth paying attention to here isn't just the 8.7-second number — it's how that number was achieved. Video generation models have long carried a reputation of "slow is fine, as long as the output looks good." But by tackling four-step compression at two different layers — serving (vLLM-Omni) and model (FastH3) — this result gets close to real-time speed. Turbo LoRA opts for flexibility, FastH3 opts for speed, and that trade-off should feel familiar to anyone who's watched LLM serving evolve. The balance between how freely you can swap adapters and how fast you can respond has always been a trade-off in that world, and video generation has now inherited the exact same dynamic.
Having personally clocked a 15-second video taking 45 minutes on an RTX 4070 laptop just last month, this result feels like it's playing in a completely different league. The gap between models running locally on consumer hardware and models that have gone through few-step distillation and landed on server-grade infrastructure is widening fast. For teams in Korea looking to bring a video generation pipeline into production, the first decision is whether to run an open-weight model locally as-is or use an endpoint that's already had this kind of serving optimization applied — because the same model can feel dramatically different depending on how it's served.
The fact that FastH3 Preview doesn't yet support per-request adapter switching or offloading shouldn't be read as a flaw — it's simply where things stand at this stage. Validating a fixed, single-server setup first and adding flexibility later is a pretty typical progression for open-source serving projects. In the coming weeks, it wouldn't be surprising to see VSA support and offloading added to FastH3, or to see this same few-step compression technique ported over to other open-source video models.
Comments