MiniMax H3 on RTX 4090: 24 GB video+audio, and where Ada's FP8 shows up

What You'll Build

A ComfyUI graph on one RTX 4090 that turns a text prompt — optionally plus a first and/or last frame — into a 24 fps clip with its own synchronised stereo soundtrack, dialogue, effects and music denoised jointly with the picture in a single pass rather than dubbed on afterwards.

Most people buying an RTX 4090 bought it for speed. That is the wrong instinct to bring to this model, and this page is largely about why. H3 is a capacity problem first: its two large modules total 34.140 GiB, so a 24 GiB card holds one of them at a time and the other one is always in flight. What Ada buys you over the same-capacity Ampere card is real but narrower than the spec sheet suggests, and most of it lands in one place nobody expects — the section on Ada's FP8, below, is the whole argument.

⚠️ 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 its Applicable Territory, and Section I.5 defines the exclusions: "means the European Union, the United Kingdom, the Republic of Korea and the United States of America." Section V.4 reaches what you generate, not only what you download: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory."

The machine-readable license: facet on both model cards is the uninformative other, so any filter keyed on that field — including HuggingFace's own — sails straight past the territorial restriction. The Comfy-Org repack installed below does not relicense anything, and neither does a community re-quantisation: an int4, NVFP4 or GGUF conversion of these weights is a Model Derivative and inherits the terms. MiniMax publishes a licence Q&A and an application route for per-deployment licensing at platform.minimax.io/h3-license. This is a summary written by a reader of the text, not legal advice — the linked agreement is the thing that binds you.

Hardware data: RTX 4090 (24GB VRAM) · 20.721 GiB at the binding denoise stage · See benchmark data

ℹ️ 768p is the local ceiling, on this card as on every other. H3's 2K output comes from a separate H3-Regenerate-2K stage, and the model card says of it: "this module is not yet open-sourced. We will release it once it is ready." What runs locally is H3-Base, which the vendor validates at a 768-pixel short edge. A 4090 buys you time, not a resolution tier.

Requirements

Component	Minimum	This recipe
GPU	12GB VRAM via ComfyUI's dynamic VRAM offload; 24GB to keep the denoise pass resident	RTX 4090 (24GB) — not measured by us; the budget below is derived from file bytes and ComfyUI's own reserve constants, and the timings in Results are other people's (/contribute)
RAM	32GB with --disable-pinned-memory or --fast-disk, 64GB without	—
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/

What 24 GB actually buys

Not residency of the pipeline. One line of arithmetic:

text encoder  15,687,142,551 B = 14.610 GiB
DiT           20,970,379,616 B = 19.530 GiB
              ──────────────────────────────
                               34.140 GiB   against a 24 GiB card:  short by 10.140 GiB

So ComfyUI's on-demand eviction runs here, and buying a bigger consumer card would not stop it — 34.140 GiB exceeds even the 32 GiB of NVIDIA's largest consumer part. load_models_gpu in comfy/model_management.py sums what the requested models need and calls free_memory(...), which walks the already-loaded models and evicts until there is room. There is no configuration of the official four files that keeps the text encoder and the transformer co-resident on this card.

What 24 GB buys is that the denoise stage — 19.530 GiB of weights plus ComfyUI's 1.191 GiB inference-reserve floor, so 20.721 GiB — clears the card by 3.279 GiB and never has to stream. That is the stage where nearly all the wall-clock lives, and it is the whole difference between this page and a 12 GB card's. It is also, precisely, what this card has in common with the previous generation's 24 GB Ampere part: same capacity, same regime, same headroom. Do not expect the memory story to be different because the card is newer. Expect the clock to be different.

The 12 GB floor in the Requirements table is not this card's number and is not a peak — it is the smallest capacity on which the install documented here runs at all, and it comes from Comfy-Org's launch post: "Combining this with our dynamic VRAM offloading enables a next-generation 2K video model to run locally on a GPU like the RTX 3060." Below 24 GB the transformer streams; at 24 GB it stops.

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 release v0.30.0 onward. The newest tag at the time of writing is v0.30.2.

The CUDA version is a gate in ComfyUI's own source, not folklore. comfy/quant_ops.py reads torch.version.cuda, and if the major version parses 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 disables the comfy-kitchen CUDA backend, which is what provides the accelerated kernels for the int8_tensorwise+convrot format the transformer below is stored in. Nothing errors; everything is simply slower.

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

Confirm two things in the startup log before going further: the torch version string contains +cu130, and comfy-kitchen's CUDA backend reports 'available': True. If that backend fails to import instead, you get one buried error line and no other symptom.

2. Download the four model files

Run these from the ComfyUI root. Pass the filenames as positional arguments rather than trying to list them behind --include. In huggingface_hub's own CLI filenames is a variadic positional argument while --include binds one value per occurrence, so --include a b c attaches only a to the flag and turns b and c into filenames — at which point the command drops the flag entirely with nothing more than warnings.warn("Ignoring \--include` since filenames have been explicitly set.")`.

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 pruned transformer. The unpruned int8_convrot file is 31.701 GiB — larger than the card on its own, so it streams on every step. That said, it is not a hard wall: a 4090 owner in discussion #3 downloaded it by mistake and ran it anyway, which is where this page's most on-target timing comes from (see Results). Pruning is also not a quality cut in the usual sense: Comfy-Org's launch post describes the removed parameters as the model's modulation weights, replaced by a functionally equivalent lookup table with no loss in output quality claimed.

Then verify the hashes. On this exact card, a MemoryError from UNETLoader has already turned out to be a truncated download rather than a memory problem — see Troubleshooting. Re-hashing a 21 GB file is cheap next to re-diagnosing it.

3. SageAttention 2.x — the same source build the 50-series needs

It is tempting to assume Ada gets an easier ride here than Blackwell. It does not, and the reason is worth one paragraph because it saves an afternoon.

pip install sageattention gets you 1.0.6, the newest release on PyPI and a pure-Triton package with no compiled kernels at all — the wheel is 20 KB and sageattention/core.py defines exactly two public functions, sageattn and sageattn_varlen. KJNodes' H3 patch needs five other symbols from that module (per_thread_int8_triton, per_warp_int8_cuda, per_block_int8_triton, per_channel_fp8, get_cuda_arch_versions) and imports them in a single statement, so on 1.0.6 the import fails, the architecture probe never runs, and every H3 sage node raises "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." — the error a 5060 Ti owner filed as KJNodes issue #721, where the maintainer's reply was "As the error says, you need newer version of sageattention." That failure is architecture-independent: it is an import, and it fails identically on sm_86, sm_89 and sm_120. The node's own schema in nodes/ltxv_nodes.py says so up front — "Requires latest sageattention version."

So you need a 2.x build. There is one genuine convenience on Ada, and it is an operating-system split rather than an architecture one:

• Windows. woct0rdho's fork ships prebuilt wheels and states that "The latest wheels support GTX 16xx, RTX 20xx/30xx/40xx/50xx, A100, H100, AGX Orin (sm75/80/86/87/89/90/120)." — sm89 is in that list, so a 4090 on Windows installs a wheel and stops.
• Linux. Build from source — there is no prebuilt wheel to install. That fork publishes Windows builds only: every asset across its releases is a sageattention-2.2.0+cu1**torch*-cp3**-abi3-win_amd64.whl, and PyPI carries nothing above the 1.x line. The build is the same as for any other arch with your own compute capability substituted:

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 above is an example, not a requirement. --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.

This step is optional. It is also the one part of the documented install where the 4090's FP8 silicon is unambiguously in the compute path, which is the next section's subject.

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. The image-to-video template uses the same four files and the same generation node — connect first_frame and/or last_frame and it switches from t2va to fl2va by itself.

Running

python main.py --disable-pinned-memory

Queue the template unchanged first, and know what "unchanged" means, because the node's stored widgets disagree with what actually runs. The template's ResolutionSelector (node 115) is set to 16:9 (Widescreen) at 0.4 megapixels with a multiple of 32, and its two outputs are wired into the generation node's width and height inputs; a connected input beats a stored widget, so the 1344×768 sitting in the widgets never reaches the sampler. sqrt(0.4 × 1024² / (16×9)) = 53.9695, rounded to the nearest 32 on each axis, gives 864 × 480. Frame count is snapped to a 17k+5 grid by the template's own math node, so a 5-second request becomes 124 frames and a 10-second one becomes 243. The scheduler is simple at 20 steps and the sampler is res_multistep. To actually get 1344×768, set the Resolution Selector to 0.98 MP.

The three stages, and why one module is always in flight

Stage	Resident weights	ComfyUI's reserve	Stage total	Surplus on 24 GiB
Text encode (Qwen3-VL-32B, NVFP4-AWQ)	14.610 GiB	1.191 GiB	15.800 GiB	8.200 GiB
Denoise (H3 DiT, pruned int8+convrot)	19.530 GiB	1.191 GiB	20.721 GiB	3.279 GiB
Decode (video VAE fp16)	4.850 GiB	1.455 GiB	6.305 GiB	17.695 GiB
Text encode with int8_convrot instead	25.277 GiB	1.191 GiB	26.468 GiB	−2.468 GiB

Every row but the last fits. No two rows fit together. The middle row is the one that binds, and it is the only row that does not move with resolution — it is weights plus a fixed floor — so raising the canvas to 1344×768 does not change whether this fits, it only lifts the decode reserve to 2.851 GiB (stage total 7.701 GiB), still nowhere near binding.

The 1.191 GiB figure is ComfyUI's minimum_inference_memory() floor on a Linux host: 0.8 GiB plus a 400 MiB EXTRA_RESERVED_VRAM, both constants in comfy/model_management.py. On Windows the constant is 700 MiB on a card this size — 600 MiB base, plus a further 100 MiB once total VRAM exceeds 15 GiB, a clause nested inside the Windows branch and applying nowhere else — making the floor 1.484 GiB and every surplus above correspondingly smaller. The sampler's own activation estimate for the stock latent is well under that floor either way, so the floor is what binds.

The last row is the one a 32 GiB card gets and you do not. The repack also ships qwen3vl_32b_minimax_h3_int8_convrot.safetensors at 27,141,342,152 B = 25.277 GiB, and the sharpest quality argument on the thread favours it — in discussion #16 a commenter posting as V33rGeer writes "you shouldn't be using the NVFP4 text encoder, as it compromises the coherence of tricky setups", with the exemption "unless your system physically cannot handle it". On 24 GiB that exemption is doing real work: the stage comes to 26.468 GiB against a 24 GiB card, so it streams. You can still load it — text encoding is a single forward pass and, as one participant in that thread puts it, "The text encoding seems to be almost instant since the text model isn't actually generating anything" — but you are paying 10.668 GiB of extra transfer for it on every run (27,141,342,152 − 15,687,142,551 B), and no one has published a 4090 timing for the swap. Treat it as a quality experiment, not a tuning step, and please send a number through /contribute if you run both.

Output lands in ComfyUI/output/video/ as an MP4 with the stereo track already muxed in by CreateVideo.

What Ada's FP8 does, and does not do, here

The RTX 4090 is the first consumer NVIDIA card with FP8 tensor cores, and it is natural to expect that to matter for a model shipped in exotic numeric formats. Mostly it does not, and the mostly is the interesting part. Three separate questions get conflated; here they are separated, each answered from ComfyUI's source and from the files' own headers rather than from architecture marketing.

1. The hardware gate does pass, and it is the one real difference from Ampere. supports_fp8_compute() in comfy/model_management.py returns True for an NVIDIA device of compute capability 8.9 or higher. A 4090 is exactly 8.9. Ampere consumer cards are 8.6, so the same function returns False on them. pick_operations turns that into a set of disabled formats and prints them at startup, so the line to grep for on this card reads Native ops: … , emulated ops: … with float8_e4m3fn and float8_e5m2 on the native side. On an Ampere card those two move to the emulated side. That is a genuine, checkable Ada-versus-Ampere difference for this model, and it is the only one in the memory-and-compute path.

2. It is inert for the four files above, because none of them is an FP8 file. Reading the safetensors headers directly:

• all 200 of the transformer's quantised layers carry {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} — identical descriptors, no full_precision_matrix_mult opt-out anywhere in the file, so this one really does take its fast path. That path is never architecture-disabled on any NVIDIA card; it is gated on the comfy-kitchen backend from step 1 instead;
• 350 of the text encoder's 351 quantised layers carry {"format": "nvfp4", "full_precision_matrix_mult": true} — the 351st is model.embed_tokens, a 29-byte {"format": "int8_tensorwise"} with no opt-out, which is an embedding lookup rather than a matmul and changes nothing. supports_nvfp4_compute() requires compute capability 10 or higher, so nvfp4 is emulated on a 4090 — but the file declines the accelerated path anyway, on every card including Blackwell: that flag sets _full_precision_mm, and the forward pass builds _use_quantized with not self._full_precision_mm as one of its conjuncts. The file also ships zero input_scale tensors, and activation scales are what an FP4 matmul needs.

That second point is what a Comfy-Org maintainer was getting at in that same discussion #16, when Ada owners asked for an int4 build — "Would it be possible to make 4-bit for those with Ada?" and "yes please! a pruned int4 would get it to a more usable point for those in Ada". Kijai's answer was that the format choice is not a hardware statement: "it's just used as storage format here, there's nothing hardware specific about that". The file's own bytes agree with him. Do not choose the nvfp4 encoder because your card can or cannot do FP4. It is a 14.610 GiB container and that is its entire contribution.

3. There is one file where Ada's FP8 genuinely fires, and nobody has measured it. The repack ships minimax_h3_fl2va_pruned_fp8_scaled.safetensors at 20,958,205,608 B = 19.519 GiB — within 12 MiB of the int8 file this page installs, so it is a like-for-like swap on memory. Its header is a different story: 150 of its 200 quantised layers carry a bare {"format": "float8_e4m3fn"} with both a weight_scale and an input_scale, i.e. no full-precision opt-out and the activation scale an FP8 tensor-core matmul actually needs. On this card that path is native; on an Ampere card the same layers land in pick_operations' disabled set and are forced back to full precision. (The other 50 — every block's mlp.fc2 — do carry "full_precision_matrix_mult": true and dequantise regardless.)

So the mechanism is real and it is specific to this architecture tier. What does not exist is a measurement. The one 4090 owner who reasoned his way to that file said so out loud in discussion #29 — "I downloaded the fp8_scaled version, deciding that it’s better suited for the 4090. Is that right, or should I use int8_convrot instead?" — and got no answer to that question in the thread. This page keeps int8_convrot as the lead because it is the file the official template references, the file every published 24 GB report used, and the file the maintainers recommend. If you compare the two on a 4090, that comparison would be new information and /contribute is where it belongs.

4. Where the FP8 silicon actually earns its keep is attention, not weights. KJNodes' H3 patch dispatches on compute capability, and the branches are not cosmetic. On sm80/sm86 it converts V to float16 and calls qk_int8_sv_f16_accum_f32_attn. On sm89 it quantises V with per_channel_fp8 and calls qk_int8_sv_f8_accum_f32_fuse_v_scale_attn_inst_buf — an INT8-QK / FP8-PV kernel — and with CUDA ≥ 12.8, which cu130 satisfies, it upgrades to the accum_f16 variant. The Blackwell branch reuses those same _qattn_sm89 kernels, so this card is the native home of that kernel family rather than a borrower. A community reporter on ComfyUI issue #15263 describes the same split from the outside: "sageattention 1.0.6 on sm_86 uses the Triton INT8-QK / FP16-PV path. On sm_89+ and Blackwell with sageattention 2.x, sageattn auto-dispatches to the FP8-PV CUDA kernels instead". The same commenter puts H3's attention share at "roughly 55% of sampling at 480p/5s, considerably more at 720p or 15s" — an estimate offered in passing rather than a tabulated figure like his s/it numbers, so read it as an order of magnitude. Even halved, attention is not a corner of the sampling clock.

The honest summary for a 4090 owner: your FP8 hardware is idle for the recommended weights, live in one alternative weight file nobody has benchmarked, and live by default in SageAttention once you have built 2.x. Install step 3 is where the FP8 story pays, not the download list.

Results

• Speed: our catalogue has no benchmark rows for this pair — /check/minimax-h3/rtx-4090 returns verdict: unknown. Unusually for this model, though, published RTX 4090 reports do exist, all of them in the Comfy-Org repack's discussion board and none of them controlled. The most on-target is in discussion #3, where a commenter posting as inflatebot reports: "run on my 4090, although there was definitely slowdown from swapping to system RAM. With a warm prompt encoding, the default T2V workflow took about 100 seconds (obviously more if the text encoder has to run.)" Read that against the Running section: the default T2V workflow is 864×480, 124 frames, 20 steps. It is also the unpruned 31.701 GiB transformer — 12.171 GiB larger than the file installed here, and streaming throughout — so as a bound on the pruned, fully-resident configuration it points the right way. What it is not: a controlled run, a repeated one, or one that states its attention backend.

  For scale on the other side, an RTX 3090 run of exactly this page's checkpoint and exactly the stock template — 864×480, 124 frames, 20 steps, res_multistep/simple — measured 9.00 s/it — 180 s across the 20 sampling steps — against 6.57 s/it with the KJNodes sage patch. Same capacity, older architecture, so treat 180 s as a pessimistic ceiling this card should beat rather than as a figure for it. Two further 4090 reports bracket the slow end, and both need their ambiguity stated. In discussion #6 a commenter posting as HodgeMann reports "4s 720p vid: 1st run was 15:01 then subsequent were 416-422s. The load times are brutal." — roughly seven minutes warm for a 4-second 720p clip on a 4090 with 128 GB of system RAM, which is his own stated hardware. What the thread never settles is which weights produced it. The sentence immediately before those numbers is that the quantised versions are far faster, and he was answering someone who had just said they were downloading the pruned convrot files; but he had also just described running the two largest files in the repack, and a first run of 15:01 collapsing to ~420 s warm is the signature of very large weights loading once and then staying cached. Both readings survive the thread. His own file sizes do not close it either: 66.3 GB is exactly the bf16 transformer, but no text encoder in the repack is 55 GB — the bf16 one is 51.5 GB and the others are 27.1 and 15.7 — so one of his two figures is about 7% off. Cite it as an order of magnitude for an unpinned configuration, not as a measurement of any particular one. TheOneNyaga on the same thread reports "any 12second 1x1 and 16x9 HD videos are averaging between 10 to 13mins." with SageAttention and a third-party workflow from CivitAI — so that one names its attention backend but not its weights, and runs a graph this page does not document. If you run the configuration this page documents, a timing posted via /contribute would be the first controlled number anyone has for this pair.

• VRAM usage: 20.721 GiB at the binding denoise stage — 19.530 GiB of int8 transformer weights plus ComfyUI's 1.191 GiB inference-reserve floor — leaving 3.279 GiB of a 24 GiB card. That is derived from the on-disk byte counts and ComfyUI's own constants, not measured by us, and it covers weights and floor only: the activation working set of a long clip sits on top of it and grows with frames and pixels. Live data, when it exists, will be at /check/minimax-h3/rtx-4090.

• Quality notes: the model's known weakness is faces at distance. A user on a 12 GB card reported in discussion #30 that H3 distorts faces badly when the subject is small in frame, and that raising the canvas did not fix it — a model property rather than a VRAM one, so 24 GB does not buy you out of it. Frame for close and medium shots. EasyCache is a large speed lever reported in the same thread to cost quality; A/B it on your own prompts before leaving it on.

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

Optional: the Turbo LoRA

A community distillation adapter, larryvrh/MiniMax-H3-Turbo-Lora, and its companion node pack, Larryvrh/ComfyUI-MiniMax-H3-Turbo, cut sampling from the usual ~20 steps to 4–8. Nothing about it is 4090-specific and nothing about it is measured on this card — the closest published figure is on a much smaller one. That link is pinned deliberately: the card was rewritten repeatedly while this page was being written, and the current text supersedes the earlier one in ways that matter. At the pinned revision the recommended weights are minimax_h3_turbo_v4_step600_ema.safetensors, the plastic look of the earlier v1 line is described as resolved, and the useful range is 4–8 steps rather than exactly 4. The author still labels the whole thing "Still a preview — training continues", naming audio and behaviour under fast motion as what is still being worked on. Given the step count is the single largest lever on any card, it is worth watching; check whether the card has moved again before you build a workflow around it.

The licence point from the top of this page applies here too: an adapter's own permissive tag does not lift the base weights' territorial restriction.

Troubleshooting

MemoryError from UNETLoader on a card that should fit

Check the download before you touch anything else — this failure has been reported on this exact card. In discussion #29 a 4090 owner on Windows, ComfyUI 0.30.2 and torch 2.11.0+cu130 hit MemoryError inside UNETLoader while the loader was still parsing the safetensors header. A Comfy-Org maintainer's first guess was a corrupt file from a failed download, and that is what it was: "So it was really failed download, same size, but different hash." The same reporter added that the file this page installs was fine for them — "PS. minimax_h3_fl2va_pruned_int8_convrot works OK". A size-matching truncation is invisible until load time, so re-hash before you start editing flags.

Generation is far slower than the numbers above

Grep the startup log for a comfy-kitchen import failure, or for the cu130 warning quoted in Installation step 1. Either one silently removes the int8-convrot fast path while ComfyUI carries on running normally, and it is the single most likely explanation for a 4090 landing near a much older card's timings. While you are in that log, confirm float8_e4m3fn is on the native side of the Native ops: line — if it is not, supports_fp8_compute() did not see an Ada device and something is wrong with the torch build.

Do not extrapolate from other 40-series reports

Architecture-class reasoning misleads badly on this model whenever offloading is involved. ComfyUI issue #15261 is a 4080 owner asking why a 5070 Ti is 2.3× faster at the same job — "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." — measured as "4080(16G)+64G minimax h3 ref2video 5s 1280x736 need 690s (tests i conducted myself)". The first reply, from a commenter posting as TheLeastMost, names the cause: "When using neural networks, its rarely about compute capabilities (which yes 4080=5070ti, in games), its about memory bandwidth." Both of those cards are 16 GB, so both are streaming the transformer on every step and the comparison is dominated by transfer rate. A 4090 holds the denoise stage resident and is not in that regime — which is exactly why a 16 GB Ada number tells you nothing useful about this page, in either direction.

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

The VRAM budget above has room; host memory is the tighter constraint, because ComfyUI stages the full 42.47 GB working set and page-locks it. The arithmetic is in comfy/model_management.py at v0.30.2: MAX_PINNED_MEMORY is set to 90 % of system RAM (40 % on Windows) unless --disable-pinned-memory is passed, and pinned_hostbuf_size(size) then returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size, in pages that can be neither swapped nor reclaimed. For the 19.530 GiB transformer alone that is a 39.060 GiB request, before the 14.610 GiB encoder asks for its own. With the flag passed, MAX_PINNED_MEMORY stays at its -1 sentinel, pinned_hostbuf_size returns 0 and the buffer is never taken at all.

--fast-disk attacks the same problem from the other end by moving weights into reclaimable page cache, and it is the one of the two with a published number attached: in discussion #6 a reporter posting as UdonJP, on an RTX 5070 Ti with 125 GB of system RAM, measured ComfyUI's resident set at 45.4 GiB with no flags and 12.6 GiB with --fast-disk. That is one person's box rather than a controlled comparison, but it puts the default launch's host-memory appetite in the right order of magnitude. Use one of the two flags. A 64 GB box will usually survive the default launch at around that peak, but with nothing left for anything else — the flags are cheap and the failure they prevent is a hard kill mid-render.

What neither flag has is a published time cost. The mechanism points one way: at 64 GB the 42.47 GB weight set stays in page cache whether or not it is pinned, so dropping the pin should change little; at 32 GB it cannot stay cached, and the streaming this model does anyway starts arriving off the SSD instead of out of RAM. Nobody has measured either tier, so treat the size of the penalty as unknown and the direction as the only thing established. You will see about 20 % quoted for the 32 GB case; it traces to a single 16 GB write-up that its own author has since withdrawn, saying its content cannot be vouched for, and nothing else stands behind it. So: on 64 GB, use the flag and expect to pay little. On 32 GB, use it anyway and expect to pay something — a slower render beats a killed one, and NVMe rather than SATA is what decides how much you feel it. If you time the same job with and without the flag on a known RAM size, that measurement does not currently exist anywhere; /contribute is where it belongs.

SageAttention output looks like noise

Not at this page's clip lengths, and the widely-linked bug report is about a different setup. ComfyUI issue #15263 reads from its title like --use-sage-attention breaks H3 outright; its author later retracted that — "sage isn't broken on H3, and my issue title is too strong." — and disclosed his configuration as an RTX PRO 6000 Blackwell on the bf16 checkpoint. His remaining, reproducible finding is that "On my box the failure tracks sequence length, not hardware", with clean runs at his stated 63k and 154k tokens and noise at 184k. By his own counting rule — ceil(frames/4) × (W/32) × (H/32) — the stock 864×480 / 124-frame job on this page is 31 × 27 × 15 = 12,555 tokens, an order of magnitude below anything that has broken. Treat sage as a safe speedup at 5-second clips and re-test your output if you start rendering 15-second ones at 1080p.

Nothing here matches your problem

Runtime errors belong at ComfyUI/issues, template problems at workflow_templates/issues, and attention-patch problems at ComfyUI-KJNodes/issues. If you get a clean run on this card, a timing sent through /contribute is worth more to the next reader than every derived number on this page.