MiniMax H3 on RTX 5080: 16 GB, and what the extra silicon cannot buy

What You'll Build

A ComfyUI graph on one RTX 5080 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.

Most people arrive at this page with a near-flagship expectation, and H3 does not honour it. On the specification sheet the 5080 is one step below NVIDIA's largest consumer card. On this model it is a 16 GB card, and 16 GB is a regime, not a rank: the same one the RTX 5060 Ti is in, decided by which of two large modules can sit on the die at once. The 5090 above it has twice the memory and still cannot hold both. That gap between what the box says and what the model does is the thing this page is about, and it is worth spending a paragraph on before you spend 42 GB of download on it.

There is also, unusually for a card this new, a published number. One RTX 5080 owner ran the exact file set installed below and posted the result; a second is running the few-step adapter on the same card. Both are cited under Results with the caveats they deserve.

⚠️ Read the licence before you download 42.47 GB. MiniMax H3 is not open-source, and the constraint is geographic rather than commercial. The MiniMax H3 Community License Agreement grants rights only inside an Applicable Territory that clause I.3 defines as everywhere except the Excluded Territories, and clause I.5 names those as "means the European Union, the United Kingdom, the Republic of Korea and the United States of America." Clause V.4 then 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, so no catalogue filter keyed on that field will show you any of the above — you have to read the text. And nothing downstream lifts it: the Comfy-Org repack installed below declares the same licence and links back to the same file, and a community re-quantisation or a LoRA is a derivative that inherits the terms rather than replacing them. MiniMax publishes a licence Q&A and a per-deployment application route. This is a summary written by a reader of the text, not legal advice.

Hardware data: RTX 5080 (16GB VRAM, sm_120) · 39.554 GiB of weights against a 16 GiB card · See benchmark data

ℹ️ 768p is the local ceiling, and no amount of card changes it. H3 reaches 2K through a separate H3-Regenerate-2K stage which the model card describes as "this module is not yet open-sourced. We will release it once it is ready." — 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, and the same card's specification table states "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 5080 (16GB) — not measured by us; one community self-report on this card is cited under Results (/contribute)
RAM	32GB with --disable-pinned-memory, 64GB to be comfortable; 45GB+ without the flag	— the flag is mandatory below 64GB and is not free below it either; see Running
Storage	42.47 GB of weights	42.47 GB across four files (byte counts from the HuggingFace tree API)
Software	ComfyUI 0.30.0+, PyTorch built against CUDA 13	—

The four files the official text-to-video template loads, byte-exact from the Comfy-Org repack:

File	Bytes	GiB	Destination
minimax_h3_fl2va_pruned_int8_convrot.safetensors	20,970,379,616	19.530	models/diffusion_models/
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors	15,687,142,551	14.610	models/text_encoders/
minimax_h3_video_vae_fp16.safetensors	5,207,808,496	4.850	models/vae/
minimax_h3_audio_vae_fp32.safetensors	605,254,808	0.564	models/vae/

min_vram_gb on this page is 12 rather than 16. That field is a filter floor — the smallest capacity on which the install below actually runs — and it is not a claim about your card. Comfy-Org put the floor at an RTX 3060 in their launch post announcing this compressed four-file set, and this catalogue carries working 12 GB recipes for the model. What 16 GB buys over that floor is one specific thing, and it is the subject of the next section.

What NVIDIA sells you here, and which part of it this model can use

The 5080's spec sheet is public and short, so put it next to the two other Blackwell cards this catalogue covers at the same capacity. Every figure below is from NVIDIA's own product pages: the RTX 5080 page, the RTX 5070 family page and the RTX 5060 family page.

	CUDA cores	AI TOPS	Memory	Interface width	PCI Express
RTX 5080	10752	1801	16 GB GDDR7	256-bit	Gen 5
RTX 5070 Ti	8960	1406	16 GB GDDR7	256-bit	Gen 5
RTX 5060 Ti	4608	759	16 GB GDDR7	128-bit	Gen 5

Against the 5070 Ti the 5080 brings 20% more CUDA cores and 28% more AI TOPS, on an identical memory capacity, an identical 256-bit interface and the same PCI Express generation. Against the 5060 Ti it brings 2.33× the cores, 2.37× the AI TOPS and twice the interface width — and, again, exactly the same 16 GB.

That last column is the one that decides your experience, because H3's working set is 39.554 GiB across four files and the two big ones do not fit together on anything NVIDIA sells to consumers. Compute is the axis the 5080 wins on, and compute is the axis with the least to bite on when a 19.530 GiB transformer is crossing the host link on every sampling step. How much less is an empirical question, and Results is where this page tries to answer it rather than assert it.

16 GiB is the tier where exactly one of the two big modules fits

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  →  short of 16 GiB by 4.721
                                                                    34.140 GiB  →  fits on no consumer card

The 1.191 GiB is a constant you can read rather than a rule of thumb. minimum_inference_memory() in comfy/model_management.py at v0.30.2 returns (1024 * 1024 * 1024) * 0.8 plus extra_reserved_memory(), and EXTRA_RESERVED_VRAM is 400 * 1024 * 1024 on Linux — 1.190625 GiB, printed above rounded to three places.

So the text encoder becomes resident and the transformer does not. ComfyUI caps how much of the transformer stays on the card and streams the remainder over PCIe, once per sampling step, for every step you queue. That is the tier's defining behaviour and it is not a failure mode — but it is also the reason a 5080 owner should stop reasoning from the position of the card in NVIDIA's stack and start reasoning from its capacity.

Read the 0.200 GiB as thin rather than as headroom, for three separate reasons.

The reserve is larger on Windows and the sign flips with it. EXTRA_RESERVED_VRAM becomes 600 * 1024 * 1024 there, and a further 100 MiB is added when total_vram exceeds 15 * 1024 MB — a threshold this card is on the far side of. Check the indentation in the source rather than taking my word for it: that extra 100 MiB sits inside the if WINDOWS: block, so it is a Windows surcharge and not a general large-card one. The floor becomes 1.484 GiB and the text-encode stage 16.093 GiB, which is 0.093 GiB over a 16 GiB card before anything else has asked for a byte.

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 unallocated at that instant. A desktop compositor, a hardware-accelerated browser tab or a second CUDA process spends directly out of that 0.200 GiB, and the driver plus the CUDA context take their cut before ComfyUI starts.

And it is a text-only margin. This is the part that catches people on this tier and it has its own upstream report. ComfyUI issue #15316, filed from a 16 GB card, points out that the loader sizes its budget from the model alone: "So after the model is loaded, encoding the images exceeds the VRAM budget, hence the slow down." Text-to-video is unaffected — the reporter measures that path finishing in seconds. Image-to-video and reference-to-video push images through the same encoder, and on a card clearing by 0.200 GiB there is nothing left to absorb them. If your interest in H3 is the reference-conditioned modes rather than plain text-to-video, treat the arithmetic above as optimistic and read the reserve note in Running before you queue anything.

The reassuring half is that losing the margin costs time and not the render. The per-stage weight budget is

lowvram_model_memory = max(0, free_vram − minimum_memory_required,
                           min(free_vram × MIN_WEIGHT_MEMORY_RATIO, free_vram − inference_floor))

and the third term is switched off on your hardware outright: MIN_WEIGHT_MEMORY_RATIO is 0.4 by default and reset to 0.0 under if is_nvidia(). Less free memory therefore means proportionally fewer weights resident and more streaming, which is the same mechanism that lets a 19.530 GiB transformer run here at all. You lose minutes, not the output.

Installation

1. Update ComfyUI onto a CUDA 13 PyTorch

H3's nodes ship in ComfyUI core (comfy_extras/nodes_minimax_h3.py) rather than as a custom node, from v0.30.0 onward. That module reaches torchaudio through the audio VAE path, so an environment built with only torch and torchvision fails at startup.

The CUDA version is a gate in ComfyUI's own source, not folklore. comfy/quant_ops.py parses torch.version.cuda, and below 13 it calls ck.registry.disable("cuda") after logging "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 weights you are about to download. Nothing raises, so the only symptom is that a card with 10752 CUDA cores performs like something much smaller.

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

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

2. Download the four model files

Run these from the ComfyUI root and pass the filenames as positional arguments. Handing several of them to --include makes everything after the first positional anyway and drops the flag, 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, 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. That is 10.667 GiB more than the file above, which pushes the encode stage well past the card and onto the streaming path the transformer is already on — the one part of this pipeline that currently fits would stop fitting. There is a genuine quality case for the int8 encoder, argued in discussion #16 by people who have run both, and it carries an explicit exemption for systems that physically cannot handle it. At this capacity you are that exemption. If prompt adherence breaks down on a complicated reference setup, swapping the encoder is the first experiment to run, and it will cost you wall-clock rather than an error.

3. SageAttention — do not pin a kernel, and know why the advice keeps changing

Read this step before you install anything. There is an open ComfyUI bug report about SageAttention and H3, it is filed specifically against sm_120, and sm_120 is your card. The recommendation in that thread has now moved three times, so what follows separates what is measured from what is still being argued about.

What is measured, and it is solid. On an sm_120 box with SageAttention 2.x, the sampler produces clean output below a token count and noise above it, and the transition is abrupt. The reporter's own tightened table — all on the global flag, one box, one checkpoint, same seed — reads 142k clean, 151k clean, 167k noise, 175k noise, 186k noise, and he describes it exactly as it looks: "And it's a cliff, not a slope. 151k is clean, 167k is garbage, nothing soft in between." Two different aspect ratios cross it, so it is not a height artefact, and a 736-frame run stayed clean at a lower token count, so it is not frame count either. The trigger is sequence size.

What is not settled is the cause, and this page will not pretend otherwise. Three explanations have been offered in that thread and two have been retracted by the people who proposed them — first a missing low_precision_attention=False opt-out (withdrawn by the reporter, and the pull request implementing it closed unmerged), then FP8 PV accumulation error, which the issue's title still names. The person who proposed the FP8 explanation has since argued against it himself: auto and the ++ mode share a PV accumulator and differ only in a quantisation-granularity parameter, yet behave differently, so "If behaviour changes with the granularity parameter while the PV accumulator is held constant, the PV path isn't the discriminating variable." His current reading of the sharp boundary and the partly-correct frames is "That's the signature of something tile-indexed going out of range past a threshold, not of arithmetic precision." Treat the mechanism as open.

What you must not do is pin a kernel. This is the part that changed most recently and it inverts the advice still sitting in the issue body. Somebody ran every KJNodes sage mode on the sm_120 box at the failing size, and the summary is "none of them work here, and I think it changes the conclusion."

KJNodes mode at ~186k tokens on sm_120	Result
auto	completes, noise
sageattn_qk_int8_pv_fp8_cuda++	crashed
sageattn_qk_int8_pv_fp8_cuda	clean first step, then cudaErrorIllegalAddress
sageattn_qk_int8_pv_fp16_triton	clean first step, then cudaErrorIllegalAddress
sageattn_qk_int8_pv_fp16_cuda	Fatal Python error: Aborted on the first attention call

The reason is in SageAttention's own dispatch: every explicit mode in that list is something sage never selects on sm_120 in the first place. fp16_cuda is chosen only for sm80/sm86, the triton kernel is annotated as unusable on sm120, and the FP8 variants sm_120 does use are reached with different parameters than the dropdown passes. Hence the reporter's conclusion — "On sm120 there isn't one to pin." — and the withdrawal of the FP16-PV recommendation by the person who had proposed it, whose closing position is that any real fix has to be architecture-aware: "Arch-aware is the only shape that fits both."

So on this card: install 2.x, use auto or the plain global flag, and change nothing else. That is the only configuration with sm_120 evidence behind it in either direction. Pinning an explicit mode does not protect you from a defect you were unlikely to reach and does reliably convert it into a crash you would.

⚠️ None of those reports is on an RTX 5080, and none is on this page's checkpoint. The two people who reproduced the failure are on an "RTX PRO 6000 Blackwell, 96 GB (sm_120)" running the bf16 transformer and the bf16 text encoder — not the pruned_int8_convrot files installed above. What transfers is the architecture, because the dispatch is keyed on it. What has never been tested is this defect against this page's quantised checkpoint, on any card.

pip install sageattention gets you 1.0.6, the newest release on the package index. That build has no architecture dispatch at all — one Triton path — which is why the one Ampere participant never met the defect, and it is also why nobody has any sm_120 data on it. On Linux, build 2.x 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 environment and wrecks it. TORCH_CUDA_ARCH_LIST=12.0 is this card's architecture and cuts build time sharply.

Two older arguments about the H3-specific node are now dead and worth retiring explicitly, because they are still repeated. The claim that MiniMaxH3MemoryEfficientSageAttentionPatch is safer because it bypasses ComfyUI's shared attention path rested on the root cause that was withdrawn. And its own label — "Activates custom sageattention on the MiniMax H3 self-attention to reduce peak VRAM usage, overrides the attention mode. Requires latest sageattention version." — did not survive contact with the one published five-configuration comparison on 16 GB Blackwell hardware, where it was not the node that lowered the peak. Reading nodes/ltxv_nodes.py, its sm120/sm121 branch quantises Q and K per warp and V per channel to FP8 — the same shape sage's own auto takes on this architecture. It is neither safer nor more dangerous than auto; it is roughly the same dispatch with a different installation mechanism.

Your token budget, and why a 16 GB card is not in this fight

The failure is gated on sequence size, which on a video model means a five-second test proves nothing about a thirty-second render. So compute the number instead of trusting a clean 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 — 63,240 and 153,824 for the early clean runs, 150,960 for the last clean one, 167,280 for the first noise one, 185,640 for the original report. Use it, because it is the convention its datapoints are in.

Two honesty notes on that formula. It is not the model's literal attention sequence length — audio and any reference blocks add tokens on top, so read it as a proxy and a floor. And ComfyUI's own H3 node computes latent frames differently: comfy_extras/nodes_minimax_h3.py uses video_latent_t(f) = ((f - 5) // 17) * 5 + 2 rather than ceil(f/4), which runs about 18% higher — so the same job carries two different absolute token counts depending on which one you use, and mixing them silently understates or overstates a margin. The good news is that the disagreement does not reach the question, because the two conventions share an identical spatial term (width / 32) × (height / 32) and differ only by a near-constant temporal factor, so any ratio between two jobs survives it. Checked across three pairs on this page, the two agree on the ratio to within 0.4%. Every row of the table below is therefore computed in the thread's convention — the one its own datapoints are in — and stated as a percentage of the thread's rows rather than as an absolute.

Job	Tokens	Against the first noise row (167,280)
Template default — 864×480, 5 s	12,555	8%
The one published RTX 5080 run — 1344×768, 10 s	61,488	37%
Largest job reachable inside H3's own limits — 1344×768 at 362 frames	91,728	55%
The thread's last clean row — 1920×1088, 12 s	150,960	90%
The thread's first noise row — 1920×1088, 13 s	167,280	100%

Read the third row first, because it is the whole answer. 91,728 is not a recommendation, it is a ceiling: it is H3's own area cap of 768 * 1344 pixels — the constant MAX_PIXELS in the node file above — at the top of the ~362-frame range the same file's tooltip calls trained. A user who stays inside the envelope the model was built for cannot reach the boundary on any card, and lands at 55% of the first failure. The observation is not ours; it was made in the thread about Ampere, but the cap is the model's rather than any GPU's, so it applies unchanged here.

And the 5080's own datapoint lands in an interesting place. The published 13-minute run computes to 61,488 tokens — 37% of the first noise row, and within 3% of the lowest verified-clean sm_120 measurement in the thread. So the biggest job this card has been shown to finish sits at the bottom of the range that has been checked on your architecture, with a wide margin to anything that has failed. To reach the first noise row at H3's native canvas you would need about 668 frames, nearly 28 seconds, roughly double the trained range; at the template's 864×480 you would need about 70 seconds of video.

The failing configuration is also not somewhere a 16 GB card goes. Those runs are 1920×1088, which is 2.02× H3's own pixel cap, on a 96 GB card that holds the entire pipeline resident — and the reporter still measured about 110 seconds per sampling step there. On a card that streams a 19.530 GiB transformer over PCIe every step, the same job is not a slow render, it is not a destination.

So the honest summary for this page: the defect is real, it is filed against your architecture, and at the canvases and durations a 16 GB card can actually finish you are not near it. Use auto, look at your output, and if you do push past the trained frame range at native canvas, understand that you are the first person to find out what this card does there.

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 alongside the image-to-video and reference-to-video variants.

Running

python main.py --disable-pinned-memory

That flag is a prerequisite on a 32 GB machine, not tuning, and the arithmetic is in the source. MAX_PINNED_MEMORY is set to ram * 0.90 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, neither swappable nor reclaimable. For the 19.530 GiB transformer on a 32 GiB box that is a request for 39.060 GiB of host memory, and the OOM killer arrives before your 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 5090, so every NVIDIA page for this model carries the same warning.

One person has posted a measured baseline for the default launch, and it is worth having if you are sizing a 32 GB box. On the repack's discussion #6, a user posting as UdonJP ran a single job on an RTX 5070 Ti with this same four-file set, changing 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. One machine, one job, and the flag he varied is --fast-disk rather than the one above — so take the baseline and not the delta. It says the default launch wants roughly 45 GiB, which 32 GB does not have.

What the flag costs you in speed is unmeasured, and the mechanism says it depends on your RAM rather than on your card. Page-locking governs how the weights reach the GPU, not where they sit in between: with 64GB or more the 42.47 GB weight set stays in page cache whether or not it is pinned, so unpinning changes the transfer path and not the source of the bytes. At 32GB it cannot stay cached, so the streaming this tier cannot avoid starts arriving off the SSD instead — and nobody has published how much that costs, here or on any other card. Take the trade anyway; the alternative at 32GB is not a slower run but a killed one, and put the weights on the fastest NVMe you own. If you have 64GB, drop the flag and keep the transfer speed.

Queue the template unchanged first, and know what "unchanged" actually 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 node's own widget list never reaches the sampler — you get 864×480. Frame count is snapped onto a 17k+5 grid at 24 fps by the template's math node, so a 5-second request becomes 124 frames and a 10-second one becomes 243. Steps are 20, sampler res_multistep, scheduler simple. To reach H3's native canvas, set the selector to 0.98 megapixels, which resolves to 1344×768.

The reserve knob points in two directions, and you cannot have both

--reserve-vram <GiB> does not add to EXTRA_RESERVED_VRAM; it replaces it. The assignment EXTRA_RESERVED_VRAM = args.reserve_vram * 1024 * 1024 * 1024 sits below both platform defaults in model_management.py and overrides whichever one applied. On a card of this capacity that single flag has two incompatible correct settings depending on which stage you are protecting.

Keeping the text encoder resident caps it at 604 MiB. Residency needs 0.8 + reserve + 14.610 ≤ 16, so:

• Linux defaults to 400 MiB, leaving 204 MiB of slack. That is the whole of the 0.200 GiB margin restated as a budget — the most you can hand a desktop session before the encoder stops being resident. --reserve-vram 0.55 is about as far as it goes.
• Windows defaults to 700 MiB and is therefore already 96 MiB past the ceiling, which is the 0.093 GiB overshoot from Requirements seen from the other side. --reserve-vram 0.5 brings the encoder back onto the card, at the cost of the shared-VRAM headroom that constant exists to provide. Try it; revert it if stalls replace speedups.

Pushing images through the encoder wants the opposite. The reporter of issue #15316 found --reserve-vram 2.5 fixed a minute-long hang at the image-to-video node on a 16 GB card — and 2.5 GiB is four times the residency ceiling, so it works precisely by pushing the encoder off the card and freeing room for the image activations the loader never budgeted for. Both settings are right for their own stage and there is no value that serves both, which is a cleaner statement of this tier's constraint than any of the arithmetic above: at 16 GiB you get to choose which stage is comfortable.

Run headless if you can. Nothing here is a crash risk on Linux — overshooting just moves the encoder onto the path the transformer is already on.

What nvfp4 does not do here

The 5080 is Blackwell, the shipped text encoder is an NVFP4 file, and the obvious inference from those two facts is wrong. The file itself is the evidence.

The hardware gate genuinely passes. supports_nvfp4_compute() in comfy/model_management.py returns False for non-NVIDIA devices and then False again for any device whose compute-capability major version is below 10; this card is 12.0, so it returns True and nvfp4 is listed under Native ops at startup rather than under emulated ops as it would be on an Ada or Ampere card.

The shipped file declines the path anyway. Reading its safetensors header over an HTTP range request, the encoder carries 351 comfy_quant descriptors. Three hundred and fifty of them are the identical 55-byte string {"format": "nvfp4", "full_precision_matrix_mult": true}; the remaining one, on the embedding table, is a 29-byte {"format": "int8_tensorwise"}. That flag is load-bearing: comfy/ops.py reads it into _full_precision_mm_config, promotes it to _full_precision_mm, and builds its _use_quantized predicate with not self._full_precision_mm as a conjunct. With the flag set the quantised matmul is skipped and the weight is dequantised into the compute dtype first — on this card exactly as on a 3090. The tensor census corroborates it from the other side: the file ships weight_scale, weight_scale_2 and pre_quant_scale tensors and zero input_scale tensors, and activation scales are precisely what an FP4 tensor-core matmul needs and cannot invent.

A Comfy-Org member said the same thing in discussion #16 when Ada owners asked for an int4 build, and the file agrees with him byte for byte: "it's just used as storage format here, there's nothing hardware specific about that." So nvfp4 here is a container that makes a 32-billion-parameter encoder fit on a mid-capacity card, which is exactly the contribution you want. Do not pick it for the tensor cores, and do not expect the encode stage to get faster because you bought Blackwell.

The transformer is a different story and worth knowing about, because the family's "the file dequantises anyway" line is true of the text encoder only. The pruned_int8_convrot DiT installed above carries 200 descriptors of {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} with no opt-out on any of them. Its fast path is real, and what gates it is the cu130 build and a working comfy-kitchen import from Installation step 1 — not your architecture.

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

Results

• Speed — the one published RTX 5080 run. Our catalogue has no benchmark rows for this pair; /check/minimax-h3/rtx-5080 returns verdict: unknown. Sweeping all 36 discussion threads on the Comfy-Org repack, all 22 on the Turbo adapter and the ComfyUI issue tracker, exactly one timing for this card exists. A user posting as zdjun1984 wrote in discussion #18: "I used pruned int8_convrot on RTX5080 for video 10 seconds /1MPixels, got a resualt :13min and 36s/step." That is the transformer this page installs, at roughly H3's native canvas, for a ten-second clip. He states neither his step count nor which accelerator nodes were in the graph, but 13 minutes divided by 36 seconds is 21.7, which is what you would expect from the template's stock 20 steps plus the fixed encode and decode stages either side. Treat it as one person's machine rather than a benchmark — and if you run this pair, a timing sent through /contribute doubles the evidence base for this page.

  That run is also the page's one calibration point for the sage question, and it lands reassuringly: by the token arithmetic in Installation step 3 it is 61,488 tokens — 37% of the lowest sequence size at which anyone has seen SageAttention fail on sm_120, and within 3% of the lowest verified-clean measurement on that architecture. It says nothing about longer clips, and it does not name its attention setting, so read the 13 minutes as a timing. But it does place the biggest job this card has been shown to finish a long way below the trouble.

• The one comparison the corpus actually supports. Immediately above that post in the same thread, a user who says he is on an RTX 5060 Ti reports "got 20 minutes per generation on 10 seconds in 0.9 MPixels". Same thread, same pruned int8 base, same clip length, canvases within about 10% of each other — this is the closest thing to a matched pair of Blackwell reports in H3's published coverage, and it is worth reading against the specification table in Requirements. The 5080 has 2.33× the CUDA cores and twice the interface width of a 5060 Ti, and it finished about 1.5× faster while carrying slightly more pixels. Two honest caveats. He never states his capacity, and the 5060 Ti ships in 8 GB and 16 GB variants that share the same 4608 cores and the same 128-bit interface — so the compute ratio holds either way, but whether both machines were streaming the same fraction of the transformer is unknown. And neither poster states steps, accelerators or software versions, so this is not a controlled comparison and the residual could be almost anything. What survives is the direction, which is what a streaming tier predicts: when a 19.530 GiB transformer crosses the host link on every step, the part of the job your extra silicon can accelerate is not the whole job, and the wall-clock gap comes out well short of the spec gap.

• Do not read a per-step figure across canvases, including from the card closest to yours. ComfyUI issue #15337 reports an RTX 5070 Ti — same capacity, same architecture, same memory type as the 5080 — at "sampling succeeds (~6.8 s/it, so the cu130 optimized kernels work fine)" on the official image-to-video template's defaults of 0.4 MP, 5 s and 20 steps. Six point eight seconds against the 5080's thirty-six is not a five-fold gap between the cards: the 5080 report's latent is roughly five times larger — 1,032,192 pixels over 243 frames against 414,720 over 124 — before the two runs' different graphs, operating systems, offload flags and accelerator choices are counted at all. Attention is quadratic in sequence length, so the honest expectation is that a five-fold latent costs more than five times as much per step, not exactly five; that these two land at almost exactly the latent ratio is a coincidence of two uncontrolled runs, not a scaling law. The corpus does not reconcile across canvases, and that is the finding. Do not build a prediction out of it — time your own job at the canvas you intend to use.

• What this model costs on a card that never has to evict anything. A run posted in discussion #34 states its configuration as "H200x1, 1920x1088, 2MP, 24 fps, 10 second, 20 steps." and pastes a log in which the transformer is loaded completely with full load: True — nothing streaming, everything resident — at 140.28 s per iteration for a 49-minute job. It is a different transformer file, a different graph and twice the canvas, so it is not a scaling datapoint and this page does not convert it into one. What it does settle is a question a 16 GB owner reasonably asks before spending money: per-step cost on H3 is not simply an artefact of your capacity. The model is expensive per step on hardware that has never had to stream a byte.

• The one cross-generation 16 GB comparison in circulation is half hearsay, and its own thread never settled the cause. ComfyUI issue #15261 is widely read as evidence that a Blackwell 16 GB card is 2.3× a 16 GB Ada one on this model, and it is worth reading rather than repeating. The reporter measured only his own half — "4080(16G)+64G minimax h3 ref2video 5s 1280x736 need 690s (tests i conducted myself)" — and took the other from a video he watched, writing "5070ti(16G)+64G minimax h3 ref2video 5s 1280x736 need 300s". A memory-bandwidth mechanism was proposed in the replies — by a commenter with no association to the repository, rather than by a maintainer or by the reporter. The one repository contributor to answer did not endorse it: his suggestion was to put the job under NVIDIA's profiler and look for gaps in the compute timeline, on the reasoning that gaps point at a host-transfer stall while a saturated memory bus looks different. That is where the thread stops. It proposed a cause and named the experiment that would test it, and the experiment has not been posted.

  Two things make that pair unusable as a bandwidth datapoint anyway, and both come off NVIDIA's own specification pages. The RTX 4080 is 16 GB of GDDR6X on PCI Express Gen 4; the RTX 5070 Ti is 16 GB of GDDR7 on Gen 5. Between those two machines the memory generation, the host-link generation and the GPU architecture all changed at once, so no single variable can be credited. And neither page publishes a lane count or a GB/s figure at all, which means the bandwidth ratio everyone reasons with is not available from the vendor and this page will not invent one. What is on those pages is worth a second look from a 5080 owner: the 4080 has 9728 CUDA cores against the 5070 Ti's 8960 — the slower card in that comparison had more of them. Core count is demonstrably not what decides this tier, which is the same conclusion the 5060 Ti pair reached from the other direction.

• VRAM usage: the number to size against is the text-encode stage — 14.610 GiB of encoder weights plus ComfyUI's 1.191 GiB reserve floor, so 15.800 GiB, clearing a 16 GiB card by 0.200 GiB on Linux and exceeding it by 0.093 GiB under the larger Windows reserve. The denoise stage asks for 20.721 GiB against the same card and streams the 4.721 GiB difference. Both figures are derived from on-disk byte counts and ComfyUI's own constants, and no measured VRAM trace exists for this card at all. The closest readings on 16 GB Blackwell hardware are two posted by a user calling himself UdonJP in the repack's discussion #6, from an RTX 5070 Ti running this same file set: "VRAM peak was 14,197 MiB for 30 s @ 640x480 and 14,437 MiB for 5 s @ 1344x768". One person, one machine, and whole-run peaks that no published trace decomposes by stage — so they tell you the ceiling a 16 GB card settles at, not which of the two stages above set it. Treat the arithmetic as a fit test rather than as a prediction of what nvidia-smi will show you. Live data, when it exists, will be at /check/minimax-h3/rtx-5080, and one polled trace from this card — one job, one configuration, VRAM sampled at one-to-two-second intervals, encode peak and sampling peak logged separately — would be worth more through /contribute than everything derived above.

• Quality notes: the model's known weakness is faces at distance, reported in discussion #30 and independently by reviewers on other cards, and raising the canvas is reported not to fix it. That is a property of the model rather than of your GPU, and 16 GB of Blackwell does not buy you out of it — frame for close and medium shots. On the accelerator nodes, nobody has published an A/B on this card. Enable them one at a time, re-render at a fixed seed, and judge each by watching the clip rather than by a summary number.

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

Optional: the Turbo LoRA

The one person who published a timing on this card ended his post looking forward to a distillation adapter. It has since shipped: larryvrh/MiniMax-H3-Turbo-Lora with the companion node pack Larryvrh/ComfyUI-MiniMax-H3-Turbo. On a tier where the step count is the largest single lever, that matters more here than it does on a card that holds the transformer resident.

Nobody has published a Turbo timing on an RTX 5080. What the adapter's board does contain is a 5080 owner reporting on it: a user posting as TTL2321265 states his configuration as "PC SPEC: RTX5080+32GB SYSTEM RAM" in discussion #19, a thread about audio degradation after a ComfyUI update, and reports the audio coming out clean on his parameters. Two useful things follow: the Turbo path runs on this card, and it runs on the 32GB RAM configuration the Running section says needs --disable-pinned-memory.

Three things the board settles that a skim leaves ambiguous:

• The pruned int8-convrot base this page installs is supported. An early report to the contrary predates the node pack and describes a hand-converted adapter under ComfyUI's generic LoRA loader. In discussion #11, opened to ask for exactly that compatibility, the pack's author replies "Node updated for pruned base.", and users on the pruned base subsequently confirm it works.
• Four steps is below the floor. In discussion #20, titled around severe degradation and audio corruption at four steps, a participant is blunt: "Forget about 4 step. 4 step is bad. Minimum is 6 steps". A second in the same thread adds that clip length and resolution need controlling alongside the step count.
• The pack moves fast and audio is where it breaks. The thread the 5080 report sits in opened as an audio regression after a ComfyUI-side sampler fix; the pack's author answered that he was fixing it, and a later participant reports the fix landing in a node-pack release. Pin a version, and re-check the audio track specifically after any update.

Get a known-good render at 20 steps on the stock sampler before you try any of this, so you have something to compare against. And the licence point from the top of this page reaches here too: an adapter's own tag covers the adapter, not the base weights it loads against.

Troubleshooting

Windows: the process dies during video VAE decode

This one is reported on your exact architecture and is worth knowing before you meet it. ComfyUI issue #15337 documents the official image-to-video template killing the whole ComfyUI process during video VAE decode on a Blackwell sm_120 card under Windows/WDDM on cu130 — a native access violation rather than a Python exception, so there is no traceback to read. The reporter tried disabling async offload alone and the process still died, noting "the crash is not limited to the async file-read path." Disabling async offload and pinned memory together completed the run. Your launch line already carries the second flag for unrelated reasons; add --disable-async-offload next to it if you are on Windows and losing the process at decode time.

The output is noise — both the picture and the audio, with no error

Check your clip length before you check anything else, because on sm_120 this failure is gated on sequence size rather than on configuration: the same install is clean at five seconds and can be garbage at thirty. Work out your token count with the arithmetic in Installation step 3. Under about 90,000 you are below everything that has ever been reported to fail on this architecture, and 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 to settle it in one experiment. Above roughly 150,000 you are in the band where sm_120 boxes have produced noise, and the honest advice is to shorten the clip or drop the canvas rather than to reach for a different kernel.

Do not respond to this by pinning a SageAttention mode. Advice to pin sageattn_qk_int8_pv_fp16_cuda circulated for about a day and was withdrawn: on sm_120 that mode aborts the process outright, and every other explicit mode either crashes or throws cudaErrorIllegalAddress. The table is in Installation step 3. auto is the only setting on this architecture that has been observed to complete at all at the failing size, and pinning trades a defect you probably cannot reach for a crash you certainly can.

The sage patch refuses to load, or someone tells you to update to 0.31

Two separate things, both cheap to eliminate. Run pip show sageattention first: 1.0.6 means you have the PyPI package, which carries no CUDA kernels — the H3-specific node raises "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." against it, which is KJNodes issue #721, filed from a compute-capability 12.x card with the maintainer answering that a newer sageattention is required. Note that on this architecture that error is arguably doing you a favour; see Installation step 3 for what the node would have dispatched. SageAttention 3 installs under a different package name (sageattn3) that the --use-sage-attention flag does not resolve. Second, circulating advice to update ComfyUI to 0.31 names a release that was never tagged; v0.30.2 was the newest when this page was written and 0.30.0 is the real floor.

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 you started without it on a 32 GB machine, the pinned-buffer arithmetic in Running accounts for the whole failure on its own: 39.060 GiB of page-locked, unswappable, unreclaimable host memory requested against 32 GiB of RAM. --fast-disk attacks the same pressure from the other end, moving weights into page cache the kernel is allowed to reclaim rather than into anonymous memory it is not — a different lever from --disable-pinned-memory rather than the same one, and whether stacking the two buys a 32 GB box anything further is unpublished. --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 truncated download that is the right byte size and the wrong hash. Re-hashing a 21 GB file is cheaper than re-diagnosing it.

Image-to-video hangs for a minute at the H3 node, then runs

That is the budgeting gap in issue #15316 rather than a fault on your machine, and it is specific to the reference-conditioned modes — plain text-to-video finishes that node in seconds. --reserve-vram 2.5 is the reported workaround. Read the reserve section in Running before you set it permanently: at 2.5 GiB the text encoder stops being resident, which is a real trade rather than a free fix, and it is the wrong setting for a text-to-video workflow.

Generation is much slower than 36 seconds a step

Check the startup log before you conclude anything about the card. A comfy-kitchen import failure or the cu130 warning quoted in Installation step 1 silently removes the int8-convrot fast path while ComfyUI keeps running normally, and on hardware with this much compute that is the single most likely way to land near a far smaller GPU's timings. After that, check the graph: on this tier the largest published lever is how many steps actually get computed, not which attention kernel is running. And check the canvas — H3's cost grows superlinearly with the latent, so a jump from the template's 864×480 default to a native-resolution ten-second clip is a much bigger change than the pixel ratio suggests.

If you have eliminated all of that and still want to know what your card is waiting on, there is a diagnostic nobody in this model's public record has actually run, and it is the one a repository contributor recommended when this exact question came up on the tracker: put the job under NVIDIA's GPU profiler and look at the compute timeline. Gaps in it point at the host transfer — which on this tier is 4.721 GiB crossing the link on every sampling step — while a continuously busy timeline points somewhere else entirely. That measurement, posted through /contribute, would be the first of its kind for H3 on any 16 GB card.

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. This page rests on a single published run of this card, so if you get a clean one, a timing sent through /contribute is worth more to the next reader than every derived number here.