MiniMax H3 Fast VAE Decode

The name is a lie, and the author will tell you so to your face. MiniMax H3 Fast VAE Decode is an experimental batched-tile decoder for the H3 video VAE, and the README's own tested comparison shows it being 7.6% slower than the standard VAEDecode it replaces. That's not a bug - it's the honest result of a genuinely clever idea that mostly doesn't pay off on typical GPUs. On the right hardware it might shave real seconds off your render. This node is a benchmark in node form: you try it, measure, and keep whichever path wins.

What it does

H3's VAE is huge and doesn't decode a whole clip at once. It works in temporal chunks, and each chunk is split into spatial tiles with overlap regions that get blended back together. The stock path decodes those tiles one at a time - at 1344×768 that's 28 serial tile calls per temporal chunk (4 rows × 7 columns). This node batches tile_batch_size horizontal tiles into a single GPU call (4 by default, so 28 calls become 8), while keeping H3's temporal chunking and tile blending intact. Wire it up where you'd use VAEDecode:

H3 video latent ─┐
                 ├→ MiniMax H3 Fast VAE Decode → IMAGE frames
H3 video VAE ────┘

It's a straight swap, and it doesn't deliberately discard information - same tiles, same overlap blending, just fewer decoder invocations.

Why "fast" doesn't always win

Fewer calls doesn't mean less work. At batch 4 each invocation computes several tiles, so the total VAE math is nearly unchanged. The author's reasoning, from the README: a single 256×256 tile already gives a modern GPU enough work, so the Python and kernel-launch overhead you save gets eaten by batching, concatenation, splitting and memory traffic. Temporal chunks also stay sequential because of the overlap blending. The measured result: 11.15 s on the batched path vs 10.36 s standard - same 1.34 GB VRAM. On a weaker GPU, a lower resolution, or with different settings, the balance can tip the other way, which is exactly why the node exists for you to test.

Inputs and outputs

Three inputs, all required, all from info_schema:

• samples - the H3 video latent, or the video part of a joint video/audio latent (it unpacks that for you).
• vae - the MiniMax H3 video VAE. Feed it any other VAE and it raises an error immediately.
• tile_batch_size (4, range 1–8) - tiles per GPU batch. Bigger isn't automatically faster and uses more VRAM. If it OOMs, the node clears its cache and silently retries at batch 1.

The single output is images (IMAGE), ready for a save node or Video Helper Suite.

Installing it

Search MiniMax H3 MotionCache in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/starsFriday/ComfyUI-MiniMax-H3-MotionCache.git

Restart ComfyUI. No extra Python packages, no model downloads from the pack itself - it just needs ComfyUI 0.30.0+ with native H3 support and the H3 video VAE you already downloaded for generation. Note it ships in the same pack as MiniMax H3 MotionCache, so if you install one you get both; the two nodes are independent, and you can use this one without touching the cache node.

The take

It's a ~50-line idea with a very honest README: "benchmark it against standard VAEDecode on your GPU." Do that - swap it in, decode the same clip, compare wall time. If it wins, keep it; if it doesn't, the author's own recommendation is the standard decoder. No quality is lost either way, so the only thing on the line is a few seconds.