MiniMax H3 · Hardware
There is no single VRAM number for MiniMax H3, and any page that gives you one is quoting a file size. Weight files are what you download; VRAM is what you need while generating. The gap between those two is where most out-of-memory errors live.
You will see “8.49GB, so an 8GB card works.” That figure is the weight file alone. Loading it is only the first allocation — generation then needs the VAE, the text encoder, latents that scale with resolution and frame count, the audio branch, and whatever your OS is already holding. A model that loads at 768p and 5 seconds can still OOM at 2K and 15 seconds.
MiniMax has not published an official GGUF for H3. Everything below is a third-party conversion — quality, speed and node compatibility are not verified by MiniMax. Sizes are the published file sizes, not measured VRAM.
| Quant | Variant | File size | Notes |
|---|---|---|---|
| Q4_0 | fl2va | 11.4 GB | Base weights pruned to FP8 before quantization. |
| U16G | fl2va | 15 GB | Publisher describes this build as designed for 16GB cards. Requires a specific ComfyUI custom node. |
| Q8_0 | fl2va | 20.2 GB | Best quality retention of the builds in this variant. |
| Q8_CR | fl2va | 20.2 GB | Built for a specific ComfyUI custom node; may fail to load anywhere else. |
| Q4_0 | ref2va | 11.4 GB | Reference-driven variant, accepts up to nine reference images. |
| U16G | ref2va | 15 GB | Also aimed at 16GB cards; same custom-node requirement. |
| Q8_CR | ref2va | 20.2 GB | Built for a specific ComfyUI custom node. |
| Q8_0 | ref2va | 21.4 GB | Largest file in the set. |
Source: molbal/MiniMax-H3-GGUF · smallest known build: Q2_K at 8.49GB (Abiray/MiniMax-H3-GGUF) · these are published file sizes, not first-party benchmarks.
Everything above is file sizes and published specs. The numbers below are measurements — but not ours. We have no benchmark hardware, so this is a third-party run, published in full with its configuration. Treat it as one data point on one machine, not a requirement table.
| Peak VRAM — 30s at 640×480 | 12.2–15.3 GiB | 736 frames, 20 steps. Well under the 42.5GB of files it loaded from. |
|---|---|---|
| Peak VRAM — 5s at 1344×768 | 14.1 GiB | Higher resolution, shorter clip — both directions cost memory. |
| Generation time — 30s at 640×480 | 9 min 55 s | 20 steps, no acceleration nodes. |
| Generation time — with sage + EasyCache | 395 s | 10 steps at the same resolution. |
| System RAM — default flags | 45.4 GiB | ComfyUI resident set. This is the number that actually kills 32GB machines. |
| System RAM — with --disable-pinned-memory | 6.1 GiB | One flag, a 39GiB difference. Pinned memory holds twice the model size in unswappable, unreclaimable pages. |
Third-party measurement · Source: github.com/Tomiigo/minimax-h3-16gb
The line worth reading twice is the last pair. Peak VRAM on that run never exceeded 15.3 GiB — comfortably inside a 16GB card — while ComfyUI’s system memory hit 45.4 GiB under default flags and dropped to 6.1 GiB with --disable-pinned-memory. If you are sizing a machine for MiniMax H3, the VRAM number is the one everybody quotes and the RAM number is the one that actually stops the generation.
MiniMax’s recommended configuration is 4 GPUs. Quantization is what brings H3 within reach of a single consumer card, and it is a trade — you are giving up precision to fit. Set a working baseline at 768px short edge, capped at 768×1344 and a short duration first, confirm it completes, then raise resolution and length one step at a time until you find your ceiling.
Quantizing down to fit an 8GB card costs you quality, and it still may not survive a 2K request. H3Video’s hosted text-to-video generator runs remotely, so your own VRAM does not constrain the request.
Compare hosted pricing →Once the model is loading, the next thing that breaks is usually the workflow itself — see the ComfyUI workflow setup and error list. And before you burn a long generation on a bad prompt, the prompt guide explains why H3 wants a shot list rather than a description.
Two things change the memory maths here. The local setup guide covers the 32B text encoder that is usually the largest single file in the stack — dropping it a quant level frees more headroom than quantizing the diffusion model further. And if you were planning to use the MiniMax H3 LoRA to save time, it attaches to any base in the table above — pruned and quantized builds included — so it does not constrain which row you pick here.
There is no single number, because weight file size is not the same as peak VRAM. MiniMax's own configuration recommends four GPUs. Community GGUF builds range from 8.49GB (Q2_K) to 21.4GB (Q8_0) on disk, and you must add the VAE, text encoder, latents, the audio branch and OS overhead on top of that figure.
Community reports say the Q2_K build loads on 8–12GB cards, but the 8.49GB figure is the weight file alone. With VAE, text encoder and activation memory added, an 8GB card is marginal and will likely fail at higher resolutions or longer durations. Treat 8GB as an experiment, not a working setup.
No. As of August 2026 MiniMax has not released an official GGUF quantization for H3. Every GGUF build available is a third-party conversion, and their quality, speed and node compatibility are not verified by MiniMax.
More than most people budget for, and it depends on your launch flags rather than your GPU. In a published third-party run on a 16GB card, ComfyUI's resident memory peaked at 45.4 GiB with default settings and fell to 6.1 GiB with --disable-pinned-memory. Pinned memory holds roughly twice the model size in pages the OS cannot swap or reclaim, so a 32GB machine can fail on system RAM while the GPU still has headroom.
Peak memory scales with resolution, frame count and the audio branch, none of which appear in the file size. A model that loads fine at 768px and 5 seconds can still OOM at 2K and 15 seconds. Establish a working baseline at low settings first, then raise them one at a time.