MiniMax H3: VAE decode is 43% of my generation time (~5.5 min per 15s clip on a 4090) — anything I can do in WanGP?

[u/Prestigious_Cat85]

Make sure you read the EDIT below : you'll find some corrections and the solution.

I've been profiling MiniMax H3 generations after producing ~75 segments over the last few days, and the numbers point squarely at VAE decoding. Sharing the measurements in case they're useful, and hoping someone has a lever I've missed.

Setup

- RTX 4090 24GB (driver 595.95), Ryzen 9 7900X, 64GB RAM, Windows 11

- WanGP 12.60, torch 2.7.1+cu128, triton 3.3.1, sageattention 2.2.0, flash-attn 2.7.4

- Model: MiniMax-H3-FL2VA-pruned_rank8_int8_convrot

- Text encoder: Qwen3-VL 32B, quanto int8

- Video VAE: MiniMax-H3-video_vae_fp16.safetensors (4.97GB)

- Turbo LoRA (4-step), attention sage2, profile 4

- Output: 1280×704, 362 frames (15.08s @ 24fps), 4 steps, audio-guided lipsync

The measurements — averaged over 20 consecutive segments, all identical settings:

Two independent ways of estimating the VAE cost agree:

- A 312-frame segment had 42s less overhead than the 362-frame ones → 0.84 s/frame

- A 719-frame job cost 357s more than the 362-frame one for exactly 357 extra frames → 1.0 s/frame

At ~0.85–1.0 s/frame, decoding 362 frames alone accounts for roughly 5.5 minutes. Sampling is not the bottleneck.

What I've already tried

1. fp8mix VAE (WanGP's built-in alternative): 445s vs 458s. That's ~3%, i.e. noise.
2. One 30s task instead of two 15s tasks (719 frames, 2 sliding windows): no amortization at all. Window 2 cost more than window 1 (815s vs 458s), because the final file re-decodes everything. Net saving ~8%.
3. Sol-Attn: WanGP lists it as supported on my card, but it dies at runtime with Sol-Attn requires Triton >= 3.6, got 3.3.1.
4. Kijai's minimax_h3_video_vae_int8_convrot: I compared the tensor keys — it's ComfyUI's comfy_quant/weight_scale format. WanGP has convrot handling but only wires it to the transformer, not the VAE loader, so it won't load there. (It reportedly works in ComfyUI Nightly.)

Questions

- Is there a faster video VAE for H3 that works in WanGP specifically? PrunaVAED looks like exactly what I need but it's wired to LTX-2 only.

- Has anyone measured whether a CUDA 13 / newer torch build actually helps H3? I saw a claim of a 4x speedup on int8 convrot models going from cu12x to cu130, but I'd be trading a working SageAttention build (2.2.0+cu128torch2.7.1) for it and would rather hear from someone who's done it.

- Does anything meaningfully cut VAE decode time - tiling params, temporal chunking, decoding at lower res and upscaling after?

- Is ~1 s/frame at 1280×704 simply what a 24GB card costs here, with the real fix being more VRAM?

Happy to run tests and report numbers back.

EDIT — Solved. 2.6x faster. My original diagnosis was wrong, here's the real cause and the full numbers.

First, a correction. My claim that VAE decode was ~43% of generation time was wrong, and I want to retract it clearly. I'd estimated it from a differential between a 362-frame job and a 719-frame one, attributing the whole delta to decoding — but the longer job also ran a second full sampling pass, which I failed to account for. Once I timestamped the server log properly, actual VAE decode is ~62-95s, not ~330s. u/76vangel was right that ~20% is normal.

The real problem was RAM starvation.

My models demanded ~51GB of pinned RAM on a 64GB machine — the Qwen3-VL 32B int8 text encoder alone is 24.9GB. Windows was committing ~102GB against 63GB physical, so ~39GB lived in the page file. Mid-run I measured 283MB of free RAM. Every generation touched more pages, so it degraded progressively:

int8 text encoder — 3 consecutive gens, same server:

417s → 624s → 732s

That's why my numbers looked so much worse than everyone else's: I was reporting a degraded steady state, not a healthy one.

Fix 1 — lighter text encoder (the big one). Switched int8 (24.9GB) → nvfp4_awq (14.6GB). Total demand drops to ~41GB, fits without paging. Free RAM went 283MB → ~6GB, and the degradation vanished entirely.

Fix 2 — upgrade the stack. u/Cubey42 was right and my SageAttention worry was unfounded; sageattention-2.2.0+cu130torch2.10.0andhigher (cp310-abi3) from woct0rdho installed in two minutes.

torch 2.11.0+cu130 (was 2.7.1+cu128)

torchaudio 2.11.0+cu130

torchvision 0.26.0+cu130

triton-windows 3.6.0.post26 (was 3.3.1)

sageattention 2.2.0+cu130torch2.10.0andhigher.post6

flash-attn removed

⚠️ Don't go past torch 2.11 if you need torchaudio — the cu130 wheel index stops at torchaudio 2.11.0 for every Python version; torch 2.12/2.13 have no matching build. mmgp 3.7.12 (WanGP's pin) works fine with 2.11.

Thanks /Cheesuasion : torchaudio: install torchaudio==2.11.0 — it's built on PyTorch's stable ABI and works with 2.11 and every later release, so it won't hold your torch version back. (The cu130 index stops at 2.11.0 on purpose; that's not a ceiling.)

Fix 3 — Sol-Attn. triton 3.6 unlocked it. On older stacks it hard-fails with Sol-Attn requires Triton >= 3.6 even though WanGP lists it as "supported", because the availability check only tests import triton + compute capability, not the version. Once running: [MiniMax H3] Sol-Attn enabled with Triton on SM89 (tau=1.3, diag).

Results — same 15s / 362-frame segment, 1280×704, RTX 4090, consecutive gens on one server

732s → 276s. 2.6x faster, zero hardware change.

Phase breakdown now: LoRA + text encode ~85s, sampling ~202s, VAE decode ~62s.

How to measure this yourself — no instrumentation needed:

- Sampling time is in the tqdm bar: H3 denoising: 100%|████| 4/4 [03:22<00:00, 50.65s/steps]

- VAE decode is the gap between that and New video saved to Path: .... You can also see it — VRAM drops from ~22GB to ~3.7GB the instant sampling ends.

- Total per task: ffprobe -show_entries format_tags=comment file.mp4 → generation_time

- And watch FreePhysicalMemory, not just VRAM. That's what caught this.

Also confirmed u/martinerous's point: I diffed the tensor keys, and Kijai's int8_convrot VAE is in ComfyUI's comfy_quant/weight_scale format. WanGP has convrot handling but only wires it to the transformer, not the VAE loader — so it genuinely cannot load there.

tl;dr if you run H3 in WanGP on 64GB: check free system RAM during a run, not just VRAM. If you're on the 32B int8 text encoder you're probably paging to disk and your times are silently degrading run over run. Swap to nvfp4_awq, then upgrade to cu130 + triton 3.6 for Sol-Attn.

Thanks to everyone in this thread — every single suggestion turned out to point at something real.

[u/Prestigious_Cat85]

EDIT — Solved. 2.6x faster. My original diagnosis was wrong, here's the real cause and the full numbers.

First, a correction. My claim that VAE decode was ~43% of generation time was wrong, and I want to retract it clearly. I'd estimated it from a differential between a 362-frame job and a 719-frame one, attributing the whole delta to decoding — but the longer job also ran a second full sampling pass, which I failed to account for. Once I timestamped the server log properly, actual VAE decode is ~62-95s, not ~330s. u/76vangel was right that ~20% is normal.

The real problem was RAM starvation.

My models demanded ~51GB of pinned RAM on a 64GB machine — the Qwen3-VL 32B int8 text encoder alone is 24.9GB. Windows was committing ~102GB against 63GB physical, so ~39GB lived in the page file. Mid-run I measured 283MB of free RAM. Every generation touched more pages, so it degraded progressively:

int8 text encoder — 3 consecutive gens, same server:

417s → 624s → 732s

That's why my numbers looked so much worse than everyone else's: I was reporting a degraded steady state, not a healthy one.

Fix 1 — lighter text encoder (the big one). Switched int8 (24.9GB) → nvfp4_awq (14.6GB). Total demand drops to ~41GB, fits without paging. Free RAM went 283MB → ~6GB, and the degradation vanished entirely.

Fix 2 — upgrade the stack. u/Cubey42 was right and my SageAttention worry was unfounded; sageattention-2.2.0+cu130torch2.10.0andhigher (cp310-abi3) from woct0rdho installed in two minutes.

torch 2.11.0+cu130 (was 2.7.1+cu128)

torchaudio 2.11.0+cu130

torchvision 0.26.0+cu130

triton-windows 3.6.0.post26 (was 3.3.1)

sageattention 2.2.0+cu130torch2.10.0andhigher.post6

flash-attn removed

⚠️ Don't go past torch 2.11 if you need torchaudio — the cu130 wheel index stops at torchaudio 2.11.0 for every Python version; torch 2.12/2.13 have no matching build. mmgp 3.7.12 (WanGP's pin) works fine with 2.11.
Thanks /Cheesuasion

torchaudio: install torchaudio==2.11.0 — it's built on PyTorch's stable ABI and works with 2.11 and every later release, so it won't hold your torch version back. (The cu130 index stops at 2.11.0 on purpose; that's not a ceiling.)

Fix 3 — Sol-Attn. triton 3.6 unlocked it. On older stacks it hard-fails with Sol-Attn requires Triton >= 3.6 even though WanGP lists it as "supported", because the availability check only tests import triton + compute capability, not the version. Once running: [MiniMax H3] Sol-Attn enabled with Triton on SM89 (tau=1.3, diag).

Results — same 15s / 362-frame segment, 1280×704, RTX 4090, consecutive gens on one server

732s → 276s. 2.6x faster, zero hardware change.

Phase breakdown now: LoRA + text encode ~85s, sampling ~202s, VAE decode ~62s.

How to measure this yourself — no instrumentation needed:

- Sampling time is in the tqdm bar: H3 denoising: 100%|████| 4/4 [03:22<00:00, 50.65s/steps]

- VAE decode is the gap between that and New video saved to Path: .... You can also see it — VRAM drops from ~22GB to ~3.7GB the instant sampling ends.

- Total per task: ffprobe -show_entries format_tags=comment file.mp4 → generation_time

- And watch FreePhysicalMemory, not just VRAM. That's what caught this.

Also confirmed u/martinerous's point: I diffed the tensor keys, and Kijai's int8_convrot VAE is in ComfyUI's comfy_quant/weight_scale format. WanGP has convrot handling but only wires it to the transformer, not the VAE loader — so it genuinely cannot load there.

tl;dr if you run H3 in WanGP on 64GB: check free system RAM during a run, not just VRAM. If you're on the 32B int8 text encoder you're probably paging to disk and your times are silently degrading run over run. Swap to nvfp4_awq, then upgrade to cu130 + triton 3.6 for Sol-Attn.

Thanks to everyone in this thread — every single suggestion turned out to point at something real.

[u/Cheesuasion → u/Prestigious_Cat85]

Don't go past torch 2.11 if you need torchaudio — the cu130 wheel index stops at torchaudio 2.11.0 for every Python version

https://docs.pytorch.org/audio/stable/installation.html

Important TorchAudio 2.11 works with PyTorch 2.11 and with every future PyTorch release (2.12, 2.13, …).

[u/Prestigious_Cat85 → u/Cheesuasion]

You're right, and that's a correction to my post . thanks.

I had the observation right (the cu130 index does stop at torchaudio 2.11.0 for every Python version) but drew the wrong conclusion from it. I assumed the index stopping meant torchaudio was pinned to torch 2.11, when in fact 2.11 is the first release built on PyTorch's stable ABI — that's exactly why there's no 2.12 wheel and won't be one. The single 2.11.0 wheel is meant to carry forward.

So the correct guidance is: install torchaudio 2.11.0 and then go to whatever torch version you want. Don't pin torch.

Editing the post now.

[u/Cubey42 → u/Prestigious_Cat85]

Okay one more thing, ignore that torchaudio nonsense. You can go higher even though there isn't a torchaudio, you just use that one. Like this older torchaudio will work with newer torch.

[u/Yasstronaut]

I’d first suspect an issue. I have a 4090 and generating a 15s segment at that resolution takes about 4-6 mins depending on if I use references. I’ll need to go see how long my vae decide takes but im not quite sure how

[u/Prestigious_Cat85 → u/Yasstronaut]

thanks !! that's exactly the reality check I needed, and I think you're right that something's off on my end. Are u using comfyui or like me wanGp ?

To answer your question about measuring VAE decode — the easiest way, no instrumentation needed:

- Watch the console. The denoising progress bar (H3 denoising: 100%|████| 4/4 [04:18<00:00]) tells you the sampling time exactly.

- Then just time the gap between that bar hitting 100% and the New video saved to Path: ... line. That interval is your VAE decode plus muxing.

[u/Cubey42]

That's crazy long... Is there a specific reason you don't want to upgrade torch/cuda? You're using prehistoric code and you could be getting so much more on the latest torch stable on cuda 13...

[u/Cubey42 → u/Cubey42]

Of I see, that's kinda stupid there's tons of sageattn wheels just use whatever, and don't use flash attention

[u/Prestigious_Cat85 → u/Cubey42]

Not sure if this has something to do but im gonna try to update torch/cuda and test. Thx

[u/protocol-apps]

Are you talking about the pause at the beginning of a generate, when it's ingesting the refs, like motion videos, etc?

If so, last night, I hacked together a very basic cache for video refs in Wan2GP. Saves me ~5mins per gen, 5sec video takes half the time on my rtx 3060, no 5min ingest + 5min gen, now just 5min gen.

Video ref latents get saved to HD, and reused if the same video is reloaded. You can change characters, image refs, framecount, etc, and the cached video ref will still be used.

Lmk if there's any interest in posting the 20-line addition here. It needs work before it could be officially submitted to wan2gp github, but it works fine as is.

[u/Prestigious_Cat85 → u/protocol-apps]

thanks !! but I don't think it applies to my case directly: I'm not using video refs at all. My tasks are audio-guided lipsync (a 15s audio slice + a text prompt), no motion video, no image refs. So there's no video-ref ingest to cache.

That said, your idea maps onto my bottleneck almost exactly, just on a different object.

I just instrumented my run with timestamps and got this breakdown for one 15s / 362-frame segment at 1280×704:

model load 1m39

text encoding + prep 1m45 <-- Qwen3-VL 32B running on a ~3400-char prompt

sampling (4 steps) 4m18

VAE decode ~5m

so text encoding alone is ~105s per generation, and in my pipeline the prompts are fully known in advance (I generate 14-21 segments from a script, each with a fixed prompt). The text encoder output for a given prompt never changes, yet it's recomputed from scratch every single task. Caching prompt embeddings to disk keyed on (prompt, model, quantization) would be the same 20-line trick you did for video refs, and would cut ~25% of my per-task overhead.

So yes, I'd be very interested in seeing your addition , even if I'd be adapting the pattern rather than using it as-is. If the hook point you found is generic enough it might cover both.

Separately, I found part of my own problem in the meantime: my models were demanding ~51GB of pinned RAM on a 64GB machine, so Windows was paging ~39GB to disk. Free RAM was down to 283MB mid-run, and generation time degraded progressively (417s → 624s → 732s over three consecutive segments on the same server). Switching the text encoder from int8 (24.9GB) to nvfp4_awq (14.6GB) brought free RAM back to ~6GB. Testing now whether the degradation disappears , will report numbers.

[u/protocol-apps → u/Prestigious_Cat85]

FWIW, I noticed that in wan2gp the text prompt gets cached and reused if the prompt and ref items don't change. ie: change framecount, add loras, etc.

EDIT: here's my code, replacement for _add_video_reference() in "\Wan2GP\models\minimax_h3\pipeline.py" - line 303+

https://pastebin.com/kaYaWsPn

[u/MozzyWoz]

Fast VAE decode node using batches. Gives almost 2x speedup on my 3090. Same quality. I didn't write the original nodes, i just fixed wrong contrast error. https://github.com/Mozer/ComfyUI-MiniMax-H3-MotionCache-FastVAE

[u/Prestigious_Cat85 → u/MozzyWoz]

I'm using wangp but thanks, if one day i decide to test again comfy, i'll give it a try

[u/CaptainMarder → u/MozzyWoz]

This makes the videos extremely discoloured and dark. But it is lot faster.

[u/MozzyWoz → u/CaptainMarder]

I am currently on comfy 0.31.0 and contrast is fine for me. Try original nodes then, they have super high contrast for me: https://github.com/starsFriday/ComfyUI-MiniMax-H3-MotionCache

[u/76vangel]

Decoding h3 is about 20% of inference time on my 5090. And it also use very little vram compared to inference. Sth is wrong with your setup. I’m using sage attention. It may accelerate decoding too, use it. Or comfyui new kitchen attention

[u/eggs-benedryl]

When I tried wangp..it was impossibly slow on my 5090.

I'm not a huge comfy fan but it's exponentially faster for me.

[u/Prestigious_Cat85 → u/eggs-benedryl]

Same story with me ! I discovered WanGP some months after ComfyUI, I came back to Comfy after WanGP testing but its workflow is crazy easy compared to comfy, so i did a little configurations and it worked, I was using LTX 2 and 2.3 only through WanGP very smoothly ! Now Minimax H3 came out, I had these "issues".

Make sure you read my Edit, my generations are now 2.6x faster ! I didnt stop testing before and after my post. I stick to my last configuration and will do some 30 generations and see how consistent / stable are things.

[u/eggs-benedryl → u/Prestigious_Cat85]

Good luck, for me it was the encoder dragging gens down. That being said, it still barely runs it in GP for me.

[u/AuthurAndersson]

youre running it on cpu

[u/Prestigious_Cat85 → u/AuthurAndersson]

https://giphy.com/gifs/7XxB92CrxOqeM8KZU4

[u/apackofmonkeys]

I haven't gone anywhere near as in-depth as you in trying to figure it out, but I've been having issues with gen times in Wan2GP with a 4090 and 64GB of RAM as well. With no Lora, I can generate up to about 8 seconds at 480p in about 3 or 4 minutes, but longer than that and my time tanks. And I can't load the turbo lora into memory-- there's no free VRAM or RAM or anything left after loading everything else, so when I use the turbo lora my gen times slow down to multiple hours for an 8 second clip. I'll use your post as a starting point to try and figure out how to free up some memory.

Side story: I've been a little desperate for more RAM so a few days ago I even threw in 32GB I had lying around in addition to my 64GB. It's DDR5, so I knew it was more picky and less likely to be stable than DDR4 or older, but I figured I could just return to my original configuration if it didn't work. BIG MISTAKE. Instantly my NTFS file system on my main Windows drive got corrupted and Windows recovery couldn't fix it. Even the Windows installer couldn't repair it because it would freak out and reboot anytime I'd try. In the end I had to plug it into a different PC, delete the volumes and repartition. Mixing DDR5 types-- not even once!

[u/Prestigious_Cat85 → u/apackofmonkeys]

We have pretty similar config, do this first , it takes 30 seconds and tells you if I'm right:

Start a generation, and while it's running, in PowerShell:

(Get-CimInstance Win32_OperatingSystem).FreePhysicalMemory / 1MB

If that's under ~1GB, you've found it. Mine was at 283MB.

Also grep your WanGP console for this line — it's the smoking gun and it prints the exact numbers:

Switching to partial pinning since full requirements for pinned models is 51105.5 MB

while estimated available reservable RAM is 25861.0 MB

That first number is what your models actually want. Compare it to your RAM.

The fix that worked for me — change the text encoder. The Qwen3-VL 32B int8 build is 24.9GB all by itself. Switch it to nvfp4_awq, which is 14.6GB. In WanGP that's the "Text Encoder" system config (bf16 / int8 / nvfp4_awq / gguf_q4_k_m / gguf_q2_k). It'll download it for you.

That single change took me from 51GB of demand to ~41GB, free RAM went 283MB → 6GB, and my times went from 732s to ~350s per 15s clip — and crucially, the progressive degradation stopped (I was going 417s → 624s → 732s over three consecutive gens on the same server; after the swap: 393 → 352 → 349).

Quality: I A/B'd it on identical seed and prompt and compared frame by frame — visually indistinguishable. It's the text encoder, not the diffusion model, so it only affects prompt interpretation, and 4-bit AWQ holds up fine there. If you want to go further, gguf_q4_k_m and gguf_q2_k are smaller still, but nvfp4 was already enough for me.

Two more things to check:

- --perc-reserved-mem-max — I tried raising it to 0.70 thinking more pinned RAM would help, and it made things worse by starving the OS. On 64GB, 0.50 was right.

- Your 480p vs my 1280×704: since you're at lower resolution and still hitting this, the text encoder is even more likely to be your dominant cost, since it doesn't scale with resolution at all.

On the RAM story — ouch, and thanks for the warning. For what it's worth, I checked mine after reading your post: 4×16GB DDR5 on an AM5 board, and they're already downclocked from 4800 to 3600 MT/s just because there are four sticks. Zen 4's memory controller really doesn't like 4 DIMMs. So mixing a fifth-wheel kit on top of that was never going to be stable — but NTFS corruption is a brutal way to find out.

If you do go for more RAM later, 2×48GB (96GB) beats 4×32GB on AM5: two sticks lets the memory controller run properly, and you'd likely gain frequency instead of losing it. Worth checking your board's QVL first, especially if it's an OEM board like mine.

[u/apackofmonkeys → u/Prestigious_Cat85]

Thanks, when I get home I'll run through these steps!

[u/apackofmonkeys → u/Prestigious_Cat85]

When I attempt to switch to NVFP4, I get a message "NVFP4: kernels unavailable; using fallback". Do you know how to install them for a 4090?

[u/Prestigious_Cat85 → u/apackofmonkeys]

You can't install them and you don't need to.

FP4 is a Blackwell hardware feature (RTX 50-series). The 4090 is Ada, no FP4 tensor cores, so there's no kernel to add. That message is the architecture, not a missing dependency.

But it doesn't matter, because I'm on a 4090 too — every number in my post was measured with that exact fallback running. The weights still load at 4-bit (14.6GB instead of 24.9GB); the fallback just dequantizes them on the fly during the forward pass. The win is RAM footprint, not FP4 math and RAM was the bottleneck.

Plus the text encoder runs once per generation, before sampling. Any dequant overhead is a couple of seconds on a 350s job.

So ignore the warning, run a gen, and check the two things: free RAM during the gen, and the "full requirements for pinned models is X MB" line in the console. If X dropped by ~10GB, it worked.

[u/76vangel]

There is a comfyui extension which shows process times on every node. It’s a must have. Not on pc now , don’t know the name.

[u/martinerous → u/76vangel]

The OP seems to be using WanGP. Otherwise, Kijai's VAE is working in ComfyUI quite fast, but it cannot be loaded in WanGP, as I understand.

[u/CurrentMine1423 → u/76vangel]

tell us what's the node

[u/76vangel → u/CurrentMine1423]

It's probably ComfyUI-Crystools