Tiled VAE Decode

Here's a special kind of frustrating: your sampler finishes, every step completes, and then you get an out-of-memory error on the VAE decode - the very last operation, the one that turns your finished latent into an actual image. That's the failure mode this node exists for. It's a drop-in replacement for the stock VAE Decode that processes the latent-to-pixel conversion in tiles instead of all at once, so decoding a big image doesn't need to hold the whole thing in VRAM simultaneously.

Why this matters separately from Tiled Diffusion

Tiled Diffusion (the pack's main node) tiles the denoising - the many-step sampling loop. But the VAE decode at the end is its own, separate memory spike, and a big one: decoding is where a lot of people actually hit their VRAM ceiling on large images, even after successfully tiling the sampling itself. This node covers that second half of the problem. You can use it completely standalone, without the Tiled Diffusion patch node upstream, any time your image is big enough that a normal VAE Decode chokes.

How it works

The README documents two distinct decode paths, controlled by fast:

Non-fast (fast = off): the original VAE forward pass gets broken into a task queue and worker. Each tile gets processed; when the network hits a GroupNorm layer (which needs statistics from the whole image, not just one tile, to look right), it pauses, stashes the running mean/variance, offloads to RAM, and moves to the next tile. Once every tile's GroupNorm stats are collected, it applies group norm consistently across all of them and finishes. A zigzag processing order cuts down on unnecessary RAM/VRAM shuffling. This is the more faithful path - closer to what a full, untiled decode would produce - at the cost of speed.

Fast (default): the whole image gets downsampled first, its GroupNorm parameters are computed once from that downsampled version, and every tile just uses those shared numbers without any of the pause-and-transfer dance. Much faster, no RAM shuttling - but the author notes it can produce images with slightly higher contrast and brightness than the non-fast path.

Inputs and outputs

• samples (LATENT) - the sampler's output, wired straight from your KSampler.
• vae (VAE) - same VAE you'd plug into a normal decode.
• tile_size (default 512, range 384–4096) - pixel size of each decode tile. The node suggests a starting value based on your available VRAM when you first add it - that default is a reasonable place to start rather than a number to second-guess.
• fast (default on) - the speed/fidelity tradeoff described above.

Output is a plain IMAGE, same as the stock decode - feed it into SaveImage, PreviewImage, or wherever else your workflow expects pixels.

How to install it

• ComfyUI Manager - search "Tiled Diffusion & VAE for ComfyUI", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/shiimizu/ComfyUI-TiledDiffusion, then restart.

No extra models or weights to download; it works on whatever VAE you already have loaded.

Common issues & troubleshooting

Still running out of memory. Lower tile_size. It's a straightforward tradeoff - smaller tiles use less VRAM per step but take longer overall.

Colors or brightness look subtly different from a normal decode. That's fast mode doing its thing - the README flags exactly this. Turn fast off if you need the output to match a standard VAE Decode as closely as possible; you'll pay for it in decode time.

You only need this for the decode, not the whole pipeline. That's fine - this node doesn't require the Tiled Diffusion sampling node upstream at all. If your generation fits in VRAM but the decode of a large output doesn't, just swap your existing VAE Decode for this one and leave everything else untouched.

Wondering whether Tiled Diffusion (the sampler node) is doing anything to help here. It isn't - the two are complementary but independent. Big generations that need both low-VRAM sampling and low-VRAM decoding should use Tiled Diffusion upstream and this node at the end; smaller generations that only choke at decode time can use this one alone.