**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:

• ☕ Buy me a coffee on Ko-fi

• 💛 Sponsor on GitHub

• 🔁 Liberapay (recurring)

• ⚡ Or right here: the Civitai tip button on this page sends Buzz directly.

GGUF quantizations of MiniMax-H3's 33B video+audio DiTs, built from MiniMax's pruned checkpoints. Same model and the same quant tiers as the original-form GGUFs, about 40% smaller — and a Q8_0 that fits a 24 GB card.

Before you load one of these: ComfyUI-GGUF does not know this architecture out of the box.

Its loader keeps a hardcoded allow-list, and minimax_h3 is not in it, so you get ValueError: Unexpected architecture type in GGUF file: 'minimax_h3'. Install ComfyUI-H3-Multishot and run python apply_gguf_arch_patch.py from its folder, then restart ComfyUI. It is one line, idempotent, and applies whichever DiT loader you use.

You also need the text encoder (Qwen3-VL GGUF + its mmproj sidecar) and the VAEs. A file here is the transformer and nothing else — on its own it generates nothing. Load the encoder with the pack's H3ClipLoaderAny at type = minimax, not with “CLIPLoader (GGUF)”, which has no minimax type and fails with a confusing tokenizer error instead.

These are a different trade, not a straight replacement. If you are on an older ComfyUI, or you would simply rather run the larger quants, the original-form files are still maintained and are not going anywhere.

• Q8_0 — 21.5 GB · original form: never built · fits a 24 GB card

• Q5_1 — 15.2 GB · original form: 25.9 GB · fits a 16 GB card, fully resident

• Q4_0 — 11.5 GB · original form: 19.9 GB · fits a 12 GB card

Both conditioning modes are here: fl2va (text / first-last frame to video+audio) and ref2va (reference-conditioned identity).

These need ComfyUI 0.30.0 or newer. On anything older they will not load, because the shape of the modulation weights changed and older builds do not know how to read them. That is the only catch — everything else is a drop-in swap: same node, same workflow. The original-form files stay up for anyone pinned to an older version.

Where the 40% went

About 40% of this model was never unique data. Every block carried a 96768 × 2688 adaln modulation matrix, and MiniMax's pruned checkpoints show those are a smooth function of the timestep rather than 51 independent tensors. The pruned form factorises each one to 96768 × 8 and adds a single shared table to reconstruct them. Same math, roughly 26 GB less file.

That is why a Q8_0 exists now. In the original form it was pointless — it landed at about the size of the official int8 release. Factored down, Q8_0 is smaller than the Q5_1 that has been shipping since day one.

Is it actually the same?

Checked by rendering, not by assuming. Every row below is the same graph and the same seed, changing only the model file. Numbers are mean absolute pixel difference across all 124 frames:

• same model, re-run — 0.00 · the noise floor; sampling is deterministic, so everything below is real signal

• Q5_1 → Q4_0, both shipped — 29.64 · the yardstick: one quant tier, already considered good enough to ship

• curve Q5_1 — 10.83 · about a third of a quant tier

• curve Q8_0 — 17.06 · distance from a Q5_1 baseline, not an error; a higher tier should sit further from Q5_1

• curve ref2va Q5_1 — 10.98 · vs its own ref2va baseline

• curve ref2va Q4_0 — 13.36 · vs the shipped ref2va Q4_0; same tier, so this isolates the form change cleanly

Per-frame motion stayed in family in every case, which is checked separately and on purpose: a frozen render scores a deceptively good pixel distance, so distance alone is not enough to trust.

The two rows that isolate the change cleanly are the same-tier ones — curve Q5_1 against shipped Q5_1, and curve Q4_0 against shipped Q4_0. Both land near a third of the yardstick. Comparing a curve Q4_0 against a shipped Q5_1 would vary tier and form at once and tell you nothing; that mistake is why the same-tier rows are here at all.

The 24 GB claim, actually tested

"Q8_0 fits a 24 GB card" is easy to assert from a file size, so it was run on one — an RTX 3090, using a graph with no text-encoder eviction, which is the unfavourable case:

• curve ref2va Q4_0 — 10.68 GiB · 6.7 min · 0 / 123 frozen frames

• curve ref2va Q5_1 — 14.18 GiB · 7.0 min · 0 / 123 frozen frames

• curve ref2va Q8_0 — 20.02 GiB · 6.8 min · 0 / 123 frozen frames

All three land within 0.3 min of each other, so none of them thrashed — DiT size simply is not the bottleneck at these sizes on that card. Mid-run the card read 21.7 GB in use of 24.0, with 2.3 GB free: the 20 GiB model is resident, not streaming.

For scale, the original-form ref2va Q4_0 that people run today is 18.5 GiB and took 7.5 min on the same machine. So curve Q8_0 is a higher quality tier, smaller, and faster than the file it replaces.

Speed

RTX 5090, 124 frames at 480×864, 20 steps:

shipped Q5_1   3.7 min
curve   Q5_1   3.1 min
curve   Q8_0   3.1 min

If a render is far slower than this, check power draw rather than utilisation. A card thrashing weights between system RAM and VRAM still reports ~98% utilisation while pulling a fraction of its rated watts. That is the tell that the model did not fit — the utilisation figure will not tell you.

You also need the text encoder

A file here is the transformer and nothing else. The DiT alone generates nothing. Get the Qwen3-VL encoder (Civitai / Hugging Face) and take the mmproj file with it — it is required for image conditioning and for multi-shot chaining, which feeds the previous shot's last frame through the encoder's vision path. VAEs come from Comfy-Org/MiniMax-H3.

The encoder and the DiT together do not fit on a 32 GB card. Evict the encoder once conditioning is computed — the node pack's keyframe and multishot nodes do this for you, and it is worth roughly a 4× difference in render time.

Why there are no K-quants

K-quants are architecturally impossible for this model. H3's hidden width is 2688 and K-quants need rows divisible by 256 (2688 % 256 = 128), so asking for one just quantises something else with the wrong name on it. The ladder here is the classic family: Q8_0, Q5_1, Q5_0, Q4_0.

Building the curve files needed a custom writer — llama-quantize cannot produce them. The factored modulation rows are only 8 wide and no GGUF block type can represent a row of 8 (they all work in 32-element blocks); llama-quantize tags them anyway and the reference reader then refuses the file outright. Those 52 tensors are stored at F32 instead, which costs ~155 MB and is not optional.

Heads up on filenames. Civitai hands every file in a model the same download name, so grabbing several variants at once leaves you with files you cannot tell apart. Rename each one as you download it.