Wan22FirstLastFrameToVideoLatent (Tiled VAE encode)
The same first/last-frame node, but it won't OOM on the Wan 2.2 VAE
- vae
- start_image
- end_image
- latent
This is the rescue variant. The base Wan22FirstLastFrameToVideoLatent node works great until the Wan 2.2 VAE's encode step eats all your VRAM - and that happens to real people on cards you'd think were safe (there's a well-known thread about a 5090 OOMing on VAE decode). The Tiled VAE encode version is the same first/last-frame latent builder, but instead of vae.encode() it uses vae.encode_tiled(), slicing the image into overlapping tiles so the VAE never has to hold a whole frame at once. The author ships it as the "more experimental" alternative and calls it a drop-in replacement - and it genuinely is. Same inputs, same latent output, same wiring into your sampler.
How it works
Instead of one big encode, each image is encoded as overlapping tiles that get stitched back together. That's the whole difference in mechanism - the latent tensor, the noise mask, the front-frame/back-frame placement are identical to the base node. The trade is straightforward: you trade encode-time and a little quality for VRAM headroom. Seams are the thing to watch - if you can see tile boundaries in the output, your overlap is too small.
The extra inputs
Everything from the base node carries over (vae, width, height, length, batch_size, start_image, end_image), plus four tiling knobs:
tile_size(default 512) - the spatial tile size. Lower it if you're still OOMing; raise it if you want faster encodes.overlap(default 64) - how much tiles overlap. Raise this if you see seams.temporal_size(default 64) - "amount of frames to encode at a time", per the tooltip.temporal_overlap(default 8) - "amount of frames to overlap".
The two temporal knobs only really bite when your start_image or end_image is actually a short clip instead of a single still - for a plain one-frame start/end, the spatial tiles are doing all the work.
When to reach for it
If your GPU fits the whole encode comfortably, use the base node - simpler, marginally faster, no seam risk. But if you're on an 8-ish GB card, running ComfyUI-Zluda (the author built this specifically because the VAE is "particularly VRAM-hungry" there), or doing 720p+ first/last-frame work that keeps dying at the encode step, this is the one you want. The author also maintains a sibling repo, ComfyUI--WanImageToVideoTiled, if you want tiled VAE encoding for other Wan img2vid workflows.
Installing
Same pack, same install. ComfyUI Manager, search "Wan22FirstLastFrameToVideoLatent", install, restart:
cd ComfyUI/custom_nodes
git clone https://github.com/stduhpf/ComfyUI--Wan22FirstLastFrameToVideoLatent
No dependencies beyond ComfyUI itself, no extra model downloads - the tiled encode is built into ComfyUI's VAE handling. Remember the same gotchas as the base node: hook up the Wan 2.2 VAE (not the 2.1 one the A14B uses), and keep length at 4n+1 (81, 121…) or the latent frame count won't round-trip and you'll get a dimension-mismatch error.
Inputs (11)
| Name | Type | Default | Description |
|---|---|---|---|
| vae | VAE | — | |
| width | INT | 83216–16384 | — |
| height | INT | 48016–16384 | — |
| length | INT | 811–16384 | — |
| batch_size | INT | 11–4096 | — |
| tile_size | INT | 512128–4096 | — |
| overlap | INT | 640–4096 | — |
| temporal_size | INT | 648–4096 | Amount of frames to encode at a time. |
| temporal_overlap | INT | 84–4096 | Amount of frames to overlap. |
| start_imageopt | IMAGE | — | |
| end_imageopt | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| latent | LATENT | — |