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.

When you download, make sure to SAVE AS -> RENAME FILE
Civitai is renaming every download the same thing, and I have not figured out why.


MiniMax-H3's video+audio transformer, quantised in ComfyUI's own format. These load with the built-in UNETLoader on stock ComfyUI 0.32+ — no custom node in the load path, no architecture patch, nothing to install first.

There are already GGUFs of this model, including mine. This is a separate set because these formats have no GGUF equivalent — and because every one of them is faster than the GGUF ladder.

Pick by your GPU, not by the file size

Fitting in VRAM is not the same as running natively. ComfyUI will happily emulate a format your card has no silicon for. It works, it is slow, and nothing in the interface tells you which one you got. A 30-series owner who grabs the 12.5 GB file because it fits will get a worse result than one who takes the 21 GB file that runs native.

• 50-series (Blackwell) → nvfp4, 12.53 GB. The fastest thing here. NVFP4 needs Blackwell tensor cores.

• 40-series (Ada) → w4a8, 12.54 GB. Needs ComfyUI 0.32+ — see the warning below.

• 30-series on ComfyUI 0.32+ → w4a8, 12.54 GB. Native on Ampere too, not just Blackwell. Verified on a 3090: ten chained shots at a flat ~45 s/it.

• 30-series on an older ComfyUI → int8, 20.97 GB. Or update and take w4a8 instead — half the size, also native.

If you are on a 30-series, update ComfyUI before you choose. Measured on the same 3090 twenty-two minutes apart, with nothing changed but the ComfyUI version:

0.30    Native ops: convrot_w4a4, int8_tensorwise
        (asym_w4a8_int8 absent entirely)

0.33.1  Native ops: convrot_w4a4, asym_w4a8_int8, int8_tensorwise

That one row is the whole story: w4a8 was a version problem, and the emulated formats are a hardware problem. Updating turns a 21 GB download into a 12.5 GB one. It will not help nvfp4 or mxfp8 — those need Blackwell silicon and stay emulated on Ampere forever.

Also here: mxfp8 (21.56 GB) and fp8 float8_e4m3fn (20.96 GB). Both work and both are Blackwell/Ada features; int8 is the same size and quicker, so take these only if you have a specific reason.

The line to check in your own log, printed when the model loads:

Native ops: int8_tensorwise, nvfp4, mxfp8, asym_w4a8_int8, ... | emulated ops: ...

Measured on two real machines, not inferred from spec sheets:

format              5090 / 0.32    3090 / 0.33.1    3090 / 0.30
------------------  -------------  ---------------  ----------------------
int8_tensorwise     native         native           native
asym_w4a8_int8      native         native           absent - will not load
nvfp4               native         emulated         emulated
mxfp8               native         emulated         emulated
float8_e4m3fn       native         emulated         emulated

If you get KeyError: 'asym_w4a8_int8', your ComfyUI is too old. That format did not exist in 0.30 — it is not in that build's format table at all, so the file raises the moment it loads. Update ComfyUI and it resolves. Nothing is wrong with the file, and everything else in this set loads fine on 0.30.

All of them beat the GGUF

Same scene, same seed, same shape — 544×960, 243 frames, 2 shots, 10 steps — so the weights are the only variable. RTX 5090, against the Q8_0 GGUF I run in production.

build          GB       shot 1      shot 2      vs Q8_0
-------------  -------  ----------  ----------  ----------------
nvfp4          12.53    12.71 s/it  19.57 s/it  -34% / -28%
int8           20.97    13.5        20.1        -30% / -26%
mxfp8          21.56    13.4        20.9        -31% / -23%
w4a8           12.54    14.05       20.50       -27% / -25%
fp8            20.96    14.8        22.4        -24% / -18%
Q8_0.gguf      21.50    19.36       27.18       (baseline)

int8 is the row worth staring at: effectively the same file size as the Q8_0 GGUF and 30% quicker. That gap is dequantisation overhead in the GGUF path, not a difference in quantisation quality. If you are on 0.32 and reached for a GGUF out of habit, this is simply faster at the same VRAM.

They are all the same quality as each other

Worth saying plainly, because it saves you a download. I rendered the same scene through w4a8 (12.54 GB) and int8 (20.97 GB) at 704×1280 and 20 steps, and had both reviewed as video by the same reviewer with the same prompt. They produce the same defects: garbled text on instrument dials, reflective safety-tape edges that warp during movement, limb distortion on fast motion, stiff lip sync. int8 additionally hallucinated a logo onto a hard hat that w4a8 did not.

Paying 8 GB more does not buy better output. Take the smallest file your card runs natively — the larger ones are not a quality upgrade, only a bigger download.

Those defects are characteristics of the base model at these shapes. They are a prompting and settings problem, not a weights problem, and no quantisation on this page will move them. I also tested whether more steps or more pixels clear them: going from 10 steps at 544×960 to 20 steps at 704×1280 left the fast-motion warping in exactly the same place. So if you see these artifacts, please do not report them as quantisation damage — check against a GGUF or the unquantised model first, because you will very likely find them there too.

The exception is w4a4, which is genuinely broken rather than merely imperfect. That is the next section.

Two formats I built and then threw away

Both exist, both were cut on evidence. If you find them elsewhere, this is what to look for.

float8_e5m2 — loads, then throws. PyTorch refuses Float8_e5m2 × Float8_e5m2: Multiplication of two Float8_e5m2 matrices is not supported. It would ship as a file that looks fine right up until you press queue.

w4a4 — renders, and looks wrong. This is the one that nearly got past me. It passes a CPU load-check, passes a GPU forward pass with finite output and sane norms, and renders end to end with no error. The output is visibly damaged: hi-vis retroreflective banding dissolves into grey blobs, a gloved hand smears into iridescent nonsense, a background figure ghosts into motion trails, and a pressure gauge that reads 20 / 40 / 60 / 80 / 100 on every other build comes out as GO / BO / US with wobbling tick marks.

The cause is in the name. w4a4 quantises activations to 4 bits; every build in this set keeps activations at 8. Weight-only 4-bit is fine — nvfp4 and w4a8 are both 4-bit weights at ~12.5 GB and both clean. Four-bit activations are not, on this model. It saved 1.2 GB against w4a8, and that is exactly what it was worth.

That last qualifier matters: LTX-2.5's w4a4 is fine, checked the same way, and I ship it. Do not carry this verdict across models — what travels is the method, not the answer.

Why nobody has K-quants of this model

H3's hidden width is 2688, and K-quants need weight rows divisible by 256. 2688 is not, so the entire K-ladder is unavailable for this DiT — which is why my GGUFs of it are Q4_0/Q5_1/Q8_0 rather than Q4_K_M. The comfy-native formats have no such constraint, which is part of why this set exists at all.

The encoder is a stock Qwen3-VL and its rows are divisible, so that one does have real K-quants. The two are easy to confuse.

How they were made

Cut from the pruned bf16 original, never from another quant. The set of layers to quantise is mirrored from the canon int8-convrot release rather than chosen by me: the same Linears, with adaLN, the timestep embedders, every norm and bias and the scale-shift tables left in bf16. Those steering layers are a small fraction of the file and rounding them is how a quantised DiT dies.

On adaLN, since the figure differs by lineage: on the unpruned H3 it is 37.2% of the model, on the pruned file 0.81%. Both are correct for their own file. If you are comparing against another repo's accounting, check which lineage it describes first.

What else you need

• Text encoder — Qwen3-VL-32B cut to 50 layers, plus its mmproj sidecar. GGUF here. The mmproj is not optional: every image-conditioned path goes through it, including multi-shot chaining.

• VAEs — video and audio, from Comfy-Org/MiniMax-H3.

• ComfyUI-H3-Multishot — not needed to load these files. It is what you want for multi-shot chaining and automatic text-encoder eviction.

Read this before reporting a slow render. The encoder (~16.5 GB resident at Q4_K_M) and the DiT do not co-fit on a 32 GB card. If both are held at once the DiT loads partially and streams the rest over PCIe every sampling step. The tell:

loaded partially; 6423 MB usable, 5847 MB loaded, 19363 MB offloaded

This is a cliff, not a curve. The fix is freeing the encoder after conditioning and before sampling. The 12.5 GB builds make that problem much easier — that is their real argument, more than the raw speed.

Honest limits

• All timings are from a 5090 on 0.32, where every format is native. I have not measured how much slower an emulated path is, only that it is one.

• w4a8 on Ada is still unmeasured. It is native on both Blackwell and Ampere, so there is no plausible reason for Ada to be the exception — but that is reasoning, not a measurement, and this set has already been bitten once by the difference.

• Rendered and compared at 544×960. Not swept across resolutions.

• These are quantisations, not fine-tunes. Anything the base model does badly, these do badly and smaller.

Support

Everything I publish is free and stays free. If it saved you a night of debugging, tips keep the 5090 warm: Ko-fi · GitHub Sponsors · Liberapay.