MiniMax H3 on RTX 4080 SUPER: 16 GB, and the one 4080 number that is nearly yours

What You'll Build

A ComfyUI graph on one RTX 4080 SUPER 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 has an awkward job to do before it can be useful, so it does it first. Exactly one published H3 timing exists for anything called a 4080, and the person who measured it wrote "4080(16G)" — not SUPER. If you own the SUPER, the closest number in the world to your card names a card that is not yours, by a margin nobody has quantified. The two sections below establish what the difference between those cards actually is according to NVIDIA, why it lands on an axis this particular workload is not bound by, and what would have to be measured to close the question. If you came here for the install, skip to Requirements; the arithmetic there is the same on every 16 GB card and it is the arithmetic that decides whether you get a render at all.

⚠️ 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 says 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 the model card is the uninformative other, with license_name: minimax-h3-community-license-agreement beside it, so a catalogue filter keyed on that field sails straight past the territorial restriction. And nothing downstream relaxes it — the Comfy-Org repack installed below declares the same licence and links back to the same file; a community re-quantisation is a derivative; an adapter's own permissive tag covers the adapter, not the base weights it patches. 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 4080 SUPER (16GB VRAM, Ada, CC 8.9) · 15.800 GiB encode stage, 20.721 GiB denoise stage · See benchmark data

ℹ️ 768p is the local ceiling. H3's 2K output comes from a separate H3-Regenerate-2K pass, which the vendor states is not yet open-sourced and will be released when it is ready — until then 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 model card 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 SUPER (16GB) — not measured by us; the budget below is derived from file bytes and ComfyUI's own constants (/contribute)
RAM	32GB with --disable-pinned-memory; 64GB comfortable	— see Running, where the flag is priced
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. That field is a filter floor — the smallest capacity on which the install documented here runs at all — and it comes from 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."

Is the SUPER different from the plain 4080 here?

Not by anything anyone has published, and the mechanism says the gap should be small. That is a finding rather than a shrug, and it is worth showing the working, because the alternative — inventing a distinction so the page feels card-specific — would be worse than useless on a workload where the wrong expectation costs you an afternoon.

Start with what the vendor claims. NVIDIA publishes the two cards side by side on one page, and the shape of that table is the whole argument:

NVIDIA's published spec	RTX 4080 SUPER	RTX 4080	Difference
CUDA cores	10240	9728	+5.3%
Shader TFLOPS	52	49	+6.1%
Tensor (AI TOPS)	836	780	+7.2%
Boost clock (GHz)	2.55	2.51	+1.6%
Standard memory config	16 GB GDDR6X	16 GB GDDR6X	none stated
Memory interface width	256-bit	256-bit	none stated
PCI Express	Gen 4	Gen 4	none stated
CUDA capability	8.9	8.9	none

Every difference NVIDIA states is on the compute side, and it is single-digit. Every entry on the memory and host-link side is identical, and NVIDIA quotes no bandwidth figure for either card on that page at all. That distribution matters here more than the sizes do, because of what H3 does on a 16 GB card: 19.530 GiB of transformer against 16 GiB of VRAM means part of that module is copied into the card on every sampling step, for the whole run. The stopwatch is dominated by moving weights, not by multiplying them.

Those 10240 cores are worth one more sentence, because they are the most shader units NVIDIA ever put behind 16 GB of Ada and it is easy to mistake that for an advantage here. The plain 4080's 9728 is the only Ada part in the same neighbourhood; the next 16 GB Ada card down, the 4070 Ti SUPER, is at 8448. But note how quickly the ranking scrambles once you leave that one column. The Blackwell RTX 5070 Ti carries fewer CUDA cores — 8960 — and NVIDIA still credits it with 1406 AI TOPS against this card's 836, on GDDR7 rather than GDDR6X. The RTX 5080 is also a 16 GB, 256-bit card and beats this one on the core count too, at 10752. So "most cores in the tier" is a leaderboard the workload is not reading, and any page that calls a 16 GB part the fastest silicon at its capacity is quietly choosing whichever column flatters it.

The one person who has published an H3 timing for a 16 GB Ada card arrived at the same axis from the other direction, by being confused. On ComfyUI issue #15261 a user posting as telppa could not understand why his card was so much slower than a 5070 Ti — "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." — and the reply that landed, from a commenter posting as TheLeastMost, put it on the axis NVIDIA's table shows no gap on: "When using neural networks, its rarely about compute capabilities (which yes 4080=5070ti, in games), its about memory bandwidth."

So: the SUPER's advantage is roughly 5–7% of the thing that is not the bottleneck, and zero of the thing that is, by NVIDIA's own accounting. The honest expectation is that a 4080 SUPER and a 4080 land close enough together on this workload that no published measurement could tell them apart — and none has tried. The catalogue's own answer to the pair is empty: /check/minimax-h3/rtx-4080-super returns verdict: unknown with zero benchmark rows.

What would change this. One stock-template run on each card, same canvas, same step count, same launch flags, same weight files, wall-clock recorded for the whole job and VRAM polled at one-to-two-second intervals. Two people with a stopwatch and the same workflow JSON would settle in an afternoon a question no amount of spec-sheet reading can. That is what /contribute is for, and this pair is at the top of the list.

The arithmetic that actually decides your run

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 the denoise pass and the encoder fit; on a 12 GB card neither does. 16 GiB is the only consumer capacity where exactly one of the two fits, and it is the encoder. The transformer's residency is capped at whatever budget remains and the shortfall crosses the bus every step. That is not a failure mode — it is how this tier works, and it is identical on both 4080 variants because it is decided by 16 GiB, not by 512 CUDA cores.

The 1.191 GiB is not a rule of thumb. minimum_inference_memory() in comfy/model_management.py returns (1024 * 1024 * 1024) * 0.8 plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux — 1.190625 GiB, printed above rounded to three places.

Read that 0.200 GiB as thin rather than as headroom, for three reasons, and the first one is the one this page returns to later.

On Windows the sign flips. EXTRA_RESERVED_VRAM is 600 MiB there, plus a further 100 MiB once the card reports more than 15 GiB. Check the indentation yourself instead of taking my word for it: that extra 100 MiB is nested inside the if WINDOWS: block, so it is a Windows surcharge and not a general large-card one, and your card is on the wrong side of the 15 GiB 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. comfy/model_management.py is byte-identical at tags v0.30.0 and v0.30.2, so this is not something a point release introduced or fixed — it applies to every release that can run H3 at all.

The budget is computed against free VRAM, not capacity. get_free_memory() in the same file reads torch.cuda.mem_get_info(dev), which reports 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. When free memory drops, ComfyUI keeps proportionally fewer weights resident and streams the rest; on NVIDIA the alternative floor term in that calculation is disabled outright, since MIN_WEIGHT_MEMORY_RATIO is 0.4 by default and reset to 0.0 under if is_nvidia(). It is the same mechanism that runs a 19.530 GiB transformer on a 16 GiB card at all.

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. The newest tag when this page was written was v0.30.2.

The CUDA version is a hard gate in ComfyUI's own source, not folklore. comfy/quant_ops.py parses torch.version.cuda, and if the major version is 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 supplies the accelerated kernels for the int8-convrot transformer you are about to download. Nothing errors; everything is simply slower. Note the gate is on the CUDA version, not on your architecture — nothing about Ada is disadvantaged here except an out-of-date toolkit.

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. A failed import there leaves ComfyUI running normally with the fast path dead — one buried error line and no other symptom.

While you are in that log, find the line ComfyUI prints as Native ops: … , emulated ops: …. On this card float8_e4m3fn and float8_e5m2 belong on the native side and nvfp4 on the emulated side. Both are expected; the section on the FP8 transformer below explains why neither is a problem.

2. Download the four model files

Run these from the ComfyUI root and pass the filenames as positional arguments — handing several of them to --include makes everything after the first positional anyway and drops the flag, with only a UserWarning to say so.

pip install -U "huggingface_hub[cli]"

hf download Comfy-Org/MiniMax-H3 \
  diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
  text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
  vae/minimax_h3_video_vae_fp16.safetensors \
  vae/minimax_h3_audio_vae_fp32.safetensors \
  --local-dir models

The repo's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models lands all four where the loaders look.

Take the nvfp4 text encoder here, 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, which would leave the run with no stage that fits at all. Take the pruned transformer too: the unpruned int8_convrot build is 34,038,892,334 B = 31.701 GiB, and Comfy-Org's launch post describes the pruning as removing modulation weights in favour of a functionally equivalent lookup table.

3. SageAttention — two different things share one name, and only one of them needs a 2.x build

This step is where a lot of confused advice lives, so here is the split, checked in the source of all three projects rather than inferred from forum consensus. There are two ways to put sage attention in front of H3 and they have different install requirements and different failure modes.

ComfyUI's global --use-sage-attention flag works on the stock PyPI package. comfy/ldm/modules/attention.py imports exactly one symbol, from sageattention import sageattn, and the current PyPI release — 1.0.6, which is genuinely the newest the index carries, the whole list being 0.1.0 and 1.0.0 through 1.0.6 — exports precisely sageattn and sageattn_varlen from its __init__. So the flag resolves and runs on a plain pip install sageattention. It is also true, and not in dispute, that attention_sage drops back to the plain PyTorch path only when its caller passes low_precision_attention=False, and that H3's attention call site in comfy/ldm/minimax/model.py does not pass it — so the flag does route H3 through sage. What you should not conclude from that is that it is the cause of the noise reports; see below, where that explanation is retracted by the person who proposed it.

The H3-specific KJNodes patch needs 2.x. nodes/ltxv_nodes.py 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 in the 1.0.6 wheel exactly one of those six (attn_false) exists. The import raises, the architecture probe never runs, and the node reports "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." That failure is an import failure, so it is architecture-independent: the same five symbols are missing whether you are on Ampere, Ada or Blackwell.

Getting 2.x is an operating-system question, not an architecture one, and on this card the Windows side is a download:

• Windows. woct0rdho's fork publishes prebuilt wheels and states: "The latest wheels support GTX 16xx, RTX 20xx/30xx/40xx/50xx, A100, H100, AGX Orin (sm75/80/86/87/89/90/120)." Your compute capability is 8.9 and sm89 is in that list unconditionally, so pick the wheel matching your torch and CUDA from the releases page and stop.
• Linux. Build from source. Nobody publishes a compiled wheel for you, and neither place one could come from has one: every file in the PyPI release list above is a py3-none-any pure-Python wheel plus an sdist — no compiled artefact for any platform — while the only project distributing binaries scopes itself in its own title, a "fork for Windows wheels and easy installation", builds them behind Visual Studio and the Windows SDK, and states why the index route does not exist: "We cannot publish the wheels to PyPI, because PyPI does not support multiple PyTorch/CUDA variants for the same version of SageAttention."

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 own CUDA 13 toolkit 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.

What you get for the build is a first-class branch rather than a fallback. In that node file the sm89 path 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 (lines 1910–1916), upgrading to the accum_f16 variant once get_cuda_version() reports at least 12.8, which cu130 does. That is an INT8-QK / FP8-PV kernel, and it is the one place in the documented install where the tensor cores NVIDIA credits with 836 AI TOPS on the SUPER are unambiguously doing work. The sm120/sm121 branch calls into the same _qattn_sm89 module, so Blackwell borrows these kernels; on your card they are native.

Load the patch as the MiniMaxH3MemoryEfficientSageAttentionPatch node, under KJNodes' KJNodes/minimax category. It replaces the attention forward wholesale rather than routing through ComfyUI's shared optimised-attention path.

The noise reports, what they are actually about now, and your exposure

You will find a widely linked ComfyUI issue that appears to say sage breaks H3 outright. Read it at its current state rather than at its title from launch week, because both its title and its explanation have changed, and the version most pages repeat is the retracted one.

Issue #15263 is open, and is now titled, in its current revision, "MiniMax H3: SageAttention FP8 PV kernels produce noise above ~160k tokens on sm_120". Its author, posting as AI4VFX, put a dated retraction at the top of his own report: "This turned out to be the FP8 PV sage kernel, not a missing low_precision_attention=False." He had already stepped back from the framing three days earlier — "sage isn't broken on H3, and my issue title is too strong." — and the one-line fix that had been proposed for the call-site theory was closed unmerged on his own instruction. So the missing-kwarg explanation this page's previous paragraph is careful not to draw a conclusion from is dead, and any page still teaching it as the cause is teaching a withdrawn hypothesis.

The finding that replaced it is narrower and sharper, and it has three properties that matter here.

It names the kernel family this card runs. A commenter posting as pepikir, who did the diagnosis, put it this way when the architecture split first came up: the FP8-PV CUDA kernels that 2.x dispatches to on sm_89 and above are "a genuinely different kernel, and a plausible place for a model-specific break that Ampere never reaches." Your card is sm_89, and the _qattn_sm89 call two paragraphs up is that family. The remedy this page recommends is also the current suspect. That is not a reason to skip the step, but it is a reason to look at your output rather than assume it.

It is length-gated, and the boundary is a cliff. AI4VFX's own bracket on Blackwell: "So the crossover is somewhere between 154k and 167k, tighter than the 154k/184k I had before. And it's a cliff, not a slope." Clean at 150,960 attention tokens, garbage at 167,280, nothing in between. A short clip that comes out fine therefore proves nothing about a long one on the same install.

And your exposure is unestablished in both directions. There is no H3 sage report on sm_89 at all, clean or broken — every noise report in that thread is sm_120, and the only clean measurements are sm_86. Worse, every sm_120 noise report that states a checkpoint is on the bf16 transformer and bf16 text encoder, while the only participant running pruned_int8_convrot — the file this page installs — is on sm_86. So the defect has never been tested against this page's file set on any card. Do not read that as safety. Sage operates on activations, not on weights, so there is no mechanism by which the checkpoint obviously matters; what the census establishes is that nobody has checked our configuration, not that our configuration is fine.

What it does not license is pinning a kernel. That workaround circulated for a day and was withdrawn by the person who proposed it, after AI4VFX ran every mode on Blackwell and found the alternatives aborting the process or corrupting memory rather than merely producing noise. His conclusion, and the right one to carry: "Your original instinct — take H3 off the low-precision path — is the right lever on that arch." On sm_120 a pin converts a bug you might never reach into a crash you certainly will; nobody has established that sm_89 behaves either way.

The reassuring part, and it is arithmetic rather than hope. The boundary sits far outside what a 16 GB card can be asked to render. Counting attention tokens the way that thread does — ceil(frames/4) × (W/32) × (H/32) — the stock template is 12,555, native canvas at five seconds is 31,248, and ten seconds at native canvas is 61,488. H3's own area cap is MAX_PIXELS = 768 * 1344 in comfy_extras/nodes_minimax_h3.py, and at the very top of the model's trained frame range that ceiling is 91,728 tokens — 55% of the first row anyone has seen fail. No job inside the model's designed envelope reaches the boundary on any GPU, which is why this page still installs the node. Carry pepikir's own caveat on the metric, though — of the very formula above he writes "I don't think it's the model's literal sequence length", because the model's own video_latent_t() yields more temporal positions than ceil(frames/4) does. It ranks jobs reliably; it is not an absolute.

4. Load the official template

Open ComfyUI, go to Template Library and pick MiniMax H3 Text to Video, or drag in video_minimax_h3_t2v.json. It wires exactly the four files above. The ComfyUI tutorial documents this template plus the image-to-video and reference-to-video variants.

Running

python main.py --disable-pinned-memory

That flag is a prerequisite, not tuning, and it is about system RAM rather than VRAM. ComfyUI page-locks host memory to speed transfers to the GPU. MAX_PINNED_MEMORY is set to 90% of total RAM on Linux and 40% on Windows unless the flag is passed, and pinned_hostbuf_size(size) then returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size, page-locked, neither swappable nor reclaimable. For the 19.530 GiB transformer alone that is a request for 39.060 GiB of pinned host memory on any machine with roughly 22 GB or more of RAM, before the 14.610 GiB encoder asks for anything. A 32 GB box cannot satisfy it and the process is killed. Pass the flag on 64 GB too — it can be satisfied there, but only by handing a third of the machine to something you get nothing back from.

One measured baseline exists for the default launch, and a 32 GB owner should have it. On the repack's discussion #6, the same user quoted below ran one job on an RTX 5070 Ti with this exact four-file set and varied only the startup flag, under the heading "One startup flag changes the RAM requirement by ~3.6x.": ComfyUI's resident-set peak was 45.4 GiB with no flags at all. One person, one machine — and the flag he varied is --fast-disk, not the one on the launch line above, so take the baseline rather than the delta. What it confirms is the arithmetic's prediction from the other side: the default launch wants around 45 GiB and a 32 GB machine has nowhere to put it.

What the flag costs you in speed is unmeasured, and the mechanism says it is not the same answer at 64 GB and at 32 GB. Page-locking governs how the weights reach the GPU, not where they live in between. At 64 GB the 42.47 GB weight set stays in page cache whether or not it is pinned, so dropping the pin changes the transfer path and not the source of the bytes, and the cost should be small. At 32 GB the set cannot stay cached, so the streaming this tier cannot avoid starts arriving off the SSD — a different and much slower path — and nobody has published how much that costs, on this card or on any other. Take the flag regardless: the alternative at 32 GB is not a slower render, it is a killed one. Put the weights on the fastest NVMe you own, and read the Requirements table's "comfortable" at 64 GB as covering this as well as the pinned buffer itself.

--reserve-vram — the one flag that moves this card's knife-edge

--reserve-vram replaces EXTRA_RESERVED_VRAM outright rather than adding to it; the assignment sits below both platform defaults in model_management.py. Its own help text in comfy/cli_args.py describes it as what it is — "Set the amount of vram in GB you want to reserve for use by your OS/other software." Encoder residency needs 0.8 + reserve + 14.610 ≤ 16, so your ceiling is a 604 MiB reserve. Read your platform off that:

• Linux defaults to 400 MiB, leaving 204 MiB of slack — which is the 0.200 GiB margin above, restated as the most you can hand a desktop session before the encoder stops being resident. Spending it is a real trade rather than a free win, and the budget is measured against free VRAM anyway.
• Windows defaults to 700 MiB on a card this size and is therefore already 96 MiB past the ceiling. --reserve-vram 0.5 brings the encoder back onto the card. That constant is larger on Windows for a reason — the driver can back allocations out of system memory once VRAM runs out — so you are spending genuine safety margin to buy residency. Try it, and revert if you start seeing stalls instead of 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. Its width and height are wired inputs fed by a ResolutionSelector set to 16:9 at 0.4 megapixels, and a connected input beats a stored widget, so the 1344×768 sitting in the widgets never reaches the sampler; you get 864×480. Frame count is snapped onto a 17k+5 grid by the template's own math node, so a 5-second request becomes 124 frames. Steps are 20, sampler res_multistep, scheduler simple. To reach H3's native canvas, set the selector to 0.98 megapixels.

The three stages

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

That the encoder genuinely becomes resident on this capacity has been observed, though on a different architecture: on the repack's discussion #6 a user posting as UdonJP sampled an RTX 5070 Ti at one-second intervals and logged "24.1 GiB after TE load (VRAM 15,219 MiB, 100% util = encoding)". 15,219 MiB is within 259 MiB of the encoder's staged size, so essentially the whole module was on the card. Same capacity, same four files, different silicon — read it as confirmation that the 0.200 GiB in the table is not a paper margin, not as a number for your card.

What is not settled, and you should not inherit it from any page in this family, is which stage owns the run's high-water mark. Every published VRAM peak for a 16 GB card is a whole-run figure; nothing anyone has posted decomposes a peak by stage. There is even a mechanical argument against the encoder owning it: on the one card that has been measured across accelerator configurations, swapping the attention node moves the run peak by about 2.4 GB, and attention is denoise-side. Size your card against the 15.800 GiB encode figure, because that is the number that decides whether you are in the game; do not size it against a peak nobody has isolated.

Where the SUPER's extra silicon could actually show up

There is exactly one place in this model's file set where the compute difference NVIDIA advertises would plausibly be visible, and nobody has run the comparison on any card — which makes this the most useful experiment a reader of this page could do.

Reading the shipped safetensors headers directly over range requests, layer by layer:

File	Quantised layers	Descriptor	input_scale tensors
qwen3vl_32b_minimax_h3_nvfp4_awq (installed)	351	350 × {"format": "nvfp4", "full_precision_matrix_mult": true}, 1 × {"format": "int8_tensorwise"}	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

Row one settles the NVFP4 question that circulates about Ada. supports_nvfp4_compute() in comfy/model_management.py returns false below compute-capability major 10, and yours is 8 — so nvfp4 prints as emulated at startup where a Blackwell card would show it as native. It makes no practical difference, because 350 of the encoder's 351 quantised layers declare full_precision_matrix_mult: true, and comfy/ops.py builds its _use_quantized predicate with not self._full_precision_mm as a conjunct. The flag skips the quantised matmul and dequantises the weight first — on a 5090 exactly as here. The header agrees from the other side: 351 weight_scale, 350 weight_scale_2 and 100 pre_quant_scale tensors, and zero input_scale, activation scales being exactly what an FP4 matmul needs. The encoder is a 14.610 GiB container and that is its entire contribution on every architecture. Hardware support is a property of the format; use is a property of the file.

Row two is the counterexample that keeps row one honest, so do not widen the conclusion. The int8-convrot transformer carries no opt-out on any of its 200 layers, so its fast path is real — gated on the cu130 torch build and a live comfy-kitchen import from step 1, not on the file.

Row three is the interesting one for this card. minimax_h3_fl2va_pruned_fp8_scaled.safetensors is 20,958,205,608 B = 19.519 GiB, which is 11.61 MiB smaller than the file this page installs — a straight swap on memory, changing nothing about the fit. But 150 of its 200 quantised layers carry a bare float8_e4m3fn descriptor with both a weight_scale and an input_scale: no opt-out, and the activation scale a real FP8 tensor-core matmul needs. supports_fp8_compute() passes from compute capability 8.9, so on Ada that path is native where an Ampere card would be forced back to full precision. (The other 50 — every block's mlp.fc2 — do carry the opt-out and dequantise regardless.)

So this is the file where the SUPER's 836 AI TOPS against the 4080's 780 would be doing something the plain card's would not do quite as fast — and it is also the file where the effect has the best chance of being swamped, because a faster matmul does not help much when the weights it multiplies are still arriving over PCIe. This page keeps int8_convrot as the lead: it is what the official template references, what the maintainers recommend, and what every published report used. If you run both files here and time them, that is genuinely new information about this architecture, 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-4080-super returns verdict: unknown. Nothing published names an RTX 4080 SUPER running H3: all 36 discussions on the Comfy-Org repack and all 22 on the Turbo adapter were enumerated and fetched individually for this page, and the string "4080" appears in none of them. What exists is one figure on a card called a 4080, and it is worth reading carefully rather than adopting. On ComfyUI issue #15261 telppa reports "4080(16G)+64G minimax h3 ref2video 5s 1280x736 need 690s (tests i conducted myself)". Five things about it before you use it as a yardstick. It is a whole-job total, not a sampling time and not a per-stage figure. It is the reference-to-video graph, which is a different memory and time question from the text-to-video path documented here. It states no launch flags, no attention backend and no weight files. It says "4080", never SUPER. And the 2.3× headline attached to it is not a controlled comparison at all — the 5070 Ti half of it is a number telppa says he heard in a YouTube video, and he confirms in the thread that he could not run the other side himself: "Since I only have one machine(4080+64G), could you run the same test(minimax h3 ref2video 5s 1280x736) and tell me how long it took if possible?" Treat 690 s as one person's order of magnitude for a heavy job on a 16 GB Ada card, and nothing more precise than that.

• One thing that figure does tell you, and it is actionable. telppa states his environment: "The tests I conducted in the brand-new ComfyUI_windows_portable 0.30 environment." Put that through the Windows arithmetic above — reserve floor 1.484 GiB, encode stage 16.093 GiB against 16 GiB — and the encoder was over the line by 0.093 GiB on his run too. So the only H3 timing anyone has published for a card called a 4080 was measured in the regime where neither of H3's large modules is resident and both stream. That is a derivation from ComfyUI's constants and his stated platform, not a VRAM reading he posted; he reported no memory figures. But if it holds, --reserve-vram 0.5 is a one-flag move out of that regime and into the one the table above describes, and it is the first thing to try on Windows before concluding anything about your card.

• 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 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-4080-super.

• Quality notes: the model's known weakness is faces at distance. A 12 GB user opened the repack's discussion #30 reporting that H3 distorts faces badly when the subject is small in frame and that raising the canvas did not fix it — a property of the model, not of your card, so neither 16 GB nor 512 extra CUDA cores buys you out of it. Frame for close and medium shots. EasyCache is the largest speed lever 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.

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

Optional: the Turbo LoRA

larryvrh/MiniMax-H3-Turbo-Lora and its node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo render in 4–8 steps instead of ~20. On a card where the transformer streams every step, step count is the largest lever available, so it matters more here than it would on a 24 GB card.

Nothing about it has been reported on either 4080 variant — the adapter's 22 discussion threads were enumerated for this page and the only 16 GB Ada card named in any of them is a 4070 Ti SUPER. Read the adapter's own card rather than the threads, though, because it has moved fast enough that even week-old forum advice is stale: the project describes itself as still a preview with training continuing, and names audio and behaviour under fast intense motion as the two areas still being improved. Its current guidance is that four steps is the recommended minimum and 4–8 the useful range, that six to eight look noticeably better than four, that going past eight stops helping and can introduce over-sharp artifacts, and that strength should stay at 1.0. It also states that one LoRA file now covers every base including the pruned and curve variants, with the node auto-detecting a pruned base and re-injecting the time conditioning at run time — so the older reports that it does not work on the pruned checkpoint predate that.

Two things that are specific to your capacity. The low_vram switch merges the LoRA into the weights for the lowest peak VRAM instead of applying it at run time, and the card is explicit that this is the softer option on quantised bases and should be turned on only if you run out of memory — on 16 GiB it is worth knowing about before you need it, not by default. And get a known-good 20-step baseline on the four official files first; a distillation adapter is the wrong thing to be debugging at the same time as a streaming-bound install.

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

Troubleshooting

Generation is far slower than a 16 GB Ada card should be

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 carries on running normally, and it is the single most likely explanation for landing near a much smaller card's timings. Then 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. What it is not is the nvfp4 encoder being emulated on your architecture; that costs you nothing a Blackwell card is not also paying, for the reasons set out above.

On Windows, the encoder is streaming and you did not know it

This is the one configuration issue specific to 16 GB cards and it is silent. The Windows reserve puts the encode stage at 16.093 GiB against 16 GiB, so ComfyUI caps the encoder's residency exactly as it caps the transformer's and you never see an error — just a slower run. --reserve-vram 0.5 recovers it. Run headless if you can, and remember the comparison is against free VRAM, so a browser with hardware acceleration on can undo the flag by itself.

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. If it still dies, --fast-disk attacks the same problem from the other end by moving weights into reclaimable page cache; its own help text offers to prefer disk-backed loading over unpinned RAM, which is a different trade rather than a second dose of the same one. --cache-none does nothing for this at all — it controls node-output caching, not weight residency.

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.

The sage patch refuses to load

Check pip show sageattention before anything else. 1.0.6 means you have the PyPI package, which cannot satisfy the KJNodes H3 patch on any architecture — see Installation step 3, and note that SageAttention 3 installs under a different package name (sageattn3) which the --use-sage-attention flag does not resolve either. Separately, advice to "update ComfyUI to 0.31" circulates and is simply wrong: the repository's tag feed ends at v0.30.2 and carries no 0.31 tag at all. The real floor is 0.30.0.

SageAttention output looks like noise

Switching from the global flag to the KJNodes node is not the fix, and for a while this page and several like it said it was. Both routes land on the same FP8-PV kernel family on sm_89, and the call-site explanation that made the swap sound curative was retracted by its author — Installation step 3 has the current state of issue #15263.

Work through it in this order instead. First, check your token count, because the only established failure boundary is a length cliff around 160k and this card cannot easily be pushed there: ceil(frames/4) × (W/32) × (H/32), which is 12,555 for the stock template and 91,728 at H3's own area cap. If you are an order of magnitude below the boundary, sage is probably not your problem and something else is — a truncated download, a bad attention chain, two patches fighting. Second, if you are genuinely near it, take H3 off the low-precision path — that is, run without sage — rather than pinning a different kernel. Do not pin one. On Blackwell every alternative mode was measured worse than the noise it was meant to avoid, and nobody has run that experiment on Ada at all.

Third, and this is the useful one: report it. sm_89 has no H3 sage datapoint in either direction, and the file set this page installs has never been tested against this defect on any card. A clean run or a broken one, with your token count and checkpoint stated, is worth more here than anywhere else on this page — /contribute.

Nothing here matches your problem

Runtime errors belong at ComfyUI/issues, template problems at workflow_templates/issues, and attention-patch problems at ComfyUI-KJNodes/issues. And if you get a clean stock run on this card, a timing sent through /contribute is worth more to the next reader than every derived number here — this page has none, and the pair it would settle is named at the top.