GGUF quantizations of MiniMax-H3's
33B video+audio DiTs, built from MiniMax's pruned checkpoints. Same model,
same quant tiers as the original-form
repo, about 40% smaller
and a Q8_0 that fits a 24 GB card.
File
Size
For
fl2va curve Q8_0
21.5 GB
best quality that still fits 24 GB
fl2va curve Q5_1
15.2 GB
the everyday choice, fully resident on 16 GB
fl2va curve Q4_0
11.5 GB
12 GB cards
ref2va curve Q8_0 / Q5_1 / Q4_0
21.5 / 15.2 / 11.5 GB
same tiers, reference workflows
fl2va = text/first-last-frame to video+audio (T2V and I2V).
ref2va = reference-conditioned generation (identity from up to 9 images,
3 videos with soundtracks, 3 voice clips).
On anything older these will not load at all, 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,
same filenames apart from -curve-.
If you are pinned to an older ComfyUI, or you would simply rather run the larger
quants, the original-form files are still maintained at
joeygambino/MiniMax-H3-GGUF.
That repo is not going anywhere.
Where the 40% went
About 40% of this model was never unique data. Each block carried a
96768 x 2688 adaln modulation matrix, and MiniMax's pruned checkpoints show
those matrices are a smooth function of the timestep rather than 51 independent
tensors. The pruned form factorizes each one to 96768 x 8 and adds a single
shared adaln_t_table to reconstruct them. Same math, ~26 GB less file.
This is why Q8_0 exists here and not in the original repo. In the original form
it was pointless - it landed at roughly the size of the official int8 release.
Factored down, Q8_0 is smaller than the Q5_1 in that repo (21.5 GB vs
25.9 GB).
Is it actually the same?
Checked by rendering, not by assuming. Every comparison below is the same graph
and the same seed, changing only the model file:
vs the original-form Q5_1 render
same model, re-run (noise floor)
0.00
original Q5_1 -> original Q4_0 (one quant tier)
29.64
curve Q5_1
10.83
curve Q8_0
17.06
curve ref2va Q5_1 (vs its own baseline)
10.98
Numbers are mean absolute pixel difference over all 124 frames. The noise floor
being exactly 0.00 is what makes the rest meaningful - sampling is deterministic
at a fixed seed, so these are real differences and not run-to-run variation.
Swapping to curve form moves the output about a third as far as dropping one
quant tier does, and per-frame motion stayed in family in every case (a frozen
render would otherwise score a deceptively good pixel distance).
The Q8_0 figure is a distance from a Q5_1 baseline, not an error measure - a
higher-fidelity file should sit further from Q5_1, not closer. Proving the
direction would need an F16 reference render, and the F16 curve file is 37.5 GB,
so that is untested rather than assumed.
Speed
RTX 5090, 124 frames at 480x864, 20 steps:
original Q5_1 3.7 min
curve Q5_1 3.1 min
curve Q8_0 3.1 min
The curve files are faster here for the obvious reason - less weight to move.
If a render is far slower than this, check power draw rather than
utilization. A card thrashing weights between system RAM and VRAM still reports
~98% utilization while drawing a fraction of its rated power; that is the signal
the model did not fit, and the utilization figure will not tell you.
Why there is no Q6_K / Q5_K / Q4_K / Q3_K
K-quants are architecturally impossible for this model. H3's hidden width is
2688, and K-quants require weight rows divisible by 256 (2688 % 256 = 128), so
requesting one just quantizes something else with the wrong name on it. The
legal ladder is the classic family: Q8_0, Q5_1, Q5_0, Q4_1, Q4_0.
Q5_0 and Q4_1 are buildable and simply have not been - they would land between
files already here.
Build notes
llama-quantizecannot build these. The factored adaln rows are only 8
wide, and no GGUF block type can represent a row of 8 (they all work in
32-element blocks). It tags them with the requested type regardless, and the
reference reader then refuses the file (row size 8 is not a multiple of Q5_1 block size 32); Q4_0 fails outright, writing 0 bytes. These were built with a
small Python writer that skips what it cannot legally quantize.
Those 52 short-row tensors are stored F32, matching the reference
converter. That costs ~155 MB and is not optional: storing them F16 produces a
structurally valid file that dies at sampling with expected dtype struct c10::Half for 'weight'.
Kept at full precision throughout: patch projections, condition projection,
final layer, token refiner.
You also need the text encoder
A GGUF here contains the transformer and nothing else. The DiT alone will
not generate anything.
Qwen3-VL-32B, Q4_K_M (19.8 GB) or Q5_K_M (23.2 GB). 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. Keep both filenames as downloaded so the loader pairs them.
Also on Civitai: Text Encoder GGUF.
Note the encoder can have K-quants even though this DiT cannot - it is a stock
Qwen3-VL, so its rows are 256-divisible.
The encoder and the DiT together do not fit on a 32 GB card. If your workflow
holds both, 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 4x
difference in render time.
Support
Everything I publish is free and stays free. If it saved you a night of
debugging, tips keep the 5090 warm:
