If you have tried to run MiniMax H3 in ComfyUI on a 16 GB card, you have probably watched it die with a CUDA out of memory error, or worse, sit frozen at “0/8” with the GPU fan spinning and nothing happening. I have spent the last few weeks fighting exactly this on my RTX 5080 16 GB build while running H3 text-to-video, image-to-video and reference-to-video jobs every day. This guide is the full list of what actually fixed MiniMax H3 out of memory in ComfyUI for me, stage by stage, plus the public fixes from ComfyUI pull requests and r/StableDiffusion that I verified along the way. I will also be honest about what did not work.
- H3 runs out of memory at four stages: model load, Qwen3-VL text encoding, sampling and VAE decode. Fix each one separately.
- Add
SetReserveVRAM(3.0 GB) afterCLIPLoaderand a KJNodesVRAM_Debugnode after conditioning to flush the encoder and VAEs before sampling. - Keep megapixels around 0.3 to 0.4 and clips around 5 seconds. Megapixels are the biggest memory lever.
- Use int8_convrot or w4a8 safetensors with
UNETLoader. In my tests a smaller Q4 GGUF was slower and still offloaded. - Update ComfyUI for the H3 VAE decode fixes (PR #15446 and #15456), and launch with
--reserve-vramand--cache-none.
Why MiniMax H3 Runs Out of Memory on 16 GB
H3 is not one model, it is a stack. A typical H3 graph in my workflows loads four big pieces: the H3 diffusion model (I use minimax_h3_fl2va_pruned_int8_convrot for text/image-to-video and minimax_h3_ref2va_pruned-w4a8_convrot_pruned for reference-to-video), the Qwen3-VL text encoder, the video VAE (minimax_h3_video_vae_fp16) and a separate audio VAE, because H3 generates sound in the same pass. On disk, my int8 UNet alone is listed at 19.5 GB in my backend notes, which is already more than a 16 GB card can hold.
ComfyUI copes with that by partially loading and streaming weights from system RAM. The trouble is that each stage has its own peak, and if any earlier model is still sitting in VRAM when the next stage starts, you hit the wall.
Where H3 Runs Out of Memory: The Four Stages
1. Model Load
The first time the sampler requests MiniMaxH3, ComfyUI decides how much fits. In my logs this shows up as a line like loaded partially; 8160.18 MB usable, 7939.68 MB loaded, 4017.42 MB offloaded. That is not an error, but it tells you only about 8 GB was usable because something else was already resident. If system RAM is also tight, this is where Windows can fail the load entirely.
2. Text Encoder (Qwen3-VL)
The Qwen3-VL encoder is large. On one of my long multi-shot workflows the job did not crash, it stalled: repeated stack captures showed it waiting inside a weight transfer (to_device) with under 100 MB of VRAM free. That “frozen at text encoding” symptom is an out of memory problem even though no OOM is printed.
3. Sampler
This is the long phase. H3 packs a huge number of tokens at high resolution. At native 1920×1088 I measured about 126,654 packed tokens, and the whole-sequence feed-forward and projection intermediates simply exceeded practical GPU memory. Windows showed ComfyUI using 15,823.7 MB dedicated plus 12,578.7 MB shared GPU memory, which means the driver was spilling into system RAM.
4. VAE Decode
The decode at the end is the classic place to OOM after a long render, especially for longer clips. ComfyUI PR #15446 explains why: the H3 VAE assembled the full decoded video in VRAM, cast it to a second float32 copy, and then duplicated it again on CPU, so decode peak memory grew linearly with video length.
Fix Checklist Per Stage
Model Load Fixes
- Pick a native-kernel quant, not just the smallest file. I tested a Q4_0 GGUF of H3 and reverted it. It loaded and ran, but in my backend notes it was 29% slower on the 5080 for image-to-video at 81 frames (333 s to 431 s). The smaller file still did not fit because the VAE was resident, and GGUF dequantises on every matmul. The int8_convrot safetensors with a plain
UNETLoader(weight_dtypedefault) was about 29% faster sampling than Q4_K_M (25 s/it vs 35 s/it at 0.4 MP) because it uses native int8 kernels. - Free the VAEs before the UNet loads. In image-to-video, the video VAE (about 2.67 GB) loads for the first-frame encode and then stays resident through sampling, and the audio VAE adds roughly 0.58 GB. That is why my log showed 4 GB offloaded. My fix is a KJNodes VRAM_Debug node spliced on the conditioning edge with
unload_all_modelsandgc_collectenabled. The r/StableDiffusion fix does the same idea: place VRAM_Debug between the guider and the sampler withempty_cache=Trueandgc_collect=True, so it acts as a sync barrier. - Know the cost.
unload_all_modelsis global. If another job is sharing the card, its models get evicted too. Test it on a GPU running H3 alone first.
Text Encoder Fixes
- Add
SetReserveVRAMafterCLIPLoader. On my multi-shot Extender workflows I insert a SetReserveVRAM node betweenCLIPLoaderand every CLIP input withreserved_gb = 3.0. Before that, my launcher reserve of 0.5 GB left only about 77 MB free and the Qwen transfer stalled. With 3 GB reserved, text encoding passed. Honest note: that same run later stalled again at sampling, so this is a text encoder fix, not a complete render fix. - Use a smaller encoder if your workflow supports it. My newer clip builder uses
ClipProjLoaderwithqwen3vl_4b_int4_convrotinstreamingmode instead of the 32B NVFP4 encoder. My backend notes list the 4B int4 file at 2.62 GB. - Drop the encoder once conditioning exists. The same VRAM_Debug splice frees the encoder. I measured a real job’s worker RAM staying flat at 27.2 GB for about 100 seconds of sampling, which proved the encoder and VAEs were never released mid-job.
Sampler Fixes
- Lower megapixels first. It is the single biggest lever. My production H3 runs at 0.3 MP (416×736 for 9:16). 0.2 MP looked soft after upscaling, and 0.4 MP (480×832) is fine but slower.
- Keep clips short. H3 snaps durations to its frame grid at 24 fps, and 124 frames is about 5 seconds. Long clips raise both sampler and decode peaks.
- Use chunked attention and feed-forward nodes. My hybrid workflows chain
MiniMaxLowVRAMAttentionandMiniMaxChunkFeedForward(chunk 4096) on the model path before sampling. - Native resolution: token chunking. Because I needed true 1920×1088, I patched the H3 model to process MLP, QKV and output projections in 8,192-token chunks while keeping full-sequence attention. In an isolated test on a 32,785-token MLP, peak allocated memory dropped from 3,990.8 MiB to 1,721.0 MiB with identical outputs. That is a layer test, not a measured full-video result.
- Turbo steps. Fewer steps do not cut peak VRAM, but they cut the time you spend streaming offloaded weights. I run 6 steps with the turbo pipeline.
VAE Decode Fixes
- Update ComfyUI. PR #15446 makes H3 decode memory stop scaling with clip length, and PR #15456 frees other models’ memory before the tiled-decode retry. Before #15456, the “retrying with tiled VAE decoding” fallback re-ran the same decode with ~14 GB of streamed weights still resident and failed again.
- Unload before decode on older builds. The PR author notes that calling
unload_all_models()between sampling and decode let the same config succeed. A VRAM_Debug node beforeVAEDecodedoes that in the graph. - Tiled decode for other video models. On my Wan 2.2 graphs I use
VAEDecodeTiledwith tile_size 512, overlap 64, temporal_size 64, temporal_overlap 8. The H3 video VAE already tiles internally, so for H3 the update matters more than the tiled node.
Launch Flags That Matter
All of these are real flags in ComfyUI’s cli_args.py:
| Flag | What it does | When I use it |
|---|---|---|
--reserve-vram 1.0 |
Reserves VRAM for the OS and other apps | Always on Windows with a browser open; raise it if desktop apps share the GPU |
--cache-none |
Re-executes nodes each run instead of caching outputs | Frees RAM between jobs, but not within one job |
--disable-pinned-memory |
Turns off pinned host memory | Try it when system RAM or commit charge is the bottleneck |
--disable-smart-memory |
Offloads models to RAM aggressively instead of keeping them in VRAM | Useful when several model families share one card |
--disable-async-offload |
Fetches offloaded weights synchronously | More stable, but slower when a lot is offloaded |
--lowvram / --novram |
Older low-VRAM modes | --lowvram does nothing when dynamic VRAM is enabled |
Recommended 16 GB Settings
| Setting | My 16 GB value | Why |
|---|---|---|
| Diffusion model | minimax_h3_fl2va_pruned_int8_convrot (T2V/I2V), minimax_h3_ref2va_pruned-w4a8_convrot_pruned (R2V) |
Native int8 kernels beat smaller GGUF quants in my tests |
| Loader | UNETLoader, weight_dtype default |
GGUF loaders dequantise every forward pass |
| Megapixels | 0.3 (0.4 for admin/hero shots) | Biggest single memory and speed lever |
| Duration | 4 to 6 s (124 frames is about 5 s) | Keeps sampler and decode peaks down |
| Steps | 6 with turbo LoRA and turbo sampler | Less time streaming offloaded weights |
| Text encoder headroom | SetReserveVRAM reserved_gb 3.0 after CLIPLoader |
Stopped my Qwen transfer stall |
| Free resident models | KJNodes VRAM_Debug after conditioning, empty_cache and gc_collect on |
Lets the UNet load with less offload |
| Low-VRAM nodes | MiniMaxLowVRAMAttention + MiniMaxChunkFeedForward (4096) |
Lower sampler intermediates |
| Launch | --reserve-vram, --cache-none |
Headroom plus clean RAM between runs |
| System RAM | 64 GB recommended | My worker peaked around 27 GB RAM in one job |
Windows-Specific Notes
- Pagefile matters. When VRAM overflows, Windows spills into “shared GPU memory”, which is system RAM. My machine at one point sat at 120 to 145% commit, and that is when loads start failing. Set the pagefile to system-managed on a fast NVMe, or give it a large fixed size.
- Shared GPU memory is not free VRAM. If Task Manager shows ComfyUI using lots of shared GPU memory, you are not OOM, you are slow. Lower megapixels or free resident models.
- Close GPU apps. Browsers, Topaz and video editors all take VRAM. That is exactly what
--reserve-vramprotects against. - Running more than one ComfyUI instance? Give each instance its own cache folder. My H3 Extender node shared one disk cache across instances until I pointed it at a per-instance directory with an environment variable in each launcher.
- Use per-process counters. Task Manager’s Details tab (Dedicated GPU memory and Shared GPU memory columns) shows which process actually holds the memory.
Troubleshooting: Error Messages and Fixes
| Symptom or message | Likely stage | Fix |
|---|---|---|
torch.OutOfMemoryError: CUDA out of memory during sampling |
Sampler | Lower megapixels, shorten the clip, add the low-VRAM attention/feed-forward nodes |
loaded partially; ... MB offloaded with slow s/it |
Model load | Free the VAEs and encoder with VRAM_Debug before sampling |
| Freezes at text encoding, GPU near 100 MB free | Text encoder | SetReserveVRAM 3.0 after CLIPLoader, or the 4B int4 encoder |
| Stuck at sampling 0/N with no error | Sampler / load | Check shared GPU memory, raise --reserve-vram, free resident models |
Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding then OOM again |
VAE decode | Update ComfyUI (PR #15456 and #15446), or unload models before decode |
| Python process killed or “paging file is too small” | System RAM | Increase the pagefile, use --cache-none, try --disable-pinned-memory |
| Wrong loader error on a GGUF H3 file | Model load | GGUF needs UnetLoaderGGUF, safetensors need UNETLoader |
Frequently Asked Questions
Can MiniMax H3 run on a 16 GB GPU?
Yes. I run it daily on an RTX 5080 16 GB. Parts of the model are offloaded to system RAM, so plenty of RAM and a short, lower-megapixel clip are what make it reliable.
Is a smaller GGUF quant the best OOM fix?
Not in my testing. Q4_0 was slower and still offloaded because the VAE stayed resident. The int8_convrot safetensors were faster thanks to native kernels.
Does –lowvram help with H3?
On current ComfyUI, --lowvram does nothing when dynamic VRAM is enabled, according to its own help text. --reserve-vram and freeing resident models helped me more.
Why does H3 freeze instead of showing an OOM error?
When VRAM is nearly full, weight transfers can wait instead of failing. I saw stalls in the text encoder transfer with under 100 MB free. Reserving VRAM fixed that stage.
Should I use tiled VAE decode for H3?
The H3 VAE tiles internally, so the bigger win is updating ComfyUI to include PR #15446 and #15456, or unloading other models before decode.
How much system RAM do I need?
There is no official figure. One profiled job on my machine took the ComfyUI worker to about 27 GB RAM, so 32 GB is tight and 64 GB is comfortable.
Final Thoughts and Related H3 Workflows
MiniMax H3 out of memory in ComfyUI is almost always about which models are still resident at the wrong moment, not raw model size. Reserve headroom for the encoder, flush the VAEs before sampling, keep megapixels sensible and update ComfyUI for the decode fixes. If you want ready-made graphs to apply these settings to, start with my workflow posts:
- Best MiniMax H3 Text-to-Video ComfyUI Workflow
- Best MiniMax H3 Image-to-Video ComfyUI Workflow
- Best MiniMax H3 Reference-to-Video ComfyUI Workflow