MiniMax-H3 Text Encoder for 16 GB GPUs — GGUF
⚠️ Not a general-purpose LLM. These files are the text encoder of MiniMax-H3 and nothing else: cut to the 50 layers H3 uses, with no LM head — they cannot chat or generate text. They exist so H3's 32B encoder fits a 16 GB GPU in ComfyUI.
Built from the official MiniMax-H3 encoder (MiniMaxAI/MiniMax-H3 → text_encoder/, revision 42ed227e;
Qwen3-VL-32B). Not abliterated.
Files (ComfyUI, visual tower included)
| File | Size | Error vs BF16 (FL2VA / Ref2VA) |
|---|---|---|
MiniMax-H3-TextEncoder-Qwen3VL-32B-11.5G_vis.gguf |
12.65 GB | 7.9% / 8.0% |
MiniMax-H3-TextEncoder-Qwen3VL-32B-12.5G_vis.gguf |
13.70 GB | 6.4% / 6.5% |
MiniMax-H3-TextEncoder-Qwen3VL-32B-13.6G_vis.gguf |
14.80 GB | 4.9% / 5.0% |
For comparison, on the same test: the earlier MiniMax-H3-TextEncoder-Qwen3VL-32B-abliterated-GGUF Q3_K_S (11.46 GB
text part) scores 14.4% / 14.7%, and a stock llama.cpp Q3_K_S of the official weights 11.8% / 12.0%.
Error = relative error of the text conditioning after the H3 DiT's own text stage (condition_proj →
token_refiner, from the FL2VA and the Ref2VA checkpoints, which ship different copies), against the BF16 encoder,
on 36 held-out H3-format prompts. Lower is better. This measures conditioning, not video; side-by-side videos are not
included yet.
Use in ComfyUI
- Load with ComfyUI-GGUF's
CLIPLoaderGGUF, typeminimax. - Checked by loading each file exactly this way and encoding 12 held-out prompts: every tensor dequantizes on the GPU (no CPU fallback), ~25–30 s to load, ~6 s per prompt, error as in the table.
- The visual tower (F16) is merged in because ComfyUI recognizes the H3 encoder by
visual.deepstack_merger_list.*+model.layers.49.*. Its 5-Dpatch_embedweight is stored the ComfyUI-GGUF way (flattened +comfy.gguf.orig_shape), so currentggufversions read it. - 16 GB cards → use the 11.5G file. Tested on an RTX 5070 Ti 16 GB (ComfyUI, H3 FL2VA turbo 4-step DiT, euler + sigma shift 12/3, 1344×768 × 61 frames): full clips render with default settings, ~75 s per clip, GPU peak ≈ 15 GB.
- 12.5G / 13.6G on a 16 GB card: with ComfyUI's default settings the encoder runs out of memory (
torch.OutOfMemoryError, no video). Starting ComfyUI with--reserve-vram 1.5makes it keep part of the encoder in system RAM: the encoding step then passes (first prompt 12 s / 19 s, later ones ~4 s), but a full clip with that setting was not tested — the DiT may then be pushed to offload too. On 20 GB+ cards they load normally.
How the sizes were spent
Not a uniform quant. For every linear of every layer and every K format, the damage it does as the H3 DiT sees it was measured (backward passes with random probes at the DiT text-stage output, both DiT variants weighted equally, 22 H3-format calibration prompts). Every tensor starts at Q3_K; upgrades go to whichever tensor removes the most DiT damage per extra byte, until the size is used up.
- K-quants only (Q3_K, Q4_K, Q5_K, Q6_K, Q8_0) — no IQ types, so ComfyUI-GGUF dequantizes everything on the GPU.
- Attention
v_proj(few parameters, very sensitive) gets Q5_K–Q8_0 almost for free;k_projmostly Q5_K; the big MLP matrices stay at Q3_K/Q4_K except where it pays. - Sensitivity is spread over all 50 layers (largest single layer ≈ 4.5% of the total); layers 44–49 carry ≈ 28%.
- Layers 50–63 and the LM head of the original 64-layer model are dropped (H3 reads the raw hidden state after layer
50);
token_embdis Q4_K. Every tensor's format:GRIDS.md.
License
The H3 encoder is Qwen3-VL-32B, Apache 2.0 (as stated in the MiniMax H3 license). MiniMax H3 itself (DiT / VAE) is under the MiniMax H3 Community License.
📌 Heads-up: I've been focused on still-image work lately, so I don't have the bandwidth to help with video setups like MiniMax-H3 for now. The files stay up as they are — thanks for understanding! 最近重心放在平面攝影,影片類(像 MiniMax-H3)暫時比較沒辦法協助排錯。檔案會照舊留著,謝謝體諒!