Tile Model Patch (VAE Utils)
Tile Model Patch (VAE Utils)
- model
- MODEL
This node patches your diffusion model so it processes the latent in overlapping 3D tiles - across width, height, and time - instead of trying to hold the whole thing in memory at once. It's the answer to the two walls every Wan user hits eventually: the VRAM ceiling and the frame-count ceiling. Feed the patched model into your sampler and it can chew on a latent that's bigger or longer than it could otherwise fit.
Why you'd reach for it
Wan's native context is famously 81 frames, and everything past that is some flavor of chunking - split the sequence into windows, run each, stitch them back together. The community has spent a lot of 2026 wrapping that chain-and-restitch dance into single nodes so you don't have to hand-calculate window sizes and overlaps. This is spacepxl's take on the same problem, done at the model level: rather than a workflow that loops over chunks, it patches the model itself to tile its forward pass, so a single sampler call transparently works window by window.
The spatial half matters just as much. High-resolution Wan work runs into VRAM long before it runs into quality limits, and tiling the height and width lets you push resolution on a card that would otherwise OOM. Same principle as tiled VAE decode or tiled diffusion upscaling, except here it's applied to the denoise pass over a 3D latent that has a temporal axis the image-era tiling tricks never had to think about.
How it works
It wraps the model so that, during sampling, the latent is carved into tiles of a set size with a minimum overlap between neighbors, and the overlaps get blended so you don't see hard seams at the joins. The temporal axis (t) is frames; h and w are the spatial latent dimensions. The overlap is what buys coherence - too little and tiles drift apart at the boundaries, which on video shows up as the identity-drift-across-chunks problem that plagues every long-form Wan pipeline. There's also a small handling detail for the start of the sequence, because Wan's causal VAE treats the first frame specially, which is what the "drop first" temporal setting is about.
The inputs that matter
There are a lot of knobs, but you set very few of them by hand. The defaults are tuned:
model- the diffusionMODELto patch. This is the required wiring; everything else has a sensible default.tile_t(default 13) - the temporal window size in latent frames. This is the big lever for long video: smaller tiles fit more easily but need more stitching.tile_h/tile_w(both default 78) - the spatial tile size. Shrink these if you're fighting VRAM on high-res generations.
The overlap settings (min_overlap_t 5, min_overlap_h / min_overlap_w 16), the drop_first_t (2), and patch_memory_estimate (a boolean, on by default, that toggles the node's internal memory-estimation for the patched operation) are mostly leave-alone territory until you have a specific seam or memory problem to chase. Raise the overlaps if you see boundary artifacts; that's the usual first adjustment.
The output is a patched MODEL, which you route into your sampler exactly where the un-patched model would have gone.
Installing it
No dependencies - the pack needs nothing beyond stock ComfyUI. Grab it in ComfyUI Manager by searching ComfyUI-VAE-Utils, or clone it:
cd ComfyUI/custom_nodes
git clone https://github.com/spacepxl/ComfyUI-VAE-Utils
Restart ComfyUI. No model download for this node.
Common issues
Tiling is a real tradeoff, not free lunch, and the honest read from the wider Wan ecosystem applies here too: chunking the temporal axis improves your ergonomics, it does not improve the underlying constraint. Identity and detail drift across tile boundaries is the failure mode - if a face or a texture changes character between windows, your overlap is too small for that content; bump min_overlap_t up. Tiling is also slower per unit of output than not tiling, because overlaps mean you recompute the shared regions; that's the price of fitting something that otherwise wouldn't fit.
Before you burn a long generation guessing at window math, use the pack's Visualize Tiles node - it draws exactly how a given length, tile size, overlap, and drop-first split up, so you can eyeball the tiling scheme first. The two nodes share the same temporal parameters on purpose, and one's a planning tool for the other.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| tile_t | INT | 13 | — |
| tile_h | INT | 78 | — |
| tile_w | INT | 78 | — |
| min_overlap_t | INT | 5 | — |
| min_overlap_h | INT | 16 | — |
| min_overlap_w | INT | 16 | — |
| drop_first_t | INT | 2 | — |
| patch_memory_estimate | BOOLEAN | true | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |