WanImageToVideo (Tiled VAE encode)

You've got a Wan 2.1 or 2.2 image-to-video workflow loaded, you hit Queue, and somewhere during the VAE encode your card just gives up - a hard crash, a driver timeout, or a slow-motion slideshow of memory pressure. That's exactly the failure this node was built to fix.

WanImageToVideo (Tiled VAE encode) is a drop-in replacement for ComfyUI's built-in WanImageToVideo node. Same conditioning, same latent, same wiring - the one difference is that the VAE encode runs in tiles instead of over the whole clip at once. It comes from stduhpf, the same person behind ComfyUI-WanMoeKSampler and a stable-diffusion.cpp contributor, who hit Wan 2.2 A14B I2V crashes on ComfyUI-zluda (the AMD ROCm fork) and traced them to the VAE swallowing all the VRAM during encode. He wrapped the core node, and this pack is the result.

Why the VAE is the bottleneck

Wan's VAE is a 3D causal VAE - it encodes the whole clip across both space and time at once. That's great for quality and terrible for peak memory: the encode pass holds a big chunk of the video in VRAM, on top of everything the denoiser already has loaded. Tiling fixes it by splitting the work. The node calls the same encode_tiled machinery as ComfyUI's core "VAE Encode (Tiled)" node, cutting the video into spatial tiles (tile_size × tile_size, with overlap between them) and into temporal chunks (temporal_size frames at a time, temporal_overlap frames of overlap). Each piece is tiny enough to encode and stitch back together, so peak VRAM stays low.

The author's honest note: tiling is theoretically a bit worse than a full encode, because tiles get blended at the seams. In practice he reported not seeing a quality difference. Keep the overlap at 64 or above; if you ever spot faint tile lines, that's the first knob to raise.

The inputs that actually matter

• start_image - your first frame, the whole point of I2V. Feed the image you want to animate forward. It gets upscaled to your width/height and used as the concat_latent_image on both conditioning passes.
• clip_vision_output - optional, from a CLIP Vision loader. Adds Wan's usual image understanding to the prompt conditioning.
• width / height / length - output resolution and frame count. Defaults (832×480, 81 frames) are the sensible Wan starting points; 81 frames is about 5 seconds at 16fps.
• tile_size / overlap / temporal_size / temporal_overlap - the four tiling knobs. Leave them alone until you need to. Smaller tile_size = less VRAM, more seams.

Outputs are the familiar triple: positive and negative conditioning, plus the empty latent that the sampler denoises. Wire positive/negative into your sampler's conditioning inputs and latent into samples.

Installing it

Through ComfyUI Manager, search for "WanImageToVideoTiled" and hit Install. Or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/stduhpf/ComfyUI--WanImageToVideoTiled

Restart ComfyUI and you're done. There's nothing else to fetch - no requirements.txt, no model files, no separate VAE. It reuses whatever Wan VAE you already have and imports its helpers from ComfyUI's own comfy_extras.nodes_wan. The whole pack is GPL-3.0 because it's largely ComfyUI's own code with the encode call swapped.

Where people get burned

The biggest misconception: this node fixes the VAE stage only. If your OOM is happening in the denoising transformer - which is where most of a Wan render's VRAM actually lives - tiled encoding won't save you. Second, use it with a VAE Decode (Tiled) node at the end of the pipeline. Decode is often the slowest, most memory-hungry step of a Wan render, and the author explicitly recommends tiling it too; one commenter reported decode going from 5–20 minutes to 5–20 seconds. And don't expect the tile knobs to affect generation quality - they only change how the VAE is computed, not how the model denoises.