H3Kit VAE 分块解码

Sampling succeeded. The latent is sitting there, denoised and pretty. Then VAE decode grabs two frames' worth of pixels at once and your card taps out. That's the pattern this node exists for: H3 decodes at 24fps with a video VAE, and the decode is a burst of activations that scales with resolution, so the thing that kills a run is often not the 33B transformer but the last few seconds of it.

H3Kit VAE 分块解码 replaces your video-side VAE Decode node and decodes the clip in 256-pixel window tiles, exactly the way H3's own VAE already knows how to. Drop it in place of the normal decoder, connect the H3 video VAE, and the decoded_frames output goes wherever your frames were going.

It changes scheduling, not the model

Read the tooltip before you start inventing values, because this part is counter-intuitive. Internally the node always uses H3's native 256-pixel model window, keeps the native temporal decode and the native blend order. tile_edge (default 256) is a scheduling span - how much vertical distance one batch may cover as it walks the rows - not a model window size. Setting it to 512 makes the scheduler visit more rows per pass; it does not change the model's positional encoding or its attention window. The README's own suggested starting point for experimentation is 512 / 64 / 2: a wider span, the standard overlap, and a small batch to compare against.

tile_blend (default 64) is the overlap between those native tiles, and it's the parameter to leave alone if you're comparing image quality - changing the overlap changes the fusion result, so you no longer know which variable moved. tiles_per_batch (default 8, range 1–16) is how many of those 256-pixel tiles get pushed through in one decode call. That's the number that costs VRAM: the node estimates roughly 128 MiB per tile per batch when it reports its budget. When a batch does run out of memory it halves itself and retries, dropping to 1 before it gives up and raises - so an OOM message here means "set tiles_per_batch lower", not "this doesn't work on your GPU".

Inputs and output

video_latent takes a video latent or, conveniently, H3's composite audio+video latent - the node pulls the video stream out for you. video_vae must be the MiniMax H3 video VAE; the node checks the type and refuses anything else, including an audio VAE or another video model's VAE. That error is worth recognizing because wiring the wrong VAE looks like a crash rather than a misconfiguration.

One output: decoded_frames, the ordinary IMAGE batch you already know how to save. Audio still goes through the audio decoder on its own branch - this is the picture half only.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/flywhale-666/ComfyUI-H3-upgrade-kit.git

Or Manager → search ComfyUI-H3-upgrade-kit → restart. Zero dependencies to install: the repo's requirements.txt is empty and the pack declares none, so it uses the torch and torchaudio already in your ComfyUI. You do need a ComfyUI new enough to know what MiniMax H3 is - this pack is built around H3's own VAE classes, not a generic decoder.

Notes from actually wiring it

Two things will ruin your afternoon. First, expecting a speedup: tiling and batching are about fitting, not about winning. The README's FAQ says it outright - chunking does not guarantee speed or VRAM savings, they depend on resolution, model, parameters and your card, and the answer is to measure. Second, wanting finer temporal control than you get: the node keeps H3's native temporal chunking and doesn't expose arbitrary temporal block sizes, so if you wanted to decode two seconds at a time you'll be improvising with a different node.

Where it earns its place is the long-clip, high-resolution case where the standard decoder has just died - and the same trick, lower batch, cheaper decode, usually gets you the last 30 seconds of a render you didn't want to re-sample. If decode is a recurring wall for you, note it also pairs with the pack's tiled sampler: same idea applied one stage earlier.