What You'll Build
A locally generated clip with a synchronised stereo soundtrack — dialogue, effects and music denoised jointly with the picture in one pass — from MiniMax H3 on a 12 GB RTX 4070 SUPER, using ComfyUI's dynamic VRAM offloading.
This page is organised around one claim, and it is worth stating before you spend an afternoon on it: on this workload the RTX 4070 SUPER is not meaningfully a faster card than the plain RTX 4070, and the parts of your machine that are not the GPU decide almost everything. That is not a hedge to cover missing data — although the data is missing, and this page says so repeatedly. It is what the arithmetic predicts once you look at where the time goes, and the practical consequence is that a reader with 32 GB of RAM and a SATA SSD should fix those before wondering about the card.
⚠️ Read the licence before you download 42 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement grants rights only inside its Applicable Territory. Section I.5 defines the Excluded Territories as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America.", and Section V.4 reaches past the weights to what you make with them: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory." — your output video is covered, not only the download.
The machine-readable
license:facet on the model card is the uninformativeother, so a catalogue filter or a licence scanner keyed on that field sails straight past all of this; the restriction lives only inside the LICENSE file. Nothing downstream relaxes it either — the Comfy-Org repack installed below declares the same licence, and a community GGUF, int4 build or Turbo LoRA made from these weights is a Model Derivative that inherits the terms. MiniMax publishes a licence Q&A and an application route for per-deployment licensing. This is a summary written by a reader of the text, not legal advice.
Hardware data: RTX 4070 SUPER (12GB VRAM, sm_89) · 20.721 GiB at the binding denoise stage against a 12 GiB card · See benchmark data
ℹ️ 768p is the local ceiling. H3 reaches 2K through a separate
H3-Regenerate-2Kmodule, and the model card says of it: "this module is not yet open-sourced. We will release it once it is ready." The official route to 2K is to send your local 768p result back to MiniMax's hosted API, which puts you under their platform terms on top of the weights licence. What runs on your card is H3-Base.
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 12GB VRAM | RTX 4070 SUPER (12GB) — not measured, by us or by anyone; see Results for what that means and what is published instead (/contribute) |
| RAM | 32GB with --disable-pinned-memory; 64GB without | — this is the prerequisite most likely to waste the download |
| Storage | 39.554 GiB of weights (42.47 GB as HuggingFace reports it) | — NVMe; see Running for why the drive is in the loop |
| Software | ComfyUI 0.30.0+, torchaudio, CUDA 13 build of PyTorch | — |
The four files the official ComfyUI text-to-video template loads, byte-exact from the Comfy-Org repack's tree API:
| File | Bytes | GiB | Destination |
|---|---|---|---|
minimax_h3_fl2va_pruned_int8_convrot.safetensors | 20,970,379,616 | 19.530 | models/diffusion_models/ |
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 15,687,142,551 | 14.610 | models/text_encoders/ |
minimax_h3_video_vae_fp16.safetensors | 5,207,808,496 | 4.850 | models/vae/ |
minimax_h3_audio_vae_fp32.safetensors | 605,254,808 | 0.564 | models/vae/ |
That is 39.554 GiB of weights against a 12 GiB card, and the single largest file is larger than the card on its own. ComfyUI closes the gap by loading one module at a time, evicting it when the next one runs, and streaming whatever still does not fit across the PCIe bus while the step executes.
The budget, and the one row that binds
All of the following comes from the byte counts above and from constants in comfy/model_management.py at tag v0.30.2. minimum_inference_memory() is 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux — a 1.191 GiB floor.
| Stage | Resident weights | Reserve floor (Linux) | Stage total | Against 12 GiB |
|---|---|---|---|---|
| Text encode (Qwen3-VL-32B, NVFP4-AWQ) | 14.610 GiB | 1.191 GiB | 15.800 GiB | short by 3.800 GiB |
| Denoise (the H3 DiT, pruned int8+convrot) | 19.530 GiB | 1.191 GiB | 20.721 GiB | short by 8.721 GiB |
| Decode (video VAE fp16) | 4.850 GiB | 1.455 GiB | 6.305 GiB | clears by 5.695 GiB |
Only the decode row fits. On Windows the reserve is 600 MiB rather than 400, giving a 1.386 GiB floor and moving every shortfall by 0.195 GiB. Note that this is not the 1.484 GiB figure quoted on this site's 16 GB and 24 GB pages: the extra 100 MiB term in that source file sits inside the if WINDOWS: branch and behind a total_vram > 15 * 1024 test, and a 12 GB card fails the second condition. Read the indentation yourself rather than inheriting a number from a larger card.
MIN_WEIGHT_MEMORY_RATIO is reset to 0.0 on NVIDIA hardware, so the resident weight budget is simply free VRAM minus that floor — at most 10.809 GiB, and less once your desktop has taken its share. The transformer is 19.530 GiB. At least 8.721 GiB of it is off the card at every moment of the sampling loop, and because the model is dense, every one of those bytes has to arrive over PCIe on every step.
That last sentence is the whole page. It is also why the next section is about the card and reaches a deflationary conclusion.
What the SUPER's extra shaders buy you here
NVIDIA's own RTX 4070 family specifications put the three 12 GB Ada parts side by side. The relevant rows:
| RTX 4070 | RTX 4070 SUPER | RTX 4070 Ti | |
|---|---|---|---|
| CUDA cores | 5,888 | 7,168 | 7,680 |
| Shader TFLOPS | 29 | 36 | 40 |
| Tensor cores (AI TOPS) | 466 | 568 | 641 |
| Boost clock (GHz) | 2.48 | 2.48 | 2.61 |
| Standard memory config | 12 GB GDDR6 / 12 GB GDDR6X | 12 GB GDDR6X | 12 GB GDDR6X |
| Memory interface width | 192-bit | 192-bit | 192-bit |
| PCI Express Gen 4 | Yes | Yes | Yes |
So the SUPER carries 21.7 % more CUDA cores than the plain RTX 4070 at exactly the same boost clock, and NVIDIA rates it 24 % higher in shader TFLOPS. Every memory row is identical, and so is the bus the streamed weights cross.
Three things follow, and they are all restrictions on how much that 21.7 % can be worth.
One: NVIDIA does not publish memory bandwidth for any of these cards. That table has no bandwidth row, and neither does the full-specifications page behind it. What is published is the interface width — 192-bit on all three — and the memory type. That is enough to say the on-card memory subsystem is the same shape and not enough to assert a percentage, so this page does not assert one. If you have seen a bandwidth figure quoted for these cards, it came from a third party doing the same multiplication you could do, using a memory clock NVIDIA did not print.
Two: the plain RTX 4070 is not even a single memory configuration. NVIDIA lists its standard memory config as 12 GB GDDR6 / 12 GB GDDR6X — two different memory types under one SKU name. The SUPER and the Ti are GDDR6X only. So the SUPER is more determinate than the card below it, which is a genuine difference, and it cuts against ever quoting a crisp SUPER-versus-4070 ratio: you would need to know which 4070 the other person has.
Three, and decisively: the extra shaders only touch the fraction of the run that is on-card compute. With 8.721 GiB of transformer arriving over a PCIe Gen 4 link on every sampling step, part of each step is transfer and part is arithmetic, and a 21.7 % improvement applies only to the second part. Nobody has published a decomposition of an H3 step into transfer time and compute time on any 12 GB card, so the honest statement of the bound is: the SUPER cannot be more than about a fifth faster than a plain 4070 here, is very likely much less than that, and no published measurement separates the two. A recipe site that told you otherwise would be inventing the number.
What this means practically. Do not buy a 4070 SUPER to run H3 faster than a 4070, and do not read a 4070 result as a floor you will comfortably beat. Do put the weights on NVMe, and do get to 64 GB of RAM if the choice is between that and a card upgrade. The next two sections give the reasoning for that ordering, and are explicit about which half of it is measured: 32 GB without the right launch flag is a killed process rather than a slow one, which is not in question; how much the flag itself costs once you pass it is a mechanism nobody has put a number to.
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 0.30.0. That module imports torchaudio at load time, so a hand-built environment with only torch and torchvision fails at startup even though requirements.txt covers it.
The CUDA version is a gate in ComfyUI's own source rather than folklore. comfy/quant_ops.py parses torch.version.cuda, and below major version 13 it calls ck.registry.disable("cuda") and logs a warning. That single call switches off the comfy-kitchen CUDA backend, which is what provides the accelerated kernels for the int8_tensorwise+convrot format the transformer is stored in. Nothing raises; everything is simply slower.
Order matters. requirements.txt lists torch unpinned, so running it after a cu130 install resolves a default-index wheel over the top and silently undoes the fast path. Install the CUDA 13 stack last, 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
Confirm two things in the startup log before continuing. The torch version string should contain +cu130. And on this card the Native ops: line should list float8_e4m3fn among the native formats with nvfp4 on the emulated side — that split is Ada's compute-capability 8.9 being detected correctly, and it is described in the text-encoder note below.
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
Run these from the ComfyUI root — step 1 left you there, so the path is models, not ComfyUI/models. The repo's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four where the loaders look. Two ways to get this wrong: passing ComfyUI/models while already inside ComfyUI/ buries everything in ComfyUI/ComfyUI/models/, and passing models/diffusion_models produces models/diffusion_models/diffusion_models/…. Both leave a node that cannot see its own weights.
Pass the filenames as positional arguments, as shown. Handing several of them to --include makes everything after the first a positional argument anyway, and the CLI then discards the flag with nothing but a UserWarning — the Ignoring --include since filenames have been explicitly set branch in huggingface_hub/cli/download.py.
3. Take the NVFP4 text encoder, and ignore the "Ada has no FP4" objection
You will meet advice saying the NVFP4 text encoder wants Blackwell hardware, and on raw capability that advice is right: supports_nvfp4_compute() in comfy/model_management.py requires compute capability 10 or higher, and Ada is 8.9, so the format lands on the emulated side of your startup log.
It does not matter, because the file never asks for the accelerated path on any card. Reading its header directly: the encoder ships 351 quantisation descriptors and zero input_scale tensors, and activation scales are precisely what an FP4 matmul needs. Kijai, a Comfy-Org member, said the same thing when Ada owners asked the repack for an int4 build — that the choice is not a hardware statement, because "it's just used as storage format here, there's nothing hardware specific about that". An RTX 3060 owner in the same thread then confirmed it from the other side, reporting a working 960×544 twenty-step run with the NVFP4 encoder loaded and noting that the saving is space and nothing else.
For a 12 GB card the size argument settles it anyway. The alternative int8_convrot encoder is 27,141,342,152 B = 25.277 GiB against NVFP4's 14.610 GiB — 10.667 GiB more to stream on every generation and to stage in host RAM, on a machine that is already short of both. Take NVFP4.
The honest counterweight, from the same thread: a commenter posting as V33rGeer argues that the NVFP4 encoder "compromises the coherence of tricky setups" and that int8 is better "unless your system physically cannot handle it". That exemption is exactly your situation. If prompt adherence collapses on a complex reference setup, the encoder is a reasonable first suspect and your prompt is the second.
4. Load the official template
Open ComfyUI, go to Template Library and pick MiniMax H3 Text to Video, or drag in video_minimax_h3_t2v.json. It wires exactly the four files above. The ComfyUI tutorial documents this template plus the image-to-video and reference-to-video variants.
Running
python main.py --disable-pinned-memory
That flag is not optional on 32 GB, and this is the section to read twice.
Why the default launch kills a 32 GB machine
ComfyUI page-locks host memory to speed up transfers to the GPU. In comfy/model_management.py, MAX_PINNED_MEMORY is 90 % of system RAM on Linux (40 % on Windows), and pinned_hostbuf_size(size) returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size. For the 19.530 GiB transformer that is a request for 39.060 GiB of page-locked host memory. Pinned pages can be neither swapped nor reclaimed, so on a 32 GB box the kernel's only remaining move is to kill the process.
The first-hand version of that arithmetic comes from a 15-second RTX 3090 write-up, and it is the datapoint that actually bears on your machine because it was taken at your memory size. On a box with 31,997 MB of RAM, running the same model and the same 362 frames twice with only this flag changed: 29,866 MB of host RAM on defaults, killed by the kernel OOM-killer, against 7,508 MB with --disable-pinned-memory, completed. Same failure, same fix, and he reaches the same MAX_PINNED_MEMORY = ram * 0.90 line quoted above.
A second, larger reading exists and is one person's on very different hardware: UdonJP, on the repack's board, instrumented ComfyUI's resident set on one job at 45.4 GiB with no startup flags against 12.6 GiB with --fast-disk, on an RTX 5070 Ti he gives as having 125 GB of system RAM (discussion #6, 2026-08-06). He tested a different flag from the one in your launch line, and closed by saying he had verified none of it on a 16 GB or 32 GB machine. Take it as a sense of scale on a big box, not as your number.
What the flag costs you, and why 64 GB is still the upgrade that matters
What the flag saves is measured: 29,866 MB down to 7,508 MB of host RAM, above. 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. The 20 % figure this page carried until 2026-08-08 came from a guide its own author withdrew as unverified, so it is deleted rather than hedged. What remains is the mechanism, and the mechanism is not in doubt.
Pinning does not decide where the weights come from; it decides whether the staging buffer is page-locked. What decides where the bytes come from is whether the 42.47 GB weight set fits in page cache. At 64 GB and up it does, so the per-step streaming this card cannot avoid is served out of RAM. At 32 GB it cannot — the weight set is larger than the machine — so the same streaming is served off the SSD. That is a real cost of unknown size.
- 32 GB: workable, with the flag, on NVMe. Budget for a penalty nobody has quantified.
- 64 GB: the weight set stays cached and the question stops mattering. No 64 GB measurement has been published either, so this is the mechanism rather than a reading.
- Anything less than 32 GB: not attempted by anyone whose numbers are public.
Set against a card upgrade worth at most a fifth of the compute fraction of the run, that RAM step is still the better spend — but notice the asymmetry in what backs the two halves of that sentence. The card bound is arithmetic over NVIDIA's own published specifications. The RAM claim is a mechanism with no measurement behind it at all, and a reader who times 32 GB against 64 GB on this card would be telling us something nobody currently knows.
The drive is part of the recipe
Because the weights stream, the disk is in the inner loop rather than in the setup. How much gets re-read per generation on this tier has never been published, and the figure this page carried until 2026-08-08 came from the withdrawn guide, so it is gone. The direction follows from the arithmetic and is not in doubt: at least 8.721 GiB of the transformer is off-card at every moment of a twenty-step sampling loop, and on a 32 GB machine none of that can be served from page cache. Put the four files on NVMe, and prefer NVMe to SATA on the same reasoning — a claim about the mechanism, not a measured penalty.
One host-RAM consequence worth knowing before you size a machine, and again one person's instrumented run rather than a controlled result: sampling at one-second intervals, UdonJP found that "ComfyUI never releases the text encoder from host RAM." — his trace reads 24.1 GiB of system RAM after the encoder loads and 45.6 GiB after the transformer loads, with the encoder's VRAM copy evicted and its host copy still resident. Plan for the encoder and the transformer occupying system RAM at the same time, not one after the other.
--reserve-vram on a card that is also driving your monitors
get_free_memory() reads torch.cuda.mem_get_info(), so ComfyUI budgets against free VRAM, not the 12 GB on the box. A desktop session, a browser with hardware acceleration or a second CUDA process all spend out of the same pool first. --reserve-vram <GiB> overrides EXTRA_RESERVED_VRAM outright — the assignment sits below both platform defaults in that file — so it is the knob for leaving your display stack some room.
On a 16 GB card that same knob is a tuning lever with a ceiling, because it decides whether the text encoder becomes resident. On 12 GB there is no such trade to make: the encode stage needs 15.800 GiB and the card holds 12, so no reserve setting makes anything resident and lowering the reserve buys you nothing but a less stable desktop. Use it in the other direction only — raise it if your compositor stutters or a second application is fighting for the card. A Windows reporter on the repack's board runs --disable-pinned-memory --disable-async-offload --reserve-vram 1, which is a reasonable shape for a machine whose GPU also draws the desktop.
Set the canvas down before you change anything else
Queue the template unchanged first, and know what "unchanged" means, because the node's stored widgets disagree with what runs. The ResolutionSelector is set to 16:9 at 0.4 megapixels with a multiple of 32, and its outputs are wired into the generation node's width and height inputs — a connected input beats a stored widget, so the 1344×768 sitting in the widgets never reaches the sampler. sqrt(0.4 × 1024² / (16×9)) = 53.9695, rounded to the nearest 32 per axis, gives 864 × 480. Frame counts snap to a 17k+5 grid at 24 fps, so a 5-second request becomes 124 frames; the node's own tooltip gives the trained range as 124-362. The scheduler is simple at 20 steps and the sampler is res_multistep.
Resolution is the largest lever you control, and on this tier it is a steeper lever than pixel count alone suggests: raising the canvas raises both the attention cost and the volume that has to cross PCIe on every step, and a 12 GB card is under maximal offload pressure at every canvas. Nobody has published a scaling curve for this model on any card, so treat that as a direction rather than an exponent. Stay at 0.4 MP while you are iterating.
Output lands in ComfyUI/output/video/ as an MP4 with the stereo track already muxed in — the template's SaveVideo node carries the filename prefix video/MiniMax_H3, and get_save_image_path in folder_paths.py treats the prefix's directory component as a subfolder of the output directory.
Results
-
Speed: there is no measurement of MiniMax H3 on an RTX 4070 SUPER, anywhere. Our catalogue holds none — /check/minimax-h3/rtx-4070-super returns
verdict: unknownwith an empty benchmark list — and neither does the community. I enumerated the Comfy-Org repack's discussion board in full (37 threads, 227 messages, each thread fetched individually rather than searched) and the Turbo adapter's board in full (27 threads, 172 messages), then searched ComfyUI's and KJNodes' issue trackers: the string "4070" does not occur once in the repack's board, and every occurrence in those trackers belongs to an RTX 4070 Ti SUPER, which is a 16 GB card in a different memory regime. Nobody has posted a run on this card.What exists at this capacity is on an older architecture. On the repack's board, a commenter posting as LabMike3D reported from an RTX 3060 12GB: "RTX 3060 12GB | T2V | 1376x768 | 24 steps | 3 sec (20 min was crazy!)" — twenty minutes for three seconds, near H3's native canvas. Read that as a pessimistic bound rather than an estimate. Same capacity, same everything-streams regime, older and slower silicon, so a 4070 SUPER should land under it; by how much is exactly the quantity nobody has measured, and the section above bounds the compute half of the answer at about a fifth. That post gives the card, canvas, steps and duration but not which weight files were loaded, so it is a same-capacity datapoint rather than a same-configuration one. A stock-path timing from this card sent through /contribute would replace this entire paragraph.
-
The other thing you will find, which names your card class and is reasoning rather than measurement. A careful Japanese write-up of an RTX 5060 Ti 16GB run reports VRAM hovering around 11.7 GB during generation and concludes, under a heading that translates as "runs even on 12 GB-class GPUs", that cards like the RTX 5070 and RTX 4070 come within range — explicitly as a calculation from his own figure, which is honest of him. The conclusion happens to be right; the route to it is not one you can lean on. 11.7 GB is what a 16 GB card settles at when it has headroom, not what the job requires — the encode stage alone comes to 15.800 GiB and the denoise stage to 20.721, and a 12 GB card runs this model by streaming rather than by fitting inside 11.7 GB. Treat the article as a good 5060 Ti report and the 12 GB sentence as an inference across a boundary it does not measure.
-
The number you will find on the open web, and why it is not about your card. A release-week guide at
qwe.edu.pl, published 2026-08-04 under the byline Taylor Kim and making no claim to have run the model, is the top search result for several natural queries here. Its FAQ tells you that a 4070 with 64 GB of RAM manages "2-3 minutes vs. 9 for a comparable clip size" against the 3060. Its own comparison table, four screens earlier, labels that row "H3-Base local (4070 + 64GB)" and gives that row's configuration as ~167 s at 608×352 and 20 steps. 608×352 is about half the pixels of the 864×480 clip the 9-minute figure describes, so the page's prose has quietly turned a smaller-canvas result into a same-canvas comparison. Neither figure carries a source. Do not plan around it, and be wary of it arriving second-hand in a forum reply. -
VRAM usage: 20.721 GiB at the binding denoise stage — 19.530 GiB of int8 transformer weights plus ComfyUI's 1.191 GiB inference-reserve floor — against a 12 GiB card, so at most 10.809 GiB is resident and at least 8.721 GiB streams. That is derived from the on-disk byte counts and ComfyUI's own constants, not measured by us or by anyone on this card. The nearest readings are one tier up and are one person's: on the repack's board UdonJP reported whole-run VRAM peaks of 14,197 MiB for a 30-second 640×480 job and 14,437 MiB for 5 seconds at 1344×768 on an RTX 5070 Ti (discussion #6). Both exceed a 12 GiB card outright, which is the cleanest evidence available that this card must offload rather than fit — and that it does not simply fail is the point of the page. Live data, when it exists, will be at /check/minimax-h3/rtx-4070-super.
-
Quality notes: the model's known weakness is faces at distance, and it is a model property rather than a card one. The same RTX 3060 owner opened his thread with "Note: MiniMax heavily distorts faces on wide shots. Distortions happen regardless of input res (even at 720p, very bad). Close/medium shots look fine!", and reported the same artefacts after re-testing higher. Frame for close and medium shots. He is also candid about the audio on his own runs — prompt ignored, words hallucinated, custom audio glitching mid-generation — which is worth knowing before you design a workflow around the synchronised soundtrack.
For the full benchmark data, see /check/minimax-h3/rtx-4070-super.
Optional: SageAttention — the cheap half, and the open bug attached to the other half
Attention is a large share of sampling time, and SageAttention is the standard way to cut it. The one H3 measurement that states its card, its checkpoint and its seed puts the gain at about 1.37× on sampling — an RTX 3090 running byte-for-byte this page's template configuration, 9.00 s/it without sage against 6.57 s/it with the KJNodes generic node and 6.50 s/it with ComfyUI's own flag (ComfyUI issue #15263). That is a sampling figure, not an attention-only one, and it is on Ampere rather than Ada — no sm_89 H3 measurement exists.
On this card there is a version of that speedup you can have with a pip install and no compiler, and a better version that costs a source build. The distinction matters, because there is a live, confirmed defect in the second one and none in the first.
The pip install version works. ComfyUI's own --use-sage-attention flag imports exactly one symbol — from sageattention import sageattn in comfy/ldm/modules/attention.py — and the stock PyPI 1.0.6 wheel's __init__.py is literally from .core import sageattn, sageattn_varlen. The import succeeds. The flag then sets optimized_attention = attention_sage for the whole process, and H3's transformer is wired into that dispatch: comfy/ldm/minimax/model.py imports optimized_attention and calls it for every block's attention. So at ComfyUI v0.30.2 the global flag reaches H3's DiT on stock 1.0.6, on Ada, with nothing built.
pip install sageattention
python main.py --disable-pinned-memory --use-sage-attention
What it does not give you is Ada's FP8. Version 1.0.6 is a pure-Triton package — a 20 KB wheel with no compiled kernels — and its core.py contains no FP8 code path at all. On Ada you get its INT8-QK / FP16-PV Triton path, which is the same path an Ampere card gets. The kernels that quantise V to FP8 and use your card's FP8 tensor cores live only in SageAttention 2.x, and PyPI does not carry it: the package index lists eight releases, the newest being 1.0.6, and every distribution across all eight is py3-none-any — a pure-Python artifact with no compiled kernels for any platform, Linux included. So on Linux 2.x is a source build. woct0rdho publishes Windows wheels covering sm89, so a Windows reader can install one and stop.
The KJNodes H3 node is the other thing that needs 2.x, and it is an import mismatch rather than an architecture gate. KJNodes' MiniMaxH3MemoryEfficientSageAttentionPatch imports six symbols from sageattention.core in a single statement — per_thread_int8_triton, per_warp_int8_cuda, per_block_int8_triton, per_channel_fp8, get_cuda_arch_versions and attn_false — and 1.0.6 defines two. The import fails, the architecture probe never runs, and the node raises a "not new enough version" error. That failure is identical on Ampere, Ada and Blackwell; nothing about it is about your card.
Before you build 2.x, read this — it is the one part of this page with an open bug in it
ComfyUI issue #15263 is open, and as of 2026-08-08 its title names the defect specifically: SageAttention FP8-PV kernels producing noise above roughly 160k tokens on sm_120. Its issue body now opens with a superseding edit note from the author retracting the original root cause, so read that before the report underneath it. The history is easy to summarise wrongly in both directions, so precisely: the author filed it in early August, withdrew his explanation on 2026-08-05 after a tester ran the flag clean on an RTX 3090 — "sage isn't broken on H3, and my issue title is too strong." — and then on 2026-08-08 confirmed the defect with a better cause, agreeing "you've got it right that FP8 PV is the cause" and pinning the boundary at 151k tokens clean, 167k noise: "And it's a cliff, not a slope." The bug is real and current. The proposed one-line ComfyUI fix was closed unmerged.
It does not reach the configuration on this page, and the reason is arithmetic rather than optimism. Every failing run is at 1920×1088, which is 2,088,960 pixels against H3's own cap of MAX_PIXELS = 768 * 1344 = 1,032,192 in comfy_extras/nodes_minimax_h3.py — 2.02× over the model's limit. Using the thread's token metric, ceil(frames/4) × (W/32) × (H/32), which reproduces every row the reporter posted:
| configuration | tokens |
|---|---|
| this page's template default, 864×480 / 124 frames | 12,555 |
| the most H3 can be asked for at its own limits: 1344×768 / 362 frames | 91,728 |
| last clean sm_120 row | 150,960 |
| first noise sm_120 row | 167,280 |
I recomputed all four from the node source. The stock canvas is 8 % of the last clean row, and H3's own ceiling on any card is 61 % of it — the failure region sits above the model's supported envelope, not merely above this card's. The tester's caveat belongs here too: he notes "I don't think it's the model's literal sequence length", since video_latent_t() gives 107 temporal positions for 362 frames rather than 91. That scales every row together and changes no ratio.
Two things not to conclude from that. The mechanism is open: on 2026-08-08 the reporter ran every KJNodes mode at 186k tokens on sm_120 and "Short version is that none of them work here", and because auto and ++ share an accumulator but differ in qk_quant_gran, the tester withdrew his own FP8-PV framing — "the PV path isn't the discriminating variable" — in favour of a scale-buffer overrun. Four explanations have been offered on that thread — a missing low_precision_attention opt-out, a smooth_k difference, FP8-PV accumulation, and now a scale-buffer overrun — and their proposers have retracted the first three. And do not pin a kernel as a workaround: that was proposed and withdrawn, because on the tested architecture "there is nothing to pin there" and pinning trades noise for a crash.
So: stock 1.0.6 is not on the implicated path at all — no FP8 kernel, no architecture dispatch, the same INT8-QK/FP16-PV Triton path that was verified clean. A 2.x build puts you in the implicated family, and sm_89 has been tested by nobody, in either direction; the failures are all sm_120 and the clean runs all sm_86. That gap is the honest answer, not a reassurance.
Should you build it anyway? On this tier, genuinely "probably not first". Sage attacks the compute half of a step, and the compute half is the half your card is not short of — the same argument that deflates the SUPER-versus-4070 comparison applies here. Turn on the flag, measure your own before-and-after, and spend the afternoon on RAM and NVMe if the difference disappoints. If you do build it, TORCH_CUDA_ARCH_LIST=8.9 is this card's compute capability and --no-build-isolation is mandatory or pip pulls a second torch into the build; check your first render frame by frame, and post an sm_89 result on that issue either way.
Troubleshooting
ComfyUI is killed, or throws MemoryError, while loading the model
Host RAM, not VRAM, which is why --disable-pinned-memory is in the launch line above rather than down here. If it still dies during the model load, look for the line Enabled pinned memory in the startup log: if it is present, the flag did not take effect. Adding swap does not help by itself — pinned pages cannot be paged out — and the RTX 3090 write-up argues from its own help text that --disable-smart-memory forces aggressive offload to regular RAM and so makes this failure mode strictly worse, and says the same of --high-ram, --reserve-vram and --cache-lru.
A MemoryError raised specifically by UNETLoader has a second, duller cause: a truncated download. A user who hit it on this repack confirmed the file was the right byte size but the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.
Generation is far slower than anything on this page
Grep the startup log for a comfy_kitchen import failure and for the cu130 warning from Installation step 1. Either one silently removes the int8-convrot fast path while ComfyUI carries on running normally — one buried line, no other symptom. On a card whose whole performance story is offload, either turns a slow run into a much slower one.
Then check that the weights are actually on the NVMe drive you think they are on. With pinning off and 32 GB of RAM, the per-step streaming comes off whatever disk is holding those four files, and a spare SATA drive you forgot was in the machine is a real answer to "why is this so slow".
torch.OutOfMemoryError during sampling, on a page that says nothing OOMs
The budget above covers weights and the reserve floor. Activations sit on top of it and grow with frames and pixels, and a reference video entering at full resolution is the common way to blow past it — scale it down before it reaches the generation node. Raising the canvas or the clip length past the template defaults is the other way.
The GGUF quantisations will not load on stock ComfyUI
Pruned Q4 GGUF builds of the transformer circulate at around 10.6 GiB 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 of flux, sd1, sdxl, sd3, aura, hidream, cosmos, ltxv, hyvid, wan, lumina2 and qwen_image, with nothing for H3. Issue #471 requests support and is open. The text encoder is the exception — qwen3vl is on the same file's text-model list, so encoder GGUFs do load.
You want 2K output
You cannot get it locally today. H3-Regenerate-2K is not in the open-weights release, and the official route is to send your local 768p result to MiniMax's hosted API — a call that falls under the same territorial licence as the weights.
Nothing here matches your problem
Runtime errors belong at ComfyUI/issues, template problems at workflow_templates/issues, and attention-patch problems at ComfyUI-KJNodes/issues. And if you get a clean run on this card, a timing sent through /contribute is worth more to the next reader than every derived number on this page — a measured stock-path 864×480 run is the single most useful thing still missing here, and it would be the first one in existence.