What You'll Build
A ComfyUI graph on one RTX 5060 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 card is unusually well covered for a mid-range part. Two people published measured RTX 5060 Ti 16GB runs within two days of H3's release, and two more reported back from it on the repack's discussion board. That is more first-hand coverage than most cards in this catalogue get — and the two published runs disagree with each other by more than a factor of three on time at the same canvas, and disagree on VRAM as well.
Neither is wrong. Working out why they differ is most of what you need to know before you queue a job here, so that is what this page is built around.
⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement is territorial: clause I.5 defines the Excluded Territories as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America.", clause I.3 defines the Applicable Territory as everywhere else, and 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."
One of the two RTX 5060 Ti reviews this page relies on is itself a demonstration of that clause. Its author took down the English-language version of his write-up and set the accompanying YouTube video to unlisted, explaining that publication of H3 output is not permitted in the US, UK, Korea and the EU and that YouTube gives him no per-country block to use instead. Note also that the machine-readable
license:facet on both model cards is the uninformativeother, so a catalogue filter keyed on that field sees none of this. The Comfy-Org repack installed below relicenses nothing, 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 5060 Ti (16GB VRAM, sm_120) · 39.554 GiB of weights against a 16 GiB card · See benchmark data
ℹ️ 768p is the local ceiling. H3 reaches 2K through a separate
H3-Regenerate-2Kstage that the model card says is not open-sourced yet and is reachable only through MiniMax's hosted API — which puts you under their platform terms on top of the weights licence. What runs on your card is H3-Base: "H3-Base: Generates audio and video based on the H3-Context-IR output, producing results at 768p resolution.", and the same card's spec table adds "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 5060 Ti (16GB) — not measured by us; two independent published runs on this exact card are cited under Results (/contribute) |
| RAM | 32GB | — one published 5060 Ti run reports host RAM climbing 20–24GB above idle on top of a full card |
| 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/ |
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 and not a peak. 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."
One module fits. It is not the one doing the work.
Work the two large files against the card and the outcome is lopsided:
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 → 4.721 GiB short of 16 GiB
The 1.191 GiB is a constant you can read out of the source, not a rule of thumb. minimum_inference_memory() in comfy/model_management.py at v0.30.2 returns (1024 * 1024 * 1024) * 0.8 plus extra_reserved_memory(), and EXTRA_RESERVED_VRAM is 400 MiB on Linux — 1.190625 GiB, printed above rounded to three places.
So the text encoder is the only one of the two that is ever fully resident, and it is the one that does the least work: it runs once per prompt, produces a conditioning tensor, and is then evicted. The 19.530 GiB transformer that runs on every one of your twenty sampling steps never fits, so ComfyUI caps how much of it stays on the card and streams the remainder over PCIe. That is the shape of this tier, and the practical consequence is that the stage you actually wait for is bounded by transfer rather than by capacity.
It is tempting to go one step further and conclude that the encode stage must therefore own the run's peak — the reasoning being that a stage which cannot fit never gets to set one. Do not. A fit test tells you whether a stage's weights go on the card; it says nothing about where the run's high-water mark falls, because activations, attention working memory and whatever else ComfyUI holds during sampling all sit outside that arithmetic. This page carried that inference until a reviewer removed it, and the measurement that removed it has since been withdrawn by its own author, so the position now is the simpler one: nobody has published a stage-decomposed VRAM trace of an H3 run on any card.
The one instrumented reading that exists is one person's, and it does not reconcile with itself. Sampling at one-second intervals on an RTX 5070 Ti, a user posting as UdonJP logged VRAM at 15,219 MiB while the text encoder ran at 100 % utilisation, then dropping to 2,999 MiB once the transformer loaded and the encoder was evicted from the card; in the same post he gives whole-run peaks of 14,197 MiB for a 30 s / 640×480 job and 14,437 MiB for 5 s at 1344×768 (discussion #6). An encode-stage reading above both stated whole-run peaks means the trace and the peaks are not describing the same job, and he does not say what canvas the trace was taken on. Treat all three as one person's readings on a different 16 GB card rather than as this card's numbers.
What the 15,219 MiB does establish is the thing this page actually rests on, and it is arithmetic rather than measurement: the reading sits within 259 MiB of the encoder's staged size, so the encoder genuinely does become fully resident, and the knife-edge in the arithmetic above is real rather than notional. Settling the rest would take one run instrumented per stage on a 16 GiB card, which nobody has published; if you take one, /contribute it.
Three things sit on top of that arithmetic before you treat 0.200 GiB as headroom.
The reserve is larger on Windows, and the sign of the surplus changes with it. EXTRA_RESERVED_VRAM becomes 600 MiB there, and a further 100 MiB is added when the card reports more than 15 GiB. Check the indentation rather than taking my word for it — the extra 100 MiB sits inside the if WINDOWS: block, so it is a Windows surcharge and not a general large-card one, and this card is on the far side of that threshold. The floor becomes 1.484 GiB, the text-encode stage 16.093 GiB, and a 16 GiB card is 0.093 GiB under water before anything else has asked for a byte.
The comparison is against free VRAM, not against capacity. get_free_memory() in the same file reads torch.cuda.mem_get_info(dev), which reports what is unallocated at that instant. A desktop compositor, a hardware-accelerated browser tab or a second CUDA process is spending out of that 0.200 GiB directly, and the driver and CUDA context take their cut before ComfyUI starts.
Running out of 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 this card 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(). The budget therefore collapses to free_vram − minimum_memory_required. Less free memory simply means fewer weights resident and more streaming — the mechanism that lets a 19.530 GiB transformer run here at all. Note what else that formula implies, because it settles a disagreement further down this page: the amount of VRAM you will see in use is not a property of H3. It is a property of how much was free when the stage loaded. ComfyUI will fill whatever budget it is given.
And the reserve is a knob, not only a margin. --reserve-vram <GiB> does not add to EXTRA_RESERVED_VRAM; it replaces it outright — EXTRA_RESERVED_VRAM = args.reserve_vram * 1024 * 1024 * 1024, with no reference to the platform default. Keeping the encoder resident needs 0.8 GiB + reserve + 14.610 GiB ≤ 16 GiB, so the reserve ceiling on this card is 604 MiB. Linux's 400 MiB default therefore leaves 204 MiB of slack you can spend, and Windows' 700 MiB is 96 MiB past the ceiling — which --reserve-vram 0.5 recovers, at the cost of the headroom that constant exists to protect. Reach for it if you are on Windows and the encoder is spilling; do not reach for it to buy 200 MiB on a machine that is also driving your display.
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. 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 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 raises; everything is just slower, and on a card in this class that is easy to mistake for the card.
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.
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.
On the text encoder: take the nvfp4 build, and do not go looking for a smaller one. The repack's alternative, 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, and enough to push the encode stage off the card entirely. There is a real quality argument for the int8 encoder, made 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.
The community's answer to that squeeze is a 4-bit encoder, and the arithmetic does not support it. In the same thread, a user posting as Liquidmind111 recommends an int4_convrot text encoder and reports that it "works well on a 5060 16GB" at 768×576 for a 10-second clip in ten minutes. Read the file sizes before you act on it: byte counts from the Abiray/MiniMax-H3-GGUF tree API put that build at 14,952,506,709 B = 13.925 GiB against nvfp4's 14.610 GiB. It saves 0.685 GiB — under half a gigabyte of real headroom on a stage that already clears the card, and nowhere near enough to change any decision on this page. The 4-bit encoders are simply the same order of magnitude as nvfp4, because nvfp4 is already a four-bit format. (The same third-party repo also ships a file named nvfp4_awq whose byte count matches the repack's int8 encoder to within 71 bytes, so weigh its labelling accordingly.) Nothing here is broken — it just is not a lever.
3. SageAttention: a real sm_120 defect, and the reason it cannot reach you
There is an open ComfyUI bug about SageAttention and H3, it is filed specifically against sm_120, and sm_120 is your card. Its conclusion has moved three times in five days, so this step separates what has been measured from what is still argued — and then does the arithmetic that tells you where your own jobs sit. Short version: install sage, and stop worrying about the bug.
Installing it. pip install sageattention gets you 1.0.6; the package index lists eight releases in total and nothing on a 2.x line. On that build the generic --use-sage-attention flag works — ComfyUI's comfy/ldm/modules/attention.py imports the plain sageattn symbol, which 1.0.6 defines — while the H3-specific KJNodes node hard-fails, because it wants get_cuda_arch_versions and per_warp_int8_cuda from sageattention.core and 1.0.6 has neither: "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 and naming compute capability 12.x in its title. To get the node, build 2.x:
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 environment. Those missing symbols are a package-version problem rather than a Blackwell one: they are absent from 1.0.6 whatever card you own, and only TORCH_CUDA_ARCH_LIST is yours. Windows users may find prebuilt 2.x wheels on third-party indexes; PyPI has none.
What is measured on this architecture is solid. ComfyUI issue #15263 reports the sampler producing clean output below a token count and noise above it, with nothing in between. The reporter's tightened sweep — one box, one checkpoint, one seed, the global flag throughout — reads 142k clean, 151k clean, 167k noise, 175k noise, 186k noise, and he puts it plainly: "it's a cliff, not a slope". Two different aspect ratios cross it, and a 736-frame run at a lower token count stayed clean, so the trigger is sequence size rather than frame count or shape.
What is not settled is why, and that matters because the fix follows the mechanism. The issue's original explanation — a missing low_precision_attention=False on H3's attention call — was withdrawn by its own author: "the root cause below is wrong. Don't merge the fix I proposed." The replacement theory, FP8 accumulation error in the PV kernel, is itself challenged in the thread's last comment: sage's auto and KJNodes' ++ share that accumulator, differ only in quantisation granularity, and behave differently, which points at a scale-buffer overrun rather than at arithmetic precision. Take the boundary as fact and the mechanism as open.
Two things follow for what you actually do.
The H3-specific node is not an escape route. It is natural to assume it is, since the withdrawn root cause was about ComfyUI's shared attention routing and the node bypasses that routing entirely. But read its dispatch. In nodes/ltxv_nodes.py the branch for {"sm120", "sm121"} quantises Q and K per warp, quantises V per channel to FP8, and — whenever CUDA is at least 12.8, which the cu130 build this page mandates satisfies — calls _qattn_sm89.qk_int8_sv_f8_accum_f16_fuse_v_scale_attn_inst_buf. That is FP8 PV with the fp32+fp16 accumulator: the same configuration sage's own auto selects on this architecture, reached by a different road. Install the node for its measured speed, not for immunity it does not confer.
Do not pin a kernel. Advice to force sageattn_qk_int8_pv_fp16_cuda circulated for about a day and was withdrawn by the person who proposed it — "let me withdraw the FP16-PV suggestion up front rather than defend it" — after every explicit KJNodes mode was run on an sm_120 box at the failing size and none survived: fp16_cuda gives "Fatal Python error: Aborted on the first attention call", fp16_triton and fp8_cuda give "clean step 1, then cudaErrorIllegalAddress", ++ crashed, and auto was the only mode that completed at all. The reason is structural — "Every explicit mode is also something sage never picks on sm120." — so on this card "there is nothing to pin there". Pinning trades a defect you probably cannot reach for a crash you certainly can.
And now the part nobody in that thread had a reason to work out for a 16 GB card. The failure is gated on sequence size, so the question is not whether the bug is real — it is — but whether your jobs can get near it. The thread counts tokens as ceil(frames / 4) × (width / 32) × (height / 32):
| Job on this card | Tokens | Share of the first noise row (167,280) |
|---|---|---|
| The stock template, 864×480 at 124 frames — where both published 5060 Ti runs sit | 12,555 | 8% |
| A realistic ceiling for 16 GB, 1344×768 at 124 frames | 31,248 | 19% |
| The largest job H3's own limits permit at all, 1344×768 at 362 frames | 91,728 | 55% |
Read the third row first, because it settles the other two. That is not a suggestion, it is a cap: MAX_PIXELS = 768 * 1344 in comfy_extras/nodes_minimax_h3.py, taken at the top of the range the same file's own tooltip calls "trained range is ~124-362, longer is untested". A user who stays inside the envelope H3 was built for cannot reach the boundary on any GPU — the model's own ceiling lands at 55% of the lowest failure anyone has reported, and you would have to leave the trained range to get there. On 16 GB you will run out of patience a long way before that; the stock job both published reviewers ran is at 8%, which is also, as it happens, almost exactly the token count of the one clean Ampere run in the thread.
Two honesty notes on that formula, neither of which changes the conclusion. It is a proxy rather than H3's literal sequence length — ComfyUI's video_latent_t() in the same node file counts latent frames differently and runs higher, and audio tokens are additional. And that is precisely why the column above is percentages: the two conventions share an identical spatial term, so ratios survive the disagreement even though absolutes do not.
One genuine gap, stated rather than papered over. Every sm_120 report in that thread that names a checkpoint names the bf16 transformer and encoder. The only participant running the int8_convrot files this page installs is on sm_86, where 1.0.6 has no FP8 kernel at all — so the defect has never been tested against your file set on your architecture. That is a reason to eyeball your own output on a fixed seed, not a reason to assume immunity.
Last, on the node's VRAM advertising. It describes itself as "Activates custom sageattention on the MiniMax H3 self-attention to reduce peak VRAM usage, overrides the attention mode. Requires latest sageattention version." Nothing published tests that claim. The comparison this page used to weigh it against — a sweep of attention and caching nodes across one job, one node changed at a time — came from a guide its own author withdrew on 2026-08-08 as unverified, and it is deleted rather than hedged. So on a tier with 0.200 GiB of arithmetic margin, read the peak-VRAM claim as the node author's, untested by anyone else, and worth checking with nvidia-smi on your own graph before you plan around it.
And check the frames, not only the peak. This page's own SageAttention material documents a kernel on this architecture that completes a run and emits noise, so "it finished and it used less VRAM" is not the same finding as "it worked" — a lower peak from an attention patch is only good news once you have looked at the output.
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
On a 32 GB machine that flag is not tuning — the default launch is the failure case, and the arithmetic is in the source. comfy/model_management.py at v0.30.2 sets MAX_PINNED_MEMORY = ram * 0.90 on Linux unless --disable-pinned-memory is passed, and pinned_hostbuf_size(size) returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size, page-locked. For the 19.530 GiB transformer on a 32 GiB box that is a request for 39.060 GiB of unswappable, unreclaimable host memory. It is not a VRAM problem and it does not scale with your card, so every H3 page in this family carries the same warning. If you have more RAM than that, drop the flag and keep the transfer speed.
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 whose stored widgets are 16:9 (Widescreen) at 0.4 megapixels, and a connected input beats a stored widget, so the 1344, 768 sitting in the sampler node's own widget list never reaches it. You get 864×480. Frame count is snapped onto a 17k+5 grid at 24 fps by the template's math node, so a 5-second request becomes 124 frames — 5.17 seconds. Steps are 20.
That default is the right place to start on this card, and both published 5060 Ti runs agree on where the ceiling is. The one that swept resolutions concludes that "864×480〜960×544あたりが実用上の現実的な上限ライン" — roughly 864×480 to 960×544 is the realistic practical upper limit here — on the grounds that VRAM is not what stops you, ten-plus minutes a clip is.
Two 5060 Ti runs, three and a bit times apart
Both are Japanese-language write-ups published within two days of release, both on an RTX 5060 Ti 16GB, both at the template's stock 864×480.
| canvas | length | steps | accelerators | time | |
|---|---|---|---|---|---|
| おーら / ai_0049 | 864×480 | 5 s | template default | none stated | 633 s |
| まゆひらa / mayu_hiraizumi | 864×480 | 5.17 s | 20 | EasyCache | 194 s first run, 185 s after |
The second author states it as "194秒（1回目の実行、20 Steps、864x480、、Easy Cache有効時）" — 194 seconds, first run, 20 steps, 864×480, with Easy Cache enabled. He is running Comfy-Org's own template with an EasyCache node added and a readout for resolution and length, and elsewhere reports that raising PyTorch and adding EasyCache moved him from 4 minutes 50 to 3 minutes 10.
Read the difference as a software gap, not a hardware one. The two accelerators available here do genuinely different jobs, and you can separate them from ComfyUI's own source rather than on anyone's authority. Sage changes what a step costs. EasyCache changes how many steps are computed at all: comfy_extras/nodes_easycache.py estimates each step's output change from the previous one, and once the running estimate falls below reuse_threshold it sets skip_current_step and returns a cached diff instead of calling the transformer. On a card where one clip costs minutes, a step you never compute is the largest lever there is — and unlike the sage path in Installation step 3, EasyCache is a stock ComfyUI node with nothing to build and no version to check.
Because those skips are adaptive rather than a fixed fraction, raising the step count does not cost proportionally more time. How far from proportional has not been published for this model on any card — the figure this page carried until 2026-08-08 came from the withdrawn guide — so measure it on your own graph before you plan around it. The node's defaults bound where it can help: it starts at 15 % of the way through sampling and stops at 95 %, so the first steps and the last are always computed in full.
One caveat from the second author, who runs it: EasyCache buys the speed with quality, sometimes visibly, so he keeps it on a node that can be bypassed rather than wiring it in permanently. Do that.
Two things about the 633 s figure before you treat the ratio as exact. Its author's stated method is the ComfyUI T2V template with only the prompt changed, so the file set and step count are pinned by reference rather than enumerated — but his stated pipeline also ends in an upscale to 4K, and each run's number is logged against that whole chain. So the two rows are not measuring the same span of work, quite apart from EasyCache; the section on sage below turns that same fact into the explanation of a second discrepancy. His third published number, 1564 s for a 10-second clip at 960×544, is more than double the 5-second figure at the same canvas, which is what you expect from a workload whose transfer volume grows with the latent.
On sage attention, the two published numbers disagree — and the likely reason is what was timed
The same author measured sage attention at 960×544 and reports "約12%の高速化" — about a 12% speed-up, 809 s down to 712 s. That is well short of the only controlled sage measurement anyone has published on H3. On ComfyUI issue #15263, a tester posting as pepikir ran the same prompt twice with cached conditioning and a fixed seed — 864×480, 124 frames, 20 steps, on the same pruned_int8_convrot file this page installs — and reported 9.00 s/it without sage against 6.57 s/it with the KJNodes patch on auto, about 1.37× on sampling. Two things keep that from being your number: it is an RTX 3090, sm_86 rather than sm_120 and with enough VRAM that it is not streaming, and it times the sampler rather than the wall clock. What it does establish is that 12% and 37% are not the same claim, and it would be easy to reach for a guess about his sage build instead.
The likeliest explanation is in what he timed, not in what he installed. His stated pipeline is generate, then upscale to 4K, and each run's figure — 633 s, 809 s, 712 s, 1564 s — is presented against that whole chain. Sage accelerates attention inside the sampler and does nothing to an upscale pass bolted on afterwards, so a sampler-side speedup measured across a pipeline with a tail it cannot touch comes out diluted. The arithmetic is undemanding: his 809 s → 712 s is a 1.14× whole-chain gain, and a 1.37× sampler inside an untouched tail produces exactly that if the sampler is about 44 % of the timed span — an unremarkable shape for a chain ending in a 4K upscale, and no appeal to a different build is needed.
Stated as carefully as the source allows: the review never says outright that the upscale sits inside the timed span, so this is the best available reading of an ambiguity rather than something it confirms. Either way the practical conclusion is the same — 12% is what that pipeline yielded, not what the node yields, and neither number transfers to a workflow shaped differently. Time your own sampler, and check pip show sageattention first: if it says 1.0.6 you are on the generic path by definition, because the H3-specific node cannot load. A measured pair sent through /contribute is worth more here than either published figure.
What nvfp4 does not do here
The RTX 5060 Ti is Blackwell, so the natural reading is that the NVFP4 text encoder is being executed on FP4 tensor cores. It is not, and you do not have to take that on trust — the file says so.
The hardware gate genuinely passes. supports_nvfp4_compute() returns true for any NVIDIA device whose compute-capability major version is at least 10, and this card reports 12.0, so nvfp4 is listed under Native ops at startup rather than under emulated ops. That single line is where the misconception comes from, and it is live: the second of the two 5060 Ti write-ups above tells its readers that RTX 50-series cards natively support the NVFP4 format used by the text encoder. The startup log agrees with him. The weights do not.
Reading the shipped safetensors header over an HTTP range request — a 231,400-byte header describing 2,054 tensors — the file carries 351 comfy_quant descriptors. Three hundred and fifty of them are the identical 55-byte string {"format": "nvfp4", "full_precision_matrix_mult": true}; the remaining one, on the embedding table, is a 29-byte {"format": "int8_tensorwise"}. That full_precision_matrix_mult flag is not decoration. comfy/ops.py reads it into _full_precision_mm_config and then builds its _use_quantized predicate with not self._full_precision_mm as a conjunct — so with the 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 tensor census corroborates it from the other direction. 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 and cannot synthesise. An independent report on 16 GB hardware describes the same behaviour from the runtime side, observing that the encoder "it stays packed and dequantizes per-op rather than expanding to bf16, so the 15.7GB file really is 15.7GB resident."
Which is exactly the contribution you want at 16 GiB: nvfp4 here is a container that makes a 32B encoder fit on a mid-range card. Just do not pick it for the tensor cores, and do not expect the encode stage to get faster because you bought Blackwell.
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-5060-ti returns
verdict: unknown. The two published runs are in the table above: 194 s (185 s warm) for 5.17 s at 864×480, 20 steps, with EasyCache, and 633 s for 5 s at the same canvas without it, plus 809 s at 960×544 falling to 712 s with sage attention added. Two shorter reports from the repack's discussion board agree on the shape. A user posting as Sc4r1et writes "i'm on rtx 5060 ti and pruned int8 runs slow but output much more realistic than ltx" and follows with "got 20 minutes per generation on 10 seconds in 0.9 MPixels, but following prompts and character identity preservation is much better than ltx, hope for some speedup LoRas in the future"; dennismc1974 replies "same here 5060 ti" without adding numbers. None of these is a controlled benchmark. Send a measured run through /contribute and it becomes one. - VRAM usage: the text-encode stage demands 15.800 GiB — 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 asks for 20.721 GiB against the same card and streams the 4.721 GiB difference. That arithmetic is what decides whether each stage fits; it is not a claim about which stage owns the run's high-water mark, and as Requirements sets out, nobody has published a stage-decomposed trace on any card. Take the arithmetic as a fit test, and for an observed envelope on 16 GiB take the only readings anyone has posted — UdonJP's whole-run peaks of 14,197 MiB for 30 s at 640×480 and 14,437 MiB for 5 s at 1344×768 on an RTX 5070 Ti (discussion #6), which are one person's numbers on a different 16 GB card. The two published 5060 Ti runs disagree here too, and the disagreement is informative rather than a contradiction: one puts VRAM at roughly 11.7 GB throughout, read off a screen recording of the sampling phase; the other reports "16GB の VRAM をほとんど消費した状態のまま、メイン RAM の使用量が 20～24GB 上昇した" — the 16 GB of VRAM stayed almost entirely consumed while main RAM rose 20–24 GB. Both are consistent with the budget formula in Requirements: resident weights are
free_vram − minimum_memory_required, so a machine with more free VRAM keeps more of the transformer on the card and reads higher, and a glance taken during sampling never sees the encoder load at all. Live data, when it exists, will be at /check/minimax-h3/rtx-5060-ti. - Corroboration from the same capacity class: the closest thing to instrumented numbers on 16 GB comes from a Linux run on an RX 9070 XT posted in discussion #17 by a user posting as doplxyz, who logged the transformer's resident share collapsing as the latent grew until two thirds of it was crossing PCIe every step, and concluded "Don't extrapolate H3 timings on a 16GB card from small test renders." Take the mechanism, not the timings: that is a different vendor, and on AMD the
MIN_WEIGHT_MEMORY_RATIOterm this page showed is disabled on NVIDIA is live, which floors weight residency at 40% of free VRAM. Your card has no such floor, so if anything the effect he describes is sharper here. - Quality notes: the model's known weakness is faces at distance, reported both in discussion #30 and by the first of the two 5060 Ti reviewers, who found small faces collapsing at 864×480 and raising resolution to fix it costing more time than it was worth. That is a property of the model, not the card, and it is the practical argument for framing close and medium shots on this tier rather than reaching for a bigger canvas you will wait ten minutes for.
For the full benchmark data, see /check/minimax-h3/rtx-5060-ti.
Optional: the Turbo LoRA
larryvrh/MiniMax-H3-Turbo-Lora and its companion node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo arrived days after H3 itself. On a card where step count is the largest lever you have, that is worth watching.
Nobody has published a Turbo result on an RTX 5060 Ti. All twenty-seven threads on the adapter's discussion board were read individually; not one mentions this card. What the board does settle is a question that reads as unresolved if you only skim it — whether the pruned int8-convrot base this page installs works at all — and the answer is version-dependent rather than contradictory:
- The early report saying it does not is from before the node pack existed. In discussion #3, a user posting as Evados hand-converted the LoRA's key prefixes with a script so the stock LoRA loader would accept it, got a completed 8-step run, and appended "Don't work with the pruned model." That is a statement about a hand-patched adapter under ComfyUI's generic loader.
- The node pack's author then shipped support for it. In discussion #11, opened specifically to ask for pruned-base compatibility, larryvrh replies "Node updated for pruned base."
- Users on the pruned base confirm it works, with a cosmetic caveat. In the same discussion #11, SeanTheITGuy, who quotes the exact filename and sha256 of the pruned int8-convrot checkpoint, reports "It does work with this pruned base and your ckpt500, it just spams the console with these errors." — the errors being
adaln_proj.linear.weightshape mismatches — and posts a same-machine before-and-after of 230 s at 20 steps against 116 s at 8 steps with the LoRA. He does not state his GPU, so read that pair as a ratio on unnamed hardware, not as a timing you can transfer.
Quality at low step counts is a separate matter and is not settled. In discussion #20, a user on a 16 GB card of the previous generation, who states "My current hardware is an RTX 4070 Ti SUPER 16GB with 32GB of system RAM.", documents a clean progression on the pruned base: clean at 20 steps without the LoRA, style drift at 8, posterisation in flat areas at 6, and outright ghosting with corrupted audio at 4 — improved substantially, though not eliminated, once he switched to the pack's own sampler. Get a known-good baseline render first, then try Turbo against it.
One thing on the pack that does apply specifically to a card in this class: in discussion #11, a user reported a cuda:0 versus cpu device mismatch that appeared, in his words, when running with VRAM offloading flags — which on 16 GB is the normal case, not an edge case — and posted a three-line patch for it. If you hit it, update the node pack before you patch anything by hand.
The licence point from the top of this page reaches here too. An adapter's own licence tag covers the adapter, not the base weights it loads against, and commentators on the repack's board attribute the slow arrival of few-step LoRAs to exactly the territorial clause quoted above constraining who is in a position to publish one.
Troubleshooting
The sage patch refuses to load
Check pip show sageattention first. 1.0.6 is the newest release that exists on PyPI, and it cannot satisfy the H3-specific node — 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 either. Separately: advice to "update ComfyUI to 0.31" circulates and names a release that was never tagged. v0.30.2 is the newest tag; 0.30.0 is the real floor.
ComfyUI is killed, or throws MemoryError, while loading
Host RAM ends more H3 runs on this tier than VRAM does, because the host copies of the weights coexist with whatever is on the card — the published 5060 Ti run that instrumented it saw main RAM climb 20–24 GB above idle while the card was already full, putting the combined footprint near 40 GB. The pinned-buffer arithmetic in Running is the first thing to eliminate: if you launched without --disable-pinned-memory on a 32 GB box, that alone accounts for it.
Two independent people have measured startup flags against this model, and they measured different flags, so read them as two readings rather than one table.
A flag-by-flag comparison on one job, posted by UdonJP in discussion #6, puts ComfyUI's resident-set peak at 45.4 GiB with no flags, 12.6 GiB with --fast-disk, and 45.1 GiB with --cache-none. --fast-disk attacks the same problem from the other end, moving weights into reclaimable page cache rather than anonymous memory — the difference between the OS dropping a page and the OOM killer arriving. --cache-none does nothing for any of this; it controls node-output caching, not weight residency, which is what its 45.1 GiB row shows. That run is one machine — an RTX 5070 Ti he gives as having 125 GB of system RAM — and he flags the limits of it himself, closing with the caveat that he has not verified any of it on an actual 16 GB or 32 GB box. His table has no --disable-pinned-memory row at all, so it says nothing about the flag in your launch line.
For that flag the measurement comes from someone else, on a machine much closer to yours. A 15-second RTX 3090 write-up ran the same model and the same 362 frames twice with only the flag changed, on a box with 31,997 MB of RAM: 29,866 MB of host RAM on defaults, killed by the kernel OOM-killer, against 7,508 MB with --disable-pinned-memory, completed. That is a first-hand before-and-after on the exact flag, from a different author, and it reaches the same MAX_PINNED_MEMORY = ram * 0.90 line quoted in Running. What it cannot give you is a time cost, because the unflagged run never finished — nobody has published a completed run on both sides of this flag, so what it costs in speed remains unmeasured.
Neither reading is on a 5060 Ti and neither is on 32 GB, so pass the flag on the pinned-buffer arithmetic in Running rather than on either number.
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
In order of likelihood on this card: no EasyCache in the graph (the difference between the two published runs on this exact GPU is larger than any hardware difference you could buy), then a comfy-kitchen import failure or the cu130 warning quoted in Installation step 1, either of which silently removes the int8-convrot fast path while ComfyUI keeps running normally. Check the startup log before you conclude the card is the problem.
Output is pure noise once you enable sage attention
Check your token count before anything else, because on sm_120 this failure is gated on sequence size rather than on configuration: the same install is clean at five seconds and can be garbage at thirty. Work it out with the arithmetic in Installation step 3. Below about 90,000 tokens you are underneath everything that has ever been reported to fail on this architecture — and every job a 16 GB card can realistically run is far below that — so the cause is almost certainly elsewhere. Check the comfy-kitchen and cu130 lines in the startup log, then re-run the same seed with sage disabled, which settles it in one experiment.
If you genuinely are above roughly 150,000 tokens, shorten the clip or drop the canvas. Do not respond by pinning a SageAttention mode: on sm_120 every explicit mode either aborts the process or throws cudaErrorIllegalAddress, and auto is the only one observed to complete at all at the failing size. See Installation step 3 for the table and the retraction.
Is the memory bus the problem?
Almost certainly not the part you are hitting first, and the honest answer is that nobody has isolated it. NVIDIA's own 50-series specifications give this card a 128-bit memory interface with GDDR7 and PCI Express Gen 5. What the published evidence shows is that the largest measured swing on this exact card — better than three to one, same canvas, same 16 GB — came from a caching node, and that the transformer's residency is decided by ComfyUI's budget formula rather than by any bus. There is no controlled measurement anywhere that varies the bus and holds the software constant, so this page does not claim one. Get your software configuration right first; it is worth more here than any hardware conclusion you could draw from what has been published.
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 here, a timing sent through /contribute is worth more to the next reader than every derived number on this page — this card has two published runs that disagree, and a third would help settle them.