Full Precision vs int8 on a 16GB Card: My H3 A/B Test, the Trap That Almost Fooled Me, and Why int8 Still Wins

The Question

MiniMax H3’s official full-precision model is 118GB (66GB UNet + 51GB text encoder). The int8 quantized model I run in production is 20GB. Common sense says “full precision must look better” — but “better” is not a feeling, it’s a measurement. And the measurement has to be honest.

So I ran the A/B test: same keyframe, same prompt, same resolution, same seed — bf16 full precision vs int8 — on a single RTX 5060 Ti 16GB (AMD Ryzen 7, 30GB RAM + 43GB swap, Ubuntu 22.04, ComfyUI-H3 on :18189).

Here’s what happened, including the mistake that almost made me publish a wrong conclusion.

First, Can 118GB Even Run on 16GB? Yes. Here’s What It Costs.

The full bf16 model does not fit in VRAM. It doesn’t fit in RAM (30GB). It fits because of 43GB of swap plus every memory optimization in the book: KJNodes chunked inference (chunk_ffn=4, head_chunks=4), TE-Speed (measured 45.6% speedup), Sage Attention auto.

The ComfyUI log shows what “fits” means:

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. Three tiers of tests, all on the same keyframe (S04) and seed 7:

Tier	Resolution	Frames	Sample speed (steady)	Swap spikes	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

Zero OOM at every tier. A 118GB model runs on a 16GB card. But watch the pattern: more frames → more swap churn → slower iterations, with periodic 65–93 s/it spikes when swap pages in. A 15-second clip takes 17 minutes. That is the cost of “full precision” on this hardware.

The Trap: My First Comparison Was Completely Wrong

My first attempt compared:
– bf16 video (S04 keyframe, its own prompt)
– an existing int8 15s video (different keyframe, different prompt)

Vision scoring gave bf16 = 2/10 vs int8 = 7.9/10. I was about to write “the full precision model is garbage on this setup.”

But look at what was actually being compared: two different shots — one front-facing, one profile — with different prompts. The 5.9-point “gap” wasn’t precision. It was content difference.

The rule that saved me: cross-model quality comparison must be same-source — same keyframe + same prompt + same resolution + same seed. Otherwise your “precision benchmark” is measuring content, not the model.

I re-ran it properly: S04 keyframe, identical motion prompt, 480×832, seed 7, once per model.

The Honest A/B: bf16 vs int8, Same Source

Version	Detail	Color	Haze	Overall
bf16 full precision	3/10	4/10	7/10	3.5/10
int8 (same source)	~2/10	~2.5/10	8.5–9/10	~2/10

What the same-source test actually shows:

bf16 is modestly better on detail — roughly +50% detail score (3/10 vs 2/10). Real, but small.
Color is a wash (4/10 vs 2.5/10 — bf16 slightly warmer, both mediocre at this resolution).
Both are hazy at 480p — this is the input keyframe + short-clip + motion-prompt combination, not a precision difference. The haze is not fixed by throwing more bits at it.

So the honest answer to “does full precision look better?” is: barely, at the cost of a 2-4× time penalty and heavy swap risk.

The Speed Numbers That Decided It

Metric	int8_convrot (production)	bf16 full
Model size	20 GB	118 GB
Sample speed (480p)	16.28 s/it	~6.5–20 s/it (swap-dependent)
15s clip	~7 min	17 min 28 s
Quality (same-source)	2/10 @480p	3.5/10 @480p
Stability	Rock solid, months of production	Swap-thrash risk, periodic 65–93 s/it spikes
Disk	20 GB	118 GB (98% disk full after download)

The verdict from the numbers: int8 wins for production on 16GB. The quality gain from full precision is real but small (~+50% detail), while the cost is enormous — nearly 2.5× slower on 15s clips, 6× the disk, and swap-induced latency spikes that make batch work unpredictable.

The Decision: int8 Stays, bf16 Is Reserved for Hero Shots

Production default remains minimax_h3_fl2va_pruned_int8_convrot.safetensors (20GB int8) — 16.28 s/it at 480p, quality 7.9/10 in its native production context (the 7.9/10 is from real deliverable work, not a same-source 480p comparison), and it has shipped deliverable after deliverable without a single OOM.

bf16 full precision is kept on disk as a one-off tool — for single hero shots where you can wait 17 minutes for 15 seconds and the +50% detail matters. It is not a batch pipeline.

The pipeline reflects this: h3av-cli.py exposes --model int8|bf16 (default int8), so switching is one flag — but the frozen h3make.py production path never leaves int8.

Lessons You Can Reuse

118GB full precision CAN run on 16GB — swap + chunked FFN + head chunks + Sage Attention + TE-Speed make it possible. But “possible” ≠ “practical” for batch work.
Same-source or it didn’t happen — cross-model quality comparisons with different inputs are worthless. Same keyframe, prompt, resolution, seed, or you’re measuring content.
Quantization is not the enemy at this scale — on 16GB, the int8 model’s practical quality is within ~50% detail of full precision, at a fraction of the time and risk. The bottleneck at high resolution is memory bandwidth and offload, not precision.
Beware swap-spike timing — bf16 iteration times swing 6.5 → 20 → 65+ s/it as swap pages. Never extrapolate a full-length render from a short test’s best-case s/it.
Keep the full model as a flag, not a default — a --model int8|bf16 switch costs nothing and preserves the option for hero shots without risking production stability.

All measurements from a T2 workstation: RTX 5060 Ti 16GB / AMD Ryzen 7 / 30GB RAM + 43GB swap / Ubuntu 22.04 / ComfyUI-H3 on :18189. Same-source tests: S04 keyframe, identical prompt, 480×832, seed 7.

Tag: int8