What You'll Build
A ComfyUI graph on one RTX 5070 Ti that turns a prompt into a 24 fps clip with its own synchronised stereo soundtrack — dialogue, effects and score denoised jointly with the picture in a single pass.
This page is unusual in the family, and it is worth saying why up front. Its whole argument is arithmetic, and the arithmetic is unusually sharp here: at 16 GiB exactly one of H3's two large modules can be resident, and it is the text encoder, by a margin of 0.200 GiB. The transformer is capped and streamed, and that is not a failure mode — it is how this tier works. What this page cannot give you is a timing. The 16 GB coverage of H3 was, almost in its entirety, one person's write-up of runs on this exact card, and its author has since withdrawn it, replacing it with a notice saying its content cannot be vouched for. What survives him is a dated forum post in which he stated some of his own readings at the time; it is cited below, by name, where it corroborates something. Everything load-bearing on this page comes from ComfyUI's source and the files' own byte counts instead — which is where the 24 GB and 32 GB pages in this family have always got their budgets, and it turns out to be enough.
⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement restricts you by territory: it 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."
That clause has teeth in practice, not just on paper. The author of the independent RTX 5060 Ti review cited under Results took their own English-language write-up down and made the accompanying video unlisted, on the reading that publishing H3 output from an excluded territory is not permitted — a working illustration of what "Outputs" means before anyone sends you a letter. Note also that the machine-readable
license:facet on both cards is the uninformativeother, so any catalogue filter keyed on that field misses all of this. The Comfy-Org repack installed below relicenses nothing — it declares the samelicense_nameand links back to the same file — and neither does a community re-quantisation or a LoRA. 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 5070 Ti (16GB VRAM, sm_120) · 14.610 GiB encoder resident, 19.530 GiB transformer streamed · See benchmark data
ℹ️ 768p is the local ceiling. H3 reaches 2K through a separate
H3-Regenerate-2Kstage, 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, which puts you under their platform terms on top of the weights licence. What runs on your card is H3-Base, of which the same card's spec table says: "The shorter side is set to 768 pixels by default."
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 12GB VRAM via ComfyUI's dynamic VRAM offload | RTX 5070 Ti (16GB) — not measured by us, and no published timing for this card survives; the budget below is arithmetic over file bytes and ComfyUI's own constants (/contribute) |
| RAM | 32GB with --disable-pinned-memory, 64GB to be comfortable | — the flag is mandatory below 64GB; what it costs you in speed is unmeasured. See Running |
| Storage | 42.47 GB of weights | 42.47 GB across four files (byte counts from the HuggingFace tree API) |
| Software | ComfyUI 0.30.0+, PyTorch built against CUDA 13 | — |
The four files the official text-to-video template loads, byte-exact from the Comfy-Org repack:
| 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/ |
Why this page's min_vram_gb is 12 and not 16: that field is a filter floor — the smallest capacity on which the install documented below actually runs — and not a statement about this card. Comfy-Org put the floor at an RTX 3060 in their launch post, writing of the same compressed four-file set: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060." What 16 GB buys over that floor is narrow and specific, and it is the subject of the next section: it is the capacity at which the text encoder stops streaming.
16 GiB is the tier where the two big modules disagree
On a 24 GB card the denoise pass fits and the text encoder fits. On a 12 GB card neither fits. 16 GiB is the only consumer tier where exactly one of them does, and that single fact reorganises everything below it.
text encoder 15,687,142,551 B = 14.610 GiB + 1.191 GiB reserve = 15.800 GiB → clears 16 GiB by 0.200
DiT 20,970,379,616 B = 19.530 GiB + 1.191 GiB reserve = 20.721 GiB → short of 16 GiB by 4.721
The 1.191 GiB is not a rule of thumb. minimum_inference_memory() in comfy/model_management.py returns 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux — 1.190625 GiB, printed above rounded.
Read that 0.200 GiB as thin, not as headroom, for two independent reasons.
First, the reserve is bigger on Windows and the verdict flips with it. EXTRA_RESERVED_VRAM becomes 600 MiB there, and a further 100 MiB is added once the card reports more than 15 GiB — a threshold your card is on the wrong side of. Check the indentation yourself rather than taking my word for it: the extra 100 MiB sits inside the if WINDOWS: block, so it is a Windows-only surcharge and not a general large-card one. That lifts the floor to 1.484 GiB, and the text-encode stage to 16.093 GiB — over a 16 GiB card by 0.093 GiB, before anything else has asked for a byte. The denoise stage moves too, to 21.014 GiB, but it was already streaming and nothing changes there.
Second, and more practically: the comparison is not against your card's capacity. The budget ComfyUI computes is against free VRAM. get_free_memory() in the same file reads torch.cuda.mem_get_info(dev), which reports what is actually unallocated at that instant — so a desktop session, a browser with hardware acceleration on, or a second CUDA process all spend directly out of that 0.200 GiB. A card is never fully free either; the driver and the CUDA context take their cut before ComfyUI starts. A 16 GB card running a desktop does not have 0.200 GiB of margin at the text-encode stage, and possibly does not have any. ComfyUI exposes a flag for spending that margin deliberately rather than by accident — see Running, where the exact budget is worked out.
The reassuring half is that losing the margin is not a cliff. The weight budget for a stage is
lowvram_model_memory = max(0, free_vram − max(inference_floor, requested + extra_reserved))
and on NVIDIA the alternative floor term in that expression is switched off outright — MIN_WEIGHT_MEMORY_RATIO is 0.4 by default and reset to 0.0 under if is_nvidia(). So when free memory drops, ComfyUI does not fail: it keeps proportionally fewer weights resident and streams the remainder over PCIe, converting the shortfall into wall-clock time. That is the same mechanism that lets the 19.530 GiB transformer run here at all. You lose minutes, not the render.
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, from v0.30.0 onward. That module imports torchaudio at load time, so a hand-built environment carrying only torch and torchvision fails at startup.
The CUDA version is a hard gate in ComfyUI's own source, not folklore. comfy/quant_ops.py parses torch.version.cuda, and below 13 it calls ck.registry.disable("cuda") and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." That one call removes the comfy-kitchen CUDA backend, which is what provides the accelerated kernels for the int8-convrot weights you are about to download. Nothing errors; everything is just 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
Before going further, confirm two lines in the startup log: the torch version must contain +cu130, and comfy-kitchen's CUDA backend must report 'available': True. If it reports a failed import instead, ComfyUI carries on running normally with the fast path dead — one buried error line and no other symptom.
2. Download the four model files
Run these from the ComfyUI root, and pass the filenames as positional arguments. Handing several of them to --include makes everything after the first positional anyway and drops the flag, with only a UserWarning to say so.
pip install -U "huggingface_hub[cli]"
hf download Comfy-Org/MiniMax-H3 \
diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
vae/minimax_h3_video_vae_fp16.safetensors \
vae/minimax_h3_audio_vae_fp32.safetensors \
--local-dir models
The repo's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four where the loaders look.
Take the nvfp4 text encoder on this card, and take it for its size rather than its name. The alternative in the repack, qwen3vl_32b_minimax_h3_int8_convrot.safetensors, is 27,141,342,152 B = 25.277 GiB — 10.667 GiB more to stream on a card that is already streaming a transformer. There is a real quality argument for the int8 encoder, made repeatedly in discussion #16 by people who have run both, and it carries an explicit exemption for systems that physically cannot handle it. At 16 GiB you are that exemption. If prompt adherence fails on a complex reference setup, swapping the encoder is the first thing to try — and it will cost you time, not an error.
3. SageAttention 2.x — buildable here, and the only accelerator with any H3 measurement behind it
This is the step where a 3090-era page will mislead you, and it is the only accelerator on this page with any measured H3 result behind it anywhere — though, as Results says, not one on this card. pip install sageattention gets you 1.0.6, which is the newest release on PyPI — the package index lists nothing above the 1.x line at all. That is the wrong kernel generation for sm_120, and the H3-specific KJNodes patch refuses to load against it rather than running slowly: "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." That is KJNodes issue #721, filed from an RTX 5060 Ti — the same compute capability 12.x as this card — where the maintainer's reply is "As the error says, you need newer version of sageattention."
The mechanism is visible in the node pack. nodes/ltxv_nodes.py imports get_cuda_arch_versions and per_warp_int8_cuda from sageattention.core; 1.0.6 has neither, the arch probe returns None, and the patch raises on that. Install a 2.x build and a dedicated sm120/sm121 branch opens up: it quantises Q and K per warp on CUDA and dispatches into the _qattn_sm89 kernels — the Ada kernels, reused on Blackwell — with a faster accumulator path gated on CUDA ≥ 12.8, which cu130 also satisfies.
On Linux there is no wheel to install. The fork that publishes 2.x builds ships Windows only — every asset across its releases is a …-cp3**-abi3-win_amd64.whl — and PyPI, as above, carries nothing over the 1.x line. Build it for this architecture:
pip install ninja packaging
CUDA_HOME=/usr/local/cuda-13.2 PATH=/usr/local/cuda-13.2/bin:$PATH \
TORCH_CUDA_ARCH_LIST=12.0 MAX_JOBS=8 \
pip install --no-build-isolation "git+https://github.com/thu-ml/SageAttention.git"
--no-build-isolation is mandatory — without it pip pulls a second torch into the build and wrecks the environment. TORCH_CUDA_ARCH_LIST=12.0 is this card's arch and cuts build time sharply.
One expected non-error, worth knowing before you chase it: on sm_120 a direct from sageattention.core import _qattn_sm89 can fail while the node pack works anyway. That is by design rather than luck — _resolve_qattn(arch) in the same file tries core._qattn_<arch>, then core.<arch>_compile, then an importlib.import_module("sageattention.<arch>_compile"), and accepts the first candidate that carries the probe symbol. A failed direct import of the first candidate is not a broken install.
Which node to use — and why that is not a correctness decision here. KJNodes ships MiniMaxH3MemoryEfficientSageAttentionPatch in its KJNodes/minimax category, alongside a generic patch and a mode dropdown. The H3-specific one is the one to reach for, on what its source actually does rather than on any published number: it replaces every transformer block's attn.forward, and the replacement consumes its qkv list so that, in the file's own comment, the float tensors can be freed "before the kernel runs — attention is the VRAM peak in these models." Its node description states the purpose as reducing peak VRAM. Whether that reduction shows up on this card is unmeasured, and so is its speed: see Results. What it is definitely not is a route around the SageAttention defect below, and an earlier version of this page claimed it was.
Read what it dispatches on your silicon. nodes/ltxv_nodes.py branches on {"sm120", "sm121"}, quantises V through per_channel_fp8, and calls into _qattn_sm89 — the f32-accumulate kernel, or the f16-accumulate one once CUDA is 12.8 or newer, which the cu130 build this page mandates satisfies. That is an FP8 PV kernel: the same family named in the title of ComfyUI issue #15263, and the same dispatch sage's own auto takes on sm_120. Picking the H3 node does not move you off it.
So do not pin a mode, and do not let anyone talk you into one. Somebody ran every KJNodes sage mode on an sm_120 box at the failing size: auto completes with noise, fp8_cuda++ crashed, fp8_cuda and fp16_triton each survive one step then raise cudaErrorIllegalAddress, and fp16_cuda kills the process with Fatal Python error: Aborted. The reason is dispatch, not luck — "Every explicit mode is also something sage never picks on sm120." The person who had proposed pinning an FP16 kernel withdrew it once that table landed, because "there is nothing to pin there". auto, or the H3 node above, is the only thing on this architecture anyone has seen finish at all.
Treat the cause as open. Two explanations have now been retracted by the people who proposed them: the original missing-low_precision_attention root cause was withdrawn by the reporter who filed it, and PR #15298 implementing it was closed unmerged; then FP8 accumulation — which the issue's title still names — was argued against by its own proposer, on the grounds that "So auto and ++ differ by one parameter and it isn't the PV path." The current leading guess is a scale-buffer overrun. Nothing is settled.
And it has never been tested against the files this page installs. I enumerated every post in that thread: exactly two participants ever name a checkpoint. Every noise report on sm_120 comes from one person running the bf16 pair, minimax_h3_fl2va_bf16.safetensors with qwen3vl_32b_minimax_h3_bf16.safetensors. The only participant running minimax_h3_fl2va_pruned_int8_convrot.safetensors — this page's transformer — is on an RTX 3090, sm_86, and reports clean output on both the node and the global flag. So the pruned_int8_convrot + nvfp4_awq set has never met this defect on sm_120 at any length. Do not read that as protection: sage operates on activations rather than on weights, so there is no mechanism that would obviously make the checkpoint matter. It is an untested combination, which is a different thing from a safe one.
None of which you can reach from this card. Work your token count as that thread does, ceil(frames / 4) × (width / 32) × (height / 32) — a formula that reproduces all five of the reporter's rows exactly:
| Job | Tokens | vs the first noise report |
|---|---|---|
| Stock t2v template (864×480, 124 frames) | 12,555 | 8% |
| 5 s at H3's native 1344×768 — the largest canvas anyone has published a VRAM figure for on this card | 31,248 | 19% |
H3's own ceiling: MAX_PIXELS = 768 * 1344 at the top of the trained frame range (1344×768, 362 frames) | 91,728 | 55% |
| First sm_120 noise report (1920×1088, 328 frames) | 167,280 | — |
The last two rows are the argument. MAX_PIXELS is a hard cap in comfy_extras/nodes_minimax_h3.py that downscales anything larger, so the biggest job H3 will let you ask for is a little over half the way to the first observed failure — on any GPU. The failing runs are 1920×1088, which is 2× over that cap.
One caveat on those numbers, from the person who computed them: the metric is a consistent way to compare runs, not necessarily the model's real sequence length — "I don't think it's the model's literal sequence length" — because video_latent_t() yields more temporal positions than frames / 4 does. Use it to rank jobs, not as an absolute.
One last note on the node itself: its description promises reduced peak VRAM, and while the mechanism for that is visible in its source, no published run on this card measures the peak with and without it. Do not budget for a saving nobody has demonstrated.
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 tuning on a normal desktop build, and the reason is arithmetic in ComfyUI's own source rather than anybody's measurement. MAX_PINNED_MEMORY is set to 90 % of system RAM (40 % on Windows) unless the flag is passed, and pinned_hostbuf_size(size) then returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size, page-locked, neither swappable nor reclaimable. For the 19.530 GiB transformer alone that is a 39.060 GiB request, before the 14.610 GiB encoder asks for its own. A 32 GB box cannot satisfy it and is OOM-killed. Pass the flag and MAX_PINNED_MEMORY stays at its -1 sentinel, pinned_hostbuf_size returns 0, and the buffer is never taken. VRAM is not what ends most H3 runs on this tier.
What the flag costs you in speed is not known. The mechanism points one way — with 64GB or more the 42.47 GB weight set stays in page cache whether or not it is pinned, so dropping the pin should change little; at 32GB it cannot stay cached and the streaming this tier cannot avoid starts arriving off the SSD instead of out of RAM — but nobody has published a timing of the same job with and without it, at any RAM size. Pass it anyway: the alternative at 32GB is not a faster run, it is an OOM-killed one. --fast-disk attacks the same problem from the other end, moving weights into reclaimable page cache, and it is the one flag here with a published number attached — in discussion #6 a reporter posting as UdonJP, on this card with 125 GB of system RAM, logged ComfyUI's resident set at 45.4 GiB with no flags against 12.6 GiB with --fast-disk. One box, one job, his own measurement — but it sizes the appetite of a default launch, and that appetite is set by the transformer rather than by your GPU.
Queue the template unchanged first, and know what "unchanged" actually means — the numbers stored on the generation node are not the numbers it runs. Its width and height are wired inputs fed by a ResolutionSelector set to 16:9 at 0.4 megapixels, and a connected input beats a stored widget, so the 1344×768 sitting in the node's widgets never reaches the sampler; you get 864×480. Frame count is snapped onto a 17k+5 grid by the template's own math node, so a 5-second request becomes 124 frames. Steps are 20, sampler res_multistep, scheduler simple. To actually reach H3's native canvas, set the selector to 0.98 megapixels.
What is resident, what streams, and what nobody has measured
| Stage | Resident weights | Reserve (Linux) | Stage total | Against 16 GiB |
|---|---|---|---|---|
| Text encode (Qwen3-VL-32B, NVFP4-AWQ) | 14.610 GiB | 1.191 GiB | 15.800 GiB | clears by 0.200 GiB — fits |
| Denoise (H3 DiT, pruned int8+convrot) | 19.530 GiB | 1.191 GiB | 20.721 GiB | 4.721 GiB short — streams |
| Decode (video VAE fp16) | 4.850 GiB | — | — | never binding |
One published trace is consistent with the knife-edge holding. Sampling at one-second intervals on this card, a reporter posting as UdonJP logged the encode stage at "24.1 GiB after TE load (VRAM 15,219 MiB, 100% util = encoding)", then caught the handover: "45.6 GiB after DiT load (VRAM drops to 2,999 MiB — TE evicted from VRAM, host copy stays)" — discussion #6. That 15,219 MiB sits within 259 MiB of the encoder's 14,960 MiB of weights, so essentially the whole encoder really was on his card; and the drop to 2,999 MiB is the eviction the arithmetic predicts, caught in the act. Read that as one person's trace on one machine, corroborating the table above rather than establishing it — he states neither the canvas nor the step count for it. The 0.200 GiB is derived from bytes and constants, and that is what it rests on.
Which stage owns the run's high-water mark, this page cannot tell you. No published trace decomposes an H3 peak by stage, on this card or any other. The only whole-run peaks published for this card are the same reporter's, in the same thread — "VRAM peak was 14,197 MiB for 30 s @ 640x480 and 14,437 MiB for 5 s @ 1344x768." — and both of those sit below his own 15,219 MiB encode-stage reading, which is a good reason not to treat the two kinds of number as commensurable: they are different runs, and neither is a decomposition. There is no accelerator sweep, no per-stage trace and no second card's repeat in circulation that would settle it.
What would settle it is small and nobody has published it: one run, one config, VRAM polled at 1–2 second intervals, logging the encode peak and the sampling peak separately, with the canvas and step count stated. If you have this card, that measurement is worth more than another timing — send it via /contribute.
For planning purposes the open question costs you nothing, because the advice does not depend on its answer: the encoder is the thing that has to fit and it fits by 0.200 GiB, so protect that margin at encode time; the transformer never fits and streams regardless of canvas, so resolution buys you wall-clock rather than a memory cliff.
And that margin has a knob, which is the practical payoff of all this arithmetic. --reserve-vram <GiB> replaces EXTRA_RESERVED_VRAM outright — the assignment sits below the platform defaults in model_management.py and overrides both of them. Since the encoder needs 0.8 + reserve + 14.610 ≤ 16, your ceiling is a 604 MiB reserve. Read off what that means per platform:
- Linux defaults to 400 MiB, so you have 204 MiB of slack — that is the whole of the 0.200 GiB margin, expressed as the most you can hand a desktop session before the encoder stops being resident.
--reserve-vram 0.55is about as far as it goes. - Windows defaults to 700 MiB and is therefore already 96 MiB past the ceiling, which is the same 0.093 GiB overshoot from Requirements seen from the other side.
--reserve-vram 0.5brings the encoder back onto the card — but the Windows constant is larger for a reason (the driver can back allocations out of system memory once VRAM runs out), so you are spending real safety margin to buy residency. Try it, and revert it if you start seeing stalls rather than speedups.
Run headless if you can. Nothing here is a crash risk — going over just moves the encoder onto the streaming path the transformer is already on.
A note on measuring any of it yourself: poll fast. H3 moves whole modules on and off the card between stages, so the peaks are narrow and a slow sampler walks straight past them — one to two second intervals is the coarsest that has been shown to catch the handover described above.
What nvfp4 does not do here
The 5070 Ti is Blackwell, so it is natural to assume the NVFP4 text encoder is exploiting FP4 tensor cores. It is not, and the file itself is the evidence.
The hardware gate does pass: supports_nvfp4_compute() returns true for any NVIDIA device of compute-capability major ≥ 10, and this card is 12.0, so nvfp4 is listed under Native ops at startup rather than under emulated ops as it would be on a 3090 or 4090. But reading the safetensors header of the shipped file over a range request, all 350 of its quantised layers carry a 55-byte inline descriptor reading {"format": "nvfp4", "full_precision_matrix_mult": true} — and comfy/ops.py builds its _use_quantized predicate with not self._full_precision_mm as a conjunct. With that flag set the quantised matmul is skipped and the weight is dequantised into the compute dtype first, on this card exactly as on an Ampere one. The header corroborates it from the other side: the file ships weight_scale, weight_scale_2 and a pre_quant_scale on 100 layers, and zero input_scale tensors — activation scales being precisely what an FP4 tensor-core matmul needs. (The one non-nvfp4 marker in the file, on the embedding table, declares int8_tensorwise.)
So the encoder is a 14.610 GiB container and that is its whole contribution on this card. Which is, to be fair, exactly the contribution you want at 16 GiB — just do not pick it for the tensor cores.
Output lands in ComfyUI/output/video/ as an MP4 with the stereo track already muxed in.
Results
- Speed: there is no surviving timing for this card, and that is the honest headline. Our catalogue has no benchmark rows for the pair — /check/minimax-h3/rtx-5070-ti returns
verdict: unknown— and the accelerator comparison that every 16 GB write-up of this model was quoting came from a single guide its own author has withdrawn, on the grounds that its content cannot be vouched for. This page does not cite it at any commit, and its commit history is part of the reason: the document existed for under 47 hours across six commits, among them a MiB→GiB conversion fix applied to its own VRAM peaks, a reversal of its primary RAM recommendation, and a rewrite into a different guide about a different card — then the withdrawal, on 2026-08-08. The objection is not that the link rotted. It is that the person who took the measurements says they cannot be stood behind, and that there is no revision of the document which was ever stable long enough to be worth pinning. So the sage speedup, the EasyCache speedup and the per-step cost on this card are all currently unknown, and anyone quoting a 2.02× or a 2.46× for a 5070 Ti is quoting that document. What does survive is the same author's dated forum post on the repack's discussion #6, where UdonJP states his setup — "RTX 5070 Ti (16 GB VRAM), 125 GB system RAM, ComfyUI v0.30.1, torch 2.12.0+cu130." — and gives host-RAM and whole-run VRAM readings but no timings at all. A stock-template run posted through /contribute would be the only timing anyone has for this card. - The nearest published figures, all on other cards. A Japanese-language RTX 5060 Ti 16GB review — same architecture, same capacity, a materially slower part — reports 633 s for a 5-second clip at the template's stock 864×480, and 809 s at 960×544 falling to 712 s with sage attention added. Read those as end-to-end times for a pipeline that terminates in a 4K upscale, so the ~1.14× sage brings there is an attention-level speedup diluted across a fixed stage it cannot touch; it is a floor on what sage does, not a measurement of it. It is also, as far as this round could find, the only published H3 sage figure on sm_120 of any kind. For contrast, on Ampere a tester posting as pepikir measured ~1.37× on sampling alone with this page's exact checkpoint and the stock template, at a fixed seed, in ComfyUI issue #15263 — a different architecture and a different kernel, quoted here only because it is the one place sage has been isolated from the rest of a pipeline at all. The 5060 Ti review also gives a steady-state VRAM figure its author puts at 11.7 GB; it states neither step count nor which weight files it loaded, so it is a same-capacity datapoint and not a same-configuration one. A third 16 GB NVIDIA report, on a 4060 Ti in discussion #30, logs a much heavier reference-to-video job — "4060ti 16gb, 64gb ddr4 ram, OG VAE, no turbo, Spectrum Apply MiniMax H3, 25 steps, 62min @ ~ 150s/it" — a useful reminder that the r2v graph is a different memory and time question from the t2v path documented here.
- VRAM usage: the number to size against is the text-encode stage — 14.610 GiB of encoder weights plus ComfyUI's 1.191 GiB reserve floor, so 15.800 GiB, clearing a 16 GiB card by 0.200 GiB on Linux and exceeding it by 0.093 GiB under the larger Windows reserve. The denoise stage is 20.721 GiB of demand against the same card and streams the 4.721 GiB difference. Both are derived from on-disk byte counts and ComfyUI's own constants, and they cover weights plus floor only — a long clip's activation working set sits on top. The only whole-run peaks published for this card are UdonJP's two in discussion #6, 14,197 MiB for a 30-second 640×480 job and 14,437 MiB for 5 seconds at 1344×768, neither of which states an accelerator configuration; nobody has published a per-stage decomposition. Live data, when it exists, will be at /check/minimax-h3/rtx-5070-ti — and a measured run posted through /contribute is worth more than every derived number on this page.
- Quality notes: the caution that matters most on this card is a methodological one. Every VRAM-reduction and speed claim for an accelerator node on a 5070 Ti currently traces back to the withdrawn document above, including the pixel-difference metrics that were used to argue one node's output was fine and another's was broken. Judge an accelerator by looking at its output on your own prompt at your own seed, not by a difference score and not by anyone's table — a node can score better on a pixel metric and look worse, which is exactly the trap that material set. On the model itself, the known weakness is faces at distance — reported in discussion #30 and not something 16 GB or any other capacity buys you out of. Frame for close and medium shots.
For the full benchmark data, see /check/minimax-h3/rtx-5070-ti.
Optional: the Turbo LoRA
Few-step distillation arrived late for this model, and there is now exactly one adapter: larryvrh/MiniMax-H3-Turbo-Lora, created on 2026-08-05, with its companion node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo the day after. Given the step count is the largest single lever on a card this size, that matters here more than it does on a 5090.
It also means this tier now has real datapoints, and they are about quality rather than speed. Both come from an RTX 4070 Ti SUPER 16GB — same capacity, previous architecture:
- A user posting as Evados reports a completed 8-step run at 1280×720 with LoRA strength 1.8 on
euler/beta: "8/8 [06:16<00:00, 47.03s/it] On a RTX 4070ti super 16 gb vram and 32gb ram." — and adds a flat warning in the same post: "Don't work with the pruned model." - A user posting as kangklx, who states "My current hardware is an RTX 4070 Ti SUPER 16GB with 32GB of system RAM.", does run it on the pruned int8-convrot base this page installs, with the pack's own sampler. They report a major visual improvement and a noticeable audio improvement over a stock sampler at 4 steps, but conclude that "there still appears to be a remaining audio-quality issue at 4 steps". A third participant in that thread is blunter: "Forget about 4 step. 4 step is bad. Minimum is 6 steps".
Those two 16 GB reports contradict each other on whether the pruned base works at all, and the adapter's own card sides with the second — it claims support for pruned and curve variants, with the node re-injecting the time conditioning at run time. Read the disagreement as unsettled rather than resolved: nobody has published a same-machine before-and-after on any 16 GB card, and the card itself has been rewritten repeatedly — at the pinned revision above the recommended weights are minimax_h3_turbo_v4_step600_ema.safetensors, the useful range is 4–8 steps rather than exactly 4, and the author still labels the whole thing "Still a preview — training continues". The pack also ships a low_vram switch that merges the adapter into the weights for the lowest peak, a little softer on quantised bases. Get a known-good baseline render first; then try Turbo against it.
The licence point from the top of this page reaches here too. An adapter's Apache-2.0 tag covers the adapter, not the base weights it loads against — and community commentary attributes the slow arrival of few-step LoRAs to exactly that territorial clause constraining who is able to publish one.
Troubleshooting
The sage patch refuses to load, or someone tells you to upgrade ComfyUI to 0.31
Two separate things, both cheap to rule out. Check pip show sageattention first: if it says 1.0.6 you have the PyPI package, which cannot satisfy the sm_120 path — see Installation step 3, and note that SageAttention 3 installs under a different package name (sageattn3) that the --use-sage-attention flag does not resolve. Second, advice to "update to 0.31" circulates and is simply wrong: no such release exists, and v0.30.2 was the newest tag when this page was written. If you are being told your version is too old, the number to check against is 0.30.0.
Your output is noise — picture and audio both, with no error raised
Compute your token count first, using the formula in Installation step 3, because on sm_120 the one documented sage failure is gated on sequence size and nothing else. Below roughly 90,000 tokens you are underneath every failure ever reported on this architecture, and on a 16 GB card you have to work to exceed that: H3's own area cap puts the largest job it will accept at 91,728, and the largest canvas anyone has published a figure for on this card, 5 seconds at 1344×768, is 31,248. So the cause is almost certainly elsewhere. Re-run the same seed with the attention patch removed — that single experiment settles whether sage is involved at all — and check the startup log for the comfy-kitchen and cu130 lines before anything else.
If you genuinely are up near the model's ceiling, shorten the clip or drop the canvas. Do not answer it by pinning a sage mode; on this architecture every explicit mode either crashes or is never what sage would have selected, and you would be trading a defect you probably cannot reach for a crash you certainly can.
ComfyUI is killed, or throws MemoryError, while loading
System RAM ends more H3 runs on this tier than VRAM does, which is why --disable-pinned-memory is in the launch command rather than here. Some useful arithmetic for sizing your box: the startup log prints what each module stages, and the staged figure tracks the file size rather than an expanded one — weights are kept quantised in host RAM. You can check that against other people's logs rather than taking it on trust: a reporter in discussion #36 pastes Model MiniMaxH3VideoVAE prepared for dynamic VRAM loading. 4965MB Staged for the 5,207,808,496-byte video VAE, which is 4,966.6 MiB on disk, and 25882MB Staged for the 27,141,342,152-byte int8 text encoder, which is 25,884.0 MiB. Both land within a couple of MiB of the file. So budget host RAM against the download sizes, not against some expanded form of them. --fast-disk attacks the same problem from the other side by moving weights into reclaimable page cache — see Running for the one published measurement of it. --cache-none does nothing for this at all: in the same thread as that measurement, the reporter tried it and got a 45.1 GiB resident set against 45.4 GiB with no flags, because it controls node-output caching rather than weight residency.
A MemoryError raised specifically by UNETLoader has a duller second cause worth eliminating first: a truncated download that is the right byte size and the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.
Generation is far slower than the numbers above
Grep the startup log for a comfy-kitchen import failure or for the cu130 warning quoted in Installation step 1. Either one silently removes the int8-convrot fast path while ComfyUI keeps running normally, and on this card that is the single most likely explanation for landing near a much smaller GPU's timings. Check it before concluding your card is the problem — and note that with no published timing for this card, "far slower than the numbers above" has no numbers above to be measured against. The comparison you can actually make is the 5060 Ti review in Results, on a slower part of the same architecture.
VRAM readings that make no sense, or a peak you cannot reproduce
Poll faster before you theorise, and the reason is in the one published trace of this card. Between two adjacent one-second samples its VRAM goes from 15,219 MiB to 2,999 MiB — the encoder handing over to the transformer, a swing of about 12 GiB inside a second (see Running). A sampler that fires every five seconds can land either side of an excursion that size, which is how a larger job comes back with a smaller peak. One to two seconds is the coarsest interval anything has been shown to catch that handover at; slower than that and you are measuring your poller.
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. 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 here — right now there is no published timing for this card at all, so yours would be the first.