Tiling Info
The 4 numbers that stop your VAE decode from blowing up VRAM
- tiling_info
Tiling Info looks like a settings node you'd skip past, but it's the thing that saves a generation from dying at the very last step. If you've ever watched a big image or a long video render happily through sampling and then hit an out-of-memory error at decode, this is the fix. It's four numbers that tell the Sage Utils sampler to decode the latent in chunks instead of all at once.
The catch: this node doesn't do anything by itself. It's a pure configuration node. You feed its single tiling_info output into the optional tiling_info input on KSampler + Tiled Decoder (SageUtils' own sampler node), and only then does the decode switch from a whole-latent vae.decode to a tiled vae.decode_tiled behind the scenes. No Tiling Info connected, no tiling - the node simply falls back to a normal decode. That's the whole trick, and it's also the whole gotcha: wire it into the wrong sampler and nothing happens.
The four inputs that matter:
- tile_size (default 512) - how big each chunk is. Bigger tiles mean fewer seams but more VRAM per tile; 512 is a fine starting point for SDXL-size work.
- overlap (default 64) - how much neighboring tiles bleed into each other. This is your seam insurance. Set it to zero and you'll invite visible tile boundaries, especially on noisy or textured images. Tiled decode blends the overlap, so a little redundancy is the price of invisibility.
- temporal_size (default 64) - only used by video VAEs: how many frames to decode in one pass.
- temporal_overlap (default 8) - the frame equivalent of overlap, for the same reason: stop the flicker/banding where frame chunks meet.
So the video-specific pair matters if your VAE is a video one (Wan, LTX, Hunyuan Video and friends); the first pair is what image people actually touch. The tooltips in the node spell this out - "Only used for video VAEs" - which is rare clarity from a pack this size.
Where this fits in the wider workflow: tiled VAE decode is the standard escape hatch for "I can sample at 2K but my 8GB card chokes turning that latent back into pixels." It's the same trick the upscaling world has used for years - split, process, blend - just applied to the decoder instead of the denoiser. The tradeoff, as with all tiling, is speed: more chunks, more overhead, slower wall-clock time. In return you get to decode latents that would otherwise be outright impossible.
Install is the standard Sage Utils story: ComfyUI Manager (search "Sage Utils") or git clone https://github.com/arcum42/ComfyUI_SageUtils into custom_nodes/, then restart. This node pulls no models and no heavy dependencies - it's just plumbing, and Sage Utils' only hard Python dependency is dynamicprompts, which installs quietly.
The one real trap people hit: connecting Tiling Info to a plain KSampler and expecting tiled sampling. It doesn't do that. The name says "tiling information to the KSampler," but in the shipped code it only steers the decoder inside KSampler + Tiled Decoder. If your OOM is happening during sampling, not decode, this won't help you - that's a different fight (lower res, higher tile size in a tiled-sampling pack, or fp8 weights).
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| tile_size | INT | 51264–4096 | Size of each tile for tiled sampling. |
| overlap | INT | 640–4096 | Overlap size between tiles. |
| temporal_size | INT | 648–4096 | Only used for video VAEs: Amount of frames to decode at a time. |
| temporal_overlap | INT | 84–4096 | Only used for video VAEs: Amount of frames to overlap. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| tiling_info | TILING_INFO | Tiling parameters for the sampler. |