What You'll Build
A locally generated clip with native stereo audio from MiniMax H3, on a 12 GB RTX 4070, using ComfyUI's dynamic VRAM offloading. The two VAEs fit on the card comfortably; the two files that do the work — a 19.53 GiB diffusion transformer and a 14.61 GiB text encoder — do not, and neither fits even alone. The card streams them from system RAM and pays for the shortfall in time rather than in an out-of-memory error.
⚠️ Read the licence before you download 42 GB. MiniMax H3 ships under the MiniMax H3 Community License Agreement, which is territorially restricted. Section I.5 defines the excluded territories: "“Excluded Territories” means the European Union, the United Kingdom, the Republic of Korea and the United States of America." Section V.4 states: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory." That clause reaches the outputs, not just the weights. The Comfy-Org repack this recipe installs carries the same
minimax-h3-community-license-agreementtag, and every community re-quantisation of these weights is a derivative that inherits the terms — none of them relicenses anything. Read the LICENSE yourself; this is not legal advice.
Hardware data: RTX 4070 (12GB VRAM) · 39.554 GiB of weights streamed against a 12 GiB card · See benchmark data
ℹ️ 768p is the local ceiling — the 2K stage is not in the open-weights release. Comfy-Org's launch post says H3 support "enables a next-generation 2K video model to run locally on a GPU like the RTX 3060", and you will meet that line if you follow the links below. Read it as a description of the model, not of what your machine will output: H3 reaches 2K through a separate
H3-Regenerate-2Kmodule, and the model card states that module is not yet open-sourced and is reachable only through MiniMax's hosted API. What runs locally is H3-Base, which the same card describes as producing results at 768p. The same split applies toH3-Context-IR, the hosted prompt-preprocessing stage — the two official prompt guides describe its output format, which you have to write by hand.
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 12GB VRAM | RTX 4070 (12GB) — not measured on this card; the cited runs below are from a different 12 GB card (/contribute) |
| RAM | 32GB | — with --disable-pinned-memory; see Running |
| Storage | 39.554 GiB of weights (42.47 GB as HuggingFace reports it), NVMe strongly preferred | — |
| Software | ComfyUI 0.30.0+, torchaudio, CUDA 13 build of PyTorch | — |
The four files the official ComfyUI text-to-video template loads, with byte-exact sizes from the Comfy-Org repack:
| File | Size | Destination |
|---|---|---|
minimax_h3_fl2va_pruned_int8_convrot.safetensors | 19.53 GiB | ComfyUI/models/diffusion_models/ |
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 14.61 GiB | ComfyUI/models/text_encoders/ |
minimax_h3_video_vae_fp16.safetensors | 4.85 GiB | ComfyUI/models/vae/ |
minimax_h3_audio_vae_fp32.safetensors | 0.564 GiB | ComfyUI/models/vae/ |
That sums to 39.554 GiB against a 12 GiB card — a 27.554 GiB shortfall. ComfyUI closes it by loading each module only when it runs and evicting it afterwards, then partially offloading whatever still does not fit. The single largest file, the diffusion transformer at 19.53 GiB, is on its own larger than the card, so no configuration keeps it fully resident. This is the central fact of running H3 on this tier: it is a streaming workload, and your system RAM and SSD determine whether it completes.
Installation
1. Update ComfyUI onto a CUDA 13 PyTorch
H3's nodes ship in ComfyUI core (comfy_extras/nodes_minimax_h3.py), not as a custom node — the ComfyUI announcement pins the floor at version 0.30.0. Take the newest 0.30.x tag rather than the floor itself. That module imports torchaudio at load time; requirements.txt covers it, but a hand-built environment with only torch and torchvision fails at startup.
H3's weights ship in an int8 "convrot" format, and the CUDA floor for its fast kernels is a gate in ComfyUI's own source rather than folklore: comfy/quant_ops.py parses torch.version.cuda and, below 13, calls ck.registry.disable("cuda") after logging "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." That single call removes the comfy-kitchen CUDA backend that supplies the convrot kernels. Nothing errors; everything is simply slower. Order matters here: requirements.txt lists torch unpinned, so running it after you have installed a cu130 build will happily resolve a default-index wheel over the top and silently undo the fast path. Install the CUDA 13 stack last, and from its own index:
cd ComfyUI
git fetch --tags && git checkout v0.30.2
pip install -r requirements.txt
pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
torch torchvision torchaudio
Then confirm it took: the ComfyUI startup log prints the torch version, and you want +cu130 in it.
2. Download the weights
pip install -U "huggingface_hub[cli]"
hf download Comfy-Org/MiniMax-H3 \
diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
vae/minimax_h3_video_vae_fp16.safetensors \
vae/minimax_h3_audio_vae_fp32.safetensors \
--local-dir models
The repo's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four files where the loaders look. Pointing --local-dir at ComfyUI/models/diffusion_models instead gives you models/diffusion_models/diffusion_models/… and a node that cannot see its own weights.
Pass the filenames as positional arguments as shown. Handing several of them to --include instead makes everything after the first one positional anyway, at which point the flag is silently discarded — huggingface_hub/cli/download.py emits a UserWarning saying it is ignoring --include because filenames were set explicitly, and carries on. A warning, not an error, so it is easy to miss and you end up with the wrong subset of a 42 GB repo.
On the text encoder — this choice is contested, and the 12 GB answer differs from the 16 GB answer. A 40-series card has no nvfp4 hardware path, so Ada owners asked the Comfy-Org repack for an int4 build. Kijai — who maintains the KJNodes suite ComfyUI users lean on for H3 — answered in that thread that nvfp4 is not Blackwell-only and you can just use it, because here it is a storage format rather than a compute path, no different in that respect from GGUF. The file agrees with him: 350 of the encoder's 351 comfy_quant descriptors set full_precision_matrix_mult, and it ships zero input_scale tensors, which is exactly what an FP4 matmul would need — so the quantised path is declined on every architecture, Blackwell included. Against that, on quality rather than hardware: in the same discussion #16, one commenter argues the nvfp4 encoder compromises coherence on demanding reference setups and that int8 is simply better unless your system physically cannot handle it. He does not say he ran both, and nobody in that thread posts a same-seed comparison.
On a 12 GB card that exemption is the whole point: int8_convrot is 25.28 GiB against nvfp4's 14.61 GiB — 10.67 GiB more to stream on every generation, on a card that is already streaming everything. (Both figures GiB; do not compare either against a vendor page's decimal GB.) Take nvfp4 here, and treat prompt-adherence failures on complex reference setups as a reason to try int8_convrot before you blame your prompt. If you have the system RAM and the patience, int8_convrot is the quality-first choice.
3. Load the official template
Open ComfyUI, go to Template Library, and search for MiniMax H3 T2V. The ComfyUI tutorial documents this template plus the I2V and R2V variants, and lists the same four files and destinations used above.
Running
Start ComfyUI with the offload flag, not without it. On a 32 GB machine the default launch is the failure case, not the baseline, and the reason is arithmetic you can check in comfy/model_management.py at tag v0.30.2. ComfyUI page-locks host memory to speed transfers to the card: MAX_PINNED_MEMORY is 90 % of system RAM on Linux and 40 % on Windows, and pinned_hostbuf_size(size) returns max(0, int(min(size, MAX_PINNED_MEMORY) * 2)) — twice the model size. For the 19.53 GiB transformer alone that is a request for 39.06 GiB of page-locked host memory, before the 14.61 GiB encoder asks for anything. Page-locked pages can be neither swapped nor reclaimed, so on a 32 GB box the kernel's only remaining move is to kill the process.
And the flag's effect is measured, at almost exactly your memory size. A 15-second RTX 3090 write-up ran the same model and the same 362 frames twice on a box with 31,997 MB of RAM, changing only this flag: 29,866 MB of host RAM on defaults, killed by the kernel OOM-killer, against 7,508 MB with --disable-pinned-memory, completed in 23 min 17 s. It is the same weight set this page installs, too — he keeps the NVFP4 text encoder over the int8 one for exactly the reason given above, and his startup log lists convrot_w4a4, int8_tensorwise under Native ops. The card is different, a 24 GB 3090 rather than your 12 GB 4070, and that is the point: pinning is sized from the transformer and your system RAM, never from your VRAM, so this failure and this fix are identical on every card in this family. He reaches the same MAX_PINNED_MEMORY = ram * 0.90 line independently.
A second and weaker report points the same way: on the repack's discussion #6, a 5070 Ti owner posting as UdonJP logs ComfyUI's resident set at 45.4 GiB with no flags on this same four-file set — one person, one job, with his own limit attached in the same post: "I have not verified any of this on an actual 16 GB or 32 GB RAM machine — it is inference from a 125 GB box."
So what the flag saves is measured; what it costs in time is not, and the reason is structural — nobody has published a completed run on both sides of it, because the unflagged run is the one that gets killed. If you have read a percentage for this flag anywhere, it came from a guide its own author withdrew on 2026-08-08 as unverified, and it is deleted here rather than hedged. The mechanism is not in doubt, and it tells you which side you are on: with 125 GiB of RAM the 42.47 GB weight set stays in page cache whether or not it is page-locked, so unpinning changes only where the bytes live; with 32 GB it cannot be cached, so the per-step streaming this card cannot avoid arrives off the SSD instead. Take the flag regardless — the alternative is not a slower render, it is the OOM killer — and put the weights on the fastest NVMe you have, which is the lever you do control. At 64 GB you keep both the flag and the page cache, and that last sentence does not apply to you.
python main.py --disable-pinned-memory
Then queue the T2V template as it ships — it comes with a deliberately small preview resolution, which is the right thing to run on a 12 GB card before committing to a long job.
Two controls decide your runtime:
- Megapixels. The tutorial notes that raising it to about
1.0at 16:9 yields roughly 1344×768, H3's native canvas. Keep Multiple at 32 to match H3's resolution grid. - length. The node snaps frame counts to a 17k+5 grid at 24 fps: 124 frames is about 5 seconds, and the node's own tooltip gives the trained range as roughly 124–362 frames.
Output lands in ComfyUI/output/video/ as an MP4 with the stereo track muxed in. If ComfyUI dies while loading the model even with the flag set, that is still a host-RAM problem rather than a VRAM one — see Troubleshooting before you touch the resolution.
Results
- Speed: no published RTX 4070 measurement exists — this pair has no benchmarks in our catalogue and none surfaced in the model's release-week threads. The closest published figures come from a different 12 GB card: on the Comfy-Org repack's discussion board, a user running an RTX 3060 12GB reported 20 minutes for a 3-second clip at 1376×768 and 24 steps — near H3's native canvas. That is the number to plan around: at the resolution the model was built for, this tier measures its output in tens of minutes per few seconds of video. The RTX 4070 holds the same 12 GB on a newer architecture, so it should land at or under that figure, but nobody has published a 4070 run — treat it as a bound, not a prediction, and please contribute one. One caveat on that citation: the post gives the card, canvas, step count and duration, but not which of the repack's weight files were loaded, so it is a same-capacity datapoint rather than a same-configuration one.
- That the install itself works on 12 GB: the same user, two days earlier and on the same RTX 3060 12GB with 32 GB of RAM, stated the file set explicitly — a pruned int8 convrot diffusion model with the nvfp4 text encoder, at 960×544 and 20 steps, working without any problem. That was the
ref2vacheckpoint rather than thefl2vaone installed here, but it is the same repack at the same quantisation, and it is the closest thing to a confirmation that this exact combination loads and runs on this capacity. - VRAM usage: the only published measurements are on a 16 GB card, they are whole-run peaks rather than stage peaks, and there are exactly two of them — both from
UdonJPon an RTX 5070 Ti in the repack's discussion #6: "VRAM peak was 14,197 MiB for 30 s @ 640x480 and 14,437 MiB for 5 s @ 1344x768". One person, one machine, and he adds his own limit — "it is inference from a 125 GB box." Both exceed a 12 GB card outright, which is why the 4070 must offload rather than fit. In the same post he describes the shape of the trade: "ComfyUI's DynamicVRAM keeps the ceiling roughly constant and pays the difference in time rather than VRAM." — raising resolution moves the clock more than it moves the VRAM peak. A longer write-up with a node-by-node peak table used to sit behind these numbers; its author withdrew it on 2026-08-08 as unverified, so it is not cited here and the wider peak band that circulated from it should be treated as unpublished. See /check/minimax-h3/rtx-4070. - Quality notes: the practical setting on this tier is a reduced canvas, not the native one. The same RTX 3060 12GB user reported that render times grow steeply with resolution, length and step count on low-VRAM hardware, and separately that H3 distorts faces badly when the subject is small in frame — an artefact of the model, not of the card, and one that a lower canvas makes worse. Expect to work at close and medium shots.
For the full benchmark data, see /check/minimax-h3/rtx-4070.
Optional: the 8-step Turbo path
The companion node larryvrh/ComfyUI-MiniMax-H3-Turbo was created on 2026-08-06, a day before this page was written, and the few-step LoRAs it drives are the same age. Their step-reduction claims come from their own authors and have not been independently measured, so do not build a workflow around this yet. One data point exists: the same RTX 3060 12GB user reported 4.5 minutes for a 5-second clip at 864×480 with an 8-step Turbo LoRA, alongside a separate experimental int8 video VAE. Two experimental components changed at once, one run, one person — that is a lead worth following, not a benchmark.
Troubleshooting
ComfyUI is killed, or throws MemoryError, while loading the model
System RAM, not VRAM, is what usually ends an H3 run on a small card — which is why --disable-pinned-memory is in the launch command above rather than here, with the 39.06 GiB arithmetic behind it. The 31 GB machine in the RTX 3090 write-up quoted under Running is the worked example: OOM-killed on defaults, and a completed 15-second clip once the flag was set. If it dies during the model load even with the flag, grep the startup log for Enabled pinned memory — if that line is present, the flag did not take effect. Adding swap does not help on its own, and that is mechanical rather than anecdotal: page-locked pages cannot be paged out, so the kernel has nothing to reclaim. Confirm the flag exists in your version against comfy/cli_args.py.
--fast-disk attacks the same problem from the other end, offering in its own help text to "Prefer disk-backed dynamic loading and offload over unpinned RAM. Can be faster for users with fast NVME disks." — reclaimable page cache instead of anonymous memory. Whether it adds anything on top of --disable-pinned-memory is unmeasured, so treat it as an alternative rather than a second dose. --cache-none is not a substitute for either: the same file puts it in the cache group as "Reduced RAM/VRAM usage at the expense of executing every node for each run.", which is node-output caching rather than weight residency.
Do not reach for --lowvram here: its own help text in that file says it does nothing when dynamic VRAM is enabled.
A MemoryError raised specifically by UNETLoader has a second, duller cause — a truncated download. A user who hit it on the Comfy-Org repack confirmed the file was the right size but the wrong hash after Kijai suggested it.
The GGUF quantisations will not load on stock ComfyUI
Two pruned Q4 GGUF builds of about 10.6 GiB circulate and look like the obvious answer for a 12 GB card. With the stock loader they are a dead end, for a mechanical reason you can check yourself: ComfyUI-GGUF/loader.py gates diffusion models against an IMG_ARCH_LIST that admits flux, sd1, sdxl, sd3, aura, hidream, cosmos, ltxv, hyvid, wan, lumina2 and qwen_image — and nothing for H3. Reading the published files' GGUF headers directly:
- of the two ~10.6 GiB builds, one carries no metadata at all — no architecture key, because it is a stable-diffusion.cpp artifact per its own repo card, not a ComfyUI file — and the other declares
general.architecture = minimax_h3, which that allow-list rejects by name - the ones that do load declare
general.architecture = wan, passing the allow-list by naming a different model. The smallest of those is a Q3_K_M at 14.5 GiB, still comfortably over the card and only 5 GiB under the official build it would replace
Issue #471 requests H3 support and is open. The text encoder is the exception: its GGUFs declare qwen3vl, which the loader's text-model list does accept.
A fork route does exist, and it is too new to recommend. molbal, who published one of those GGUF sets, also maintains a fork of ComfyUI-GGUF with dynamic-VRAM-aware loaders and points users at them in place of the stock Load Diffusion Model node. It is days old, its first H3 loading bug was reported and fixed inside 24 hours, and nobody has published a 12 GB result with it. Worth watching; not worth building on yet.
The quantiser's own verdict is the reason to stay on the official safetensors regardless. Answering a bug report on his repo, molbal wrote on 2026-08-05: "But with both cases the INT8 safetensors usually outperforms GGUFs since ComfyUI implemented dynamic vram." Dynamic VRAM is what makes this whole tier work, and it removed the advantage GGUF was there to provide.
Generation is far slower than the numbers above
Two lines in the startup log decide this, and both fail quietly: a comfy_kitchen import failure, and the cu130 warning quoted in Installation step 1. Either one calls ck.registry.disable("cuda") in comfy/quant_ops.py and takes the int8-convrot kernels out of play while ComfyUI carries on running as though nothing happened — one buried log line, and everything is simply slower.
You want 2K output
You cannot get it locally today. See the note at the top: H3-Regenerate-2K is not part of the open-weights release, and the official route to 2K is to feed your local 768p result back to MiniMax's hosted API. That API call falls under the same territorial licence.
Hit something this page missed? Send it via the submission form — a measured RTX 4070 run is the single most useful thing this page is missing.