H3 VAE Decode Fast (Batched Tiles)

The name is doing real work here. Once you actually render MiniMax H3 clips locally, the sampling often isn't the thing eating your afternoon - it's the VAE decode that turns the latents back into pixels. H3FastVAEDecode is a drop-in replacement for the stock VAEDecode in an H3 pipeline, and it makes the decode faster by decoding spatial tiles in batches instead of one at a time. The trade-off is spelled out in its own tooltip: more VRAM per batch. If your clip fits in memory at default settings, you usually don't need it. The moment decode starts crawling or you're running H3 inside a memory-conscious windowed batch, this is the swap you want.

Only gotcha up front: it refuses to run unless you feed it the actual MiniMax H3 video VAE. It checks that the VAE's first_stage_model is a MiniMaxH3VideoVAE and raises a ValueError otherwise. SD, Flux, and LTX VAEs need not apply - this is H3-only by design.

How it works

ComfyUI's tiled decode for a big H3 latent splits the image into overlapping spatial tiles, decodes each tile, and blends the seams back together. Doing that tile-by-tile is a lot of tiny decoder passes. This node monkeypatches a clone of your VAE so its tiled_decode runs tiled_decode_batched instead: it grabs the same tile grid straight off the model (split_tiles, with the overlap regions blended via the model's own blend), but feeds up to tile_batch_size same-shaped tiles through _decode_pixels in a single call before stitching them onto the canvas.

Two details worth knowing. First, the batching is purely spatial - the temporal dimension is left to the stock H3 path, which is what the author means by "preserves stock temporal processing and blending." Second, the node clones the patcher, multiplies the VAE's VRAM estimate by your tile_batch_size so Comfy's memory planner doesn't quietly offload mid-decode, and tears the whole clone down in a finally block afterward. It's marked "experimental" in its own description, so treat first runs as a smoke test rather than gospel - verify the output looks identical to a stock decode before trusting it on long jobs.

The inputs and outputs

Only three inputs, and really only one you'll touch:

• samples (LATENT) and vae (VAE) - wire in whatever was feeding your old VAEDecode.
• tile_batch_size (INT, default 4, range 1–16) - spatial tiles decoded together per pass. Higher uses more VRAM but fewer, bigger decoder calls. Set it to 1 and it just calls the stock vae.decode untouched - handy as a sanity check and a great fallback when you OOM.

Outputs are images (IMAGE) and report (STRING). The report is a text line with decode time in seconds, frame count, and tile batch - wire it to a text preview if you like benchmarking, or ignore it. images goes where your VAEDecode output went: a preview, Video Combine, or the video saver.

Install

This is one node inside the VRGameDevGirl pack, so you install the whole pack:

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl.git

then restart ComfyUI and hard-refresh the browser. ComfyUI Manager users can just search for vrgamedev under Install Custom Nodes.

Fair warning about dependencies: the pack's requirements.txt is not small - it pulls in transformers, llama-cpp-python, voxcpm, demucs, and more, plus Cython/scikit-build-core to build them on Windows. None of that is needed for this one node. What you do need is a current ComfyUI build with native H3 support and the H3 video VAE weights in models/vae/ (minimax_h3_video_vae_fp16.safetensors). If you already run H3 locally, you have both.

Common issues

• "H3 VAE Decode Fast requires the MiniMax H3 video VAE" - wrong VAE attached. You're almost certainly feeding an LTX or SD VAE from another part of the workflow.
• CUDA out of memory - your tile_batch_size is too high for your card. Drop it to 2, or to 1 for the pure stock path, and confirm the result still looks identical before going back up.
• Decode looks subtly different from stock - it's experimental and reorders the decoder's work. If you see seams or banding, that's the batching, not the model.
• You're in the US, EU, UK, or South Korea - the MiniMax H3 Community License doesn't actually grant you the right to run the local weights there. That's a model problem, not a node problem, but worth knowing before you build a whole pipeline around it.