VAE Decode (Exact Tiles, low VRAM)

The decode that OOMs after everything else worked

You spent twenty minutes sampling a 1792×2944 image and then the VAE decode runs out of memory. Or worse, it doesn't OOM - it uses tiled decoding and gives you faint grid lines that you only notice on the final export.

This node is the answer to both, for one specific VAE. It decodes with seamless tiles: it tiles only the decoder's local layers, with a halo exactly equal to their receptive field, and runs the attention on the whole latent. That's the mechanism behind "no seams" - the part of a VAE that would suffer from being cut is never cut. ComfyUI's own tiled decode tiles more aggressively and blends overlaps afterwards, which is why it leaves visible structure.

The numbers from the author on a 1792×2944 image with an RTX 4060: untiled peak 6.3GB; stage 2 at 3.1GB with 99.7% of pixels identical and at most one level of difference; stage 0 at 0.7GB, 82% of pixels identical, at most six levels apart. Reading that honestly: stage 2 is free, and stage 0 is what you use when you have absolutely nothing left.

Which VAE, though - this is the part to get right. Wan 2.1's VAE only. That covers Anima and Qwen-Image, both of which use it. Anything else, or a video latent with more than one frame, falls back to ComfyUI's stock VAE Decode and you gain nothing. You haven't broken anything; you just wasted a node.

How it works

The node checks the loaded VAE's class and the latent's shape. If it's the Wan VAE with a single-frame latent, it runs the decoder in stages, tiling only from the point where the feature maps are big enough to matter and adding the halo needed for exactness. If it isn't, it hands everything to VAEDecode and leaves. In auto mode it reads free VRAM - minus whatever the pack's VRAM budget says to keep - and picks the least tiling that fits, then re-requests memory for that peak so ComfyUI doesn't evict the model mid-decode.

Inputs and outputs

• samples - the latent.
• vae - the Wan 2.1 VAE (Anima's, or Qwen-Image's).
• mode - auto (default), untiled, stage 2, stage 1, stage 0. auto picks untiled if it fits - and when untiled, the output is byte-identical to ComfyUI's VAE Decode. Then stage 2 is the sane low-VRAM choice; stage 1 and stage 0 are emergency modes.
• tile_size (512) - output pixels per tile side, with the halo added on top. 512 is a good default; smaller saves more memory and costs more time.

One output, IMAGE.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/nyanmi-1828/ComfyUI-WeightFerry

Manager → WeightFerry → install → restart. Nothing to pip install, no models. NVIDIA, ComfyUI 0.38.0+.

Where it goes wrong

Using it on SDXL or Flux. Falls straight through to ComfyUI's decode. If the VRAM peak didn't move, that's why - check which VAE you actually have loaded before you start tuning mode.

Video latents. The node tests for a single-frame latent and bails otherwise. Wan video work needs a video-capable tiled decode; this isn't it.

Treating stage 0 as the low-VRAM default. It's 0.7GB because it's doing much less exact work - 82% identical pixels with up to six levels of difference. On a gradient-heavy anime background those six levels can show as faint banding. Try stage 2 first; it costs you 3.1GB instead of 6.3GB and is visually identical.

Reading the differences as tiling artifacts. The author's note is worth repeating because it's counter-intuitive: at the lower stages, the pixel differences come from different convolution algorithms being selected for different shapes, not from the tiling boundaries. So you can't "fix" them by lowering tile_size. If you need exactness, you need untiled, and you need the VRAM for it.

Expecting it to save you from a bad pipeline. The decode is the last thing that needs VRAM, and it needs it after the model has been evicted. On a 2GB card you'll want this node plus the pack's DiT streaming plus probably a tile pass on the upscale. Each solves its own peak; none of them solve the others.