Qwen3-VL-32B Heretic (MiniMax-H3 text encoder) — NVFP4
The uncensored MiniMax-H3 text encoder, in 15.7 GB — it fits on a single 16 GB card.
This is a mixed-precision NVFP4 re-quantization of
ethanfel/Qwen3-VL-32B-Ultra-Heretic-MiniMax-H3-ComfyUI-INT8-ConvRot,
the Heretic (uncensored) text encoder for MiniMax-H3
video generation.
| build | size | fits 16 GB card? |
|---|---|---|
| Heretic INT8-ConvRot (upstream) | 26.4 GB | no (needs offload) |
| Heretic NVFP4 (this repo) | 15.7 GB | yes |
| Comfy-Org NVFP4 (censored) | 15.7 GB | yes |
Same size as Comfy-Org's official NVFP4 encoder, so it is a drop-in replacement:
point CLIPLoader at this file instead and the rest of your MiniMax-H3 workflow is unchanged.
Why
80 GB cards always had the choice. This is for the people who don't have one.
Creative work shouldn't require datacenter hardware — that's the whole point of quantizing it.
Measured
Generated 6 s of 480×864 vertical video with audio, MiniMax-H3 fl2va pruned INT8 diffusion model,
res_multistep 20 steps, ComfyUI 0.30.0, Sage Attention on:
| | value |
|---|---|
| GPU | 1× RTX PRO 2000 Blackwell (16 GB, sm_120) |
| peak VRAM during generation | ~9.9 GB |
| encoder staged in VRAM | 14.9 GB (dynamic loading) |
| system RAM used by the ComfyUI process | ~36 GB |
Output was compared against the upstream INT8-ConvRot build on identical prompt and seed.
The two are visually equivalent — the quantization does not change what the encoder will describe.
Files
qwen3vl_32b_heretic_minimax_h3_nvfp4.safetensors 15.7 GB
Place in ComfyUI/models/text_encoders/ and select it in CLIPLoader (type: minimax).
You still need the diffusion model and VAEs from
How it was made (and the trap you must avoid)
The upstream weights are rotated. Its comfy_quant metadata reads:
{"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256, "per_row": true}
ConvRot stores each weight already multiplied by a normalized Hadamard matrix
(W_stored = W @ Hᵀ, per 256-wide group) and rotates activations to match at runtime.
If you dequantize those weights and re-quantize them to plain NVFP4 **without undoing the
rotation**, you get a file that loads, runs, and produces completely unrelated video —
in our first attempt a prompt for a war-torn street rendered a speedboat on open water.
Nothing errors. The conditioning is simply meaningless.
Because the Hadamard is orthogonal, the fix is to multiply by H again before re-quantizing:
from comfy_kitchen.backends.eager.convrot_w4a4 import _build_hadamard
def unrotate(w, gs=256): # w: dequantized [out, in]
out_f, in_f = w.shape
h = _build_hadamard(gs, device=w.device, dtype=torch.float32).to(w.dtype)
return torch.matmul(w.reshape(out_f, in_f // gs, gs), h).reshape(out_f, in_f)
Mixed precision. 350 linear layers are NVFP4 (TensorCoreNVFP4Layout, group size 16).
model.embed_tokens (151936 × 5120 = 778 M params) is left as INT8 — the same choice
Comfy-Org made in the official NVFP4 build. Quantizing it gives little size benefit and it is
the one layer whose temporaries will OOM a 16 GB card during baking. ComfyUI reads per-layer
comfy_quant metadata, so the mixed file loads with no special handling.
The bake runs on a single 16 GB GPU in about two minutes.
Provenance
- Uncensoring / Heretic work: ethanfel
- Original encoder: Qwen3-VL-32B (Alibaba / Qwen team), as adapted for MiniMax-H3
- MiniMax-H3: MiniMaxAI
- ComfyUI packaging conventions and quantization layouts: Comfy-Org
- This NVFP4 re-quantization: Lna-Lab (@Tono_Ken3)
Licensing follows the upstream repositories; the MiniMax-H3 model weights themselves are
subject to the MiniMax H3 Community License.
Notes
- Re-quantizing INT8 → NVFP4 means this build inherits the upstream INT8 rounding.
A bake straight from BF16 would be marginally cleaner; we did not have those weights.
- Blackwell (sm_120) was used for both baking and inference. NVFP4 needs hardware support.
- If output looks unrelated to your prompt rather than merely lower quality, suspect a
rotation mismatch, not the quantization.