HyperFlow H3 Flash: a 31B video model cut to 13.7B for one GPU

Video Rebirth, a company building video-generation tools, published HyperFlow H3 Flash on 7 November 2026 and introduced it on Hacker News the same day (54 points at the time of writing). Its README describes a compressed, few-step version of MiniMax-H3, an open model that generates video and synchronised stereo audio together. The authors say the transformer drops from roughly 31B to 13.7B parameters and that it samples in 4, 6 or 8 steps.

What changed in the model

An engineer on the project, posting as jiant, listed three changes in the thread. They pruned 3 of the model's 50 blocks and factored 102 linear layers into low-rank form. They added a two-value conditioning scheme so each sampling step knows both the current noise level and where it should land, which the README says lets the model run in 4 to 8 steps without classifier-free guidance. And they applied 8-bit integer (W8A8 INT8) quantisation, with a Hadamard rotation, to 180 linear layers.

What it costs to run, according to the README

For a 5.2-second clip at 1344×768 in 6 steps, the README reports 8.7 seconds on four NVIDIA B200 GPUs, 36 seconds on one H200 and 92 seconds on one RTX 5090. It also says NVIDIA's SOL-H3 inference engine, built by a partner, runs the model in real time on four Blackwell-class GPUs. These are the authors' own measurements; I have not seen an independent run.

For smaller machines the README offers GGUF builds from 7.2 GB (Q3_K_M) to 15.2 GB. It recommends the 9.1 GB Q4_K_M build for 24 GB GPUs and says it runs on 24 GB and 32 GB cards in PCs with 16 GB of system RAM. 16 GB GPUs, it says, are not measured yet. The data-centre route uses the INT8 build at about 16 GB.

Neither route is light on disk. The README says the first run of the Python package downloads about 90 GB, or about 68 GB with an FP8 text encoder, and compiles kernels for roughly a minute. Output is 5.2 to 15 seconds at 24 frames per second.

Pushback in the thread

The strongest objection, from several commenters, was that the post compares speed and size but not quality. One said it was like announcing a JPEG compressed to half its size without checking what it looks like; another asked for a head-to-head against the original model. A commenter pointed to the project's showcase page for sample videos. Another asked how it compares with FastVideo's FastH3 variants, which they run on a laptop-class NVIDIA card; no answer from the authors appeared in the part of the thread I read.

Others asked about tooling. The README supports ComfyUI, Unsloth Studio and stable-diffusion.cpp for the GGUF builds, and a command-line tool for the INT8 build. Commenters said they drive such runtimes from coding agents.

What a team can take from it

If your team generates marketing or training video and is paying per clip to a hosted service, this is a candidate for an in-house pilot: one workstation GPU, no per-clip fee. Run the same ten prompts through your current service and through the 9.1 GB build, and have a reviewer score them blind. Check the licence of both the base model and the weights before any commercial use; I did not verify either. Treat the speed table as a ceiling, not a plan.