**CIVITAI IS RENAMING EVERY DOWNLOADED FILE THE SAME THING. MAKE SURE YOU SAVE-AS AND NAME THE FILE SO YOU KNOW WHAT IT IS.**
Support
Everything here is free and stays free — the format spec, the nodes, the workflows, the cartridges, the LoRAs. If it saved you a night of debugging (it contains several hundred of mine), tips keep the 5090 warm:
🔁 Liberapay (recurring)
⚡ Or right here: the Civitai tip button on this page sends Buzz directly.
MiniMax-H3's 33B video+audio DiTs, quantized for 16-32 GB cards. Both flavors — fl2va (text / first-last-frame to video+audio) and ref2va (identity from reference images, videos, and voice clips) — quantized from the Comfy-Org bf16 releases with a first-class minimax_h3 architecture in the metadata.
The files
fl2va Q5_1 — 25.9 GB · 6.0 bits/weight · the 24-32 GB tier, near-Q6 quality. The demo on the companion workflow page rendered on this file.
fl2va Q4_0 — 19.9 GB · 4.5 bits/weight · the 16 GB tier (streams the overflow).
ref2va Q5_1 / Q4_0 — same sizes, for reference-identity workflows.
Coming after validation: Q3mix (17.3 GB) — real 3-bit K-quants on the tensors whose geometry allows it, classic types elsewhere. Named for what it is.
Quick fixes — read this first
“unknown model architecture: minimax_h3”
Why: ComfyUI-GGUF doesn't know this architecture out of the box.
Fix: Install ComfyUI-GGUF, then run the one-lineapply_gguf_arch_patch.pyfrom the attached loader pack (idempotent, takes two seconds), restart ComfyUI.Where is the text encoder? Where are the VAEs?
Why: A GGUF here contains the transformer and nothing else.
Fix: The text encoder is now quantized too — MiniMax-H3 Text Encoder GGUF (also on Hugging Face) (take themmprojfile with it, it is required for reference images AND for multi-shot chaining). VAEs come from Comfy-Org/MiniMax-H3. Load the GGUF withUnetLoaderGGUF— or with the one-dropdown dual-format loader in the companion workflow pack.It's 19.9 GB and I have a 16 GB card
Why: That is the wrong mental model — the file does not need to fit.
Fix: Nothing. ComfyUI streams what doesn't fit; you pay some speed, not failure. Measured reference: Q5_1 on an RTX 5090 runs ~22 GB resident, about 10 minutes for a 243-frame 544x960 shot at 20 steps.Which flavor do I want?
Why: Two different conditioning systems, two checkpoints.
Fix:fl2vafor text-to-video, image-to-video, and last-frame chaining (the multishot workflow).ref2vawhen identity comes from reference images or voice clips instead.
Why there is no Q6_K
K-quants (Q6_K, Q5_K, Q4_K, Q3_K…) require weight rows divisible by 256, and H3's hidden width is 2688 — which is not. Requesting one just quantizes something else with the wrong name on it. The ladder for pure quants here is the classic family: Q5_1 and Q4_0 above. One useful exception exists — the FFN down-projections ARE 256-divisible, which is what makes the mixed Q3mix tier possible at 17.3 GB.
Quantization notes
About 40% of this model is per-block adaln modulation; it is quantized here, exactly as the official int8 release quantizes it.
Kept at full precision: patch projections, time embedder, condition projection, final layer, token refiner.
Built with a patched llama.cpp adding
minimax_h3as a first-class architecture — the metadata says what the file actually is.
Everything else I've published
Description
FAQ
Comments (6)
can you provide the workflow?
Added to Suggested Resources
thank u
The size of these models is as large as the pruned INT8, making them pointless. Why don't you prune them after quantization?
You're not wrong about the Q5_1 - a pruned INT8 lands at ~20 GB and will beat a 24 GB Q5_1 on quality. That file's been overtaken and I'll deprecate it.
These went up when H3 released, before any pruned INT8/INT4 builds existed. The first pass was a faithful straight conversion of the official bf16 weights; nothing removed, nothing reordered - because that's the version you can hand people on day one and be confident it behaves exactly like the reference. Dropping the AdaLN branches means acting on the claim that ~13B of the 33B is inference-dead; the model card says so, but I wanted that verified against the actual ComfyUI graph before shipping weights with a third of the tensors missing. Once it checked out, I rebuilt from pruned source and published those separately:
https://civitai.com/models/2835678/minimax-h3-curve-form-gguf-fl2va-ref2va-low-vram
curve-Q4_0 — 10.7 GB
curve-Q5_1 — 14.2 GB
curve-Q8_0 — 20.0 GB
curve-Q4_0 is still the smallest H3 DiT I've seen published -under the AsymW4A8 (11.2 GB) and the w4a8_mixed builds.
On why GGUF rather than only INT8: the convrot int8/int4 formats need fused quantized-matmul kernels to be available in your stack. When they are, they're excellent and generally faster, since GGUF dequantizes on the way into compute. When they're not - older cards, ROCm, a torch or ComfyUI build without those custom ops, or anything currently marked experimental - GGUF just loads. It also degrades gracefully: the ComfyUI-GGUF loader handles partial offload well, so a 10.7 GB file is genuinely runnable on a 12 GB card by streaming layers, which is the whole point of that listing.
Different tools. If the int8/int4 path works on your machine, use it. The GGUFs are there for the machines where it doesn't.
And on pruning after quantizing rather than before: it's structural here; whole tensors the graph never touches, so the output is identical either way. Pruning first just avoids spending quantization time on 13B of parameters headed for deletion.