VAE Decode Tiled (Batched)

Everyone thinks the sampler is the VRAM hog, and then a big batch reaches the VAE decode and the whole thing goes sideways. ComfyUI's built-in VAE Decode (Tiled) already solves the spatial problem - it splits one huge latent into tiles so a single giant image doesn't blow your card. What it doesn't solve is the batch problem: decoding 8 latents at once is 8× the peak memory, and it does it in one call regardless. This node from the vsLinx pack adds the missing batch_size control on top of all the normal tiled fields. You get both knobs: how each latent is split spatially, and how many latents get decoded per call.

How it works

The Python is embarrassingly straightforward, which is why it's worth trusting: it subclasses ComfyUI's own VAEDecodeTiled and keeps every original input and behavior, then chops the latent batch along dimension 0 and decodes batch_size latents at a time, concatenating the results back into one output batch. The tooltip on batch_size says it best: lower values reduce peak VRAM at the cost of more sequential calls, and values equal to or greater than your batch size behave exactly like the built-in node - a single decode.

That last point matters. This is a drop-in replacement with zero downside: leave batch_size at 1 and it's strictly gentler on VRAM; set it high and it's identical to the node you already use. You can keep it in every workflow permanently.

The inputs that matter

• samples (LATENT) and vae (VAE) - same as the built-in node.
• tile_size (default 512) - how big each spatial tile is.
• overlap (default 64) - feathering between tiles so seams don't show.
• temporal_size / temporal_overlap - only used by video VAEs; controls how many frames are decoded at once and how many overlap. Ignore them for images.
• batch_size (default 1) - the star. Decode one latent per VAE call.

Output is a single IMAGE tensor, same shape as the input batch.

When it saves you

The classic case: you generate a preview grid or a whole batch of images, and the decode at the end spikes memory just as you thought you were done. Or you're chaining img2img on a stack of images and the VAE stage is what tips you over. Setting batch_size to 1 makes ComfyUI decode one image at a time - slightly more sequential work, but peak memory drops proportionally, and on many setups a single big decode was the thing pushing ComfyUI into its slower tiled fallback anyway. People also pair it with the batched non-tiled decode sibling (VAE Decode (Batched)) when the image itself is small enough that tiling is unnecessary.

Install

Part of the ComfyUI vsLinx Nodes pack. Via ComfyUI Manager: search "ComfyUI vsLinx Nodes". Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/vslinx/ComfyUI-vslinx-nodes.git comfyui-vslinx-nodes

Restart, and it appears under vsLinx/latent as "VAE Decode Tiled (Batched)". No extra dependencies.

Gotchas

Nothing exotic. If your images are small, tiling adds nothing and the batched non-tiled variant is the better fit. And if you're decoding video latents, remember the temporal_size fields still apply - batch_size only changes how many latent frames go through per call, not the frame tiling. Don't expect a speedup on a single-image decode; this is a memory-management tool, not a performance hack. It's the kind of node you install once, forget about, and quietly owe a debt to the next time a 4-image batch would have OOM'd.