Video Rebirth's HyperFlow H3 Flash shrinks MiniMax-H3 to 14B for consumer-GPU video and audio

Video Rebirth has open-sourced HyperFlow H3 Flash, a compressed reworking of MiniMax-H3 that generates video and synchronized stereo audio in a single pass using as few as four diffusion steps. According to the project's GitHub repository, which reached the front page of Hacker News on November 7, 2026, the transformer has been cut to 13.7 billion parameters — under half of the roughly 31 billion in MiniMax-H3 — with weights published on Hugging Face and tooling for ComfyUI, Unsloth Studio and a standalone Python package.

What the model generates

The model produces clips between 5.2 and 15 seconds long at 24 frames per second, defaulting to 1344×768 resolution, with a 32 kHz stereo soundtrack generated alongside the visuals. Sampling runs at four, six (the default) or eight steps, and the pipeline operates without classifier-free guidance, removing a duplicated forward pass that usually doubles step cost.

Three task variants ship with the release. A text-to-video-and-audio mode works from a prompt alone. A keyframe mode accepts either a first frame or a first and last frame to bookend a shot. A reference mode takes up to 12 references in prompt order — nine images, three videos and three audio clips — so a subject from one picture can be placed into the scene of another.

Measured performance

The repository publishes timings for a 5.2-second clip at six steps: 8.7 seconds on four B200 GPUs, 36 seconds on a single H200, and 92 seconds on a single RTX 5090. Video Rebirth also names NVIDIA SOL-H3 as a partner for accelerated inference that runs the model in real time on four Blackwell-class GPUs. The reference-guided variant is slightly larger, at 13.9 billion parameters.

Quantized builds for desktop GPUs

For consumer machines the model ships in GGUF format, spanning roughly 7.2 GB at Q3_K_M to 14.9 GB at Q8_0, with a 9.1 GB Q4_K_M build recommended for 24 GB graphics cards. Video Rebirth says the GGUF builds run on 24 GB and 32 GB GPUs in PCs with only 16 GB of system RAM, although 16 GB cards have not been benchmarked yet. The project's rule of thumb is to use GGUF on any PC with 64 GB of system RAM or less.

A separate INT8 path, using W8A8 weights plus low-rank corrections at about 16 GB, targets H100, H200, B200 and B300 accelerators in one-to-eight-GPU configurations, or RTX cards in machines with at least 69 GiB of RAM. The first INT8 run downloads around 90 GB of material — a 15.7 GB Qwen3-VL-32B-based text encoder, the VAEs and the quantized transformer — or about 68 GB with an fp8 text encoder. Notably, the 62 GB full-size MiniMax-H3 transformer is never downloaded.

Runtimes and integration

The GGUF builds run in ComfyUI, Unsloth Studio and stable-diffusion.cpp; the last requires a patch that adds the model's two-timestep embedder, its low-rank layers and a default six-step schedule read from GGUF metadata. ComfyUI users install two custom-node packages and pick from templates covering all three task modes, with a fast-disk startup flag for lower-memory machines. In GGUF form the reference mode accepts images only, while the INT8 build also takes video and audio references.

The INT8 build comes through a Python package offering both a command-line tool and a diffusers-based API, with multi-GPU context and VAE tile parallelism across one, two, four, seven or eight cards. Requirements are Python 3.10+, PyTorch 2.6+, diffusers 0.40 or newer and an Ampere-or-newer NVIDIA GPU. The release also links an 8-step LoRA that brings the few-step schedule to the full-size MiniMax-H3.

Why it matters

Joint video-plus-audio generation has largely lived behind APIs or in checkpoints far too large for personal machines. Shipping a roughly half-size, few-step derivative — with quantized weights, ComfyUI templates and a plain CLI, plus benchmarks down to a single RTX card — moves the capability onto desktops and small studios, and the speed figures on server hardware point toward interactive use. The repository does not publish quality comparisons against the full 31B model, so how much fidelity the compression costs is a question early adopters will have to judge themselves.