What You'll Build
A local ComfyUI graph that turns a text prompt (optionally plus a first and/or last frame) into a 124-frame, 24 fps clip at 864×480 — 5.17 seconds — with its own synchronised stereo soundtrack — dialogue, effects and music denoised jointly with the picture in a single pass, not dubbed on afterwards. The whole pipeline runs on one RTX 3090.
⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not released under an open-source licence. The MiniMax H3 Community License Agreement grants rights solely within the "Applicable Territory", and it defines the Excluded Territories as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America". Section V.4 extends that to what you generate: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory." — so the output video is covered, not just the weights.
Three traps worth naming. (1) The machine-readable
license:facet on the model card isother— the territorial restriction lives only inside the LICENSE file, so any filter keyed on thelicense:field, or on HuggingFace's flattenedlicense:othertag, sails straight past it. (Both cards do also setlicense_name: minimax-h3-community-license-agreement; the point is thatothercarries no signal.) (2) TheComfy-Orgrepack this recipe uses does not relicense it — it declares the samelicense_nameand links back to the same file. (3) A community LoRA taggedapache-2.0does not lift the restriction either: the agreement's definition of a Model Derivative opens with "any modification of MiniMax H3 or any Model Derivative thereof; (ii) any work based on MiniMax H3", which is where an adapter loaded against these weights lands — and it separately reaches distillation, "including by distillation methods, methods using intermediate data representations, or methods based on training using synthetic-data Outputs".If you are in an excluded territory, MiniMax publishes a licence Q&A and an application route for per-deployment licensing at
platform.minimax.io/h3-license. This is a summary written by a reader of the text, not legal advice — the linked agreement is the thing that binds you.
Hardware data: RTX 3090 (24GB VRAM) · 19.530 GiB resident at the denoise stage · See benchmark data
ℹ️ The 2K in the marketing is not in the download. H3's 2K output comes from a separate
H3-Regenerate-2Kmodule, and MiniMax's own README says that module is not open-sourced yet — "We will release it once it is ready". What you get locally isH3-Base, which the vendor validates at 768p. (TheMiniMaxH3ImageToVideonode's own schema defaults are 1344×768 — but the official template overrides them from a Resolution Selector, so the resolution you actually get is 864×480. See Running.) Everything on this page is about that 768p-class model.
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 24GB VRAM for a fully-resident denoise pass; less works via ComfyUI's dynamic VRAM offloading | RTX 3090 (24GB) — not measured by us; the budget below is derived from file bytes and ComfyUI's own reserve constants (/contribute) |
| RAM | 64GB, or 32GB with --fast-disk on an NVMe drive | — |
| Storage | 42.47 GB of weights | 42.47 GB across four files (byte counts from the HuggingFace tree API) |
| Software | ComfyUI 0.30.0+, Python 3.10+ | — |
MiniMax's own README gives no hardware guidance at all — a grep across the full raw text for VRAM, GPU memory, CUDA, NVIDIA, memory, GB, RTX, H100, A100, 3090 and requirement returns zero hits, and its only deployment example is an SGLang serve with --num-gpus 4. The ComfyUI tutorial page is silent on the same terms. The consumer-hardware claim comes from Comfy-Org's launch post, which describes shrinking the footprint "from 123.6 GB in full precision to 42.5 GB" — the same four files, byte for byte — and then says: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060."
That sentence is why min_vram_gb on this page is 12 rather than 24, and it is worth being precise about how much weight it carries. Two caveats: it is the same sentence whose "2K" framing the box above says overstates what the open weights do locally, and the smallest run of this exact four-file set that anyone has actually documented is a 16GB card, in discussion #6. So read 12 as the vendor's floor, 16 as the demonstrated one, and 24 — this card — as where the denoise pass stops needing to stream at all.
Installation
1. Update ComfyUI
MiniMax H3 landed in ComfyUI PR #15224, merged 3 August 2026 and shipped in release v0.30.0. Nothing older will load these files.
cd ComfyUI
git pull
pip install -r requirements.txt
2. Download the four model files
These are the exact four files the official text-to-video and image-to-video templates reference. Do not substitute the bf16 or unpruned variants on a 24 GB card. Run these from the ComfyUI root — the same directory step 1 left you in.
pip install -U "huggingface_hub[cli]"
hf download Comfy-Org/MiniMax-H3 \
diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
--local-dir models
hf download Comfy-Org/MiniMax-H3 \
text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
--local-dir models
hf download Comfy-Org/MiniMax-H3 \
vae/minimax_h3_video_vae_fp16.safetensors \
vae/minimax_h3_audio_vae_fp32.safetensors \
--local-dir models
The four files land in the layout the Comfy-Org repack card documents:
ComfyUI/models/
├── diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors 20,970,379,616 B
├── text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors 15,687,142,551 B
├── vae/minimax_h3_video_vae_fp16.safetensors 5,207,808,496 B
└── vae/minimax_h3_audio_vae_fp32.safetensors 605,254,808 B
Verify the hashes. A MemoryError on this repack has already turned out to be a silently-truncated download rather than a real memory problem — see Troubleshooting. Re-hashing a 21 GB file is cheap next to re-diagnosing it.
3. Load the official workflow
Drag video_minimax_h3_t2v.json into ComfyUI, or pick MiniMax H3 Text to Video from the template library. The image-to-video template uses the same four files and the same MiniMaxH3ImageToVideo node — connect first_frame and/or last_frame and it switches from t2va to fl2va by itself.
Running
Queue the template unchanged first. Its stock settings are 864×480, length 124 (5.17 s at 24 fps), 20 steps, sampler res_multistep, scheduler simple.
That resolution is worth pinning down, because the node's own default disagrees with it. The template's Resolution Selector node is set to 16:9 (Widescreen) at 0.4 megapixels, and its two outputs are wired into the generation node's width and height inputs — a connected input wins over a stored widget value, so the 1344×768 sitting in the node's widgets never reaches the sampler. ResolutionSelector.execute computes scale = sqrt(0.4 × 1024² / (16×9)) = 53.9695, then rounds each axis to the nearest multiple of 32: 864 × 480. The template's own reference table agrees (| 0.4 | 16:9 | 864 x 480 |). To actually get 1344×768, set the Resolution Selector to 0.98 MP — that is the value that reproduces the node default.
python main.py --fast-disk
ComfyUI then walks three stages, and it only ever holds one large module on the GPU at a time:
| Stage | Resident weights | ComfyUI's reserve for that stage | Stage total |
|---|---|---|---|
| Text encode (Qwen3-VL-32B, NVFP4-AWQ) | 14.610 GiB | 1.191 GiB | 15.800 GiB |
| Denoise (the H3 DiT, pruned int8+convrot) | 19.530 GiB | 1.191 GiB | 20.721 GiB |
| Decode (video VAE fp16) | 4.850 GiB | 1.455 GiB | 6.305 GiB |
The middle row is the one that has to fit, and on a 24 GiB card it clears by 3.279 GiB. It is also the only row that does not move with resolution — it is weights plus a fixed floor — so raising the canvas to 1344×768 changes nothing about whether this fits, it only lifts the decode reserve to 2.851 GiB (stage total 7.701 GiB), still nowhere near binding.
That single-module-at-a-time behaviour is not an assumption, it is what load_models_gpu in comfy/model_management.py does: it sums the memory the requested models need and calls free_memory(...), which walks the already-loaded models and evicts them until there is room. The text encoder and the DiT sum to 34.140 GiB, so on a 24 GiB card they simply cannot both be resident — and the fact that this workflow completes on a 3090 at all is the evidence that the eviction happens. The 1.191 GiB reserve is ComfyUI's minimum_inference_memory() floor for a Linux host (0.8 GiB plus a 400 MiB EXTRA_RESERVED_VRAM); on Windows the constant is larger, making the floor 1.484 GiB and the surplus correspondingly smaller. The sampler's own activation estimate for this latent — memory_usage_factor 0.114 against the stock [1, 24, 37, 30, 54] video latent — works out to 0.267 GiB, i.e. below that floor, so the floor is what binds. (At 1344×768 the latent is [1, 24, 37, 48, 84] and the estimate rises to 0.664 GiB — still under the floor.)
The decode reserve is not a guess either. comfy/sd.py ships a first-party estimator for this VAE, (9.5 × frames × height × width + 270,000,000) × dtype_size × 1.03, which at 124 frames of 864×480 in fp16 gives 1.455 GiB. The video VAE also tiles internally — 256-pixel spatial tiles with ≥64 px overlap, in 17-frame temporal chunks — so the decode footprint is bounded by tile geometry rather than by the full canvas.
Output lands in ComfyUI/output/video/ as an MP4 with the audio already muxed in by the CreateVideo node.
Results
- Speed: not measured by us on this card. The closest on-target figure is a single community report on ComfyUI issue #15263, which lists a setup of "RTX 3090 (sm_86), ComfyUI 0.30.1, torch 2.11.0+cu130,
sageattention1.0.6 (PyPI, pure-Triton wheel),minimax_h3_fl2va_pruned_int8_convrot.safetensors, 864×480, 124 frames, 20 steps,res_multistep/simple,BasicGuider, fixed seed." and reports 9.00 s/it without Sage Attention — 180 s of sampling across the 20 steps — against 6.57 s/it with it. Read that setup line against the Running section above: 864×480, 124 frames, 20 steps,res_multistep/simpleis exactly the stock template, on exactly the checkpoint this page installs, on exactly this card. It is as on-target as an uncontrolled datapoint gets. Two things it still is not: it is one commenter rather than a repeated measurement, and it counts sampling only — not text encode, VAE decode or the model loads, which the same threads describe as substantial. Treat it as a strong single data point, not a benchmark. If you run this pair, please post numbers via /contribute so /check/minimax-h3/rtx-3090 can carry a real measurement. - VRAM usage: 20.721 GiB at the binding denoise stage — 19.530 GiB of int8 DiT weights plus ComfyUI's 1.191 GiB inference reserve floor — leaving 3.279 GiB of a 24 GiB card. Derived from the on-disk byte counts above and ComfyUI's own reserve constants; the backend currently reports
verdict: unknownwith no benchmark rows for this pair at /check/minimax-h3/rtx-3090. - Quality notes: when a 3090 owner asked directly which quantisation tier to use — Q4, Q2 or int8 — a Comfy-Org member answered int8, in discussion #18 on the repack. He did not distinguish pruned from unpruned; the pruned qualifier in this recipe is the memory budget's doing, since the unpruned int8 file is 31.701 GiB and cannot sit resident on this card at all. Sub-int8 community conversions exist and opinions on them in discussion #22 are openly split, with no measured comparison in either direction — they are outside the scope of this page.
For the full benchmark data, see /check/minimax-h3/rtx-3090.
Optional: the Turbo LoRA
A community distillation adapter, larryvrh/MiniMax-H3-Turbo-Lora, with a companion node pack at Larryvrh/ComfyUI-MiniMax-H3-Turbo, brings sampling out of the template's 20 steps and into a low single-digit range. Step count is the largest lever on any card, so this is the one optional thing on this page worth watching.
Both links are pinned to a revision, and you should check whether it has moved again before you follow any of it. This project rewrote its documentation three times inside a single day. Anything you find quoted around the community about a paused training round, over-sharp grain in the weights or prototype nodes came from a text its own author has replaced, and following it would now steer you onto the wrong checkpoint. What the pinned revision says:
- Take
minimax_h3_turbo_v4_step600_ema.safetensors. The author calls it the strongest checkpoint released, with better static and small-motion shots and better micro-detail, and states that the over-sharpened, plastic look of the earlierv1(~850) line is resolved in it. Prefer the EMA files generally; the non-EMA ones are published for comparison. - 4–8 steps, not 4. Four is described as the recommended minimum, six to eight as noticeably better, and past eight as no longer helping and liable to introduce over-sharp artifacts. v4's one regression sits at exactly four steps with large, fast motion, where it can produce motion smear or trailing ghosts; six to eight steps is the stated fix, and the older
v1~850 remains the friendlier pick if you specifically need four steps on heavy motion. - Keep
strengthat 1.0 and the scheduler onsimple. Reach for the strength dial only when a particular clip misbehaves. - The pruned int8-convrot base this page installs is supported. The node detects a pruned base and re-injects the LoRA's time-conditioning at run time, so one LoRA file covers the bf16, int8_convrot, pruned_int8 and pruned_fp8 bases alike. Its
low_vramswitch merges the LoRA into the weights for a lower peak instead of applying it at run time; the author notes the merge comes out softer on quantised bases, which is exactly what you have, so leave it off unless you run out of memory. On 24 GB you should not need it.
The sampler advice has changed, and the old version is still circulating. Earlier guidance was that the pack's own sampler is mandatory because a stock sampler over-steps H3's separate audio flow schedule at four steps. That is no longer the position: recent ComfyUI carries the audio latent on the video schedule itself, and the pack's sampler now auto-detects which behaviour it is running on. ComfyUI's own H3 module agrees at the version this page pins — the docstring at the top of comfy_extras/nodes_minimax_h3.py in v0.30.2 states that "sampling runs on the flat pack with any stock sampler (the model handles the audio stream's shifted schedule internally)". Keep the Turbo Sampler in the graph anyway, since it is version-agnostic by design, and re-check the audio track specifically after any ComfyUI or node-pack update.
Treat the speedup as unmeasured here. The author's headline figure is a ~5× sampling speedup against 20 steps; no same-machine before/after has been published on an RTX 3090, and this page has none. The project also still describes itself as a preview with audio and fast-motion behaviour under active work, so get a known-good render at 20 steps on the stock sampler first, to have something to compare against.
The licence point from the top of this page reaches here too: the adapter's Apache-2.0 tag covers the adapter, while the base weights it loads against remain under the territorial agreement.
Troubleshooting
MemoryError in UNETLoader on a card that should fit
Check the download before you touch anything else. In discussion #29 a Comfy-Org member's first guess at a MemoryError in UNETLoader was a corrupt file from a failed download, and that is what it turned out to be — the reporter re-fetched and got the same byte size but a different hash. Worth knowing precisely what that case was: the reporter was on the r2v graph with minimax_h3_ref2va_pruned_fp8_scaled.safetensors, and said in the same thread that minimax_h3_fl2va_pruned_int8_convrot — this recipe's file — worked fine for them. So this is one documented instance on a neighbouring artifact, not a known defect in the file you just downloaded. It is still the cheapest thing to rule out, because a size-matching truncation is invisible until load time.
The generation dies on system RAM, not VRAM
On a 24 GB card the VRAM budget above has room; RAM is the tighter constraint, because ComfyUI stages the full 42.47 GB working set. A reporter in discussion #6 measured this same four-file set with and without one startup flag and saw ComfyUI's RSS peak drop from 45.4 GiB to 12.6 GiB with --fast-disk, which comfy/cli_args.py documents as preferring "disk-backed dynamic loading and offload over unpinned RAM". Anonymous memory cannot be reclaimed; page cache can. On an NVMe box, start with the flag on.
Don't reach for VAEDecodeTiled
The H3 video VAE already tiles and chunks internally, and ComfyUI marks it handles_tiling = True. Routing its packed audio+video latent through the tiled-decode node raises a to() received an invalid combination of arguments - got (NestedTensor) error, reported in ComfyUI issue #15274. Use the plain VAEDecode and VAEDecodeAudio nodes the template wires up.
Sage Attention: this is the architecture where the picture is good
pip install sageattention gets you 1.0.6 from PyPI, and on this card that is the version you want. Do not go looking for a 2.x source build on the strength of a Blackwell page: the measured 1.37× below was taken on the stock wheel, no Ampere benefit from 2.x has been published by anyone, and a source build is a lot of effort for an unmeasured delta.
Both paths are measured clean here, which is not true everywhere. In ComfyUI issue #15263 a commenter running the setup quoted under Results — a named RTX 3090, the checkpoint this page installs, the stock template geometry, a fixed seed and cached conditioning — ran the KJNodes Patch Sage Attention KJ node and the plain --use-sage-attention flag and got clean output from both, at 6.57 and 6.50 s/it against 9.00 without. He checked the renders rather than assuming them, and scored them against the same-seed non-sage reference at 32.01 dB and 30.30 dB — a differently-sampled but equally valid frame, not degradation. He also retracted his own first explanation for why the two paths might differ ("my smooth_k explanation was wrong — retracting it"), which is a good sign about the rest of it.
The defect that thread is now about is on a different architecture, and its title changed under it. As of 8 August 2026 the issue is titled around FP8 PV sage kernels producing noise above roughly 160k tokens on sm_120 — a title it did not carry a week earlier, so check it again rather than trusting this sentence. Be precise about what its author did and did not withdraw: he withdrew his explanation (a missing low_precision_attention=False, whose pull request closed unmerged) and then confirmed a defect, writing "I think you've got it right that FP8 PV is the cause". The finding was sharpened, not dropped. Ampere is outside it because the kernel differs: 1.0.6 has no architecture dispatch and no FP8 kernel at all — it is a single Triton path doing INT8 QK, FP16 PV and FP32 accumulation — and on sm_80/sm_86 a 2.x build selects an FP16 PV kernel too. The sorted table in that thread reads "Every noise report is FP8 PV. Every clean report at high token count is FP16 PV."
And the failing range is not merely unreached on this card — it is unreachable inside H3's own limits. Counting tokens the way that thread does, ceil(frames / 4) × (width / 32) × (height / 32), its last clean row is 150,960 and its first noise row 167,280. H3's own area cap — MAX_PIXELS = 768 * 1344 in comfy_extras/nodes_minimax_h3.py, at the top of the range the same file's length tooltip calls "trained range is ~124-362, longer is untested" — puts the largest job the model is built for at 91,728 tokens, 55% of the first noise row and below even the last clean one. That ceiling is the model's, not Ampere's; it is the same number on every GPU. Meanwhile the same commenter has verified this card clean up to 56,120 tokens (1280×736 over 243 frames), 4.5× the stock template's 12,555. So the honest position for a 3090 owner is not "safe at five seconds, unknown at fifteen" — it is that you cannot get near the boundary without leaving the envelope the model was trained in.
One caveat on the metric, from the person who computed most of it: "I don't think it's the model's literal sequence length". ComfyUI's video_latent_t() gives 107 temporal positions for 362 frames where ceil(frames / 4) gives 91, so absolutes move about 19% between conventions while ratios barely do. Rank jobs with it; do not read it as an attention sequence length.
Out of memory while encoding a reference video in the r2v graph
The reference-to-video workflow VAE-encodes each reference clip before sampling, and that encode is a separate, larger peak than anything in the table above — ComfyUI issue #15312 shows a 16 GB card failing on a single 7.17 GiB allocation there. It also loads a different diffusion checkpoint (minimax_h3_ref2va_pruned_int8_convrot.safetensors), so the r2v path is a separate download and a separate memory question from the t2v/i2v path this page covers. Start with reference images before reference video.
Nothing in the log about your problem
Report it against the right tracker: runtime errors at ComfyUI/issues, template problems at workflow_templates/issues. If you get a clean run on this card, a timing posted through /contribute is worth more to the next reader than any of the derived numbers above.