MiniMax H3 on RTX 4080: 16 GB Ada, and the only number this card has

What You'll Build

A ComfyUI graph on one RTX 4080 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 rather than dubbed on afterwards.

This card sits in an odd position in H3's coverage, and the odd position is what this page is about. By NVIDIA's own specification table the RTX 4080 carries 9728 CUDA cores behind a 256-bit GDDR6X interface — near the top of the 16 GB tier, and comfortably ahead of the Blackwell RTX 5070 Ti's 8960. Several cards in this tier have published H3 timings. This one is unusual in what its timing is: a single figure, filed as a bug report against ComfyUI, because the run took 2.3 times as long as a Blackwell card with fewer shader units was said to need. It is the whole published record for this GPU, and it is also the tier's only attempt at a same-job comparison between two cards.

That report is the most useful thing anyone has written about H3 on this GPU and it is also the most easily misread, so the section that unpacks it is the centre of this page. The short version: on a tier where a 19.530 GiB transformer cannot fit and is copied into the card on every sampling step, extra shader units are not the resource in short supply, and the comparison that produced the 2.3× does not isolate the one that is.

⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement is territorial at its root: clause I.3 defines the Applicable Territory as "means worldwide, excluding the Excluded Territories.", and clause I.5 names them — "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."

Three practical notes. The machine-readable license: facet on the model card is the uninformative other (with license_name: minimax-h3-community-license-agreement beside it), so any catalogue filter keyed on that field sails straight past all of this. Nothing downstream relaxes it — the Comfy-Org repack installed below declares the same licence and links back to the same file, and a re-quantisation or a LoRA is a derivative rather than an escape hatch. And there is a documented route in: the agreement itself says that "should any person in such Excluded Territories be interested in deploying our models, you are welcome to contact us about obtaining a license", alongside a published licence Q&A. This is a summary written by a reader of the text, not legal advice; the linked agreement is what binds you.

Hardware data: RTX 4080 (16GB VRAM, Ada sm_89) · 256-bit GDDR6X, PCIe Gen 4 · encoder resident by 0.200 GiB, transformer streamed · See benchmark data

ℹ️ 768p is the local ceiling on every card, this one included. H3 reaches 2K through a separate H3-Regenerate-2K stage which the model card does not ship — "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 4080 (16GB, sm_89) — not measured by us; the budget below is derived from file bytes and ComfyUI's own constants, and the single published timing is somebody else's (/contribute)
RAM	32GB with --disable-pinned-memory, 64GB to be comfortable	— the one published run on this card had 64GB; see Running for why the flag is not optional
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/

min_vram_gb on this page is 12, not 16. That field is a filter floor — the smallest real card capacity on which the install documented here runs at all — and it comes from Comfy-Org's launch post, which explains how the footprint got to 42.5 GB ("the model's modulation weights (~40% of the total parameters) could be pruned and replaced with a functionally equivalent lookup table") and then states the floor: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060."

The arithmetic of this tier, re-derived

Two numbers decide everything on a 16 GiB card, and neither of them is a benchmark. minimum_inference_memory() in comfy/model_management.py at v0.30.2 returns (1024 * 1024 * 1024) * 0.8 plus EXTRA_RESERVED_VRAM, and on Linux that constant is 400 MiB — 1,278,423,859 bytes, or 1.191 GiB. Add it to each large module in turn:

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, streams

On a 24 GB card both modules fit, one at a time. On a 12 GB card neither does. 16 GiB is the only consumer tier where exactly one of them fits, and it is the encoder. ComfyUI then caps the transformer at whatever weight budget is left and fetches the remainder over PCIe on every sampling step — which is not a failure mode, it is the operating regime of this whole tier, and it is why the paragraphs about shader counts below end where they do.

What this arithmetic does not tell you is which stage owns the run's high-water mark, and no page should tell you it does. Every published 16 GB VRAM figure for H3 is a whole-run peak; nothing in the record decomposes one by stage. There is even a mechanical argument against the encoder owning it — on the one 16 GB card that has been instrumented, swapping the attention node moved the run peak by roughly 2.4 GB, and attention is denoise-side, so a peak the encoder had set could not have moved that far. Size your card against the 15.800 GiB encode figure, because that is the number that decides whether you are in the envelope at all. Do not size it against a peak nobody has isolated.

Three caveats on that 0.200 GiB, in descending order of how likely they are to bite.

The reserve is bigger on Windows, and the sign of the surplus 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 of total VRAM. Check the indentation in the source yourself 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. Together they lift 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. Keep that number; the one published measurement on this GPU was taken on Windows, and it comes back in Results.

The comparison is against free VRAM, not 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 hardware-accelerated browser tab or a second CUDA process spends straight 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 max(0, free_vram − minimum_memory_required, min(free_vram × MIN_WEIGHT_MEMORY_RATIO, free_vram − inference_floor)), and the third term is switched off outright on your hardware — MIN_WEIGHT_MEMORY_RATIO is 0.4 by default and reset to 0.0 under if is_nvidia(). So when free memory drops, ComfyUI keeps proportionally fewer weights resident and streams more. It degrades; it does not fail.

Installation

1. Put ComfyUI on 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; v0.30.2 was the newest tag when this page was written. That module reaches torchaudio through the audio VAE path, so an environment carrying only torch and torchvision fails at startup.

The CUDA version is a gate in ComfyUI's own source rather than folklore, and on this card it gates the one downloaded file that genuinely uses a quantised kernel. comfy/quant_ops.py parses torch.version.cuda; 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 supplies the accelerated kernels for the int8-convrot transformer. Note what the gate is keyed on: the CUDA version, not the architecture. Ada is not disadvantaged here — it is only as disadvantaged as an out-of-date toolchain makes it.

Order matters: requirements.txt lists torch unpinned, so running it after a cu130 install can resolve a default-index wheel over the top and silently undo 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, read two things out of the startup log. The torch version string 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. While you are in that log, find the Native ops: line: on this card float8_e4m3fn and float8_e5m2 belong on the native side and nvfp4 on the emulated side. Both are expected, and neither is a problem — the section under Running explains why the second one costs you nothing.

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, and take it for its size rather than its name. 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, which would leave this run with no stage that fits at all. There is a quality argument against the nvfp4 encoder, and it is worth reading with its provenance attached: one commenter, posting as V33rGeer on the repack's discussion #16, writes that "you shouldn't be using the NVFP4 text encoder, as it compromises the coherence of tricky setups, and unless your system physically cannot handle it; the int8c model is plain better at mostly just storage cost." He does not say he ran both, and nobody in that thread posts a same-seed comparison. What the sentence does carry is its own exemption clause for systems that physically cannot take the larger file — and at 16 GiB you are inside it.

Take the pruned transformer too: the unpruned int8_convrot is 34,038,892,334 B = 31.701 GiB, twice this card's capacity, and the pruning removes modulation weights in favour of the lookup table quoted under Requirements rather than cutting precision.

Then verify the hashes before you conclude anything about memory. A download that is the right byte size and the wrong hash presents as a MemoryError inside UNETLoader — see Troubleshooting. Re-hashing a 21 GB file is cheap next to re-diagnosing it.

3. SageAttention — two things share the name, and neither is settled

This step is optional, it is the largest speed lever on the page, and it is the one part of this install where the public record moved while these pages were being written. Take the install mechanics first and the open bug second; they are separate questions and conflating them is how most of the bad advice on this subject got made.

The startup flag installs from PyPI. --use-sage-attention is a plain switch in comfy/cli_args.py, and all it needs is a sageattn symbol — comfy/ldm/modules/attention.py imports exactly from sageattention import sageattn, which the stock 1.0.6 package provides. So pip install sageattention plus the flag genuinely runs. One mechanical detail is worth knowing and is not in dispute: attention_sage in that file drops to the PyTorch path only when a caller passes low_precision_attention=False, and H3's attention call site — comfy/ldm/minimax/model.py line 181, optimized_attention(q, k, v, self.heads, mask=None, skip_reshape=True, transformer_options=transformer_options) — does not pass it, while several other model families in the same tree do. Read that as a fact about the source and nothing more. It was once believed to be the cause of H3's noise reports; it is not, and the subsection below is why.

The H3-specific node is the faster one and will not install from PyPI. KJNodes ships MiniMaxH3MemoryEfficientSageAttentionPatch, described in its own schema as "Activates custom sageattention on the MiniMax H3 self-attention to reduce peak VRAM usage, overrides the attention mode. Requires latest sageattention version.", and it replaces the attention forward wholesale instead of routing through the shared path above. It 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 and attn_false — and unpacking the 20,105-byte pure-Triton 1.0.6 wheel shows that its core.py defines exactly two module-level functions, sageattn and sageattn_varlen; only attn_false of the six appears anywhere in it. So on the PyPI package that import fails, the architecture probe never runs, and the node raises "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." rather than running slowly. PyPI's release index lists 0.1.0 and 1.0.0 through 1.0.6 and nothing above the 1.x line, so there is no version to upgrade to there. That failure is not architectural — it is an import, and it fails identically on sm_86, sm_89 and sm_120.

Getting a 2.x build is where the one real Ada convenience shows up, and it is an operating-system split rather than an architecture one:

• Windows. woct0rdho's fork publishes prebuilt wheels and its README 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 download a wheel matching your torch and CUDA and stop.
• Linux. Build from source — there is no prebuilt wheel to download. That fork is, in its own title, a "fork for Windows wheels and easy installation": it builds against MSVC and the Windows SDK, and its README explains why the binaries never reach the package index at all — "We cannot publish the wheels to PyPI, because PyPI does not support multiple PyTorch/CUDA variants for the same version of SageAttention." PyPI's own index stops at 1.0.6, and that artifact is py3-none-any with no compiled kernels in it. The build is a one-liner with your own compute capability pinned:

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"

Point CUDA_HOME at wherever your CUDA 13 toolkit actually lives — 13.2 is an example. --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; a page written for a 50-series card will tell you 12.0 there, and that value builds kernels your GPU cannot run.

What the build gets you on Ada is one specific kernel family, and naming it precisely matters for the next subsection. In nodes/ltxv_nodes.py the patch dispatches on detected architecture, and at lines 1901–1916 the sm89 branch quantises Q and K to int8 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 — upgrading to the accum_f16 variant when CUDA is 12.8 or newer, which cu130 satisfies. Note that per_channel_fp8 runs on both sides of that branch: your card takes an FP8-PV kernel whether or not the CUDA upgrade applies, and the newer toolkit buys the accumulator variant rather than the format. The sm120/sm121 branch calls into the same _qattn_sm89 module, so Blackwell borrows these kernels rather than having its own.

The open noise report, and what it does and does not say about an Ada card

ComfyUI issue #15263 is open and is the thing to read before you enable any of this — but read the current version of it, because the title it circulated under for its first five days named a cause its own author has since withdrawn. It was filed under a title naming the startup flag and the missing kwarg, and blamed exactly that. On 2026-08-08 its author replaced the top of his own body with a dated note retracting that diagnosis and telling readers not to merge the one-line fix he had proposed; the PR was closed unmerged on his instruction, and the issue was retitled to name the FP8 PV kernel and a token threshold instead. In his own words in the thread, agreeing with the commenter who worked it out — "I think you've got it right that FP8 PV is the cause", and, on the retitle, "Agreed on the retitle, the current one is wrong either way." He had already softened the report three days before that: "sage isn't broken on H3, and my issue title is too strong."

What survives is an empirical boundary on Blackwell, and it is sharp. All of the failing runs are the issue author's RTX PRO 6000 (sm_120, 96 GB) on the bf16 transformer and bf16 text encoder. Bracketing it himself across five runs he reports the crossover "So the crossover is somewhere between 154k and 167k, tighter than the 154k/184k I had before." and stresses its shape: "And it's a cliff, not a slope. 151k is clean, 167k is garbage, nothing soft in between." The counting convention both participants use is ceil(frames/4) × (W/32) × (H/32), and its own author flags what it is not: it reproduces all five of his rows exactly, so it compares runs reliably, but "I don't think it's the model's literal sequence length" — H3's own video_latent_t() gives 107 temporal positions for 362 frames rather than 91. Use it to rank jobs, not as an absolute.

Three things follow for a 4080 specifically, and the third is the uncomfortable one.

First, your remedy is inside the suspect family. The paragraph above is the evidence: on sm89 the KJNodes patch quantises V to FP8 and calls the _qattn_sm89 FP8-PV kernels. And a commenter posting as pepikir, who did the diagnostic work the retraction credits, states the same about the global flag — that on sm_89 and up with 2.x, sageattn "auto-dispatches to the FP8-PV CUDA kernels instead", which he calls "a genuinely different kernel, and a plausible place for a model-specific break that Ampere never reaches". So on this card the node-versus-flag choice does not move you off the kernel under suspicion. The only build that avoids FP8 PV entirely is the stock 1.0.6 — and that is precisely the version the H3 node refuses to load against.

Second, nobody has reported H3 with sage on sm_89 at all. Across the issue's nine comments the string sm_89 occurs exactly once, in pepikir's sentence about dispatch, and no 40-series card is named anywhere in the thread. There is no Ada result to inherit in either direction.

Third — and say this in the same breath as the second, or it reads as reassurance — untested is not the same as unaffected. Every sm_120 noise report that names a checkpoint is on bf16. The only participant running minimax_h3_fl2va_pruned_int8_convrot.safetensors, the file this page installs, is pepikir on an RTX 3090 (sm_86) — where the stock 1.0.6 wheel has no FP8 kernel at all, so his clean result is not a test of the failing path. The defect has therefore never been tried against this page's file set on any card. That is a hole in the record, not a clearance: sage operates on activations, not on weights, so there is no obvious mechanism by which the checkpoint would protect you.

What genuinely bounds your exposure is job size, and that bound is the model's rather than your card's. The stock template — 864×480, 124 frames — is 31 × 27 × 15 = 12,555 tokens, under 8% of the first reported noise row. And H3 caps its own canvas: MAX_PIXELS = 768 * 1344 at comfy_extras/nodes_minimax_h3.py line 27, which at the top of the trained frame range (362) gives 91 × 42 × 24 = 91,728 tokens — 55% of the first noise row at 167,280 (pepikir puts the same figure at 61% of the last clean row at 150,960; both ratios are right, they differ only in denominator, and this page standardises on first-noise). His conclusion for his own architecture generalises here because the ceiling is H3's and not Ampere's: "So Ampere cannot reach even your" clean row. Neither can you, inside the model's designed envelope.

Work your own jobs out before you worry — the arithmetic is three multiplications and it is the only thing on this page that tells you whether the boundary is anywhere near you. Running tells you to raise the Resolution Selector to 0.98 megapixels for H3's native canvas; at 1344×768 that is 42 × 24 = 1,008 spatial positions, so a 5-second clip (124 frames) comes to 31,248 and a 10-second one (243 frames) to 61,488. Both are far below the 167,280 boundary — but be precise about the second one rather than reassured by it: the smallest job anyone has verified clean on Blackwell is his 1920×1088 five-second run at 31 × 60 × 34 = 63,240 tokens, so a 10-second native-canvas clip on this card lands at 97% of it, essentially at the bottom edge of the range anyone has checked at all. The 91,728 ceiling above is what you reach only by holding native canvas across H3's entire trained frame range.

Do not pin a kernel to work around this, however confidently you are told to. The issue body still recommends it and its own thread has overtaken that: running every KJNodes mode at ~186k tokens on the Blackwell box, the author reports "Short version is that none of them work here, and I think it changes the conclusion." — the FP16 alternatives abort the process or raise cudaErrorIllegalAddress. pepikir withdrew his own pinning proposal on that basis, because "which is strictly worse" than the bug it replaces.

So, concretely, on an RTX 4080. Build 2.x and use the H3 node — that remains the fastest configuration, and the only measured H3-plus-sage numbers anywhere are pepikir's on sm_86, where both paths ran clean at "1.37× on sampling" against a fixed-seed non-sage reference on this page's exact DiT file. Then look at your output, and look hardest as you lengthen clips: the failure mode is a clean-looking run that is not clean, it appears as a cliff rather than a gradient, and your architecture is the one nobody has checked. If you do hit it, the lever with no open failure report attached is not a different kernel but no sage at all. And a posted result either way — with the token count worked out by the formula above — would be the first sm_89 datapoint the thread has.

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. Two sibling templates ship alongside it — video_minimax_h3_i2v.json and video_minimax_h3_r2v.json — and the reference-to-video one matters more on this page than on most, because the only timing anyone has published for this GPU was measured on it. The ComfyUI tutorial documents all three.

Running

python main.py --disable-pinned-memory

That flag is a prerequisite on this model, not a tuning knob, and the reason has nothing to do with your GPU. ComfyUI page-locks host memory to speed transfers to the card: MAX_PINNED_MEMORY is set to 90% of total RAM on Linux and 40% on Windows, 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 before the 14.610 GiB encoder asks for anything. On a 32 GB box it cannot be satisfied and the process is killed; on 64 GB it can, at the cost of most of the machine.

The flag's effect is measured; only its time cost is not. A 15-second RTX 3090 write-up ran the same model and the same 362 frames twice on a 31,997 MB box with only this flag changed: 29,866 MB of host RAM on defaults, killed by the kernel OOM-killer, against 7,508 MB with --disable-pinned-memory, completed in 23 min 17 s. Different card, same mechanism — pinning is sized from the transformer and system RAM, not from VRAM — and he derives the same ram * 0.90 ceiling independently. What it costs in time nobody has published, and the reason is structural: there is no completed run on both sides of the flag, because the unflagged run is the one that dies. The only with-and-without timing anyone wrote up was withdrawn by its own author on 2026-08-08 as unverified, so this page carries no percentage. The rest of the mechanism, which is not in doubt, is the page cache: at 64 GB the 42.47 GB weight set stays cached whether or not it is pinned, so dropping the pin changes only where the bytes live; at 32 GB it cannot be cached, and the per-step streaming this tier cannot avoid starts arriving off the SSD instead. That is also why the storage row in Requirements says NVMe rather than just "45 GB", and the arithmetic behind it is your own to check: 4.721 GiB of transformer crosses the host link on each of the template's 20 sampling steps, so a single render moves roughly 94 GiB of weights — derived from the numbers above rather than measured. When the weight set fits in page cache that traffic comes out of RAM; when it does not, it comes off the disk, and a SATA link becomes the thing you are waiting for. Use the flag on both tiers; expect to pay for it only on the smaller one. --fast-disk attacks the same problem from the other end, offering in its own help text to "Prefer disk-backed dynamic loading and offload over unpinned RAM. Can be faster for users with fast NVME disks.", and is an alternative rather than a second dose.

--reserve-vram is the knob that moves this card's knife-edge, and on Windows it is the single most useful flag on the page. The argument replaces EXTRA_RESERVED_VRAM rather than adding to it — the assignment sits below both platform defaults in model_management.py — and its help text describes it as the amount "you want to reserve for use by your OS/other software. By default some amount is reserved depending on your OS." Encoder residency needs 0.8 + reserve + 14.610 ≤ 16, so the ceiling is 604 MiB:

• Linux defaults to 400 MiB, leaving 204 MiB of slack. That slack is the whole of the 0.200 GiB margin restated as a budget for everything else on the card. Spending it is a real trade, not a free win.
• Windows defaults to 700 MiB on a card this size, which is already 96 MiB past the ceiling — the 0.093 GiB overshoot from Requirements seen from the other side. --reserve-vram 0.5 brings the encoder back onto the card. The Windows constant is larger for a reason, so revert it if you start seeing stalls rather than speedups.

Queue the template unchanged first, and know what "unchanged" means, because the numbers stored on the generation node are not the numbers it runs. 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 and you get 864×480. Duration is snapped onto a 17k+5 frame grid by the template's own math node, so a 5-second request becomes 124 frames at 24 fps. Steps are 20, sampler res_multistep, scheduler simple. To reach H3's native canvas, set the selector to 0.98 megapixels — and expect it to cost more than the pixel ratio suggests, because the sampler's working set competes with the transformer for the same free VRAM and pushes more of it back across the bus.

What Ada gets from these three files, and what it does not

The nvfp4 text encoder invites a wrong inference on this card, and it is worth answering from the files rather than from a forum. Each safetensors header carries a per-layer comfy_quant descriptor whose payload is a small JSON string; reading them over HTTP range requests, together with the tensor census from the same headers, gives this:

File	Quantised layers	Descriptor	input_scale tensors
qwen3vl_32b_minimax_h3_nvfp4_awq (installed)	351	350 × {"format": "nvfp4", "full_precision_matrix_mult": true}, 1 × int8_tensorwise on the embedding table	0
minimax_h3_fl2va_pruned_int8_convrot (installed)	200	200 × {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256}	0 (by design)
minimax_h3_fl2va_pruned_fp8_scaled (alternative)	200	150 × bare {"format": "float8_e4m3fn"}, 50 with full_precision_matrix_mult	150

The hardware gate does behave differently on Ada, and it points the way you expect. supports_nvfp4_compute() in comfy/model_management.py returns false for any device whose compute-capability major is below 10; yours is 8. So nvfp4 prints under emulated ops at startup where a Blackwell card would show it as native. If you have read a 50-series write-up of this model, this is the one line where its startup log and yours genuinely differ.

It makes no practical difference, and the first row of that table is why. Every one of the encoder's 350 nvfp4 layers declares full_precision_matrix_mult: true, and comfy/ops.py builds its _use_quantized predicate with not self._full_precision_mm as a conjunct — so that flag alone skips the quantised matmul and dequantises the weight into the compute dtype first, on a 5090 exactly as on this card. The file corroborates it from the other side: 351 weight_scale, 350 weight_scale_2 and 100 pre_quant_scale tensors, and zero input_scale, activation scales being precisely what an FP4 tensor-core matmul needs. Read the emulated-ops line as bookkeeping: the accelerated path it disables is one this file declines everywhere.

Do not widen that to the rest of the pipeline — it is the single most over-generalised sentence in this model's coverage. The int8-convrot transformer's 200 quantised layers carry the identical descriptor with no opt-out anywhere in the file, so it really does take its fast path, and that path is gated on the cu130 torch build and a working comfy-kitchen import from step 1 rather than on your architecture. Hardware support is a property of the format; use is a property of the file, and the two files disagree.

The third row is where Ada's FP8 silicon is genuinely live, and it remains the tier's open experiment. minimax_h3_fl2va_pruned_fp8_scaled.safetensors is 20,958,205,608 B = 19.519 GiB — 11.61 MiB smaller than the file this page installs, so on memory it is a straight swap. Its 150 bare float8_e4m3fn layers ship both a weight_scale and an input_scale, i.e. no opt-out plus the activation scale an FP8 matmul actually needs, and supports_fp8_compute() passes from compute capability 8.9 — exactly what you have — while the same layers are forced back to full precision on an Ampere card. Somebody has at least run it: on the repack's discussion #34 a user posting as Heouzen loads the ref2va variant of that file on an H200 and the log reports "19984.52 MB loaded, full load: True". That figure sits 2.78 MiB under the file's own 19,987.30 MiB, so the weights stay packed rather than expanding on load — the same thing the int8 file does, and worth knowing before you assume an FP8 build costs residency. What nobody has published is a comparison of the two files on the same machine at any capacity. This page leads with int8_convrot because it is what the official template references and what every published report used. 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 — one published number, and it needs its context more than most. Our catalogue has no benchmark rows for this pair; /check/minimax-h3/rtx-4080 returns verdict: unknown. What this card has instead is exactly one figure, and it repays reading closely. On ComfyUI issue #15261, opened 2026-08-03 by a user posting as telppa, the reported measurement is "4080(16G)+64G minimax h3 ref2video 5s 1280x736 need 690s (tests i conducted myself)" — a 5-second reference-to-video clip at 1280×736 with 64 GB of system RAM, on the stock graph: "My workflow uses the official ref2video workflow provided by ComfyUI."

  Four things to hold onto before you plan around 690 s. It is the reference-to-video template, not the text-to-video one this page installs, and r2v additionally encodes the reference material. It is a 1280×736 canvas, more than twice the stock template's 864×480 in pixels, on a tier where time does not scale linearly with pixels. It names no attention backend and no launch flags. And — the detail that matters most on this specific tier — it was measured on Windows: "The tests I conducted in the brand-new ComfyUI_windows_portable 0.30 environment." Under the Windows reserve worked out in Requirements the text-encode stage comes to 16.093 GiB against a 16 GiB card, so on that box the encoder was over the line by 0.093 GiB and the tier's one structural advantage was switched off by default. --reserve-vram 0.5 is the two-word fix, and nobody has published a before-and-after of it on any card.

• What the 2.3× does and does not compare. The issue is titled around a comparison, and the comparison is not symmetrical. The 4080 half is telppa's own run. The other half — "5070ti(16G)+64G minimax h3 ref2video 5s 1280x736 need 300s" — is explicitly second-hand, sourced in the issue body as a markdown link to a YouTube video, on somebody else's machine, with no flags, no attention backend and no ComfyUI version stated. It is a reasonable thing to be puzzled by and a poor thing to treat as a controlled result, and his own reasoning for the puzzlement is worth quoting because it is where the interesting question lives: "The performance of the 5070ti should be very similar to that of the 4080, or even the 4080 might be slightly better. However, the speed is so much slower."

  On shader count he is right, and NVIDIA's own spec pages say so. Line the two up:

  	RTX 4080	RTX 5070 Ti
  Architecture	Ada Lovelace (sm_89)	Blackwell (sm_120)
  CUDA cores	9728	8960
  Memory	16 GB GDDR6X, 256-bit	16 GB GDDR7, 256-bit
  PCI Express	Gen 4	Gen 5

  So the two cards are equal on the one axis people quote — bus width — and differ on three others: this card leads on shader units by about 8%, and trails on both memory generation and host-link generation. On a tier where 4.721 GiB of transformer crosses the host link on every sampling step, that last row is not a boot-time detail; it is in the inner loop. What nobody has published is a decomposition, so this page will not pretend to one: no measurement anywhere separates local memory bandwidth from PCIe transfer from architecture on this workload, and an 8% shader advantage is plainly not the term that produces a 2.3× gap in either direction. The honest summary for an RTX 4080 owner is that having the larger shader count of the two cards did not buy its owner out of a streaming-bound regime, and that the published comparison is a starting point for a question rather than an answer to it.

• No other RTX 4080 datapoint exists anywhere I could find. All 36 discussion threads on the Comfy-Org repack, all 61 on the vendor repo and all 22 on the Turbo adapter were enumerated and fetched individually — 558 messages between them — and the string 4080 appears in none of them. A web search adds nothing but aggregator pages. A stock-template run posted through /contribute would be the first text-to-video timing this card has, and given how much of the above is inference from one Windows reference-to-video job, it would change this page materially.

• The nearest same-architecture, same-capacity figures come from an RTX 4070 Ti SUPER — fewer shader units, same 16 GB Ada regime — and both are few-step Turbo runs rather than stock renders, so read them under the Turbo section below rather than as a guide to a 20-step job. There is also a heavier 16 GB Ada datapoint of a different shape on the repack's discussion #30, where a 4060 Ti 16GB owner reports "4060ti 16gb, 64gb ddr4 ram, OG VAE, no turbo, Spectrum Apply MiniMax H3, 25 steps, 62min @ ~ 150s/it" on a long reference-to-video job. That card sits at the narrow end of this tier — 128 bits and eight PCIe lanes — where yours is 256-bit, so it brackets the range from below; it does not predict your clock.

• 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 on-disk byte counts and ComfyUI's own constants, not measured by us, and both 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-4080.

• Quality notes: the model's known weakness is faces at distance, reported on that same discussion #30 by a 12 GB user who found that raising the canvas did not fix it. It is a property of the model rather than of your card, so neither 16 GB nor 9728 shader units buy you out of it. Frame for close and medium shots. EasyCache is the largest speed lever short of a distillation LoRA and is reported in the same thread to cost quality; A/B it on your own prompts rather than leaving it on.

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

Optional: the Turbo LoRA, and how the 16 GB Ada disagreement actually resolved

larryvrh/MiniMax-H3-Turbo-Lora renders in 4–8 steps instead of ~20, driven by the node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo. Step count is the largest single lever available on a card that streams its transformer, so this matters more here than on a 24 GB part — and the only published reports on 16 GB Ada hardware concern exactly this.

Read casually, those reports contradict each other about whether the pruned base this page installs works at all. They do not, and the resolution is a timeline rather than a hardware difference:

• 2026-08-06 01:36 and 02:04 UTC, on the adapter's discussion #3, a user posting as Meryruizk publishes a key-renaming script and then corrects his own first impression: "I'm getting this so I thought it's not working but I tested and if we ignore the errors the Lora is working on pruned versions too."
• 04:05 UTC, in the same thread, a user posting as Evados reports a completed 8-step run at 1280×720, LoRA strength 1.8 on euler/beta, timed at 47.03 s/it for 6 m 16 s total, "On a RTX 4070ti super 16 gb vram and 32gb ram." — and closes with a flat "Don't work with the pruned model." Note what he was running: his own hand-rolled prefix-renaming script, not the author's node.
• 10:57 UTC, after several users reported the node erroring on pruned_int8_convrot in discussion #11, the adapter's author replies "Node updated for pruned base."
• 11:19 UTC, a user posting as SeanTheITGuy confirms it against the exact file this page installs, with its sha256, and separates the noise from the failure: "To be clear: It does work with this pruned base and your ckpt500, it just spams the console with these errors." He goes on to post 20-step and 8-step timings from that setup — but he never states his GPU anywhere in the thread, so they are not a 16 GB datapoint and this page does not treat them as one.

So the answer for an Ada 16 GB owner is: the pruned base works, through the author's node, on a current checkout. The mechanism is in the node's source and explains why a plain LoRA loader cannot do it: on a pruned base the adapter's adaln update lives in a space the pruning has collapsed into a lookup curve, so it cannot be applied as a weight patch, and the node re-injects it at run time instead. The adaln_proj.linear.weight shape ... is invalid errors are that path announcing itself, not a failure.

What is genuinely unsettled is quality at low step counts, and no card capacity changes it. A 4070 Ti SUPER owner posting as kangklx — "My current hardware is an RTX 4070 Ti SUPER 16GB with 32GB of system RAM." — ran a controlled ladder against a clean 20-step no-LoRA baseline on this exact pruned file and found the artefacts worsening monotonically as steps dropped, improving markedly once he switched to the pack's dedicated Turbo sampler but not disappearing at 4 steps. Another participant in that thread is blunter: "Forget about 4 step. 4 step is bad. Minimum is 6 steps". The adapter's own card agrees the work is unfinished, though not in the direction an earlier draft of this page claimed — it says "Still a preview — training continues; the two areas still being improved are" audio and behaviour under fast, intense motion, which is a live training run rather than an abandoned one, and it names audio as a known weak point in advance of kangklx finding it. Get a known-good 20-step baseline first, then try Turbo at 8 steps before 6, and update the node before concluding anything. The node pack's low_vram switch merges the LoRA into the weights for the lowest peak — attractive at 16 GiB — but its own README says the result is softer specifically on quantised and pruned bases, which is exactly what you are running.

The licence point from the top of this page reaches here too: an adapter's own permissive tag covers the adapter, not the base weights it loads against.

Troubleshooting

MemoryError from UNETLoader on a card that has not started rendering

Check the download before you touch a single flag. This failure has been reported on Ada hardware with a full 64 GB of RAM, and the cause was a file that matched on size and not on hash — a truncated download is invisible until the loader parses the safetensors header. Re-hash the transformer against the repack before you start theorising about memory.

ComfyUI is killed while loading, or dies on system RAM rather than VRAM

That is the pinned-memory arithmetic in Running, not your GPU: 39.060 GiB of page-locked host memory requested for a 19.530 GiB transformer. --disable-pinned-memory is in this page's launch command for that reason. If it still dies, --fast-disk is the other lever, and --cache-none is not — it controls node-output caching rather than weight residency.

Generation is far slower than 9728 CUDA cores ought to be

Rule the software out before you blame the tier, in this order. First, grep the startup log for a comfy-kitchen import failure or for the cu130 warning in Installation step 1; either silently removes the int8-convrot fast path while ComfyUI keeps running normally, and it is the single most likely way an RTX 4080 lands near a much smaller card's timings. Second, confirm float8_e4m3fn sits on the native side of the Native ops: line — if it does not, supports_fp8_compute() did not see an Ada device and something is wrong with the torch build. Third, check the resolution the sampler actually received rather than the one shown in the node's widgets; see Running. Fourth, if you are on Windows, try --reserve-vram 0.5 and compare — the default reserve puts the encode stage 0.093 GiB over your card, and that is the one thing on this list that is specific to a 16 GiB part. What is not the explanation is the nvfp4 encoder being emulated on Ada: that costs you nothing a Blackwell card is not also paying.

SageAttention output looks like noise

Do not reach for a different kernel, and do not expect switching between the flag and the node to fix it — on sm_89 both land on the FP8-PV path, and pinning an FP16 alternative is what issue #15263's own thread walked back after every explicit mode crashed on the card where it was tried. Installation step 3 has the full picture. The short version: turn sage off entirely, confirm the output is clean without it, and work out your token count as ceil(frames/4) × (W/32) × (H/32) before you conclude anything — the only reported boundary is a cliff between roughly 151k and 167k tokens on sm_120, and the stock template on this card is 12,555. If you are nowhere near that and still seeing noise, you have found something the thread has not, and it is worth posting there with your card, your sage version and your checkpoint.

Two cheaper things to eliminate first. Only the last attention patch applied takes effect, so a workflow that enables two of them has one silently dead and you may not be running what you think. And SageAttention 3 installs under a different package name (sageattn3) that neither the startup flag nor the H3 node resolves.

Somebody tells you a 16 GB Ada number that does not match yours

Be careful which 16 GB card it came from. This capacity tier runs from a 128-bit board on eight PCIe lanes at one end to 256-bit boards like this one at the other, across two NVIDIA architectures and an AMD one, and every single member of it streams the same 19.530 GiB transformer — so the tier's published figures differ by more than architecture normally accounts for. Numbers also move with the template — text-to-video, image-to-video and reference-to-video are three different memory and time questions — with the canvas, with the attention backend, and, on this tier specifically, with the operating system. When you compare, name all five.

Nothing here matches your problem

Runtime errors belong at ComfyUI/issues, template problems at workflow_templates/issues, attention-patch problems at ComfyUI-KJNodes/issues, and Turbo-LoRA problems at the node repo's issues. And if you get a clean stock run on this card, a timing sent through /contribute is worth more to the next reader than every derived number here — this GPU's entire published record is one reference-to-video job filed as a bug.