Skip INT8/BF16 on Small VRAM: Why It's Slow and Wears Out Your SSD
A very common mistake: your GPU is small (8-12GB), but you download INT8 (19.5-34GB) or even BF16 (40-66GB) weights "for better image quality". The result: every single video tortures your disk, and it's so slow you start questioning your life choices. This article does the accounting, then gives you the right choice.
First, understand the three memory tiers: VRAM → RAM → disk
When ComfyUI runs H3, weights must be resident in VRAM to be computed. The parts that don't fit go through this chain:
- VRAM: whatever fits computes normally;
- System RAM: weights that don't fit are fed into VRAM over PCIe as "per-step transfers". PCIe 4.0 delivers about 24GB/s in practice, PCIe 5.0 about 48GB/s — sounds fast, but that's the cost of moving them on every single step;
- Disk (pagefile / page cache): when RAM can't hold it either (for example, 32GB of RAM trying to hold a 14.6GB text encoder + 19.5GB main model at once), the system can only put the data on disk. Pagefile reads and writes only reach 3-5GB/s on NVMe — 10-20× slower than RAM.
Do the math: a 12GB GPU running the INT8 main model (19.5GB) has roughly 10-13GB of weights to move every step. Over PCIe that's about +0.5 s/step; once it lands on disk it becomes +2.5-3.5 s/step — even 4-step acceleration can't save you.
Why it "wears out your SSD": two modes, two different bills
| Mode | Where the data lives | Disk behavior | Consequence |
|---|---|---|---|
| Default (anonymous memory) | Weight copies occupy RAM | Pagefile writes + reads (swapped in and out every step) | SSD writes go up → real TBW lifetime consumed; slowest |
--fast-disk |
Weights live in the page cache (reclaimable) | Mostly reads (re-read from NVMe each step) | Very few writes (no lifetime cost), but read amplification tanks speed just the same |
Community measurements: an 8GB GPU with little RAM running one clip read up to 270GB from disk in a single sampling run, while writing only 0.04GB (fast-disk mode); in another default-mode test with "16GB RAM + 46GB pagefile", a 5-second video took 389 s, 10 seconds took 768 s, and 15 seconds simply failed — the pagefile was being erased and rewritten over and over.
SSD lifetime in plain numbers
Take a mainstream 1TB TLC SSD (600TBW rated writes): in default mode, pagefile writes run about 30-50GB per clip (including repeated paging), so 100 videos consume roughly 0.5-0.9% of its health; if you run 10 clips a day, that's 1.5-2.7% a month. On QLC drives, double it. Switch to a suitable quantization + enough RAM and that number goes straight to 0.
Any exceptions? When BF16 is actually worth it
BF16 full precision (61.7GB) has essentially no practical use on consumer GPUs: it doesn't fit in VRAM, doesn't fit in RAM, needs 50GB+ moved every step, and ends up several times slower than INT8. The people who genuinely need BF16 are on workstations with 96GB+ VRAM and 128GB+ RAM — for the vast majority, the quantization loss (about 0.9% measured for INT8, ~0.073 relative error for W4A8) buys 3-5× the speed.
The right choice table (by VRAM tier)
| VRAM | Recommended quant | Minimum RAM | Expected behavior |
|---|---|---|---|
| 8GB | GGUF Q3 (8.9GB) | 16GB + 48GB pagefile (NVMe) | 540p short clips, 5-8 minutes per clip, acceptable |
| 8GB + want better | GGUF Q4 (11.6GB) | 32GB | More weights stay resident in RAM, less pagefile pressure |
| 12GB | W4A8 (12.5GB) or GGUF Q4 | 32GB (64GB is better) | Half the per-step transfer of INT8, stable speed |
| 16GB | Pruned INT8 (20.97GB) + 4-step acceleration | 64GB or --fast-disk | 540p-768p usable; SSD reads only, no writes |
Adding --fast-disk to your launch arguments is the key step to "save the SSD": it turns weights from
"anonymous memory" into a "reclaimable page cache", so write amplification basically disappears — at the cost of
slower disk reads when RAM is short.
Verify your own config with the calculator
Open the WhichH3 calculator: enter your VRAM/RAM/pagefile in "Step 1"; in Step 3, each cell directly shows SSD reads per step and pagefile writes per clip, SSD wear per 100 clips. You can see at a glance how dropping one quant tier turns tens of GB of writes into 0.
Conclusion
- Small VRAM + big weights = per-step transfers + pagefile swapping; slow and SSD-wearing are the same root cause;
- The right approach for 8-12GB: GGUF Q3/Q4 or W4A8 + 4-step distillation + 540p;
- Keep RAM ≥32GB and leave
--fast-diskalways on to turn "writes" into "reads" and protect your drive's life; - BF16 is for 96GB-VRAM workstations, not a quality patch for small cards.