What You'll Build
A ComfyUI graph on a single RTX 3090 Ti that turns a text prompt — optionally with a first and/or last frame — into a 24 fps clip carrying its own synchronised stereo soundtrack. Dialogue, sound effects and music are denoised jointly with the picture in one pass; nothing is dubbed on afterwards.
The 3090 Ti is the fastest card NVIDIA ever shipped on Ampere, and this page is partly about where that helps and partly about one thing the architecture simply cannot do. Both answers are more specific than "it is a 24 GB card", and both are below.
⚠️ Read the licence before you spend 42.47 GB of bandwidth. MiniMax H3 is not open-source. The MiniMax H3 Community License Agreement grants rights only inside an "Applicable Territory", and its clause I.5 defines the exclusions: "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 the footage: "You may not use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory."
Do not expect a metadata filter to warn you. The machine-readable
license:facet on both cards is the uninformativeother, so anything keyed on that field — HuggingFace's own filters included — passes straight over a territorial restriction. Repacking does not reset it either: the Comfy-Org build installed below points back at the same agreement, and a community GGUF or int4 conversion of these weights is a derivative that inherits the same terms. MiniMax publishes a licence Q&A and takes per-deployment applications atplatform.minimax.io/h3-license. This paragraph is one reader's summary; the linked agreement is what binds you. The two clauses above are quoted from revisionbfc8ed0353and the links deliberately point at the current text rather than that revision — for a licence, what is in force now is the thing to read.
Hardware data: RTX 3090 Ti (24GB VRAM) · 20.721 GiB at the binding denoise stage · See benchmark data
ℹ️ The 2K in the launch coverage is not in the download. H3's 2K output is produced by a separate
H3-Regenerate-2Kmodule, and the MiniMax 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, which the same card documents with a 768-pixel short edge by default. No consumer card changes that, this one included.
Requirements
| Component | Minimum | This recipe |
|---|---|---|
| GPU | 12GB VRAM via ComfyUI's dynamic offload; 24GB to keep the denoise pass resident | RTX 3090 Ti (24GB), Ampere GA102 — not measured by us; the budget below is arithmetic over file bytes and ComfyUI's own constants (/contribute) |
| RAM | 32GB with --disable-pinned-memory or --fast-disk; 64GB without | — |
| Storage | 42.47 GB of weights | 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, taken byte-exact from the Comfy-Org repack's tree API this round:
| 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 the 24 GB is actually for
Not for holding the pipeline. Two of those files are large and they do not co-exist:
text encoder 15,687,142,551 B = 14.610 GiB
transformer 20,970,379,616 B = 19.530 GiB
──────────────────────────────
34.140 GiB against 24 GiB: short by 10.140 GiB
So ComfyUI's on-demand eviction runs on this card, and no consumer card avoids it — 34.140 GiB is past the 32 GiB of NVIDIA's largest consumer part too. load_models_gpu in comfy/model_management.py adds up what the requested models need and calls free_memory(...), which walks the already-loaded models and unloads them until the request fits. There is no arrangement of the four official files that keeps the encoder and the transformer co-resident here.
What 24 GB does buy is that the denoise stage stays put: 19.530 GiB of transformer weights plus ComfyUI's 1.191 GiB inference-reserve floor is 20.721 GiB, which clears the card by 3.279 GiB. Denoise is where nearly all the wall-clock goes, and a card that holds it never streams those weights across PCIe on any of the 20 steps. That is the same regime the previous 24 GB Ampere part is in, and it is a different regime from every 16 GB and 12 GB card — see /check/minimax-h3/rtx-3090-ti for how the tiers compare in our catalogue.
The 12 in the Requirements row 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 is in flight during sampling; at 24 GB it stops being.
Installation
1. Put ComfyUI on a CUDA 13 PyTorch
H3's nodes are in ComfyUI core (comfy_extras/nodes_minimax_h3.py) from release v0.30.0, not a custom node pack. v0.30.2 is the newest tag at the time of writing, and it is what every source reference on this page is pinned to.
The CUDA gate is in ComfyUI's own code rather than folklore. comfy/quant_ops.py parses torch.version.cuda; if the major version is below 13 it calls ck.registry.disable("cuda") and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." That one call removes the comfy-kitchen CUDA backend — the accelerated kernels for the int8_tensorwise + convrot format the transformer is stored in. Nothing raises; the run is simply slower, and on Ampere you have no second fast path to fall back to.
Order matters: requirements.txt lists torch unpinned, so running it after a cu130 install can pull a default-index wheel over the top and quietly undo the gate you just cleared. 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
Two things to confirm in the startup log before continuing: the torch version string ends in +cu130, and comfy-kitchen's CUDA backend reports itself available. A failed import there produces one buried line and no other symptom.
2. Download the four model files
Run this 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 demotes b and c to filenames — whereupon the command drops the flag altogether with nothing but a warnings.warn("Ignoring \--include` since filenames have been explicitly set.")` in the way.
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 repository's own paths are already diffusion_models/, text_encoders/ and vae/, so --local-dir models puts all four exactly where the loaders look.
Take the pruned transformer. The unpruned int8_convrot build is 31.701 GiB — 12.171 GiB larger, and larger than the card, so it streams on every step. Pruning here is not a precision cut in the usual sense: Comfy-Org's launch post describes the removed parameters as the model's modulation weights, swapped for an equivalent lookup table, with no quality loss claimed.
Then check the hashes. A MemoryError out of UNETLoader on this repack has already turned out to be a truncated download that matched on size — see Troubleshooting. Re-hashing a 21 GB file costs less than re-diagnosing one.
3. SageAttention — on this card, the easy path is the measured one
This is where an Ampere page gets shorter than an Ada or Blackwell one rather than longer, and it is worth being precise because the two things called "SageAttention support" are different code paths.
The path with a published Ampere measurement needs nothing but pip install sageattention. ComfyUI's built-in --use-sage-attention routes through attention_sage in comfy/ldm/modules/attention.py, which imports exactly one symbol, sageattn, and that symbol is present in the current PyPI release. H3's transformer does not opt out of it: comfy/ldm/minimax/model.py still calls optimized_attention(...) at v0.30.2 with no low_precision_attention=False argument, so the flag reaches the DiT. The same one-symbol import backs KJNodes' general-purpose Patch Sage Attention KJ node in auto mode. Timings for both are in Results.
pip install sageattention
The path that does need a 2.x build is KJNodes' H3-specific memory-efficient patch, and its blocker is an import rather than a kernel. nodes/ltxv_nodes.py pulls six names out of sageattention.core in a single statement — per_thread_int8_triton, per_warp_int8_cuda, per_block_int8_triton, per_channel_fp8, get_cuda_arch_versions and attn_false. Reading the published 1.0.6 wheel: its core.py is 8,530 bytes, defines two functions (sageattn and sageattn_varlen), and of those six names carries only attn_false, and that as a re-export of another module's forward. So the statement raises, the architecture probe never runs, and the node reports "sageattention is not new enough version or could not determine CUDA architecture, cannot apply MiniMax H3 Memory Efficient Sage Attention Patch." That failure has nothing to do with your card — it is the same on every architecture. The genuine split is the operating system:
- Windows. woct0rdho's fork ships prebuilt wheels and states "The latest wheels support GTX 16xx, RTX 20xx/30xx/40xx/50xx, A100, H100, AGX Orin (sm75/80/86/87/89/90/120)." —
sm86is on that list, so a 3090 Ti on Windows installs a wheel and is done. - Linux. There is no wheel to install — that fork ships Windows builds only, and every asset across its releases is a
…-cp3**-abi3-win_amd64.whl, while PyPI carries nothing above the 1.x line. Build it, 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.6 MAX_JOBS=8 \
pip install --no-build-isolation "git+https://github.com/thu-ml/SageAttention.git"
--no-build-isolation is not optional — without it pip drags a second torch into the build environment. 8.6 is this card's compute capability and confines the build to kernels you can actually run.
What that build buys on Ampere is the memory-efficient patch, not different kernels. _cuda_archs[0] in {"sm80", "sm86"} in the same KJNodes file casts V to torch.float16 and calls _qattn_sm80.qk_int8_sv_f16_accum_f32_attn; the sm89 branch instead quantises V with per_channel_fp8 and calls into _qattn_sm89. Same node, different silicon, different kernel — and the Ampere one is the INT8-QK / FP16-PV variant, which on current evidence is the side of that split you want to be on. The SageAttention entry in Troubleshooting is why.
4. Load the official template
Open ComfyUI, go to Template Library, pick MiniMax H3 Text to Video — or drag in video_minimax_h3_t2v.json. The image-to-video template loads the same four files through the same generation node; connect first_frame and/or last_frame and it switches from t2va to fl2va on its own.
Running
python main.py --disable-pinned-memory --use-sage-attention
Queue the template unchanged first — and know what "unchanged" resolves to, because the generation node's stored widgets disagree with what runs. The template's Resolution Selector is set to 16:9 (Widescreen) at 0.4 megapixels, 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 multiple of 32 on each axis, gives 864 × 480. The template's own math node snaps the frame count to a 17k+5 grid, so a 5-second request lands on 124 frames. Sampler is res_multistep, scheduler simple, 20 steps. If you actually want 1344×768, set the Resolution Selector to 0.98 MP.
Three stages, one large module at a time
| 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 the int8_convrot encoder instead | 25.277 GiB | 1.191 GiB | 26.468 GiB | −2.468 GiB |
Every row but the last fits on its own; no two fit together. The middle row is the binding one, and it is also the only row that does not move with canvas size — weights plus a fixed floor — so pushing the resolution to 1344×768 does not change whether this card holds the denoise pass. It only lifts the decode reserve to 2.851 GiB, a 7.701 GiB stage that is still nowhere near binding.
That 1.191 GiB is minimum_inference_memory() on a Linux host: 0.8 GiB plus a 400 MiB EXTRA_RESERVED_VRAM, both literal constants in comfy/model_management.py at v0.30.2. On Windows the constant is 700 MiB for a card this size — 600 MiB base plus a further 100 MiB once total VRAM passes 15 GiB, a clause nested inside the Windows branch and reached nowhere else — which raises the floor to 1.484 GiB, the denoise stage to 21.014 GiB, and shrinks your surplus to 2.986 GiB. Either way the floor is what binds, because the sampler's own activation estimate for the stock latent lands well below it. Note also that get_free_memory() reads torch.cuda.mem_get_info, so the budget is against free VRAM: a desktop session or a browser with hardware acceleration is spending out of the same 24 GB before ComfyUI starts.
The last row is what 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 some people who have compared the encoders prefer it — in discussion #16 a community poster writing as V33rGeer says "you shouldn't be using the NVFP4 text encoder, as it compromises the coherence of tricky setups", with the escape clause "unless your system physically cannot handle it". On 24 GiB that clause is load-bearing: the stage comes to 26.468 GiB, so it streams. You can still load it — text encoding is one forward pass — but you are paying 10.667 GiB of extra transfer per run for it, and nobody has published a timing for the swap on any 24 GB Ampere card. Treat it as a quality experiment rather than a tuning step, and 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 Ampere's fastest part changes here — and what sm_86 subtracts
The Ti part
NVIDIA's own RTX 3090 family page puts the two 24 GB Ampere cards in one table, and the deltas are small in count and large in power: 10,752 CUDA cores against 10,496, a 1.86 GHz boost clock against 1.70 GHz (1.56 against 1.40 GHz base), and a 450 W board power against 350 W. Memory is identical on both counts NVIDIA publishes — 24 GB of GDDR6X on a 384-bit interface — and that page publishes no memory clock or bandwidth figure for either card, so this page does not assert one.
Where that matters is narrow and specific. The denoise stage above is resident on a 24 GB card, which means the 20 sampling steps are not gated on moving 19.530 GiB across PCIe the way they are on a 16 GB or 12 GB card. A clock advantage has somewhere to land only once streaming is out of the way. The inverse is on display in ComfyUI issue #15261, where a 16 GB Ada owner asks why a 16 GB Blackwell card appears 2.3× faster at the same job — his own half of that comparison is a measurement, the other half a figure he took from a third-party video — and the first reply, from a commenter posting as TheLeastMost, answers "When using neural networks, its rarely about compute capabilities (which yes 4080=5070ti, in games), its about memory bandwidth." Both cards there are streaming the transformer on every step; that is the regime this one is not in.
How much of the clock advantage lands on H3 is unmeasured. Every published H3 datapoint this round could find lives in the Comfy-Org repack's discussions and the ComfyUI tracker, and enumerating all 36 threads message by message — 219 messages — turns up no RTX 3090 Ti report at all, with or without a space in the name. So nothing on this page is a Ti measurement, the Results section names the card behind every number it quotes, and a timing sent through /contribute would be the first one anybody has.
The sm_86 part
Ampere's compute capability is 8.6, and one function in ComfyUI turns that into a real subtraction. supports_fp8_compute() in comfy/model_management.py returns True for major ≥ 9, then False for major < 8, then False for minor < 9 — so 8.9 passes and 8.6 does not. pick_operations in comfy/ops.py turns each failed probe into a disabled format and prints the split at startup as a Native ops: line with an emulated ops: tail. On this card float8_e4m3fn and float8_e5m2 are on the emulated side. Three consequences, in descending order of how much they should change what you do:
1. The FP8 transformer is not a fork you have. The repack ships minimax_h3_fl2va_pruned_fp8_scaled.safetensors at 20,958,205,608 B = 19.519 GiB — 11.61 MiB smaller than the int8 file this page installs, so on memory it is a straight swap. Reading its safetensors header directly, its 200 quantised layers split cleanly by descriptor length: 150 carry a 27-byte {"format": "float8_e4m3fn"} with no full-precision opt-out and an accompanying input_scale, and the other 50 — every block's mlp.fc2 — carry the 63-byte form with "full_precision_matrix_mult": true and no input_scale. On an Ada card those 150 layers are a native FP8 matmul. Here they are not: the loader in comfy/ops.py sets _full_precision_mm = True for any layer whose format is in the disabled set, and the forward pass builds its _use_quantized decision with not self._full_precision_mm as a conjunct. So the file loads, occupies the same memory, and dequantises. It is the one place Ada owners have an open question worth asking; on sm_86 the question does not arise.
2. NVFP4 was never a compute story on any card, and the text encoder proves it from two directions. supports_nvfp4_compute() requires compute capability 10 or higher, so nvfp4 is emulated here — but the encoder file declines the accelerated path regardless of hardware. Its header carries 351 comfy_quant descriptors: 350 of them are the 55-byte {"format": "nvfp4", "full_precision_matrix_mult": true}, and the remaining one, on model.embed_tokens, is a 29-byte int8_tensorwise. The file also ships zero input_scale tensors, and activation scales are precisely what an FP4 matmul needs. A Comfy-Org maintainer made the same point in prose in discussion #16 when Ada owners asked for an int4 build — "it's just used as storage format here, there's nothing hardware specific about that" — and a 3090 owner posting as progmars reported the observable half a few messages later: "did not notice any benefits from NVFP4 on 3090 but it was not any worse than int8 either". Pick the encoder on size and quality, never on whether your card speaks FP4.
3. The transformer's fast path is real, and it is not gated on your architecture. This is the half of the story that is easy to over-generalise, so state it positively: every one of the 200 quantised layers in minimax_h3_fl2va_pruned_int8_convrot.safetensors carries the identical 72-byte descriptor {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256}, and there is no full_precision_matrix_mult opt-out anywhere in the file. int8_tensorwise never enters pick_operations' disabled set on any NVIDIA card. So "the file declines its quantised path" is true of the text encoder and false of the transformer, and what actually gates the transformer's kernels is Installation step 1 — a cu130 torch build and a working comfy-kitchen import — not sm_86.
Where the FP8 silicon you do not have would otherwise have shown up is attention, not weights, and that is the KJNodes kernel split in Installation step 3. The size of the prize is worth knowing: the commenter who measured this card's predecessor put H3's attention share at "roughly 55% of sampling at 480p/5s, considerably more at 720p or 15s", so it is over half the sampling clock. Ampere gets a working INT8 attention speedup, measured below, and does not get the FP8 PV kernel — which on this particular model has turned out to be the better half of the trade. Troubleshooting has the thread.
Results
-
Speed: our catalogue has no benchmark rows for this pair — /check/minimax-h3/rtx-3090-ti returns
verdict: unknown— and no RTX 3090 Ti run of H3 has been published anywhere this round could find. The nearest thing is a run on the RTX 3090, the same GA102 silicon at 24 GB and lower clocks, posted by a commenter as pepikir on ComfyUI issue #15263. His setup line is "RTX 3090 (sm_86), ComfyUI 0.30.1, torch 2.11.0+cu130,sageattention1.0.6 (PyPI, pure-Triton wheel),minimax_h3_fl2va_pruned_int8_convrot.safetensors, 864×480, 124 frames, 20 steps,res_multistep/simple,BasicGuider, fixed seed." — read against the Running section, that is the stock template on the exact checkpoint installed here. On an RTX 3090 he measured 9.00 s/it without SageAttention, which his table reports as ~180 s across the 20 sampling steps, against 6.57 s/it with the KJNodes node and 6.50 s/it with ComfyUI's own--use-sage-attention, both on the stock PyPI wheel — a ~1.37× either way, with "Zerousing pytorch attention insteadfallbacks in either run, so sage was genuinely active both times."That number is an RTX 3090's, not this card's, and it should be read as a ceiling rather than an estimate. The 3090 Ti is the same architecture with more cores, higher clocks and a 100 W larger power budget per NVIDIA's own table, and it is running a stage that never leaves VRAM, so it should come in under 180 s — by how much, nobody has published. It is also one person's uncontrolled run, and it counts sampling only: text encode, VAE decode and the model loads sit on top and are substantial. If you run this pair, please post a timing through /contribute so /check/minimax-h3/rtx-3090-ti can carry something first-party.
-
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 above and ComfyUI's own constants rather than measured by us, and it covers weights and floor only: a long clip's activation working set sits on top and grows with frames and pixels. Live data, when it exists, appears at /check/minimax-h3/rtx-3090-ti.
-
Quality notes: the model's documented weakness is faces at distance. A 12 GB-card owner 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 property of the model rather than of memory, so 24 GB does not buy you out of it. Frame for close and medium shots. On the quantisation tier, a 3090 owner asked directly in discussion #18 whether to run Q4, Q2 or int8, and a Comfy-Org maintainer answered "Int8 indeed." — the pruned qualifier on this page is the memory budget's doing, since the unpruned int8 file is 31.701 GiB and cannot sit resident here.
For the full benchmark data, see /check/minimax-h3/rtx-3090-ti.
Optional: the Turbo LoRA
A community distillation adapter, larryvrh/MiniMax-H3-Turbo-Lora, with its own node pack at Larryvrh/ComfyUI-MiniMax-H3-Turbo, brings sampling down to as few as 4 steps — "a ~5× sampling speedup" against the usual 20, in its author's words. Step count is the largest single lever on any card, so of everything optional on this page this is the one worth watching.
That link is pinned to a specific revision on purpose, and you should check whether the card has moved again. It was rewritten three times inside one day while this page was being written. At the pinned revision the recommended weights are minimax_h3_turbo_v4_step600_ema.safetensors; the over-sharpened, plastic look of the earlier v1 line is described there as resolved; and the useful step range is given as 4–8 rather than exactly 4, with 6–8 preferred. The author still labels the whole thing "Still a preview — training continues", naming audio and behaviour under fast motion as the areas still being worked on. Its instructions route SamplerCustomAdvanced through the pack's own sampler node, and an earlier version of this page said that was required because a stock sampler over-steps H3's separate audio flow schedule. That is not true on the ComfyUI this page installs. The core module's own docstring at v0.30.2 says the opposite — comfy_extras/nodes_minimax_h3.py opens with "sampling runs on the flat pack with any stock sampler (the model handles the audio stream's shifted schedule internally)" — and MiniMaxH3SigmaShift is what makes that so: it sets the sampler's sigma schedule from shift_video and hands both shifts to the DiT through transformer_options, which derives the audio schedule from the video one itself. The adapter's own card agrees when you read it closely: it presents the custom sampler as a compatibility shim that "auto-adapts to your ComfyUI version", for older builds that lack the native handling. Use the pack's sampler because its instructions ask for it, not because a stock one is broken here.
None of that is card-specific and none of it is measured here: no before-and-after has been published on any 24 GB Ampere card, so read the 5× as the author's figure for his own hardware rather than a number for yours. The licence point at the top of this page survives here too — an adapter's own permissive tag does not lift the base weights' territorial restriction.
Troubleshooting
The text encoder will not load — UnicodeDecodeError, then "Unknown quantization format"
Reported on an RTX 3090 in ComfyUI issue #15400 against this recipe's exact encoder file, so it is worth naming — but check your own artifact before inheriting the symptom. The report's premise is that "Some comfy_quant tensors in this file contain only NUL bytes", specifically that model.embed_tokens.comfy_quant is a 29-byte all-zero placeholder that sends json.loads down a UTF-32 detection path. Reading that tensor out of the published file over a byte-range request this round, its 29 bytes are not zeros: they decode to {"format": "int8_tensorwise"}. The reporter was also on a master checkout rather than a release tag, and CUDA 12.9. So before changing anything, pin the release tag as in Installation step 1 and re-hash the download; a size-matching truncation looks exactly like this and is far more common than a bad upload.
MemoryError from UNETLoader on a card that should fit
Same instinct, cheaper check. In discussion #29 a Comfy-Org maintainer's first guess at a MemoryError raised while the loader was still parsing the safetensors header was a failed download, and that is what it was — the reporter re-fetched and got the same byte size with a different hash. That instance was on a neighbouring ref2va artifact, not on this recipe's file, so it is one documented case rather than a known defect. Re-hash first anyway; truncation is invisible until load time.
ComfyUI is killed, or dies on host RAM rather than VRAM
The VRAM budget above has room. Host memory is the tighter constraint here, and it is a property of the transformer's size rather than of your card. MAX_PINNED_MEMORY is 90% of system RAM on Linux (40% on Windows), and pinned_hostbuf_size(size) returns min(size, MAX_PINNED_MEMORY) * 2 — twice the model size in page-locked host memory, which can be neither swapped nor reclaimed. For the 19.530 GiB transformer that is a 39.060 GiB request, which a 32 GB box cannot satisfy and will be OOM-killed for. --disable-pinned-memory skips the allocation entirely: the flag guards the assignment, so MAX_PINNED_MEMORY stays at its -1 sentinel, pinned_hostbuf_size returns 0 and no buffer is ever registered. --fast-disk attacks the same problem from the page-cache side, and it is the one of the two with a published number: in discussion #6 a reporter posting as UdonJP, on an RTX 5070 Ti with 125 GB of system RAM, logged ComfyUI's resident set at 45.4 GiB with no flags against 12.6 GiB with --fast-disk. Treat that as one person's box rather than a controlled comparison — but it sizes the appetite of a default launch, and it is the same appetite on this card, because the number is set by the transformer rather than by your GPU.
What neither flag has is a measured time cost, and you should not budget one you cannot cite. The mechanism points in a clear direction: at 64 GB the 42.47 GB weight set sits 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 arrives off the SSD instead of out of RAM. Nobody has published either measurement. 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. On 64 GB, use the flag and expect to pay little. On 32 GB, use it anyway and expect to pay something — a slow render beats a killed one, and NVMe rather than SATA is what decides how much of it you feel. Timing the same job with and without the flag at a known RAM size is a small experiment nobody has run; /contribute is where it belongs.
Do not route the decode through VAEDecodeTiled
H3's video VAE already tiles and chunks internally, and ComfyUI sets handles_tiling = True for it in comfy/sd.py. Pushing its packed audio+video latent through the tiled-decode node raises a to() received an invalid combination of arguments - got (NestedTensor) error, reported as ComfyUI issue #15274. Use the plain VAEDecode and VAEDecodeAudio nodes the template already wires up. The decode reserve in the Running table is not a guess either: comfy/sd.py ships a first-party estimator for this VAE, (9.5 × frames × height × width + 270,000,000) × dtype_size × 1.03, which at 124 frames of 864×480 in fp16 gives the 1.455 GiB in that row.
SageAttention noise: the broken kernel is one this card never runs
ComfyUI issue #15263 is worth reading rather than skimming, because it has held four positions and its current title is only the newest of them. As of 8 August 2026 that title names FP8 PV kernels, noise above roughly 160k tokens, and sm_120 — none of which appeared in the title the issue carried a week earlier, so check it again rather than trusting this sentence. Its author began by blaming a missing low_precision_attention=False, withdrew that root cause, and then confirmed a different one — "I think you've got it right that FP8 PV is the cause". Note what was and was not retracted: his explanation was, his finding was not, and it was sharpened afterwards.
The reason this card is out of scope is the kernel, not the clip length. A commenter re-sorted every datapoint in the thread by PV path rather than by GPU and got a table that finally sorted: "Every noise report is FP8 PV. Every clean report at high token count is FP16 PV." Neither Ampere route reaches an FP8 PV kernel. The stock PyPI 1.0.6 wheel has a single Triton path and no architecture dispatch — reading it, that same commenter finds "no FP8 kernel at all" and describes what it does run as "INT8 QK, FP16 PV, FP32 accumulator. That is arithmetically the same class as @mapuamap's clean Blackwell run." Build 2.x for the memory-efficient node instead, and sm80/sm86 dispatch to _qattn_sm80.qk_int8_sv_f16_accum_f32_attn — the same class again. So on this card there is nothing to pin and nothing to switch off: the default is already the kernel nobody has broken. Do not lift the FP16-PV workaround the issue body offers Blackwell owners, either; its own proposer withdrew it after every explicit kernel mode failed on that architecture, on the grounds that pinning a kernel which aborts turns noise into a crash.
A clip-length caveat would not have earned its place here anyway, because the model will not build a job that big. The observed boundary is sharp — clean at 150,960 tokens, noise at 167,280, and the reporter calls it "a cliff, not a slope". But H3 caps its own canvas: MAX_PIXELS = 768 * 1344 in comfy_extras/nodes_minimax_h3.py, enforced by adapt_canvas, so the largest job the model will accept at the top of its trained frame range — 1344×768 at 362 frames — is 91 × 42 × 24 = 91,728 tokens under the thread's counting rule. That is 55 % of 167,280, the lowest count at which anyone has seen the failure. Reaching the cliff means leaving the model's supported envelope, on any GPU. Carry the metric's own caveat too, from the person who computed it: "I don't think it's the model's literal sequence length" — video_latent_t() returns 107 temporal positions for 362 frames where that rule gives 91 — so it ranks jobs rather than measuring them.
What is genuinely unestablished is whether this configuration is exposed at all. Every sm_120 noise report in the thread that names a checkpoint is on the bf16 transformer with the bf16 text encoder; the thread's only int8_convrot participant is on an Ampere card. So nobody has tested the defect against the four files this page installs, on any GPU. Read that as a gap in the evidence, not a clean bill — SageAttention operates on activations rather than weights, so there is no mechanism by which the checkpoint would obviously matter. The cause is open as well: three explanations have been offered in that thread and two were retracted by the people who proposed them. The live hypothesis is not arithmetic at all, since auto and the ++ mode share a PV accumulator and differ only in qk_quant_gran yet behave differently — "the PV path isn't the discriminating variable" — and a sharp in-frame boundary reads instead as "the signature of something tile-indexed going out of range past a threshold, not of arithmetic precision." Take the boundary as observed and the cause as unsettled.
In practice, on this card: sage is measured clean on the stock template at a fixed seed with a PSNR check against the non-sage render (see Results), and past that you should be looking at your own output regardless.
Out of memory while encoding a reference video
The reference-to-video workflow VAE-encodes each reference clip before sampling, and that encode is a separate and larger peak than anything in the Running table — ComfyUI issue #15312 shows a 16 GB card failing on a single 7.17 GiB allocation there. That graph also loads a different diffusion checkpoint (minimax_h3_ref2va_pruned_int8_convrot.safetensors), so it is a separate download and a separate memory question from the t2v/i2v path documented here. Start with reference images before reference video.
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 above.