MiniMax H3 on RTX 5090: 32 GB video+audio, and what nvfp4 does not buy you

What You'll Build

A ComfyUI graph on one RTX 5090 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. The 5090 is the largest consumer NVIDIA card, and this page is about the two things that are different at 32 GB and only at 32 GB: the card is the first one where nvfp4 is a native compute format rather than an emulated one, and it is still not big enough to hold H3's two large modules at the same time.

⚠️ 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, which Section I.3 defines as "means worldwide, excluding the Excluded Territories." — and Section I.5 defines those as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America." Section V.4 extends the restriction to what you generate: "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 license: facet on the model card is other, which carries no territorial signal at all, so any filter keyed on it sails straight past this. The Comfy-Org repack this page installs does not relicense anything, and neither does a community re-quantisation — an 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.

Hardware data: RTX 5090 (32GB VRAM) · 34.140 GiB of weights against a 32 GiB card, so eviction runs even here · See benchmark data

ℹ️ 768p is still the local ceiling on the biggest card. 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 you run locally is H3-Base, validated at a 768-pixel short edge. A 5090 buys you longer clips and bigger batches, 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 5090 (32GB) — not measured by us; the timings below are one author's published 5090 runs and the VRAM budget is derived from file bytes (/contribute)
RAM	32GB with --disable-pinned-memory, 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/

32 GB is not enough to hold the pipeline, and that is the point

The intuition a 5090 owner arrives with is "top card, everything stays resident." It is wrong here, and the arithmetic is one line:

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

So ComfyUI's on-demand eviction — load_models_gpu summing what the requested models need and calling free_memory(...) to walk the already-loaded models and evict them, in comfy/model_management.py — is forced on the largest consumer card NVIDIA sells. There is no configuration of the official four files that keeps the text encoder and the transformer co-resident.

The measurement agrees, and the direction of the agreement is the part worth reading slowly. The one 5090 run of this exact file set that surfaced anywhere (see Results) reports a peak of 28,581 MiB — that is 4,187 MiB inside the card's 32,768, and 6,378 MiB below the 34,959 MiB the two modules would need together. A pipeline that genuinely held both resident could not have produced that number; it would have had to exceed the card and fail. The peak fits because eviction ran. It sits 7,363 MiB above the 21,218 MiB the denoise stage alone accounts for (20.721 GiB), which is the activation working set of a 243-frame clip on top of whatever ComfyUI had not yet had to evict.

What 32 GB actually buys, then, is not residency. It is that the denoise stage — 19.530 GiB of weights plus ComfyUI's 1.191 GiB inference reserve, so 20.721 GiB — clears by 11.279 GiB instead of the 3.279 GiB it clears by on a 24 GB card. That surplus is headroom for frames and pixels, both of which grow the activation working set while the weights stay fixed. It is also, uniquely on this card, enough room for a bigger text encoder; see Running.

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 matters more here than on any previous card, and it is not a folklore claim — it is a gate in ComfyUI's own source. comfy/quant_ops.py reads torch.version.cuda, and if it parses to anything 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 — the thing that provides the accelerated kernels for both quantised formats this recipe touches, int8_tensorwise+convrot and nvfp4. The same gate is present verbatim in v0.30.0, v0.30.1 and v0.30.2. Nothing raises, so the only symptom of getting this wrong is that the largest consumer GPU NVIDIA sells performs like something much smaller.

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 lines in the startup log before going further: the torch version must contain +cu130, and comfy-kitchen's CUDA backend must report 'available': True. If that backend fails to import instead, ComfyUI keeps running and everything is simply slower — one buried error line and no other symptom.

2. Download the four model files

Run these from the ComfyUI root — the directory step 1 left you in. 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 pruned transformer. The unpruned int8_convrot file is 31.701 GiB, which with the reserve below comes to 32.892 GiB and so does not fit a 32 GiB card even alone — it would stream on every step. Pruning here is not a quality cut: the model card describes the transformer as "H3-Omni-Transformer is a 33B-parameter dense, single-stream Transformer, with approximately 13B parameters residing in AdaLN-related branches." and notes those branches can be precomputed and cached rather than loaded for inference. When someone asked this exact question for this exact card in discussion #3, the answer was the same: "Your GPU is 32gb of VRAM so you should go with the minimax_h3_ref2va_pruned_int8_convrot.safetensors" — the reference-to-video sibling of the file above.

3. SageAttention — install 2.x, pin nothing, and count your tokens

Read this step before you install anything. There is an open ComfyUI report about SageAttention and H3, it is filed specifically against sm_120, and sm_120 is what you own. The recommendation in that thread has moved four times in a week, and an earlier version of this page repeated one of the discarded ones — so what follows keeps the measurement and the explanation deliberately apart.

The boundary is measured, and it is a step rather than a ramp. On an sm_120 box running SageAttention 2.x through the plain global flag, the sampler is clean below a token count and emits noise above it. The reporter's tightened table — one machine, one checkpoint, one set of sampler settings, varying only canvas and duration — runs 142k clean, 151k clean, 167k noise, 175k noise, 186k noise, and he describes the shape himself: "And it's a cliff, not a slope. 151k is clean, 167k is garbage, nothing soft in between." Two different aspect ratios cross the line, so it is not a height artefact, and the two 15-second rows carry identical frame counts and differ only in token count, so it is not duration either. Take that as established.

The cause is not established, and the issue's title is ahead of its own thread. Four explanations have been offered there and three have been withdrawn by the people who proposed them: a missing low_precision_attention=False opt-out (retracted by the reporter, its pull request closed unmerged), a smooth_k difference (retracted the same evening by the person who raised it), and FP8 PV accumulation error — which is what the current title names, and which the person who worked it out has since argued against himself. His reason came from the other participant's observation that sage's auto and KJNodes' ++ mode pass the same pv_accum_dtype="fp32+fp16" and differ only in qk_quant_gran, yet behave differently: "the PV path isn't the discriminating variable". What he now reads out of a sharp threshold plus a frame that came back partly correct is "That's the signature of something tile-indexed going out of range past a threshold, not of arithmetic precision." — a scale-buffer overrun, which if it holds would make the noise and the crashes one bug rather than two. Nobody has run a memory sanitizer on it. Treat the mechanism as open and the hypothesis as named, not adopted.

Do not pin a kernel. This is the most recent change and it inverts the advice still sitting in the issue's body. Every KJNodes sage mode was run on that sm_120 box at the failing size, and the one-line summary is "none of them work here, and I think it changes the conclusion."

KJNodes mode, ~186k tokens, sm_120	Outcome
auto	runs to completion at ~110 s/it and returns noise
sageattn_qk_int8_pv_fp8_cuda++	crashed
sageattn_qk_int8_pv_fp8_cuda	first step clean, then cudaErrorIllegalAddress
sageattn_qk_int8_pv_fp16_triton	first step clean, then cudaErrorIllegalAddress
sageattn_qk_int8_pv_fp16_cuda	Fatal Python error: Aborted on the first attention call

Dispatch explains the pattern: every explicit entry in that dropdown is something sage would never select on this architecture in the first place, so — "On sm120 there isn't one to pin." The FP16-PV recommendation that circulated for about a day was then withdrawn by the person who had proposed it: "That kernel table settles the part I had wrong, so let me withdraw the FP16-PV suggestion up front rather than defend it." Pinning a mode on this card trades a defect you are unlikely to reach for a crash you would meet on the first attention call.

So: install 2.x, leave it on auto or on the plain global flag, and change nothing else. That is the only configuration with sm_120 evidence behind it in either direction.

⚠️ Nothing in that thread was run on the files this page installs — and untested is not the same as safe. Every sm_120 noise report that names a checkpoint names the bf16 pair, minimax_h3_fl2va_bf16.safetensors with qwen3vl_32b_minimax_h3_bf16.safetensors. That qualifier is load-bearing: a second sm_120 participant states no checkpoint at all, and his run being counted as a noise result is another commenter's inference rather than his own report. The only participant on minimax_h3_fl2va_pruned_int8_convrot.safetensors — the transformer you downloaded in step 2 — is on Ampere, sm_86, which takes a different dispatch entirely. So this defect has never met this page's configuration on any card.

Do not read that as protection. SageAttention works on activations, not on weights, so there is no mechanism by which the checkpoint would obviously matter. The census establishes that nobody has checked; it establishes nothing at all about whether you are affected.

pip install sageattention gets you 1.0.6, the newest release the package index carries — there is no 2.x wheel there, and no prebuilt Linux wheel anywhere, so on Linux 2.x means building thu-ml/SageAttention from source:

pip install ninja packaging
CUDA_HOME=/usr/local/cuda-13.2 PATH=/usr/local/cuda-13.2/bin:$PATH \
TORCH_CUDA_ARCH_LIST=12.0 MAX_JOBS=8 \
pip install --no-build-isolation "git+https://github.com/thu-ml/SageAttention.git"

--no-build-isolation is mandatory — without it pip pulls a second torch into the build and wrecks the environment. TORCH_CUDA_ARCH_LIST=12.0 is this card's arch and cuts build time sharply.

The H3-specific KJNodes patch will not load against 1.0.6 at all, raising "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." — that is KJNodes issue #721, filed from another compute-capability 12.x card, and the maintainer's answer is "As the error says, you need newer version of sageattention." Once 2.x is present, read what the node actually dispatches on your silicon before treating it as a safer route than the flag. nodes/ltxv_nodes.py branches on {"sm120", "sm121"}, sets _qk_quant_gran = 2 # per warp, pushes V through per_channel_fp8, and calls _qattn_sm89.qk_int8_sv_f8_accum_f16_fuse_v_scale_attn_inst_buf — an FP8 PV kernel at per-warp granularity, which is the same shape sage's own auto takes here. It is not a route around any of the above.

This step is optional. It is also the largest single speed lever on this card that does not change the output resolution; see Results.

Your token budget on 32 GB, and the one number that does not move

The failure is gated on sequence size, which on a video model means a clean five-second test proves nothing about a thirty-second render. Compute the number instead of trusting a short clip. The thread counts tokens as

tokens = ceil(frames / 4) x (width / 32) x (height / 32)

and every row it publishes reproduces from that formula exactly, so it is the convention its own datapoints live in. Every percentage below is against the first noise row, 167,280 — state which denominator you used, because the last clean row, 150,960, gives a different and equally defensible figure.

Job	Tokens	Share of first noise
Template default — 864×480, 5 s (124 frames)	12,555	8%
The one published run on this card — 864×480, 10 s (243 frames)	24,705	15%
Largest job H3's own limits allow — 1344×768 at 362 frames	91,728	55%
Thread's last clean row — 1920×1088, 12 s	150,960	90%
Thread's first noise row — 1920×1088, 13 s	167,280	100%

Read the third row first, and note that it has nothing to do with your card. 91,728 is H3's own area cap — the constant MAX_PIXELS = 768 * 1344 in comfy_extras/nodes_minimax_h3.py — evaluated at the top of the range that file's own length tooltip calls "trained range is ~124-362, longer is untested". It is the same 91,728 on a 12 GB card and on a 96 GB one. Anyone who stays inside the envelope the model was built for cannot reach the boundary on any GPU, and tops out at 55% of it.

What is specific to 32 GB is that this is the consumer card best placed to leave that envelope. Everything the extra memory buys here is frames and pixels — the weights are fixed and the reserve is fixed, so the 11.279 GiB the denoise stage clears by is headroom on exactly the two axes that grow the token count. Reaching 167,280 at H3's native canvas takes about 668 frames, 27.8 seconds, roughly 1.8× the trained range; at the template's 864×480 it takes about 69 seconds of video. Both are places a 32 GB card can plausibly go and no card in the public record has been. Go there and you are the first person to find out what this configuration does.

One honesty note on the metric, from the participant who did most of the arithmetic: "I don't think it's the model's literal sequence length". ComfyUI's own video_latent_t() returns 107 temporal positions for 362 frames where ceil(frames / 4) gives 91, so every absolute above rises about 19% in the model's own convention — 91,728 becomes 107,856 — while the ratios barely move. Use it to rank jobs, not as an attention sequence length.

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.

Running

python main.py --disable-pinned-memory

Queue the template unchanged first, then change two things.

Know what the stock template actually runs. Its BasicScheduler is simple at 20 steps, its sampler is res_multistep, and its resolution is 864×480 — not the 1344×768 sitting in the generation node's widgets. 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 node's width and height inputs; a connected input beats a stored widget, so the widget values never reach 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 (max(5, round(a * 24)) + (5 - (max(5, round(a * 24)) % 17)) % 17), so a 5-second request becomes 124 frames and a 10-second one becomes 243.

Then drop the step count. 20 is a template author's number, not a published default — MiniMax's own reproducible request script carries task, prompt, target, seed and conditions, and no step field at all. The 5090 runs cited in Results measured the same clip at both counts — 324 s at 20 steps against 172 s at 10, a 47% cut the author reports as producing no visible difference. Read that as the size of the step lever on this card rather than as a timing for this page's configuration: the A/B was run on the author's own NVFP4 transformer, not the pruned_int8_convrot installed above, and no 20-step figure is published for ours. A follow-up post on the same card settled on 14.

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

Stage	Resident weights	ComfyUI's reserve	Stage total	Surplus on 32 GiB
Text encode (Qwen3-VL-32B, NVFP4-AWQ)	14.610 GiB	1.191 GiB	15.800 GiB	16.200 GiB
Denoise (H3 DiT, pruned int8+convrot)	19.530 GiB	1.191 GiB	20.721 GiB	11.279 GiB
Text encode with int8_convrot instead	25.277 GiB	1.191 GiB	26.468 GiB	5.532 GiB

The 1.191 GiB figure is ComfyUI's minimum_inference_memory() floor for 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 100 MiB more once total_vram exceeds 15 GiB — making the floor 1.484 GiB and every surplus above correspondingly smaller.

Every row fits. No two rows fit together — which is the whole content of the 34.140 GiB line in Requirements.

The one upgrade that only a 32 GB card can take

Row three is the reason this page exists as something other than a bigger-numbers reprint. The Comfy-Org repack also ships qwen3vl_32b_minimax_h3_int8_convrot.safetensors at 27,141,342,152 B = 25.277 GiB, and a 32 GiB card is the first consumer card on which that stage fits with the reserve. On a 24 GB card it does not: 26.468 GiB against 24 GiB.

Whether it is worth 10.667 GiB more to stream is a quality argument, and the people who have run both are clear about the direction. 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", which on this card does not apply. (A later reply in that thread block-quotes those words back; they are V33rGeer's, and neither post says which card either of them runs, so take it as a quality opinion and not a hardware report.) No same-seed comparison of the two encoders has been published on this card, or on any card, so treat the swap as an experiment you run rather than a settled upgrade.

hf download Comfy-Org/MiniMax-H3 \
  text_encoders/qwen3vl_32b_minimax_h3_int8_convrot.safetensors \
  --local-dir models

Then point the template's CLIPLoader at it. No published 5090 timing exists for this variant — the runs in Results all use the nvfp4 encoder, so treat the swap as a quality option with an unmeasured time cost, not as a tuned configuration.

Output lands in ComfyUI/output/video/, not in output/ itself, as an MP4 with the stereo track already muxed in by CreateVideo. The subdirectory comes from the template: its SaveVideo node carries the filename prefix video/MiniMax_H3, and folder_paths.get_save_image_path splits that prefix with os.path.dirname(os.path.normpath(...)) and joins the leading video onto the output directory. Verified against v0.30.2 and the template as shipped.

What nvfp4 does, and does not, do on this card

The 5090 is the first consumer card with FP4 tensor cores, and the shipped text encoder is an NVFP4 file. It is natural to read those two facts as one. They are not.

The hardware gate passes. supports_nvfp4_compute() in comfy/model_management.py returns True for any NVIDIA device whose compute-capability major version is at least 10. A 5090 is 12.0, so nvfp4 is listed under Native ops at startup. An RTX 4090 is 8.9 and an RTX 3090 is 8.6, so on those it appears under emulated ops instead. The blogger who benchmarked H3 on a 5090 puts the pre-Blackwell case plainly: "It saves disk and nothing else. ComfyUI lists nvfp4 under emulated ops on pre-Blackwell hardware, meaning the weights are expanded back to high precision before the matmul."

This particular file declines the path anyway. Read the safetensors header of qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors and every one of its 350 quantised layers carries a small inline descriptor tensor, <layer>.comfy_quant, 55 bytes of UTF-8:

{"format": "nvfp4", "full_precision_matrix_mult": true}

comfy/ops.py loads that key into module._full_precision_mm_config and thence module._full_precision_mm, and the forward pass builds _use_quantized with not self._full_precision_mm as one of its conjuncts. With the flag set the quantised matmul is skipped and the weight is dequantised into the compute dtype first — on a 5090 exactly as on a 3090. The file also ships no input_scale tensors at all, only weight_scale (F8_E4M3 block scales, group size 16), weight_scale_2 (F32 per-tensor) and pre_quant_scale (the AWQ smoothing vector, on 100 layers) — and activation scales are what an FP4 tensor-core matmul needs.

That is precisely what a Comfy-Org member said in discussion #16 when Ada owners asked for an int4 build. First "The nvfp4 is not for Blackwell only, you can just use it.", and when pushed: "it's just used as storage format here, there's nothing hardware specific about that". The file agrees with him byte for byte. Do not choose this encoder because your card can do FP4. It is a 14.610 GiB container, and that is its entire contribution.

Where the hardware path is actually exercised is a community NVFP4 transformer — coolthor/MiniMax-H3-pruned-NVFP4, 12,528,636,800 B = 11.668 GiB against the official 19.530, verified through the HuggingFace tree API (the repo is gated, so a direct file read returns 401). The author's published header dump lists its per-layer marker as comfy_quant U8 [19], and 19 bytes is exactly the length of {"format": "nvfp4"} — the same marker without the opt-out. Their measured gain, on a 5090, was 175 s against 185 s — 5.4% — which they attribute to clock rather than arithmetic, concluding that "Weight-only quantization buys power budget, not arithmetic throughput."

So the honest summary for a 5090 owner: the FP4 tensor cores are available, the file that could use them is not the one you install, and the one file that does use them bought its author 5.4% on a card that was already thermally pinned. Nothing on this page is worth choosing for FP4's sake.

Results

• Speed: our catalogue has no benchmark rows for this pair — /check/minimax-h3/rtx-5090 returns verdict: unknown. The only RTX 5090 timings that surfaced across the repack's 35 discussion threads, the ComfyUI and KJNodes issue trackers and a web search come from a single author writing at ai-muninn.com, and they are worth reading with their caveats attached. On the first post the summary is that "one 32GB RTX 5090 generates a 864×480 ten-second clip with audio in about 175 seconds" — that is 243 frames at 10 steps with an NVFP4 transformer. The same clip under the same conditions on this page's official pruned_int8_convrot transformer measured 185 s at a 28,581 MiB peak — that is the number to plan around, and it is the only published figure on the transformer this page installs. The author's separate 324 s → 172 s step comparison was run on their NVFP4 build, so no 20-step timing exists for ours. Environment: ComfyUI 0.30.1, torch 2.11.0+cu128, res_multistep/simple, a 500 W cap and Sage Attention off. A second post takes a 15-second 1080p render from 625 s to 314 s on the same card by stacking three changes, of which Sage Attention 2.2.0 is worth 18.8% on its own (507.0 s → 411.8 s) — corroborated at 20.1% on a GB10, which the author calls "Two independent machines landing that close to each other is the difference between a measurement and a fluke."

  Three caveats before you plan around any of this. It is one person's machine and not a controlled benchmark. Their stated environment is cu128, which by ComfyUI's own gate (Installation step 1) means both runs had the comfy-kitchen CUDA backend disabled — so the int8-convrot figure was measured without its fast kernels, and a cu130 install may not reproduce either number. And the same 185 s → 175 s pair appears twice in the first post under two different explanations, once as NVFP4-versus-INT8 and once as a 600 W-versus-500 W power cap, so read that 5.4% as noise on a thermally pinned card rather than as an attributable gain in either direction — and the 10-step NVFP4 run is itself given as 172 s in one section and 175 s in another. If you run this pair, a timing posted via /contribute is worth more than all of the above.

• VRAM usage: 20.721 GiB at the binding denoise stage on the official files — 19.530 GiB of int8 weights plus ComfyUI's 1.191 GiB reserve floor — leaving 11.279 GiB of a 32 GiB card. That figure is derived from the on-disk byte counts and ComfyUI's own constants, not measured by us; the one published 5090 measurement of the same file set reports a 28,581 MiB peak for a 243-frame clip, which is the derived weight budget plus the activation working set of a long clip. Live data, when it exists, will be at /check/minimax-h3/rtx-5090.

• 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 — this is a model property, not a VRAM one, and 32 GB does not buy you out of it. Frame for close and medium shots. Separately, EasyCache is reported in the same thread to cost quality; it is a large speed lever and worth its own A/B on your prompts before you leave it on.

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

Optional: the Turbo LoRA

A community distillation adapter, larryvrh/MiniMax-H3-Turbo-Lora, with a companion node pack at Larryvrh/ComfyUI-MiniMax-H3-Turbo, brings sampling down into a 4–8 step range rather than the template's 20. Both links are pinned on purpose: the card was rewritten three times inside a single day, and the descriptions still quoted around the community — a paused training round, prototype nodes — are gone from the current text, where the recommended checkpoint is minimax_h3_turbo_v4_step600_ema.safetensors and the earlier line's plastic look is described as resolved. Check whether it has moved again before planning around any of it.

Treat the speedup as unmeasured on this card. No same-machine before/after has been published on an RTX 5090 and this page has none; the author's own ~5× figure is his, for his hardware. The closest published run is on a very different GPU: a user in discussion #35 reports 4.5 minutes for a 5-second 864×480 clip at 8 Turbo steps on an RTX 3060 12GB, alongside a separate experimental int8 video VAE — two experimental components changed at once, one run, one person.

There is also a licence dimension here that is specific to this model. The adapter's own tag does not lift the base weights' territorial restriction, and community commentary in discussion #11 attributes the slow arrival of few-step LoRAs to exactly that clause constraining who may publish one. Given the step count is the single biggest lever on this card, that is worth knowing before you plan around a Turbo path arriving.

Troubleshooting

The sage patch will not load, or the picture comes back as noise

Two different problems that share a section because people arrive at both with the same question.

If nothing loads, check your version first: pip show sageattention. 1.0.6 is the PyPI package and the wrong generation for this card — the 5090 benchmark author hit it too and wrote "The version on PyPI is not the one you want." On sm_120 the H3-specific KJNodes patch refuses outright with the arch-probe error quoted in Installation step 3, while the plain --use-sage-attention flag accepts 1.0.6 silently and simply does not perform. SageAttention 3 installs under a separate package name, sageattn3, which the flag does not resolve — it looks for sageattention only.

If the output is noise — picture and audio both, with no error — check your clip length before you touch the install. On this architecture that failure is gated on sequence size rather than on configuration: the same install is clean at five seconds and can be garbage at thirty. Work out your token count with the arithmetic in Installation step 3. Under about 90,000 you are below everything ever reported to fail on sm_120, so the cause is almost certainly elsewhere — check the comfy-kitchen and cu130 lines in the startup log, then re-run the same seed with sage disabled, which settles whether sage is involved in one experiment. Above roughly 150,000 you are in the band where sm_120 boxes have produced noise, and the answer is to shorten the clip or drop the canvas.

Do not answer it by pinning a SageAttention mode. Advice to pin sageattn_qk_int8_pv_fp16_cuda circulated for about a day and was withdrawn by the person who gave it: on sm_120 that mode aborts the process outright, and every other explicit mode either crashes or raises cudaErrorIllegalAddress. The table is in Installation step 3.

Finally, do not import the 3090-era speedup numbers for this card. A figure measured with the pure-Triton 1.0.6 wheel on Ampere says nothing about a 2.x CUDA build on Blackwell — the sm_120 dispatch path does not exist in the version that produced it.

The monitors go black mid-render

This is reported on this card specifically, and the resolution is thermal rather than software. A 5090 owner in discussion #32 wrote: "My system can do 1280x736 5s exports in t2v, but when I try 10-15s renders it causes my monitors to go blank and stay blank after a few minutes of processing", having already tried --disable-pinned-memory and --disable-dynamic-vram. The fix in that thread was cooling — the reporter was peaking at 86 °C and the problem stopped once the case airflow improved. Another participant in that thread, posting as V33rGeer, framed the workload: "This model is an extremely high power workload, and will probably smash directly into the power limit unless you severely restrict the voltage/frequency of the GPU." Read that as a statement about the model rather than a second 5090 report — the 5090 owner above block-quotes those words back in agreement, but they are not his and V33rGeer never names a card.

The benchmark author's telemetry lines up: at a 500 W cap the peak was 82 °C against a throttle point they put at 84 °C, and their verdict on the run was "Not power-limited — thermally limited." Before you add power, find out which wall you are hitting. A third reporter in the same thread traced the same symptom to sage attention instead — "I had a similar issue but turned out to be sage attention. It was causing the video card to fail requiring a PC restart. Switched to py attention and it worked." — so if cooling does not settle it, disable the attention patch as the next test.

Your 1080p output is 1056 pixels tall

MiniMaxH3ImageToVideo computes the latent height as height // 16. Ask for 540 and you get 540 / 16 = 33.75 → 33 → 528, so the generation is 960×528 and a 2× upscale lands at 1920×1056. Nothing errors and nothing warns; the frame count and audio are correct and only the height is 24 pixels short. Insert an ImageScale at 960×540 (bilinear, crop disabled) between the H3 node and the upscaler.

ComfyUI is killed, or throws MemoryError, while loading

System RAM ends more H3 runs than VRAM does, even on this card, and the arithmetic is in ComfyUI's source rather than in anyone's anecdote. MAX_PINNED_MEMORY is 90% of system RAM on Linux unless --disable-pinned-memory is passed, and pinned_hostbuf_size(size) returns max(0, int(min(size, MAX_PINNED_MEMORY) * 2)) — twice the model size, page-locked, and pinned pages can be neither swapped nor reclaimed. For the 19.530 GiB transformer on a 32 GB box that is a request for 39.060 GiB of host memory, and the OOM killer arrives before the first sampling step. Note what this does not depend on: your card. The DiT is 19.530 GiB whether you own this GPU or a 12 GB one, so every NVIDIA page for this model carries the same flag.

What the flag costs is a function of your RAM, and this page cannot put a number on it. The mechanism is the page cache: with 64GB the 42.47 GB weight set stays cached whether or not it is pinned, so unpinning changes nothing, while at 32GB it cannot stay cached and the weights stream off the SSD instead. The only published before/after on that trade came from a repository whose author has since withdrawn the whole document pending re-verification, so this page no longer quotes a figure from it. Take the flag anyway at 32GB — the alternative there is not a slower run but a killed one — and drop it at 64GB and up.

A MemoryError raised specifically by UNETLoader has a duller second cause — a truncated download. In discussion #29 a report of exactly that turned out to be a file of the right byte size and the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.

Generation is far slower than the numbers above

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. This is the single most likely explanation for a 5090 landing near a much smaller card's timings.

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.