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>.

MiniMax-H3 comfy-native ref2va - w4a8 / nvfp4 / int8 / mxfp8, ComfyUI 0.32+

minimaxH3ComfyNativeRef2vaW4a8_v10_nvfp4.safetensors

minimaxH3ComfyNativeRef2vaW4a8_v10_3111060.safetensors

minimaxH3ComfyNativeRef2vaW4a8_v10_3110296.safetensors

minimaxH3ComfyNativeRef2vaW4a8_v10_3110778.safetensors

minimaxH3ComfyNativeRef2vaW4a8_v10_3110634.safetensors

MiniMax-H3 comfy-native — w4a8 / nvfp4 / int8 / mxfp8, stock ComfyUI 0.32+

v1.0

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. The <code>fl2va</code> half of the comfy-native set. 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.Looking for <code>ref2va</code>? That is a separate listing: <a target="_blank" rel="ugc" href="https://civarchive.com/models/2857809">MiniMax-H3 comfy-native</a>. Same formats, same method, same speeds — a different job, explained below.<h2 id="what-fl2va-does-that-ref2va-cannot">What fl2va does that ref2va cannot</h2><code>fl2va</code> is the first/last-frame variant. It carries no reference rows, so voice anchoring, the identity bank and reference images all do nothing on it. In exchange it does the one thing <code>ref2va</code> has no mechanism for: it lands on a supplied frame.<pre><code>checkpoint PSNR vs the supplied frame
--------------------------------- --------------------------
fl2va 26.35 dB
ref2va + keyframe, turbo 6 steps 16.15 dB
ref2va + keyframe, stock 20 steps 16.81 dB</code></pre>The stock-20-step row is the control: it rules out the sampler, so that ~10 dB gap is the checkpoint. <code>ref2va</code> treats a keyframe as a suggestion; <code>fl2va</code> treats it as the task. It will also take a first and a last frame and plan a camera move between them.Rule of thumb. ref2va when a face or a voice has to persist across shots. fl2va when a shot has to start exactly where the last one ended — stepping through a scene one shot at a time, feeding each shot's last frame into the next.This is not a size decision. fl2va and ref2va are byte-identical in size at every quantisation. "Lighter" only ever meant fewer tokens per sampling step, because there are no reference rows riding along.<h2 id="pick-by-your-gpu-not-by-the-file-size">Pick by your GPU, not by the file size</h2>A file that fits can still run emulated, and nothing in the UI tells you which you got. ComfyUI prints it at startup — find the line beginning <code>Native ops:</code> and check your format is on it.Emulation is hardware, not a ComfyUI version problem. NVFP4 and microscaling FP8 are Blackwell tensor-core features; <code>float8_e4m3fn</code> wants Ada or newer. An Ampere card emulates all three however current ComfyUI is.<pre><code>file GB take it if
------------------------------------------------ ------ ---------------------
MiniMax-H3-fl2va-pruned-comfy-nvfp4.safetensors 12.53 Blackwell, 50-series
MiniMax-H3-fl2va-pruned-comfy-w4a8.safetensors 12.54 Ada, 40-series
MiniMax-H3-fl2va-pruned-comfy-int8.safetensors 20.97 Ampere, 30-series
MiniMax-H3-fl2va-pruned-comfy-fp8.safetensors 20.96 Ada+, 24 GB and up
MiniMax-H3-fl2va-pruned-comfy-mxfp8.safetensors 21.56 Blackwell, 24 GB up</code></pre>On a 4090 a user measured <code>w4a8</code> at 17.4 s/it against 31.0 s/it for <code>fp8</code> on identical settings — because fp8 at 21 GB does not fit beside the activation pool on 24 GB and streams weights over PCIe. Native ops you cannot reach are worth nothing.<h2 id="all-of-them-beat-the-gguf">All of them beat the GGUF</h2>Measured on the ref2va set — same architecture, same layer set, same quantiser, so it carries over. 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.<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.<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. The same scene was rendered through <code>w4a8</code> (12.54 GB) and <code>int8</code> (20.97 GB) at 704×1280 and 20 steps, and both were 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.So paying 8 GB more does not buy better output. Those defects are characteristics of the base model at these shapes — a prompting and settings problem, not a weights problem, and no quantisation here moves them.Take the smallest file your card runs natively. The larger ones are not a quality upgrade. And if you hit those artifacts, do not report them as quantisation damage — check against the unquantised model or a GGUF first, because you will very likely find them there too.<h2 id="two-formats-i-built-and-then-threw-away">Two formats I built and then threw away</h2><ul><li><code>convrot_w4a4</code> — renders without error and the output is visibly degraded. It quantises activations to 4 bits; every file here keeps activations at 8. Instrument text becomes scribble, hi-vis banding dissolves, hands smear. Caught by render at seed 4040 against four other builds. It saves 1.2 GB against <code>w4a8</code> and costs all of it.</li><li><code>float8_e5m2</code> — loads cleanly, then throws at the first matmul: Multiplication of two Float8_e5m2 matrices is not supported. Same on LTX-2.5. It would ship as a file that looks fine until you sample.</li></ul>Neither was built for fl2va. Both failures are properties of the format, not of these particular weights, so building 32 GB in order to quarantine it would have been busywork.<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 whole K-ladder is unavailable for the DiT — which is why the GGUFs of it are Q4_0 / Q5_1 / Q8_0 and never Q4_K_M. The encoder is a stock Qwen3-VL and its rows do divide, so that repo has real K-quants; the two are easy to confuse.The comfy-native formats have no such constraint, which is part of why this set exists.<h2 id="how-they-were-made">How they were made</h2>The layer set is mirrored from Comfy-Org's own <code>minimax_h3_fl2va_pruned_int8_convrot</code> rather than guessed: exactly 200 Linears — <code>attn.qkv_proj</code>, <code>attn.out_proj</code>, <code>mlp.fc1</code> and <code>mlp.fc2</code> across 50 blocks. Everything else stays bf16/fp16: adaLN, the timestep embedders, every norm and bias, the token refiner, the patch projections, the final layer. Those steer every block, and rounding them is how a quantised DiT dies.Built from the pruned bf16 lineage, which matters arithmetically. On the unpruned lineage adaLN is 38% of the file and 4-bit lands at 19.9 GB — what the existing GGUF Q4_0 already achieves. Pruned 4-bit lands near 12.5 GB.How these were verified, honestly. These were forward-gated, not render-tested: every build ran a GPU forward pass on an attention layer and a feed-forward layer, and all five passed. That catches a format that cannot execute; it does not catch one that executes and looks wrong. The speed table, the quality equivalence and both cuts are inherited from the ref2va set, which was rendered at matched seed and shape on identical architecture. If you render a fl2va build and it disagrees with any of this, please say so.<h2 id="what-else-you-need">What else you need</h2>The text encoder and the two VAEs from <code>Comfy-Org/MiniMax-H3</code> (video and audio are separate). Nothing else — that is the point of these.<h2 id="honest-limits">Honest limits</h2><ul><li>No render A/B on the fl2va weights specifically — the findings above are inherited from ref2va, not measured here.</li><li><code>fl2va</code> ignores <code>voice_ref</code>, <code>self_anchor_voice</code> and the identity bank entirely. If your workflow leans on those, you want ref2va.</li><li>Resolution cannot change mid-chain, and neither variant changes that.</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: 29a7e03cb5d902e2f01e0f03f43ffdb915b640f3328a3f21173cebf90825978f