From 118GB to 12GB: Running MiniMax H3 Through Every Precision Tier on a 16GB GPU

The Question Nobody Answers Directly

When MiniMax H3 came out, the full-precision model was 118GB (66GB UNet + 51GB text encoder). Every tutorial said “you need a big GPU” and left it there. Nobody showed what actually happens when you try to squeeze that through a 16GB consumer card — and whether the smaller quantized versions are actually worth it.

I ran all of them on the same machine: RTX 5060 Ti 16GB, AMD Ryzen 7, 30GB RAM + 43GB swap, Ubuntu 22.04. This is the full comparison: bf16 full precision (118GB), FP8 scaled (20GB), NVFP4 (12GB), and int8. Same keyframe, same prompt, same seed, same resolution — because anything less is not a comparison.

---

Tier 1: The 118GB Full-Precision Model — It Runs. Barely.

The Download

118GB over a residential connection is its own project. Two files, serial downloads (parallel would blow the disk):

File	Size	Time at 105 MiB/s
minimax_h3_fl2va_bf16.safetensors	66.28 GB	~8 min
qwen3vl_32b_minimax_h3_bf16.safetensors	51.5 GB	~12 min

Two things that matter here:

1. hf-mirror is fully usable for the official Comfy-Org repo at 105 MiB/s — but it’s a dead source for third-party NVFP4 repos (HEAD returns 200, GET times out). Test before you trust: curl -r 0-1048575 must return 206, not 000.
2. Verify by byte count, not “it loads.” 66280487368 and 51506295256 — exactly. A file that loads with a corrupted tail will happily fail strict validation later.

The Reality of 118GB on 16GB

The model doesn’t fit in VRAM. It doesn’t fit in RAM (30GB). It fits in 43GB of swap, and ComfyUI’s offload machinery shuffles everything through it.

The ComfyUI log tells the whole story:

Model MiniMaxH3 prepared for dynamic VRAM loading. 63208MB Staged
MiniMaxH3TEModel_ 49118MB Staged
MiniMaxH3VideoVAE 4965MB Staged

63GB UNet + 49GB text encoder + 5GB VAE, all staged, none resident. To make this work at all on 16GB VRAM, I used:
– KJNodes chunked inference: chunk_ffn=4, head_chunks=4
– TE-Speed (45.6% speedup)
– Sage Attention in auto mode
– 43GB of swap as the overflow tank

Results — Three Tiers of Tests

Test	Resolution	Frames	Sample speed	Swap swings	VRAM peak	OOM?	End-to-end
480p short	480×832	107	~6.5 s/it	28–50	~11.2 GB	No	425 s
768p short	768×1344	107	~16 s/it	65–70	~11.2 GB	No	13 min 36 s
480p 15s	480×832	362	~20 s/it	84–93	~12.9 GB	No	17 min 28 s

The full 118GB model runs on a 16GB card. All three tests, zero OOM.

But look at the pattern: the more frames, the more swap churn, the slower it gets — and it periodically spikes to 65-93 s/it when the swap pages in. A 15-second clip takes 17 minutes. That’s not a workflow, that’s an endurance test.

Surprise: the full-precision bf16 model was actually faster at 480p (~6.5 s/it) than the int8 production model we were running (16.28 s/it). Chunking + memory strategy differences trump raw precision. Full precision is not automatically “the slow one.”

---

Tier 2: The Comparison Trap That Made bf16 Look Terrible

My first “comparison” showed bf16 scoring 2/10 vs int8’s 7.9/10. I was about to write off the full model as useless.

Then I realized the two videos weren’t the same input — different keyframe, different prompt, one was a front-facing shot, the other a profile. The “quality gap” was content difference, not precision difference.

The fix: strictly same source. Same keyframe, same prompt, same resolution, same seed:

Version	Details	Color	Fog/haze	Overall
bf16 full	3/10	4/10	7/10	3.5/10
int8 same-source	~2/10	~2.5/10	8.5-9/10	~2/10

Same source, bf16 is slightly better (roughly +50% detail). But both are visibly hazy at 480p — that’s the input + short-clip + motion-prompt combination, not a precision difference.

The lesson that applies to every model comparison you’ll ever do: same keyframe + same prompt + same resolution + same seed, or your “benchmark” is measuring content, not quality.

---

Tier 3: FP8 Scaled (20GB) vs NVFP4 (12GB) — Bigger Is Not Better

After the bf16 experiment, I benchmarked the two practical mid-tier quantizations against each other, same methodology:

Metric	NVFP4	FP8 scaled
Model file	12 GB	20 GB
Staged VRAM	11,944 MB	19,983 MB
Sample speed (steady)	60.4 s/it	66.9 s/it
20-step estimate	~20 min	~22 min

FP8 scaled is bigger, slower, and hungrier — and buys nothing. On 16GB it’s strictly dominated by NVFP4. The interesting data point: at 768×1344, both models run at ~60 s/it, which is 10× slower than the 480p numbers — the bottleneck at high resolution is attention + offload bandwidth, not precision.

---

The Final Stack (What I Actually Run)

After testing every tier, the production config is:

• UNet (production): minimax_h3_fl2va_pruned_int8_convrot.safetensors (20GB, int8 — this is what the T2 workstation runs as its default; ~16.28 s/it at 480p, quality 7.9/10, rock stable)
• Text encoder: qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors (14.6GB)
• Video VAE: official minimax_h3_video_vae_fp16 — never the third-party int8 VAE (NaN black frames)
• Audio VAE: minimax_h3_audio_vae_fp32

The full bf16 model is reserved for single hero shots where 17 minutes per 15 seconds is acceptable and detail matters. Everything else runs int8_convrot (20GB), which remains the production default — it is the most battle-tested config on this card. NVFP4 (12GB) was benchmarked as the theoretical sweet spot (smaller file, competitive speed), but the working production setup stayed on int8.

---

What You Should Take Away

1. 118GB full precision runs on 16GB — swap + chunked inference + sage attention make it possible, but it’s slow and only worth it for one-off quality shots.
2. FP8 scaled is a trap on small GPUs — bigger (20GB) and slower than both NVFP4 (12GB) and int8 (20GB) with no quality win. On 16GB, the practical winners are int8 (production default) and NVFP4 (smaller footprint); FP8 sits in the worst of both worlds.
3. Compare models only with identical inputs — same keyframe, prompt, seed, resolution. Otherwise you’re measuring content, not precision.
4. The bottleneck at high resolution is bandwidth, not precision — at 768×1344, every quantized tier converges to ~60 s/it because offload dominates.
5. “Bigger model = better” is dead on small GPUs — 20GB int8 and 12GB NVFP4 both beat 20GB FP8 and 118GB bf16 on the only metric that matters for batch work: wall-clock time per usable frame.

Hardware: RTX 5060 Ti 16GB / AMD Ryzen 7 / 30GB RAM + 43GB swap / Ubuntu 22.04 / ComfyUI-H3 on :18189. All benchmarks same-source (same keyframe, prompt, seed, resolution).

---

More in the MiniMax H3 on 16GB series

• The Production Pipeline I Built to Run MiniMax H3 on a 16GB GPU
• Full Precision vs int8 on a 16GB Card: My H3 A/B Test
• MiniMax H3 on 6GB vs 8GB vs 16GB: What Low VRAM Actually Means