NVIDIA Sol-H3 Generates AI Video Faster Than Playback

NVIDIA's SANA team merged pull request 484 into the sol-engine branch of the NVlabs/Sana repository at 16:09 UTC on September 7, 2026, publishing a standalone inference runtime called Sol-H3. On a system of 8 NVIDIA B300 GPUs it generates 124 frames of 1344x768 video at 24 FPS, with synchronized stereo audio, in a warm-pipeline median of 1.653 seconds. Those 124 frames are 5.17 seconds of footage. The generator is now roughly 3.1 times faster than the clip plays.

That threshold has been approached for months and crossed in pieces. This is the first time an NVIDIA-published runtime has claimed it outright, in writing, with a reproducible benchmark matrix and an unusually candid list of what was traded away to get there.

What NVIDIA actually shipped

Sol-H3 is not a model. It is a production inference package that wraps MiniMax H3, the 33B omni-modal video model MiniMax open-sourced in late July, which we covered when the weights first landed. The runtime directory ships three task paths: four-step text-to-video, first-frame image-to-video, and Ref2VA, the reference-conditioned mode that takes an image or video plus optional audio and returns a clip with matching sound.

It runs on 1, 2, 4, or 8 GPUs with Ulysses sequence parallelism, and defaults to a sparse attention profile the team calls SOL/BSA. Output is fixed at 1344x768 and 24 FPS in durations of 5, 10, or 15 seconds. Ref2VA is slower than plain text-to-video but still ahead of playback at the top configuration: 2.192 seconds for 124 frames, 4.348 for 243, 5.947 for 362.

The benchmark matrix

The published table measures three engines at three GPU counts on NVIDIA B300 SXM6 hardware, each cell the median of three requests after one warmup, all at the same prompt and seed. Text encoding, DiT denoising, and video and audio VAE decoding are counted. Checkpoint loading, compilation warmup, and MP4 encoding are excluded.

The headline multipliers on the project page, 11.04x at 5 seconds, 13.57x at 10, and 15.05x at 15, are measured against the SGLang row at the same GPU count, not against Diffusers. Against Diffusers the 8-GPU gap is wider still, about 18.6x. Note also that the speedup grows with clip length, which is the signature of attention cost dominating at longer sequences.

Why 11x is not an honest runtime number, and NVIDIA says so

This is the part worth reading twice, because it is the part no aggregator will carry. The README states it plainly: Sol-H3 "uses a distilled four-forward adapter and its multi-GPU profile uses approximate SOL/BSA attention, so the difference from either 49-forward baseline is not a runtime-only speedup."

Unpacked, the two baselines run the base BF16 dense model with 50 scheduler points, meaning 49 DiT forward passes. Sol-H3 runs a distilled FastH3 adapter with five scheduler points, meaning four forward passes. Before a single kernel optimization is counted, that is roughly a 12x reduction in denoising work. On top of it, the 4 and 8 GPU profiles use approximate attention in which, per the project page, "selected blocks use exact attention; skipped blocks receive an approximate correction from pooled K/V summaries," plus INT8 transport for QKV and FP8 for output.

So the honest reading is that this is a distillation result wearing a runtime's clothes, and NVIDIA labels it as such. The earlier Sol Engine work from August 3 was a true like-for-like runtime win: 3.95x end-to-end on 8 GB200s, 27.205 seconds down to 6.883, same model, same step count. The Super Acceleration profile of August 17 already introduced the draft-then-refine trick to reach 6.852 seconds for a 5-second clip on a single GB200. Sol-H3 is the third and most aggressive step down that road. Quality is not free here, and the page does not pretend otherwise.

What faster-than-playback actually unlocks

Below 1x realtime, generation is a render job: you write a prompt, you wait, you judge the result. Above 1x, it becomes an interactive medium, and three workflows open that were previously impossible.

The first is iterate-while-watching. If a 5-second clip returns in under 2 seconds, a creator can run 20 prompt variants in the time a single Diffusers pass used to take, which turns prompt engineering from a batch process into something closer to scrubbing a timeline. The second is live preview inside an editor: a runtime this fast can sit behind a node in a compositor and update as parameters change, the same way GPU viewport rendering replaced offline preview passes in 3D. The third is streamed and interactive output, the direction already visible in steerable real-time models and in interactive world models, where the generator must stay ahead of the viewer indefinitely rather than finish a fixed clip.

Audio matters more here than it first appears. Sol-H3 generates synchronized stereo sound in the same pass, so the faster-than-playback claim covers a finished audiovisual clip, not a silent plate that still needs a sound design pass bolted on afterward.

What it costs to run

Here is the reality check. The headline configuration is 8 NVIDIA B300 GPUs, which is a datacenter system, not a workstation. The threshold survives at 4 GPUs, where 2.918 seconds for 5.17 seconds of footage is still about 1.8x realtime. It does not survive at one GPU: 13.745 seconds for the same clip is roughly 2.7 times slower than playback.

Kernel validation in this release is also narrower than the repository as a whole. The team validated SM103, the B300 architecture, through the SM100-family backend, and states that the reachable SM90 and SM120 paths, which cover H100 and the consumer Blackwell cards, remain unvalidated pending hardware-specific checks. If you are on an RTX 5090, the relevant prior work is the separate on-device Sol Engine report, which measured 4.52x acceleration but a 5-second 768p clip in 231.2 seconds. That is two orders of magnitude away from playback speed.

For anyone who wants the speed without the hardware, the hosted route already exists. fal's post-trained H3 Max reached roughly 3 seconds for a 5-second clip and lists $0.08 per second at 768p after its launch promotion, which we covered when fal shipped it. Sol-H3 is faster on paper, but you supply the cluster.

The license split: Apache code, community-license weights

Worth checking before anything commercial gets planned, because the two halves are not governed by the same document. The NVlabs/Sana repository that carries the Sol-H3 runtime is Apache 2.0. The model weights it loads are not. MiniMax H3 on Hugging Face carries the MiniMax H3 Community License Agreement, and the setup instructions require accepting the model terms and authenticating before download_checkpoints.py will pull anything.

The same distinction applies to the adapters. The four-step T2V path pulls a FastVideo-hosted FastH3 preview LoRA, and the Ref2VA path pulls a separate four-step turbo adapter from lightx2v. Read each one on its own terms. Permissive inference code around restrictively licensed weights is now the normal shape of an open video stack, and reading only the repository badge will mislead you.

How to run Sol-H3

1. Provision Linux with Python 3.12, CUDA 13.0, and PyTorch 2.10. The documented install pins torch 2.10.0+cu130 with matching torchvision and torchaudio from the CUDA 13.0 wheel index.
2. Clone the sol-engine branch of NVlabs/Sana and install from models/minimax_h3/Sol-H3/requirements.txt.
3. Accept the MiniMax H3 model terms on Hugging Face, run hf auth login, then python download_checkpoints.py --output-dir ./checkpoints. Add --task ref2va to fetch the reference-conditioned partition and its adapter instead.
4. Launch with torchrun --standalone --nproc_per_node=8 infer.py, pointing --model at the checkpoint directory and --adapter at the FastH3 LoRA, then set --task, --duration, a prompt file, and an output path.
5. Pass --warmup. Every published number is a warm-pipeline median, and a cold first request includes compilation you should not benchmark against.
6. If you need a dense-attention reference, or you are on a single GPU, select the dense profile. The default profile is explicitly lossy.

Frequently asked questions

Is Sol-H3 a new video model?

No. It is an inference runtime for MiniMax H3, which was released in late July. The generation quality ceiling is still H3's, and the four-step adapter trades some of that ceiling for speed.

Does 1.653 seconds mean I can generate video in real time on my PC?

Not on one consumer card. That figure is a warm-pipeline median on 8 NVIDIA B300 GPUs. A single GPU takes 13.745 seconds for the same clip, and the consumer Blackwell code path is listed as unvalidated in this release.

Does the output include sound?

Yes. Text-to-video generates synchronized stereo audio in the same pass, and the benchmark timings include audio VAE decoding. Ref2VA additionally accepts reference audio alongside an image or video.

How much quality is lost against the standard pipeline?

The release does not publish a quality metric, which is its main gap. It documents the mechanisms instead: four denoising forward passes rather than 49, approximate attention on skipped blocks, and INT8 or FP8 transport on multi-GPU profiles. Run the dense profile side by side on your own prompts before committing to it.

What license applies if I use this commercially?

Two separate ones. The runtime code sits in an Apache 2.0 repository. The MiniMax H3 weights carry the MiniMax H3 Community License Agreement, and the adapters have their own terms. The permissive repository license does not extend to the weights.

How long are the clips?

Fixed at 5, 10, or 15 seconds, at 1344x768 and 24 FPS, corresponding to the 124, 243, and 362 frame counts in the benchmark table.

What to watch next

Two things decide whether this becomes a workflow rather than a benchmark. The first is whether the SM90 and SM120 paths get validated, because that is what moves faster-than-playback from a B300 cluster onto H100 rentals and eventually onto desktop Blackwell. The second is whether anyone publishes a quality comparison of the four-step adapter against the 49-step baseline on identical prompts. Until that exists, the speed number is verified and the cost of it is not.