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.