What You'll Build
A ComfyUI graph on one RTX 4060 Ti 16GB 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 about the 16 GB SKU. NVIDIA sells two cards called RTX 4060 Ti and they differ only in memory: our catalogue carries the other one separately as rtx-4060-ti-8gb. The distinction is load-bearing here, because the whole argument below turns on one module fitting in 16 GiB and the other not. On 8 GB neither fits, which is a different install and a different page.
Every other page in this family is about capacity: what fits, what has to stream. This card asks a second question at the same time. It carries 16 GB on a 128-bit memory interface, and the AD106 die behind it exposes eight PCIe lanes rather than sixteen. Tom's Hardware's review of this card puts its spec-table bandwidth at 288 GBps against a 128-bit bus and concludes that "The bump in memory capacity will definitely help, but raw bandwidth remains a potential problem.", listing "Limited by the 128-bit bus" among its cons. That was written about games. This workload streams a 19.530 GiB transformer that cannot fit, on every sampling step — which is a far more direct test of the same complaint. Capacity and bandwidth point in opposite directions on this card, and the honest answer to "which one wins" is at the bottom of the Results section: nobody has measured it.
⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement grants rights only inside an Applicable Territory, and clause I.5 defines what is carved out of it: "means the European Union, the United Kingdom, the Republic of Korea and the United States of America." Clause 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."
Two practical notes. The machine-readable
license:facet on both model cards is the uninformativeother(withlicense_name: minimax-h3-community-license-agreementalongside it), so a catalogue filter keyed on that field sails straight past the territorial restriction. And the Comfy-Org repack installed below relicenses nothing — it declares the samelicense_nameand links back to the same file — nor does a community re-quantisation, a GGUF conversion or a LoRA. MiniMax publishes a licence Q&A and invites applications for a per-deployment licence from inside the Excluded Territories. This is a summary written by a reader of the text, not legal advice; the linked agreement is what binds you.
Hardware data: RTX 4060 Ti 16GB (16GB VRAM, Ada sm_89) · 128-bit bus, PCIe 4.0 ×8 · See benchmark data
ℹ️ 768p is the local ceiling. H3 reaches 2K through a separate
H3-Regenerate-2Kstage, and the model card says that module is not yet open-sourced, promising only that "We will release it once it is ready" — so 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 4060 Ti 16GB — not measured by us; the budget below is derived from file bytes and ComfyUI's own reserve constants (/contribute) |
| RAM | 32GB with --disable-pinned-memory; 64GB comfortable | — see Running, and the sizing note in Troubleshooting |
| Storage | 42.47 GB of weights, NVMe | 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/ |
The min_vram_gb on this page is 12, not 16, and that is deliberate: it is the filter floor for the install documented here, not this card's capacity. It rests on Comfy-Org's launch post, which describes shrinking the footprint to 42.5 GB and then says: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060."
16 GiB is the tier where exactly one of the two big modules fits
ComfyUI reserves a fixed inference floor on top of whatever weights it keeps resident. minimum_inference_memory() in comfy/model_management.py returns 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux — 1.191 GiB, printed here rounded. Add that to each module in turn:
text encoder 15,687,142,551 B = 14.610 GiB + 1.191 GiB = 15.800 GiB → clears 16 GiB by 0.200
DiT 20,970,379,616 B = 19.530 GiB + 1.191 GiB = 20.721 GiB → 4.721 GiB short, streams
On a 24 GB card both the denoise pass and the encoder fit. On a 12 GB card neither does. 16 GiB is the only consumer tier where exactly one of them does. That the encoder genuinely becomes resident at this capacity has one published report behind it, from a different 16 GB card: sampling VRAM at one-second intervals on an RTX 5070 Ti, a reporter posting as UdonJP logs "24.1 GiB after TE load (VRAM 15,219 MiB, 100% util = encoding)" in discussion #6. That reading sits 259 MiB above the encoder's 14.610 GiB of weights, so essentially the whole encoder was on his GPU while it ran. Read it as one person's trace on one machine, corroborating the arithmetic rather than replacing it — the arithmetic above is what this page stands on. The transformer never gets that treatment on any 16 GB card: ComfyUI caps its residency at the weight budget and streams the remainder.
What does not follow is that the encoder therefore owns the run's VRAM peak, and this page will not tell you it does. No published trace decomposes an H3 peak by stage. The other figures in circulation are whole-run totals, including the same reporter's "VRAM peak was 14,197 MiB for 30 s @ 640x480 and 14,437 MiB for 5 s @ 1344x768." in that thread — and note that 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 at all: they come from different runs, and neither of them is a decomposition. Which stage owns the peak is open, and no accelerator sweep, per-stage trace or repeat on a second card has been published that would settle it. Nothing below depends on the answer. You may still meet material that does settle it, because the 16 GB write-up that most of this model's coverage drew on — a five-configuration accelerator sweep, a 12,473–15,633 MiB peak band, an argument that swapping the attention node moves a 16 GB card's peak by 2.4 GiB — was withdrawn by its own author, who says its content cannot be vouched for. It is still cached and still quoted. Treat any 16 GB accelerator table you find as unsourced until someone re-measures it.
Read that 0.200 GiB as thin rather than as headroom, for three reasons.
The reserve is larger on Windows and the sign 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 — check the indentation yourself rather than taking my word for it, because that extra 100 MiB sits inside the if WINDOWS: block and is therefore a Windows surcharge, not a general large-card one. Your card is on the wrong side of that threshold. The floor becomes 1.484 GiB and the encode stage 16.093 GiB — over a 16 GiB card by 0.093 GiB before anything else has asked for a byte.
The budget is not measured against your card's capacity. get_free_memory() in the same file reads torch.cuda.mem_get_info(dev), i.e. what is genuinely unallocated at that instant. A desktop compositor, a browser with hardware acceleration on, or a second CUDA process spends directly out of that 0.200 GiB, and the driver plus the CUDA context take their cut before ComfyUI starts.
Losing the margin costs time, not the render. The weight budget for a stage is
lowvram_model_memory = max(0, free_vram − minimum_memory_required,
min(free_vram × MIN_WEIGHT_MEMORY_RATIO, free_vram − inference_floor))
and on NVIDIA the third term 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 rest over PCIe. That is the same mechanism that lets the 19.530 GiB transformer run here at all.
What the bus and the lanes actually are
Two numbers about this specific board, because both of them are unusual for a 16 GB card and both bear on a streaming workload:
- Local memory: 128-bit, 288 GBps. Those are the spec-table values in Tom's Hardware's RTX 4060 Ti 16GB review, whose verdict on the pairing is that "most users would be better off opting for a GPU with a wider memory bus and 12GB instead of the 128-bit bus and 16GB".
- Host link: PCIe 4.0 ×8, not ×16. NVIDIA's own spec page names the 128-bit interface and says "PCI Express Gen 4" but publishes no lane count. That figure comes from a second Tom's Hardware piece — not the review above, which does not carry it — where it is stated plainly: "Nvidia's AD106 graphics processor only has eight PCIe 4.0 lanes since 15.754 GB/s raw bandwidth provided by eight PCIe lanes is enough for modern GPUs".
Hold onto the second one. In a workload where a module larger than the card is copied in across every sampling step, the host-to-device link is not a boot-time detail — it is in the inner loop, and this card has half the lanes of the cards it shares a capacity tier with. What that costs in practice is the open question this page ends on.
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 pulls in torchaudio through the audio VAE path, 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 major 13 it calls ck.registry.disable("cuda") and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." That single 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 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
Before going further, confirm two things in the startup log: the torch version string contains +cu130, and comfy-kitchen's CUDA backend reports '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.
While you are in that log, find the Native ops: line. On this card float8_e4m3fn and float8_e5m2 should be on the native side — supports_fp8_compute() in comfy/model_management.py returns True from compute capability 8.9, which is exactly what Ada is — and nvfp4 should be on the emulated side, because supports_nvfp4_compute() requires major version 10 or higher. Both of those are expected here. Neither is a problem; see "What nvfp4 does not do here" below for why.
2. Download the four model files
Run these from the ComfyUI root, and pass the filenames as positional arguments rather than repeating --include.
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. The repack's alternative, qwen3vl_32b_minimax_h3_int8_convrot.safetensors, is 27,141,342,152 B = 25.277 GiB — a 26.468 GiB encode stage against a 16 GiB card, so it would stream too, and the run would have no stage left that fits. There is a real quality argument for the int8 encoder, made in discussion #16 by a single commenter posting as V33rGeer — he does not claim to have run both, but he does state the case with an explicit exemption for systems that physically cannot handle the larger file. At 16 GiB you are that exemption.
Take the pruned transformer too. The unpruned int8_convrot is 34,038,892,334 B = 31.701 GiB; the pruning removes modulation weights in favour of a lookup table, which Comfy-Org's launch post describes as functionally equivalent.
3. SageAttention 2.x — and here Ada has it easier than Blackwell
pip install sageattention gets you 1.0.6. That is not a stale mirror: the PyPI release index lists 0.1.0 and 1.0.0 through 1.0.6 and nothing above the 1.x line at all. KJNodes' H3 patch imports six names 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, attn_false — and the 1.0.6 wheel is a 20 KB pure-Triton package whose core.py defines exactly two public functions, sageattn and sageattn_varlen. Five of the six are missing, the import raises, the architecture probe never runs, and every H3 sage node then raises "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch.". The node's own schema says as much up front: "Requires latest sageattention version."
So you need a 2.x build, and this is the one step where sm_89 is better served than the newer architectures:
- Windows. woct0rdho's fork publishes prebuilt wheels and states that "The latest wheels support GTX 16xx, RTX 20xx/30xx/40xx/50xx, A100, H100, AGX Orin (sm75/80/86/87/89/90/120)." — sm89 is in that list, so you install a wheel and stop. The same README notes that "CUDA kernels for sm80/89/90 are bundled in the wheels, and also sm120 for CUDA >= 12.8", i.e. this card's kernels are in every wheel while Blackwell's are conditional. Pick the wheel matching your CUDA major version; the releases page currently carries eight of them, all tagged
v2.2.0-windows*. - Linux. There is no wheel — that fork ships Windows builds only. Build from source with your own compute capability:
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 — without it pip pulls a second torch into the build and wrecks the environment. TORCH_CUDA_ARCH_LIST=8.9 is this card's compute capability and cuts build time sharply.
What you get for it is visible in nodes/ltxv_nodes.py. The patch dispatches on architecture, and sm89 is a first-class branch rather than a fallback: it quantises Q and K per thread, converts V with per_channel_fp8, and calls _qattn_sm89.qk_int8_sv_f8_accum_f32_fuse_v_scale_attn_inst_buf — an INT8-QK / FP8-PV kernel. With CUDA ≥ 12.8, which cu130 satisfies, it upgrades to the accum_f16 variant. The Blackwell branch borrows those same _qattn_sm89 kernels; on this card they are native.
Before you enable it: the open noise report, and what it does and does not say about this card
That FP8-PV kernel family is also the subject of an open bug, so read this before you decide — and be careful with anything written about it before 2026-08-08, including community write-ups that predate the issue's own retitling.
ComfyUI issue #15263 has been retitled to "MiniMax H3: SageAttention FP8 PV kernels produce noise above ~160k tokens on sm_120". Its author spent the first week of the thread proposing a different cause, then withdrew it in his own body on 2026-08-08 — telling readers not to merge the fix he had written — and settled on the current one: "you've got it right that FP8 PV is the cause". He had already softened the original claim three days earlier: "sage isn't broken on H3, and my issue title is too strong."
Four things follow, and the third is the one that matters here.
The missing-kwarg story is dead. H3's Attention.forward in comfy/ldm/minimax/model.py does call optimized_attention(...) without low_precision_attention=False — that part is still true in the source — but it is not the cause, and the pull request that would have added it is closed with nothing merged. A page that hands you that mechanism is teaching a withdrawn diagnosis, and several written before 2026-08-08 still do.
The KJNodes 2.x node is not the safe side of this. The suspect is the FP8-PV kernel, and 2.x on sm89 is exactly what dispatches to it — the same branch praised two paragraphs above. A participant in the thread, working on an RTX 3090, put the architecture split precisely: "On sm_89+ and Blackwell with sageattention 2.x, sageattn auto-dispatches to the FP8-PV CUDA kernels instead", which he called "a genuinely different kernel, and a plausible place for a model-specific break that Ampere never reaches". That is a hypothesis about this card, not a measurement of it. There is no version of this install where you get 2.x on sm_89 and avoid the kernel family under suspicion.
Nothing published tests this architecture or this file set. I read the issue body and all nine comments: the three human participants are on an RTX 3090 (sm_86) and two Blackwell workstation cards (sm_120). No sm_89 result exists, clean or broken — the single occurrence of "sm_89" anywhere in the thread is the hypothesis quoted above. And every sm_120 noise report that names a checkpoint names the bf16 transformer with the bf16 text encoder; the one participant running pruned_int8_convrot — the file this page installs — is the sm_86 owner, who measured both sage paths clean at 864×480 / 124 frames / 20 steps, i.e. exactly this page's stock template, at 1.37× on sampling. Do not read any of that as reassurance. Sage quantises Q, K and V — activations, not weights — so there is no mechanism by which your checkpoint obviously protects you, and Ampere's clean result comes from a kernel your card does not use. What the census establishes is that nobody has checked sm_89; it establishes nothing about whether sm_89 is affected.
The reported boundary is far outside anything this card will render. The failure is a cliff rather than a slope — "So the crossover is somewhere between 154k and 167k", and "And it's a cliff, not a slope." — measured in video tokens counted as ceil(frames/4) × (W/32) × (H/32), the thread's own convention, which ranks jobs rather than giving H3's literal sequence length. On that scale the stock template here is 12,555 tokens, a figure the same sm_86 participant published for this exact job. The ceiling he then computed is the useful one, because it is a property of the model rather than of any GPU: "That's the 768x1344 area cap (MAX_PIXELS = 768 * 1344 in nodes_minimax_h3.py:27) at the top of the trained frame range (362)" — 91,728 tokens, 55 % of the first row that produced noise. Everything inside H3's own designed envelope sits below the boundary on any card. The failing run is outside it in both directions: "your exact 1920x1088 is 2.02x over the pixel cap", at the top of the ~124–362 frame range that the length input's own tooltip in comfy_extras/nodes_minimax_h3.py calls trained.
So: enable the node, run your first clip, and look at the output rather than assuming either outcome. And do not go looking for a specific kernel to pin. The person who suggested that withdrew it himself once the alternatives were tested — "If fp16_cuda aborts the process and fp16_triton corrupts memory on sm_120, there is nothing to pin there" — and nobody has tested any of them on sm_89 at all.
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
Queue the template unchanged first — and know what "unchanged" means, because 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 (Widescreen) at 0.4 megapixels with a multiple of 32, and a connected input beats a stored widget, so the 1344×768 sitting in the node's widgets never reaches the sampler. The template's own reference table maps 0.4 MP to 864 × 480, and 0.98 MP to 1344 × 768. Duration is converted to a frame count by a math node that snaps onto a 17k+5 grid, so a 5-second request becomes 124 frames at 24 fps. Inside the subgraph the sampler is res_multistep, the scheduler simple, and the step count 20.
That default is a sensible first render on this card. Raising the canvas is the expensive move here, and the next section is why.
The three stages, and the one that streams
| 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 |
| 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 | 1.191 GiB | 6.041 GiB | never binding |
The middle row is where nearly all the wall-clock lives, and it is the row that cannot fit. What ComfyUI does instead is keep part of the transformer resident and fetch the rest across PCIe on every step — and how much "the rest" is depends on the canvas, because the sampler's own working set competes for the same free VRAM.
The clearest published picture of that behaviour on a 16 GB card is not on this card, so read it for the shape rather than for the numbers. On the repack's discussion #17 a user posting as doplxyz measured the same four files and the same stock template on a 16 GB RX 9070 XT under ROCm, and logged the transformer's resident share falling from 14,636 MB at 320×192 to 5,737 MB at 1344×768 as the latent grew. Their summary of the largest canvas: "At 1344×768 two-thirds of the 21GB DiT streams over PCIe every step." The consequence they draw is the practical one — sampling time scaled as N^1.25 while the model mostly fit and as N^1.59 once offload dominated, so "Don't extrapolate H3 timings on a 16GB card from small test renders."
Two caveats before you carry that across. It is a different vendor and a different runtime path (they launched with --lowvram, which on that configuration puts the text encoder on the CPU entirely). And the residency floor is not the same: MIN_WEIGHT_MEMORY_RATIO guarantees a stage at least 40 % of free VRAM for weights by default, but ComfyUI resets it to 0.0 on NVIDIA, so on this card the resident share is free to fall further than that table shows rather than less. The direction transfers; the exact fractions do not.
What nvfp4 does not do here
Ada has no FP4 tensor cores, supports_nvfp4_compute() requires compute capability major ≥ 10, and so nvfp4 prints on the emulated side of ComfyUI's startup line on this card. It is natural to read that as a penalty you are paying for the smaller encoder. It is not, and the file itself is the evidence.
Reading the safetensors header of the shipped encoder over a range request: the file declares 2,054 tensors and 351 comfy_quant markers, of which 350 read exactly {"format": "nvfp4", "full_precision_matrix_mult": true} and one — the embedding table — reads {"format": "int8_tensorwise"}. comfy/ops.py builds its _use_quantized predicate with not self._full_precision_mm as a conjunct, so that flag turns the quantised matmul off and the weight is dequantised into the compute dtype first. The header corroborates it from the other side: the file ships 351 weight_scale, 350 weight_scale_2 and 100 pre_quant_scale tensors, and zero input_scale tensors — activation scales being precisely what an FP4 tensor-core matmul needs. The shipped encoder declines its own quantised path on every card, Blackwell included. You are not missing anything an RTX 50-series owner is getting.
That is also what a Comfy-Org maintainer told Ada owners who asked for an int4 build in discussion #16. Kijai's answer there — as an organisation member, not a bystander — was that the format choice is not a hardware statement: "it's just used as storage format here, there's nothing hardware specific about that."
One worry is worth killing explicitly, because it circulates in various forms and would point 16 GB owners at a file they cannot fit: that an emulated nvfp4 file gets expanded to bf16 at load time, so the smaller download buys you nothing and you should swap in the 27 GB int8 encoder instead. It does not expand. doplxyz's ComfyUI log on an emulated-nvfp4 card records the encoder loading at 14960.20 MB, full load: True — 14,960.20 MiB is 14.610 GiB, the file's own size to the byte — and their reading of it is the mechanism: "it stays packed and dequantizes per-op rather than expanding to bf16, so the 15.7GB file really is 15.7GB resident". The dequantisation is per-operation and transient, not a resident cost. What is true is only the speed half: there is no accelerated path to lose here, on any card. Swapping to the int8 encoder would cost you 10.667 GiB of residency to buy nothing back, and on 16 GiB it is not available at all.
Do not widen that conclusion to the transformer. The int8-convrot DiT's 200 quantised layers all read {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} with no opt-out anywhere, so its fast path is real — gated on the cu130 torch build and a working comfy-kitchen import from step 1, not on the file.
The one file where Ada's FP8 silicon is live
The repack also ships minimax_h3_fl2va_pruned_fp8_scaled.safetensors at 20,958,205,608 B = 19.519 GiB — 11.61 MiB smaller than the int8 file, so on memory it is a straight swap. Its header is a different story from the encoder's: of its 200 quantised layers, 150 carry a bare {"format": "float8_e4m3fn"} with both a weight_scale and an input_scale, i.e. no opt-out and the activation scale an FP8 tensor-core matmul actually needs. (The other 50 — every block's mlp.fc2 — do carry full_precision_matrix_mult and dequantise regardless.) supports_fp8_compute() passes from compute capability 8.9, so on this card that path is native where it would be emulated on an Ampere one.
The file is not untested — a run of its reference-to-video twin posted in discussion #34 pastes the loader line 19984.52 MB loaded, full load: True, i.e. resident at its on-disk size, which is the arithmetic above confirmed from the other side. But that was on an H200, a datacenter card with room to keep everything resident, so it says nothing about this tier.
Two reasons this page still leads with int8_convrot: it is the file the official template references and the file every published consumer report used, and — specific to this tier — a faster matmul is not obviously where the time goes when the transformer is being copied across the bus on every step anyway. Nobody has published a comparison of the two files on any card, consumer or otherwise. If you run both here, that would be new information and /contribute is where it belongs.
Output lands in ComfyUI/output/video/ as an MP4 with the stereo track already muxed in.
Results
-
Speed: our catalogue has no benchmark rows for this pair — /check/minimax-h3/rtx-4060-ti-16gb returns
verdict: unknown. Exactly one published run on this card exists anywhere I could find, and it is not the workload this page documents. In discussion #30 a user posting as 010O11 reports: "4060ti 16gb, 64gb ddr4 ram, OG VAE, no turbo, Spectrum Apply MiniMax H3, 25 steps, 62min @ ~ 150s/it" — for, in the same post, a 22-second clip at 0.6 megapixels in a 3:4 portrait frame, driven by four reference images at roughly 2K and about two minutes of input audio. That is the reference-to-video graph, not text-to-video; it is more than four times the stock clip length; and it uses the original video VAE rather than the experimental one another participant in the same thread was testing a day earlier. Read it as proof that a 16 GB Ada card completes a long, heavy H3 job, and as a sense of the order of magnitude on this tier — not as a t2v figure. There is no published text-to-video timing for this card at any canvas, and a stock-template run posted through /contribute would be the first. -
Does the narrow bus actually bind? Unestablished. The mechanism is not in doubt: 19.530 GiB of transformer against 16 GiB means part of it crosses the host link every step, and the fraction grows with the canvas. What is missing is the measurement that would separate this card's 128-bit local bus and eight Gen-4 lanes from everything else, and the study that would do it — the same H3 job on this card and on a 16 GB Ada card with a wider bus — has not been run by anyone.
The nearest thing in circulation is ComfyUI issue #15261, which is widely passed around as a 16 GB card-versus-card result and is not one. Read the body: its author, posting as telppa, measured only his own half — a 4080 with 64 GB of RAM taking 690 s on the official 5-second 1280×736 reference-to-video workflow, on a fresh Windows portable install — and sources the other half, a 300 s figure on a 5070 Ti, to a YouTube video he watched. Two operators, two machines, one number nobody in the thread can inspect. Even at face value it cannot isolate an axis: per NVIDIA's own pages the 4080 is 256-bit GDDR6X on PCI Express Gen 4 and the 5070 Ti is 256-bit GDDR7 on Gen 5, so local memory generation and host-link generation move together with the architecture — and on a tier that streams part of the transformer on every step, the host link is not a background detail. telppa's own reading is that the two cards ought to be close and he cannot explain why they are not; the thread is an open question, not a finding.
Worth noticing while you are there: NVIDIA publishes no PCIe lane count and no GB/s figure on any of those three product pages, this card's included. The one number that most distinguishes this board from its capacity tier is not something the vendor states anywhere, which is why the Requirements section above had to source it from a review. Until someone runs the stock template on a 4060 Ti 16GB and on a wider-bus 16 GB Ada card, treat the bus as a reason to keep the canvas modest and expectations low — not as a quantified penalty.
-
VRAM usage: 15.800 GiB at the text-encode stage — 14.610 GiB of encoder weights plus ComfyUI's 1.191 GiB reserve floor — 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 figures are derived from the on-disk byte counts and ComfyUI's own constants, not measured by us, and they cover weights plus floor only — a long clip's activation working set sits on top. Live data, when it exists, will be at /check/minimax-h3/rtx-4060-ti-16gb.
-
Quality notes: the model's known weakness is faces at distance, and it is a property of the model rather than of your card — the same discussion #30 opens with a 12 GB user reporting the distortion at 720p and finding that raising resolution did not fix it, and the 4060 Ti post above is itself a reply arguing that a portrait framing at 0.6 MP can hold a distant face where a wide shot cannot. Frame for close and medium shots.
EasyCacheis the largest speed lever available short of a distillation LoRA, and a participant in that thread reports it costing quality; A/B it on your own prompts rather than leaving it on by default.
For the full benchmark data, see /check/minimax-h3/rtx-4060-ti-16gb.
Optional: a smaller text encoder that actually uses a quantised path
This is the one genuinely card-specific tuning option, and it is third-party, so treat it as an experiment rather than part of the install.
Abiray/MiniMax-H3-GGUF publishes text_encoders/qwen3vl_32b_minimax_h3_int4_convrot.safetensors at 14,952,506,709 B = 13.926 GiB (byte count from that repo's HF tree API). That is only 0.684 GiB below the nvfp4 encoder, which sounds like nothing — but on this tier it moves the encode stage from 15.800 GiB to 15.116 GiB on Linux, and from 16.093 GiB to 15.409 GiB on Windows, which is the difference between over the line and under it. Reading its header the same way as above: 350 quantised layers, each declaring {"format": "convrot_w4a4", "convrot_groupsize": 256}, and no full_precision_matrix_mult flag. convrot_w4a4 is in ComfyUI's QUANT_ALGOS table and is never added to the architecture-disabled set, so unlike the shipped nvfp4 file this one can actually take the quantised path — on this card, through the comfy-kitchen backend that install step 1 exists to keep alive.
Against that: it is a redistributor's file, its provenance is not documented, and the only report of it working comes from a single Blackwell user in discussion #16. Nobody has published an Ada result with it, and nobody has compared its output against the official encoder on the same seed. Get a known-good baseline with the four official files first; then try it, and send what you find through /contribute.
Troubleshooting
Confirm the link is running at ×8 Gen 4 — and know that ×8 is normal here
nvidia-smi --query-gpu=name,pcie.link.gen.current,pcie.link.width.current --format=csv
Eight lanes is this card's design, not a fault: the AD106 die exposes no more. What is worth catching is a Gen 3 slot, which halves an already-narrow link and does so silently. On a workload that copies part of a 19.530 GiB transformer into the card on every sampling step, that is the one motherboard-level detail that can plausibly cost you real minutes. Move the card to the CPU-attached ×16 slot if there is any doubt, and take the reading while a render is running rather than at idle.
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. The arithmetic is in comfy/model_management.py at v0.30.2 and it is brutal. MAX_PINNED_MEMORY is set to 90 % of total RAM on Linux (40 % on Windows) unless that 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 request for 39.060 GiB of pinned host memory on any machine with 22 GB or more of RAM, before the 14.610 GiB encoder asks for its own. On a 32 GB box that cannot be satisfied and the process is killed. On a 64 GB box it can — leaving about a third of the machine for everything else, including the page cache this workload depends on. Pass the flag on both.
64 GB is doing real work on this card, and it is not only about surviving the load. The four files are 42.47 GB. On a 64 GB machine they sit in page cache, so the per-step streaming that this tier cannot avoid is served out of RAM. On a 32 GB machine they cannot, and the same streaming comes off the SSD instead — which is why the Requirements row says NVMe rather than just "a disk". How much that costs has not been measured by anyone, on this card or any other, so treat the direction as established and the size as unknown. What is measured points the same way from the other side: doplxyz's 16 GB run in discussion #17 reports "Peak system RAM reached about 56GB of 62GB, so 32GB machines will likely struggle.", and the published 4060 Ti run at the top of Results is on a 64 GB box. Thirty-two gigabytes plus the flag plus an NVMe drive will complete a render; sixty-four is what stops you paying for the difference.
--fast-disk attacks the same problem from the other side — its help text in comfy/cli_args.py offers to "Prefer disk-backed dynamic loading and offload over unpinned RAM. Can be faster for users with fast NVME disks.", which is a different trade rather than a second dose of the same one. --lowvram is not the answer here — its own help text in comfy/cli_args.py says it does nothing when dynamic VRAM is enabled, and on the path where it does apply it moves the text encoder to the CPU, which trades your one resident stage for a flat CPU cost per new prompt.
A MemoryError raised specifically by UNETLoader has a duller second cause worth eliminating first: a download that is the right byte size and the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.
You downloaded a file called nvfp4 and it is 25 GiB
Check where you got it. The Comfy-Org repack's qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors is 15,687,142,551 B. The same-named file in Abiray/MiniMax-H3-GGUF is 27,141,342,223 B, and reading its header shows 350 layers declaring {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} — it is the int8 convrot encoder under an nvfp4 filename. On a 24 GB card that is a slow surprise; on this one it is a 26 GiB stage against a 16 GiB card. Download the encoder from Comfy-Org/MiniMax-H3 and check the byte count against the table in Requirements before you load it.
Generation is far slower than you expected
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 it is the first thing to rule out before concluding that the card's bus is the problem. Second, check the resolution the sampler actually received rather than the one in the node's widgets — see Running. Third, remember that on a card this size time does not scale linearly with pixels once the transformer is streaming: the 16 GB RX 9070 XT measurement cited under Running reports that extrapolating from its small test renders underestimated its own largest canvas by 38 %.
SageAttention output looks like noise
First, establish that it is sage: run the identical graph and seed with the patch removed. If that is clean and the patched run is not, you have reproduced the shape of issue #15263 on an architecture nobody has reported it on, and the thread would want to hear about it — say your card, your canvas, your frame count and which weight files you loaded, because the frame count is the variable that report turns on.
Resist two tempting fixes. Do not chase the missing low_precision_attention=False kwarg — see Installation step 3; that diagnosis was retracted by the person who proposed it. And do not pin a specific sage kernel: there is no sm_89 measurement to choose one from, and the participants who proposed pinning one on Blackwell withdrew it themselves after finding that the alternatives crashed rather than merely degrading. Sampling at a smaller canvas or a shorter clip is the cheap diagnostic, and dropping the patch is the reliable workaround — it costs you time, not the render.
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 on this page — this is the one card in its tier where nobody has published the number that matters.