FastH3-QAD-v2 is the October 19 update to FastVideo's eight-step MiniMax H3 video-and-audio stack. Its practical change is a quantization-aware trained checkpoint, accompanied by two new video decoders and support for community LoRA layouts. The download linked in the announcement is named FastVideo-FastH3-8-Step-V2.1-NVFP4-Consumer. That repository name and the QAD-v2 announcement refer to the same release path; they are not two competing H3 base models.
This guide follows the author's release article, consumer model card, and decoder instructions, reviewed October 20, 2026. We have not installed or benchmarked this stack. H3Vid's online generator does not execute this checkpoint.
Start with the GPU and loader
The new NVFP4 decoder kernels require NVIDIA Blackwell hardware. The card lists B200/GB200, RTX 50-series, RTX PRO 6000 Blackwell and DGX Spark. It explicitly excludes a working FP4 path on Hopper, Ada, Ampere, CPU and MPS, with no automatic fallback. Owning an RTX 4090 or an Apple Silicon Mac therefore does not make these particular decoder files usable through the advertised kernel path.
The decoder card also says its loader has not yet merged upstream. It points to aryan5v/FastVideo on branch aryan/h3-nvfp4-vae-spark. Check that branch and the current card before changing an existing installation. A new weight file cannot supply a loader that your checkout lacks. Keep the older working configuration so that you can compare the same clip after the upgrade.
What QAD changes
The earlier V2 NVFP4 export used post-training calibration and rounding. QAD adapts the student weights while running the deployed quantized arithmetic against a full-precision teacher. The new card reports an eight-step schedule, 80% Video Sparse Attention, and a text encoder reduced to the layers H3 actually reads.
The sparse-attention gate and normalization layers remain BF16. Calling the stack four-bit is a description of its major compute components, not a claim that every tensor has four-bit precision. The author's teacher-error measurements indicate closer numerical agreement in its evaluation; they are not a universal ranking of cinematic quality, identity retention or prompt accuracy.
There is another important distinction: the consumer model card still lists a lightweight INT8 video VAE in its default stack. Downloading the QAD checkpoint alone does not prove that either new NVFP4 decoder has been selected. Verify the loader configuration and logs separately.
Choose a decoder tier
The quality-36L tier preserves all 36 decoder blocks and uses about 1.29 GiB for the decoder on the GPU. The fast-8L tier reduces this to eight blocks and about 0.31 GiB. These figures describe the decoder, not the peak memory of text encoding, denoising, VAE loading and MP4 creation combined.
For the quality tier, the host vae/ must contain the full 36-block H3 VAE. The 26-block light VAE bundled with older V2 or Trim repositories is too shallow and is rejected. The eight-block tier can use that light host VAE because the loader reduces its depth. This is a concrete reason that a successful file download may still end in a configuration error.
Start with the packed decoder-nvfp4.safetensors for inference. The BF16 master file is useful for conversion and further work, but selecting it does not bypass the FP4 runtime requirement. The documented loader packs it into the same deployed arithmetic.
A documentation-based upgrade sequence
First confirm your machine, checkout and dependencies against the linked instructions. Then select one tier and download it:
hf download FastVideo/FastH3-NVFP4-VAE-Decoder quality-36L/decoder-nvfp4.safetensors --local-dir fasth3-nvfp4-vae
Point the supported FastVideo loader at that file using FASTVIDEO_H3_VAE_NVFP4_DECODER. Choose a known short prompt, seed and output shape from your existing configuration. Record the selected host VAE, decoder file and branch revision before running. This is an instruction derived from documentation, not a workflow we have executed.
On machines with less than 64GB of host RAM, the QAD card describes precomputed AdaLN tables that avoid loading the large timestep projection weights. Those tables cover only the shipped eight-step schedule. Changing timesteps while retaining the table is unsupported and should raise an error. Do not treat it as a general replacement for arbitrary sampling schedules.
Read speed numbers with their measurement boundary
The announcement reports markedly shorter warm end-to-end times on Spark and RTX 5090, while the decoder card gives separate GB200 decode timings. Different hardware, canvases, frame counts and timing boundaries answer different questions. A fifteen-times decoder improvement cannot be applied to text encoding or multiplied directly into a whole-video speed claim.
For your own comparison, measure from an accepted prompt to a usable MP4, report loading separately, and inspect both frames and sound. Use the same prompt and seed, and keep resolution, schedule and decoder choice explicit. Compare fine texture, faces, dark gradients and motion edges before choosing the fast tier. The author's blind comparisons include quality losses for the eight-block decoder; it is a tradeoff, not an identical-output mode.
LoRAs and the next release
FastVideo now documents direct loading of common community LoRA layouts alongside packed weights. The LoRA runs as a BF16 branch, and the author warns that a useful strength on a fifty-step base may differ on eight-step FastH3. Turbo LoRAs are unnecessary, and full-model LoRAs are not supported on Trim's reduced block layout.
Update, October 21: FastVideo published OmniRef on October 20. It has a separate reference-conditioned checkpoint and runtime packages; the text-focused V2.1 download does not gain those inputs automatically. See our Omni ComfyUI setup guide for file selection and FastH3-Omni API explanation for hosted sessions. For the earlier consumer variants and pruning tradeoff, read FastH3 V2 and Trim.