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:<ul><li>☕ <a target="_blank" rel="ugc" href="https://ko-fi.com/joeygambino">Buy me a coffee on Ko-fi</a></li><li>💛 <a target="_blank" rel="ugc" href="https://github.com/sponsors/jlucasmcrell">Sponsor on GitHub</a></li><li>🔁 <a target="_blank" rel="ugc" href="https://liberapay.com/joeygambino">Liberapay</a> (recurring)</li></ul>⚡ Or right here: the Civitai tip button on this page sends Buzz directly.<h3 id="when-you-download-make-sure-to-save-as-greater-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.">When you download, make sure to SAVE AS -&gt; 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 <code>UNETLoader</code> on stock ComfyUI 0.32+ — no custom node in the load path, no architecture patch, nothing to install first.</h3>There are already GGUFs of this model, <a target="_blank" rel="ugc" href="https://civarchive.com/user/joeygambino">including mine</a>. This is a separate set because these formats have no GGUF equivalent — and because every one of them is faster than the GGUF ladder.<h2 id="pick-by-your-gpu-not-by-the-file-size">Pick by your GPU, not by the file size</h2>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.<ul><li>50-series (Blackwell) → <code>nvfp4</code>, 12.53 GB. The fastest thing here. NVFP4 needs Blackwell tensor cores.</li><li>40-series (Ada) → <code>w4a8</code>, 12.54 GB. Needs ComfyUI 0.32+ — see the warning below.</li><li>30-series on ComfyUI 0.32+ → <code>w4a8</code>, 12.54 GB. Native on Ampere too, not just Blackwell. Verified on a 3090: ten chained shots at a flat ~45 s/it.</li><li>30-series on an older ComfyUI → <code>int8</code>, 20.97 GB. Or update and take <code>w4a8</code> instead — half the size, also native.</li></ul>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:<pre><code>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</code></pre>That one row is the whole story: <code>w4a8</code> 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 <code>nvfp4</code> or <code>mxfp8</code> — those need Blackwell silicon and stay emulated on Ampere forever.Also here: <code>mxfp8</code> (21.56 GB) and <code>fp8</code> <code>float8_e4m3fn</code> (20.96 GB). Both work and both are Blackwell/Ada features; <code>int8</code> 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:<pre><code>Native ops: int8_tensorwise, nvfp4, mxfp8, asym_w4a8_int8, ... | emulated ops: ...</code></pre>Measured on two real machines, not inferred from spec sheets:<pre><code>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</code></pre>If you get <code>KeyError: 'asym_w4a8_int8'</code>, 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.<h2 id="all-of-them-beat-the-gguf">All of them beat the GGUF</h2>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.<pre><code>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)</code></pre><code>int8</code> 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.<h2 id="they-are-all-the-same-quality-as-each-other">They are all the same quality as each other</h2>Worth saying plainly, because it saves you a download. I rendered the same scene through <code>w4a8</code> (12.54 GB) and <code>int8</code> (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. <code>int8</code> additionally hallucinated a logo onto a hard hat that <code>w4a8</code> 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 <code>w4a4</code>, which is genuinely broken rather than merely imperfect. That is the next section.<h2 id="two-formats-i-built-and-then-threw-away">Two formats I built and then threw away</h2>Both exist, both were cut on evidence. If you find them elsewhere, this is what to look for.<code>float8_e5m2</code> — loads, then throws. PyTorch refuses <code>Float8_e5m2 × Float8_e5m2</code>: Multiplication of two Float8_e5m2 matrices is not supported. It would ship as a file that looks fine right up until you press queue.<code>w4a4</code> — 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 <code>20 / 40 / 60 / 80 / 100</code> on every other build comes out as <code>GO / BO / US</code> with wobbling tick marks.The cause is in the name. <code>w4a4</code> quantises activations to 4 bits; every build in this set keeps activations at 8. Weight-only 4-bit is fine — <code>nvfp4</code> and <code>w4a8</code> 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 <code>w4a8</code>, and that is exactly what it was worth.That last qualifier matters: LTX-2.5's <code>w4a4</code> 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.<h2 id="why-nobody-has-k-quants-of-this-model">Why nobody has K-quants of this model</h2>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 <a target="_blank" rel="ugc" href="https://huggingface.co/joeygambino/MiniMax-H3-encoder-GGUF">that one</a> does have real K-quants. The two are easy to confuse.<h2 id="how-they-were-made">How they were made</h2>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.<h2 id="what-else-you-need">What else you need</h2><ul><li>Text encoder — Qwen3-VL-32B cut to 50 layers, plus its mmproj sidecar. <a target="_blank" rel="ugc" href="https://huggingface.co/joeygambino/MiniMax-H3-encoder-GGUF">GGUF here</a>. The mmproj is not optional: every image-conditioned path goes through it, including multi-shot chaining.</li><li>VAEs — video and audio, from <a target="_blank" rel="ugc" href="https://huggingface.co/Comfy-Org/MiniMax-H3">Comfy-Org/MiniMax-H3</a>.</li><li><a target="_blank" rel="ugc" href="https://github.com/jlucasmcrell/ComfyUI-H3-Multishot">ComfyUI-H3-Multishot</a> — not needed to load these files. It is what you want for multi-shot chaining and automatic text-encoder eviction.</li></ul>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:<pre><code>loaded partially; 6423 MB usable, 5847 MB loaded, 19363 MB offloaded</code></pre>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.<h2 id="honest-limits">Honest limits</h2><ul><li>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.</li><li><code>w4a8</code> 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.</li><li>Rendered and compared at 544×960. Not swept across resolutions.</li><li>These are quantisations, not fine-tunes. Anything the base model does badly, these do badly and smaller.</li></ul><h2 id="support">Support</h2>Everything I publish is free and stays free. If it saved you a night of debugging, tips keep the 5090 warm: <a target="_blank" rel="ugc" href="https://ko-fi.com/joeygambino">Ko-fi</a> · <a target="_blank" rel="ugc" href="https://github.com/sponsors/jlucasmcrell">GitHub Sponsors</a> · <a target="_blank" rel="ugc" href="https://liberapay.com/joeygambino">Liberapay</a>.

Files with SHA256: ddb5e0590ec4702b8024c123c3e8b1d64539ba85446860e86c45783be8c3a09f