TL;DR:
FastVideo FastH3 now runs on up to 2x NVIDIA DGX Sparks and on Apple Silicon. Up to 8x speedup! We also share some updates on next versions of FastH3!
FastVideo FastH3 builds on Minimax H3. We thank the Minimax team for releasing its weights and code.
The FastVideo Team collaborated closely Nuva Lab,
NVIDIA FastGen (Julius Berner, Chao Liu, Arash Vahdat), and NVIDIA Enterprise Products (Pengcheng Li, Cliff Woolley) team collaborated FastH3 Preview.
H3 generates video and audio together. That used to mean a data-center GPU. Our FastH3 Preview distilled it into a few steps on NVIDIA Blackwell. This release puts that model on NVIDIA DGX Sparks (up to 2x) and Apple Silicon through MLX. The Mac path needs 36 GB of unified memory or more. A pair of Sparks can share one clip over QSFP.
This post also publishes the FastVideo Cookbook for the first time. MiniMax H3 is on it, with CUDA, native MLX, a Spark-pair recipe, and a local OpenAI-compatible server.
Generated locally
The same prompts on an Apple M4 Max, NVIDIA DGX Spark, and four GB200s. Turn the audio on.
Those six clips are the same recipe: 832×480, 124 frames, four-step FastH3, full VAE. The chart splits a first generation from a repeat. Spark repeat is a second generate in the same process, not a loaded server. Qwen and DiT still reload. Most of those 20 to 31 seconds are VAE compile already paid. GB200 is a loaded server. 350 s of model start sits outside both bars.
On the Mac, denoising is most of the wait. On Spark with the full VAE, decode is.
FastH3 on DGX Spark
DGX Spark is NVIDIA’s desktop Blackwell machine. GB10 GPU, 128 GB of unified LPDDR5X, CUDA 13, ARM64. The FastH3 CUDA path from the Preview release now runs here, on one Spark or on a pair.
Although the model fits, we cannot load it the usual way.
There is no separate VRAM. CPU and GPU share one pool, at roughly 270 GB/s, about a tenth of datacenter HBM. FastH3’s encoder, transformer, and decoders add up to more than the 121 GB a workload actually gets. Keep them all resident and the process dies before the first frame.
So the pipeline never holds them together. It encodes the prompt, drops the text encoder, loads the transformer, denoises, drops the transformer, then loads the VAE. Patch size and compression ratios come from the checkpoint config, so decode does not keep a 65 GB DiT loaded just to read a patch size.
On a discrete GPU, copying weights to the host frees device memory. On Spark that copy lands in the same pool. We stopped it. DiT weights load straight onto the GPU. On one GB10 that cut the transformer load from 445 seconds to 39 seconds, and a 768×1344, 124-frame run from 772 seconds to 336 seconds.
H3 never uses the last layers of its text encoder. The Spark path skips them.
Video Sparse Attention stays on CUDA. The FastVideo kernel builds from source
for sm_121.
A pair of Sparks can share a single generation. Sequence parallel splits denoising and decode across both NVIDIA GB10s over the QSFP link. Each box still loads components in phases. The transformer is copied onto both, so neither can skip the phased load.
On the same 768×1344, 124-frame recipe, two Sparks finished in 292 seconds. One Spark took 374. TAEH3 on that pair was 195 seconds. A 345-frame clip, about 14 seconds of video, finished in 581 seconds on the pair with the full H3 VAE.
The public vLLM-Omni MiniMax H3 recipe for DGX Spark starts at 1024×576, five seconds, 50 steps. On one Spark that request took 1881 seconds. FastH3 at the same shape, four steps, finished in 268 seconds, about 7×. 832×480 was 8.4×. 1344×768 was 7.9×. Same box, same 124-frame clip.
Install from the CUDA 13 Spark guide. For a pair, follow the pair guide, then pick a CUDA recipe in the Cookbook.
How H3 runs on a Mac
The weights are only part of the problem. H3 also needs a large text encoder, working memory for denoising, and decoders for video and audio. Load all of that at once on a 36 GB Mac and there is nothing left to generate with.
So the runtime never tries. It runs in phases. Encode the prompt, denoise, decode, export. Each phase loads what it needs and frees the rest.
H3 reads an intermediate layer of Qwen3-VL, so the encoder skips the last 14 layers. It streams the rest one layer at a time and keeps only the embedding rows the prompt uses. An uncached prompt used to spend about 80 seconds here. A single bounded read per tensor brings that to about 17 seconds, with the same hidden features. Cache those embeddings and the next prompt skips this stage.
After denoising, tiled video decode and a native audio decoder finish the clip without rebuilding the whole frame buffer at once.
Smaller weights are not always faster. H3 multiplies large video and audio matrices. At those shapes, unpacking a quantized weight into BF16 and using MLX’s dense matrix multiply beat the quantized kernel. The unpacked copy is discarded after the multiply.
On a four-step INT6 run, denoising dropped from 386.47 seconds to 348.75 seconds. The video and audio latents were bit-exact. Peak MLX memory rose from 19.31 GiB to 19.46 GiB. That run used 832×480, 124 frames, and dense attention, so this is the matmul path, not Video Sparse Attention.
The Mac path still implements Video Sparse Attention. Selected video tiles attend. The rest do not.
INT8, INT6, and INT4
Every Mac number in this post comes from an M4 Max with 36 GB of unified memory.
INT8 keeps more of the original weights. INT4 leaves the most room for activations. INT6 is the default we timed. Wall clock barely moves across the three. Peak memory does. Same prompt, same seed.
INT8, INT6, and INT4 MLX weights are on Hugging Face.
Full VAE versus TAEH3
The full H3 VAE is the quality path. TAEH3 is the preview path. It reconstructs the same latents much faster, and fine detail goes softer. Hair, fabric, and distant backgrounds lose bite.
On an M4 Max, tiled H3 VAE decode took 104 seconds. TAEH3 took one second. On one Spark, VAE decode was 114 seconds and TAEH3 was 1.3 seconds. End-to-end with TAEH3 was 134 seconds on that box, 119 seconds on two. At 768×1344 on two Sparks, TAEH3 decode was 12.5 seconds and the clip finished in 195 seconds. Use TAEH3 to check a prompt. Render with the full VAE when you like what you see.
Same prompt and seed. First row is the full VAE. Second row is TAEH3. Columns are an M4 Max, one Spark, and two Sparks.
Faster drafts
A native-resolution clip takes a while. That is fine for a final render. It is a lot to pay to find out the prompt is wrong.
--fast denoises fewer video frames, then interpolates back to 124.
This run generated 73 frames. RIFE filled the rest. Audio keeps its full
duration.
--fast-spatial denoises a smaller canvas, then resamples up. The clip
below is the conservative setting, 672×384 up to 832×480. Composition and
fine detail get softer. Treat it as a preview knob, not a final render.
Same prompt and seed on the M4 Max. INT6, cached prompt, full VAE.
FastVideo Cookbook
Open the Cookbook, pick a model, pick a recipe, and copy a command we actually run.
H3 is there with CUDA, the four-step preview, LoRA, native MLX, and a two-Spark recipe.
You can also serve FastH3. Start the server once on CUDA or on MLX. Then change prompts from the playground, from cURL, or from an OpenAI-compatible SDK in your app. Later prompts reuse that process. You do not reload the model for every try. Open the H3 recipes or the server guide. Spark users should install from the CUDA 13 Spark guide first. Two boxes should follow the pair guide.
We are still cutting latency, adding distilled models, and looking at schedules with fewer than four steps. The RTX family, including the 5090 and 4090, is the next CUDA focus.
Apple just announced M6 in the Mac mini and M5 Ultra in the Mac Studio. We have not run FastH3 on those, or on M5 Max or M5 Pro Mac mini. Every Mac number here is from an M4 Max. The MLX path is the same on those chips. They should be faster, especially M5 Ultra with its unified memory and GPU. We want to measure them.
If you measure a new machine, improve a kernel, or hit a bug, start from the contribution guide or the repository. Include hardware, settings, timings, and the output.
Acknowledgements
FastVideo FastH3 builds on Minimax H3. We thank the Minimax team for releasing its weights and code.
We thank the NVIDIA Enterprise Products team (Pengcheng Li, Cliff Woolley) for the amazing work on the Video Sparse Attention (VSA) kernel used by FastH3!
The FastVideo Team collaborated closely with Nuva Lab,
NVIDIA FastGen (Julius Berner, Chao Liu, Arash Vahdat), and NVIDIA Enterprise Products team on FastH3.
We thank Ollin Boer Bohan for TAEH3, the optional preview decoder this release uses. The Mac path is built on MLX and the community around it.
We also thank the vLLM project, NVIDIA, and MBZUAI for their continued sponsorship and support of FastVideo.
FastVideo team
Contributors: Aryan Kumar*
,
Kyle Hu*
,
Satyam Srivastava*
,
Ishan Vaish
(*Equal Contribution)
Tech lead: Will Lin
Advisor: Hao Zhang