MiniMax H3 on RTX 4070 Ti: 12 GB Ada, and the 16 GB card wearing your card's name

What You'll Build

A ComfyUI graph on one RTX 4070 Ti that turns a prompt into a 24 fps clip with its own synchronised stereo soundtrack — dialogue, effects and music denoised jointly with the picture in a single pass rather than dubbed on afterwards.

Two things shape this page. The first is that the RTX 4070 Ti is the fastest 12 GB Ada part NVIDIA made, and this is a workload where that buys much less than the spec sheet implies. The second is a naming problem with real consequences: search for H3 results on a 4070 Ti and you will find them, and every one of them is an RTX 4070 Ti SUPER, a 16 GB card that sits on the other side of the boundary that decides how this model behaves. Sorting that out is most of what this page is for.

⚠️ 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." — the video you generate is covered, not only the download.

The machine-readable license: facet on the model card is the uninformative other, so any catalogue filter or licence scanner keyed on that field misses every word of this; the restriction lives only inside the LICENSE file. Nothing downstream loosens it: the Comfy-Org repack installed below declares the same licence, community re-quantisations are Model Derivatives that inherit the terms, and an adapter's own permissive tag covers the adapter and not the base weights it patches. MiniMax publishes a licence Q&A and a per-deployment application route. This is a summary written by a reader of the text, not legal advice.

Hardware data: RTX 4070 Ti (12GB VRAM, sm_89) · at least 8.721 GiB of the transformer off-card on every sampling step · See benchmark data

ℹ️ 768p is the local ceiling on every card, this one included. H3 reaches 2K through a separate H3-Regenerate-2K module, 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 an API call back to MiniMax with your local 768p result, which puts you under their platform terms as well as the weights licence.

Requirements

Component	Minimum	This recipe
GPU	12GB VRAM	RTX 4070 Ti (12GB) — not measured by us and not measured by anyone; the reports you will find for this name are a different card, see below (/contribute)
RAM	32GB with --disable-pinned-memory; 64GB without	—
Storage	39.554 GiB of weights (42.47 GB as HuggingFace reports it), on NVMe	—
Power	NVIDIA specifies 700 W system power for this 285 W card	—
Software	ComfyUI 0.30.0+, torchaudio, PyTorch built against CUDA 13	—

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/

39.554 GiB of weights against a 12 GiB card. ComfyUI runs one module at a time, evicts it when the next one is needed, and streams whatever still does not fit across PCIe while the step executes.

The 16 GB card wearing your card's name

This section is unusual for a recipe, and it exists because the alternative is that you plan a schedule on somebody else's hardware.

I enumerated every surface where H3 hardware reports live: the Comfy-Org repack's discussion board in full (37 threads, 227 messages, each thread fetched individually rather than searched), the Turbo adapter's board in full (27 threads, 172 messages), and the ComfyUI and KJNodes issue trackers. The string "4070" does not appear once in the repack's board. Everywhere else it appears, it belongs to an RTX 4070 Ti SUPER with 16 GB:

• On the Turbo adapter's board, in a thread about converting that LoRA to ComfyUI's format, a commenter posting as Evados reports an 8-step run at 1280×720 finishing at 47.03 s/it and gives his machine as "On a RTX 4070ti super 16 gb vram and 32gb ram." He closes with "Don't work with the pruned model." — read in its thread, that is his converted adapter failing against the pruned checkpoint, not a verdict on the checkpoint itself.
• A second Turbo reporter, kangklx, opens a thread about quality degradation from that same LoRA on pruned INT8 convrot — so the pruned weights plainly load for him — and states "My current hardware is an RTX 4070 Ti SUPER 16GB with 32GB of system RAM."
• In ComfyUI's tracker, the author of PR #15324 validates a torch.compile fix by reporting that a "MiniMax H3 pruned INT8 workflow completed twice on an RTX 4070 Ti SUPER" — no LoRA involved, and a warm run of 40.49 seconds.
• PR #15316, a fix for the image-to-video encoder stalling, gives its test environment as an RTX 4070 Ti S with 16 GB and 96 GB of system RAM.

Line those up and the trap is visible. Four reports, one card name, four different configurations — a converted LoRA, that LoRA on pruned weights, a plain pruned INT8 graph under torch.compile, an image-to-video graph with dynamic VRAM switched off — and timings between 40 seconds and six minutes that mean nothing to each other. Treating them as one picture of "the 4070 Ti" would be wrong even if the card matched. It does not match, and that is the deeper problem: 16 GB and 12 GB are not neighbouring points on a curve here, they are on opposite sides of a threshold.

Why 16 GB is a different machine, not a faster one

From the byte counts above and the constants in comfy/model_management.py at tag v0.30.2. minimum_inference_memory() is 0.8 GiB plus EXTRA_RESERVED_VRAM, 400 MiB on Linux, so the reserve floor is 1.191 GiB.

Stage	Resident weights	Reserve	Stage total	On 12 GiB (this card)	On 16 GiB (the SUPER)
Text encode (Qwen3-VL-32B, NVFP4-AWQ)	14.610 GiB	1.191 GiB	15.800 GiB	short by 3.800 GiB	clears by 0.200 GiB
Denoise (H3 DiT, pruned int8+convrot)	19.530 GiB	1.191 GiB	20.721 GiB	short by 8.721 GiB	short by 4.721 GiB
Decode (video VAE fp16)	4.850 GiB	1.455 GiB	6.305 GiB	clears by 5.695 GiB	clears by 9.695 GiB

The encode row is the threshold. On a 16 GB card it clears by 200 MiB — a knife-edge, but a real one, and one reporter's second-by-second trace of an RTX 5070 Ti run shows VRAM settling at 15,219 MiB at 100 % utilisation while the text encoder runs, within 259 MiB of the encoder's staged size (UdonJP, discussion #6). That is one machine, not a controlled result, but it lands where the arithmetic says it should: on that card, one of the two large modules genuinely becomes resident. On yours it cannot: 15.800 GiB does not go into 12, and no launch flag changes that. Every stage of your run streams; on the 16 GB card one of them does not. A number carried across that line is not a conservative estimate, it is a different regime.

On Windows the reserve is 600 MiB rather than 400, so the floor is 1.386 GiB and every shortfall above grows by 0.195 GiB. That is not the 1.484 GiB figure this site's 16 GB and 24 GB pages quote: the extra 100 MiB term sits inside the if WINDOWS: branch and behind a total_vram > 15 * 1024 test, and 12 GB fails the second test. On a 16 GB Windows box the encode stage comes to 16.093 GiB and the knife-edge above flips to a miss — one more way that card is not yours.

MIN_WEIGHT_MEMORY_RATIO is reset to 0.0 on NVIDIA, so your resident weight budget is free VRAM minus the floor: at most 10.809 GiB, less once the desktop has taken its share. The transformer is 19.530 GiB and the model card describes it as a dense single-stream transformer, so every sampling step touches every weight and at least 8.721 GiB has to cross PCIe on each one.

What the Ti's silicon buys against that

NVIDIA's own RTX 4070 family specifications put the 12 GB parts side by side:

	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
Base clock (GHz)	1.92	1.98	2.31
Standard memory config	12 GB GDDR6 / 12 GB GDDR6X	12 GB GDDR6X	12 GB GDDR6X
Memory interface width	192-bit	192-bit	192-bit
Total graphics power (W)	200	220	285

The Ti leads the trio on every compute row — 12.9 % more AI TOPS than the SUPER, 37.6 % more than the plain 4070 — and is level with both on every memory row. It also draws 285 W against the SUPER's 220 W for that 12.9 %, which is the shape of a part pushed to the top of its bin.

Three limits on what to expect from it:

1. NVIDIA publishes no memory bandwidth figure for any of these cards. There is no such row on that page. Interface width and memory type are published; memory clock is not. So this page states that the three cards' on-card memory is the same shape and declines to assert a percentage, because asserting one would mean inventing a clock. (The plain 4070 is not even a single configuration — NVIDIA lists it as 12 GB GDDR6 / 12 GB GDDR6X. The SUPER and the Ti are GDDR6X only.)
2. The compute rows only touch the compute fraction of a step. With 8.721 GiB arriving over PCIe Gen 4 on every step, part of that step is transfer, and no amount of shader is a transfer. Nobody has published a transfer-versus-compute decomposition of an H3 step on any 12 GB card.
3. What is on-card is not all matmul either. The one estimate of attention's share of sampling — "roughly 55% of sampling at 480p/5s, considerably more at 720p or 15s" — comes from a commenter on ComfyUI issue #15263, offered in passing rather than tabulated, and was measured on a 24 GB card that is not streaming. Treat it as an order of magnitude, not a coefficient.

The honest verdict, stated plainly: the RTX 4070 Ti is the strongest 12 GB Ada card, its advantage over the 4070 SUPER is at most about a tenth of the compute portion of a run, no published measurement separates the two on this model, and the difference is very likely below the noise of anything anyone has posted. If you own one, run it. If you are choosing between the three 12 GB Ada cards for H3 specifically, choose on price and on how much system RAM the saving buys you.

Installation

1. Update ComfyUI onto a CUDA 13 PyTorch

H3's nodes ship in ComfyUI core (comfy_extras/nodes_minimax_h3.py) from release 0.30.0 onward, not as a custom node. That module imports torchaudio at load time; requirements.txt covers it, but a hand-built environment with only torch and torchvision fails at startup.

The CUDA gate is in ComfyUI's source, not folklore: comfy/quant_ops.py parses torch.version.cuda, and below major 13 it calls ck.registry.disable("cuda") and logs a warning. That call switches off the comfy-kitchen CUDA backend, which is what accelerates the int8_tensorwise+convrot format the transformer ships in. Nothing raises. Everything is slower.

Install the CUDA 13 stack last. requirements.txt lists torch unpinned, so running it afterwards resolves a default-index wheel over the top and silently undoes the fast path.

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

In the startup log, confirm +cu130 in the torch version and check the Native ops: line: on compute capability 8.9 you should see float8_e4m3fn among the native formats and nvfp4 on the emulated side. That split is supports_fp8_compute() returning True and supports_nvfp4_compute() returning False, both from comfy/model_management.py, and it is the one genuine architectural difference between this card and a same-capacity Ampere one. What it is worth here is the subject of a section below.

2. Download the four files

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 destination is models, not ComfyUI/models; passing the latter from inside ComfyUI/ buries the 42 GB in ComfyUI/ComfyUI/models/. The repo's paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four where the loaders look. Pass the filenames positionally as shown — hand several of them to --include and everything after the first becomes a positional argument anyway, at which point the CLI discards the flag with nothing but a UserWarning, in the Ignoring --include since filenames have been explicitly set branch of huggingface_hub/cli/download.py.

Take the pruned transformer. The unpruned int8_convrot file is 31.701 GiB, which is 12.171 GiB more to stream on a card that is already streaming everything.

Then verify the hashes before you troubleshoot anything. A MemoryError out of UNETLoader on this repack has already turned out to be a size-matching but hash-mismatched download; re-hashing a 21 GB file is cheaper than re-diagnosing it.

3. The text encoder, and the FP4 objection that does not apply

Take qwen3vl_32b_minimax_h3_nvfp4_awq. You will read that NVFP4 wants Blackwell, and at the hardware level that is true — supports_nvfp4_compute() requires compute capability 10 and Ada is 8.9, so the format lands on your log's emulated side. It changes nothing, because the file never requests the accelerated path on any card, Blackwell included. Reading its header directly: 351 quantisation descriptors and zero input_scale tensors, and activation scales are exactly what an FP4 matmul needs. A Comfy-Org member put the same point to Ada owners asking for an int4 build: "it's just used as storage format here, there's nothing hardware specific about that".

The alternative int8_convrot encoder is 25.277 GiB against 14.610 GiB — 10.667 GiB more to move on every generation and to stage in host RAM. On 12 GB that settles it. The counter-argument in the same thread is a quality one, from a commenter posting as V33rGeer, who says the NVFP4 encoder "compromises the coherence of tricky setups" and prefers int8 "unless your system physically cannot handle it". Yours cannot; treat the encoder as the first suspect if adherence collapses on a complex reference setup.

4. Load the official template

Template Library → MiniMax H3 Text to Video, or drag in video_minimax_h3_t2v.json. The ComfyUI tutorial documents it along with the image-to-video and reference-to-video variants.

Running

python main.py --disable-pinned-memory

The flag is a prerequisite, not a tuning option, unless you have 64 GB. MAX_PINNED_MEMORY is 90 % of system RAM on Linux and 40 % on Windows, and pinned_hostbuf_size(size) returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size, so the 19.530 GiB transformer asks for 39.060 GiB of page-locked host memory. Pinned pages cannot be swapped or reclaimed, so a 32 GB machine meets the OOM killer rather than an error message. A 15-second RTX 3090 write-up is the first-hand version of that arithmetic, on a 31,997 MB box and with only this flag changed between two runs of the same 362-frame job: 29,866 MB of host RAM on defaults, killed by the kernel OOM-killer, against 7,508 MB with the flag, completed. Different card, same RAM class as yours, and it reaches the same MAX_PINNED_MEMORY line.

What the flag costs in time is unmeasured, and the reason is structural. Nobody has published a completed run on both sides of it — the unflagged run in that write-up died, which is the whole point of the flag. The 20 % figure this page carried until 2026-08-08 came from a guide its own author has since withdrawn as unverified, so it is deleted rather than hedged. The mechanism survives and is the part you can act on: page-locking decides whether the staging buffer is pinned, not where the weights come from, and what decides that is whether the 42.47 GB weight set fits in page cache. At 64 GB and up it does, so the streaming this card cannot avoid is served out of RAM; at 32 GB it cannot, so the same streaming comes off the SSD. Pass the flag regardless — the alternative is a killed process — and put the weights on NVMe.

Set the canvas, and know what the template actually runs

Queue the template unchanged first — and note that its stored widgets disagree with what executes. The ResolutionSelector is set to 16:9 at 0.4 megapixels, multiple 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 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. Frames snap to a 17k+5 grid at 24 fps, so a 5-second request becomes 124; the tooltip gives the trained range as 124-362. The scheduler is simple at 20 steps, the sampler res_multistep. To reach H3's native 1344×768, set the selector to 0.98 MP — and expect the clock rather than the VRAM peak to absorb it, since offload pressure grows with token count and a 12 GB card is already at maximum offload pressure. How steeply time grows with canvas has not been published for this model on any card, so treat that as a direction rather than a curve.

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.

If the image-to-video graph stalls before sampling

Not a fault of your card, and worth knowing before you blame it. In PR #15316 a contributor traces a minute-plus hang at the MiniMax H3 Image to Video node to the loader budgeting for the text-encoder weights but not for encoding the images, so the encode then exceeds the VRAM budget it was given. His stopgap is --reserve-vram 2.5, which raises EXTRA_RESERVED_VRAM — the assignment sits below both platform defaults in model_management.py, so the flag overrides them outright. That was diagnosed on a 16 GB card with 96 GB of RAM, so treat the mechanism as transferable and the specific value as a starting point; on 12 GB you are giving up headroom you have less of.

What Ada's FP8 does here, and the honest gap

supports_fp8_compute() returns True at compute capability 8.9 and False on Ampere's 8.6. That is a real, checkable difference between this card and an RTX 3060 with the same 12 GB. It is also mostly inert for the files above, and the exceptions are worth stating precisely.

Inert for the recommended weights. The transformer is int8_tensorwise with convrot, and that path is not architecture-gated on any NVIDIA card — it is gated on the comfy-kitchen backend from installation step 1. The text encoder declines its own quantised path everywhere, as the zero input_scale count above shows. So on the four files this page installs, your FP8 silicon does nothing.

One alternative file where it genuinely fires, and nobody has measured it. The repack also ships minimax_h3_fl2va_pruned_fp8_scaled.safetensors at 20,958,205,608 B = 19.519 GiB — within 12 MiB of the int8 file, so it is a like-for-like swap on memory. I read its header directly: 200 quantisation descriptors, 200 weight_scale tensors and 150 input_scale tensors. Those 150 layers carry the activation scale an FP8 tensor-core matmul needs and no full-precision opt-out, so on sm_89 they take the native path; on Ampere the same layers are forced back to full precision.

Whether that is worth anything on a card that streams the transformer regardless is an open question, and this page is not going to answer it by assertion. The mechanism is real and specific to Ada. The context is that the per-step cost here is part transfer and part compute, and a swap that changes only the compute half of a step by an unmeasured amount, on a file that is the same size, is exactly the kind of thing that disappears into the noise — or does not. Nobody has published the comparison on any card. This page keeps int8_convrot as the lead because it is what the official template references and what every published report used. If you run both on this card, that comparison would be new information and /contribute is where it belongs.

SageAttention on sm_89: which half you can have for free

Attention is the part of sampling your extra shaders can actually reach, so this is where a 4070 Ti has the best case in the whole recipe. It is also the part with the most confused advice on the internet, and the confusion has a specific shape: two different things are both called "sage", they have different requirements, and there is a live, confirmed defect in one of them that does not reach the configuration this page documents. Sorting out which is which is worth the five minutes, because the wrong summary of it is circulating in both directions.

The CLI flag works on the stock PyPI wheel. ComfyUI's --use-sage-attention imports exactly one symbol — from sageattention import sageattn in comfy/ldm/modules/attention.py — and version 1.0.6, the newest on PyPI, exposes it: its __init__.py is from .core import sageattn, sageattn_varlen. The flag then sets optimized_attention = attention_sage process-wide, and H3's transformer is wired into that dispatch — comfy/ldm/minimax/model.py imports optimized_attention and calls it for every block. So at v0.30.2 the flag reaches H3's DiT with a plain pip install sageattention and no compiler.

pip install sageattention
python main.py --disable-pinned-memory --use-sage-attention

The KJNodes H3 patch is the thing that needs 2.x, and its requirement is an import, not an architecture. MiniMaxH3MemoryEfficientSageAttentionPatch imports six symbols from sageattention.core in one 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 identically on Ampere, Ada and Blackwell. For 2.x: woct0rdho ships Windows wheels whose supported list includes sm89, so Windows readers install one; on Linux you build from source, and the reason is checkable in one request — PyPI's own release map lists eight releases topping out at 1.0.6, and every distribution across all eight is py3-none-any, so there are no compiled kernels on that index to install on any platform.

pip install ninja packaging
CUDA_HOME=/usr/local/cuda-13.2 PATH=/usr/local/cuda-13.2/bin:$PATH \
TORCH_CUDA_ARCH_LIST=8.9 MAX_JOBS=8 \
pip install --no-build-isolation "git+https://github.com/thu-ml/SageAttention.git"

--no-build-isolation is mandatory or pip pulls a second torch into the build. 8.9 is this card's compute capability and restricting the list cuts build time sharply. Point CUDA_HOME at your own toolkit; 13.2 is an example.

The live defect, stated accurately — ComfyUI issue #15263

This issue 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. The issue body now opens with a superseding edit note in which the author retracts the original root cause and points at the FP8-PV kernel instead, with the original report left below it for history — so if you land on that page and read top-down, the first thing you meet is a correction rather than the claim it corrects. If you find a summary saying the report was withdrawn, that summary is reading one event and missing the next one. Two separate things happened:

• On 2026-08-05 the author withdrew his explanation, not his bug. He had filed it as a missing low_precision_attention=False opt-out, and a pull request implementing exactly that followed — its author arguing that "H3's partial split-half RoPE creates channel-wise magnitude outliers that corrupt INT8 quantization." That PR was closed unmerged about two hours after it opened, on the reporter's own advice: an independent tester had run both the KJNodes node and the core flag on an RTX 3090 against a fixed seed and reported "So the noise doesn't reproduce on Ampere.", and the reporter conceded "sage isn't broken on H3, and my issue title is too strong."
• On 2026-08-08 he confirmed the defect and a better cause. After a Blackwell owner posted a clean run at the same settings using an FP16-PV kernel, the tester sorted every datapoint in the thread by PV path rather than by GPU — "Every noise report is FP8 PV." — and the original reporter agreed: "you've got it right that FP8 PV is the cause". He then tightened the boundary to 151k tokens clean and 167k noise, adding "And it's a cliff, not a slope."

So the bug is real, it is current, and it is being actively narrowed. What it is not is reachable from this page.

Why it does not reach a 12 GB card running H3 in its trained envelope

Every failing run in that thread is at 1920×1088. H3's own node module caps the canvas: MAX_PIXELS = 768 * 1344 in comfy_extras/nodes_minimax_h3.py, which is 1,032,192 pixels — 1920×1088 is 2,088,960, i.e. 2.02× over the model's cap. The thread's own token metric, ceil(frames/4) × (W/32) × (H/32), reproduces all five of the reporter's rows exactly, and it also bounds what you can reach:

configuration	tokens	vs the 151k clean row
this page's template default, 864×480 / 124 frames	12,555	8 %
H3's own ceiling: 1344×768 at 362 frames, the top of the trained range	91,728	61 %
last clean sm_120 row (1920×1088 / 294 f)	150,960	—
first noise sm_120 row (1920×1088 / 328 f)	167,280	—

I recomputed all four from nodes_minimax_h3.py rather than copying them. The most tokens H3 can be asked for inside its supported envelope, on any card, is 91,728 — 61 % of the last configuration that ran clean. The failure region is above the model's own ceiling, not merely above yours. The tester makes the same argument to close out the Ampere half of the thread, and one caveat of his belongs here too: he notes "I don't think it's the model's literal sequence length", since video_latent_t() returns 107 temporal positions for 362 frames rather than 91, which would scale every row up together. It moves the absolute numbers, not the ratios.

The mechanism is open, so do not act as though it is settled

Four explanations have been offered on that thread and their proposers have retracted the first three — the missing low_precision_attention opt-out, a smooth_k difference, and then the FP8-PV framing itself. On 2026-08-08 the reporter ran every KJNodes mode at 186k tokens on sm_120 with a fixed seed and identical settings: "Short version is that none of them work here" — auto completes as noise, fp8_cuda++ crashed, and both the fp32+fp32 and FP16-Triton modes gave a clean first step then an illegal address. He also observed that auto and ++ share pv_accum_dtype="fp32+fp16" and differ only in qk_quant_gran, which prompted the tester to withdraw his own conclusion: if behaviour changes with the granularity parameter while the accumulator is held constant, then "the PV path isn't the discriminating variable", and a scale-buffer overrun fits the evidence better — including a reported frame that was half clean and half noise with a sharp boundary, which accumulation error does not produce.

The practical instruction that falls out of this: do not pin a kernel. That was the obvious workaround and it was withdrawn — on sm_120 "there is nothing to pin there", because the FP16 modes abort or corrupt memory, so pinning would trade noise for a crash. The thread's conclusion is that any real fix has to be architecture-aware.

What that means for your card, including the part nobody knows

• Stock 1.0.6 + the CLI flag is not on the implicated path at all. The 1.0.6 wheel is pure Triton with no FP8 kernel on any architecture — I checked the wheel's core.py and it contains zero FP8 code, and the tester states the same from the source. It has no architecture dispatch either, so an sm_89 card runs the same INT8-QK / FP16-PV path an sm_86 card does. That is the path verified clean against a fixed seed. Start here, and it is a pip install.
• A 2.x build puts you in the implicated kernel family, and sm_89 has been tested by nobody. Every noise and crash report is sm_120; the only measured-clean H3 datapoints are sm_86. There is no sm_89 result in either direction, and that gap is the honest answer rather than a reassurance. What is on your side is the arithmetic above: you cannot reach the token counts where anything has failed. What is not on your side is that the mechanism is unresolved, so "below the crossover" is a statement about the observed boundary and not about a cause anyone has isolated.
• One further, weaker signal, and it needs its qualifier: every sm_120 noise report that states a checkpoint names bf16, not the int8_convrot file this page installs. The second sm_120 reporter states no checkpoint at all, and his run being a noise datapoint is the tester's inference from context rather than something he wrote. Treat it as one more reason not to panic, not as evidence.

If you do build 2.x, check your first render frame by frame instead of assuming, and if you get either a clean or a broken result on sm_89, that thread wants it — it is the one architecture nobody has data for.

One last thing worth knowing if you do build it: no published comparison ranks the H3-specific KJNodes node against the generic path. The figures that do exist are the RTX 3090 run above, which used byte-for-byte this page's template configuration — "864×480, 124 frames, 20 steps", res_multistep/simple, fixed seed — and measured 9.00 s/it without sage against 6.57 s/it with the KJNodes generic node and 6.50 s/it with the core flag, about 1.37× either way. Those two are within a per cent of each other on one machine, which ranks nothing, and neither of them is the H3-specific node. What that node buys is a code-path property rather than a speed one: it replaces attn.forward outright instead of traversing the shared dispatch.

Results

• Speed: no measurement of MiniMax H3 on an RTX 4070 Ti has been published. Our catalogue has none — /check/minimax-h3/rtx-4070-ti returns verdict: unknown with an empty benchmark list — and the enumeration at the top of this page found none in the community either. Do not substitute the 4070 Ti SUPER figures for it; 16 GB puts the text encoder on the card and your 12 GB does not, so those runs are not a slower or faster version of yours, they are a different one.

  The one same-capacity, same-regime datapoint is on an older architecture: an RTX 3060 12GB owner reported twenty minutes for a 3-second clip at 1376×768 and 24 steps in discussion #30 on the repack's board, and 4.5 minutes for 5 seconds at 864×480 using an 8-step Turbo LoRA plus an experimental VAE. Those are the closest published bounds. Read them as pessimistic — same capacity, same everything-streams behaviour, older silicon — and note that the section above bounds by how much this card can beat them: the compute half of a step, and no more. Neither post states which weight files were loaded. A stock-path timing from this card sent through /contribute would be the first that exists.

• VRAM usage: 20.721 GiB at the binding denoise stage — 19.530 GiB of transformer weights plus ComfyUI's 1.191 GiB reserve floor — against 12 GiB, so at most 10.809 GiB is resident and at least 8.721 GiB streams on every step. Derived from on-disk byte counts and ComfyUI's own constants, not measured on this card by anyone. The nearest readings are one tier up and belong to a single reporter: UdonJP, posting an instrumented RTX 5070 Ti run in discussion #6, logged 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. Both exceed 12 GiB outright, which is the plainest evidence that this card offloads rather than fits — and does not fail. Live data, when it exists, will be at /check/minimax-h3/rtx-4070-ti.

• Quality notes: H3's known weakness is faces at distance, and it is a property of the model rather than of the card, so neither the Ti's clocks nor a bigger canvas buys you out of it — the 12 GB reporter above found the distortion persisted at 720p and that close and medium shots were fine. EasyCache is the largest step-count lever and the published opinion on its quality is not in its favour: a commenter in that same discussion #30 says it degrades the final result, and the measured comparison this page used to set against that came from a source withdrawn by its own author on 2026-08-08, so it is gone rather than hedged. Nobody has published a controlled EasyCache A/B on any card. Run one on your own prompts before leaving it on.

For the full benchmark data, see /check/minimax-h3/rtx-4070-ti.

Troubleshooting

ComfyUI is killed, or dies on host memory rather than VRAM

This is the commonest way an H3 run ends on a 12 GB card, which is why --disable-pinned-memory is in the launch line rather than here. If it still dies during the model load, look for Enabled pinned memory in the startup log — if that line is present, the flag did not take effect. Swap does not rescue it, because pinned pages cannot be paged out — the RTX 3090 write-up makes the same point from its own failed run. --fast-disk attacks the same problem from the other end, by moving weights into reclaimable page cache rather than anonymous memory; nobody has published a run that varies both flags, so whether it is worth adding on top of --disable-pinned-memory is untested. --lowvram is not an answer either; its own help text says it does nothing when dynamic VRAM is enabled.

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 silently removes the int8-convrot fast path while ComfyUI carries on normally, and on a card whose story is offload, either turns a slow run into a much slower one. While you are in that log, confirm float8_e4m3fn is on the native side of the Native ops: line — if it is not, supports_fp8_compute() did not recognise an Ada device and your torch build is wrong.

torch.OutOfMemoryError during sampling

The 20.721 GiB budget above covers weights and the reserve floor only; activations sit on top and grow with frames and pixels. The usual causes are a reference video entering at full resolution — scale it before the generation node — and a canvas or clip length raised past the template defaults.

Output is pure noise after enabling SageAttention

There is a real, open bug with this shape — ComfyUI #15263, confirmed by its reporter on 2026-08-08 — but every reported instance is on sm_120 with 2.x FP8-PV kernels above roughly 160k tokens, and the stock template configuration on this card is 12,555 tokens. Read the SageAttention section above for why the arithmetic keeps you clear of it.

Two things that entry must not be read as saying. On sm_89 there is no H3 result either way: the clean fixed-seed verification of the core flag and the KJNodes generic node is on an RTX 3090, which is sm_86, and the failures are all sm_120. And the mechanism is unresolved — the FP8-PV explanation has since been questioned by the person who proposed it.

Practically: if you are on stock 1.0.6 you are not on the implicated path, so look elsewhere first — a comfy_kitchen import failure, a below-cu130 torch, or a bad download. If you built 2.x and then saw noise, drop back to 1.0.6 and the core flag to isolate it. Do not try to pin a specific kernel as a workaround — that was proposed on the thread and withdrawn, because the FP16 modes abort or corrupt memory on the architecture where it was tested. Post what you find on that issue; sm_89 is the gap in it.

You have a second GPU in the machine

Dynamic VRAM streaming has an open multi-GPU failure in which HostBuffer.read_file_slice failed cascades into a spurious CUDA out-of-memory, filed as ComfyUI issue #15255. The maintainers' workaround is to restrict ComfyUI to one GPU with --cuda-device 0, or to use --disable-pinned-memory — which is already your launch line.

You want 2K output

Not available locally. H3-Regenerate-2K is not part of 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 the single most valuable thing you can give the next reader — it would be the first RTX 4070 Ti measurement of MiniMax H3 in existence, and it would end the name confusion this page had to spend a section on.