SeedVR2 (Down)Load VAE Model

Every SeedVR2 upscale needs two models: the DiT that does the actual detail work, and the VAE that translates your frames in and out of the compressed latent space the DiT operates in. This node loads the second one. It looks like the boring plumbing of the four-node setup - and it mostly is, since there's really only one VAE to pick - but it's also where a surprising amount of your VRAM trouble lives, so it's worth understanding rather than just wiring up and forgetting.

Here's the thing people miss: even after you've optimised the DiT to death with BlockSwap and GGUF quantisation, the VAE can still be your bottleneck. It's genuinely slow, and at high resolutions the encode/decode passes are memory-hungry enough to OOM on their own. The pack's own docs say it outright - the VAE is the slow part. That's why this node carries the tiling controls: they're your lever for the "Decoding" crashes that BlockSwap can't touch.

How it works

A VAE (variational autoencoder) compresses an image into a small latent representation and reconstructs it afterward. SeedVR2 encodes your input frames to latent, the DiT restores detail in that space, then the VAE decodes back to pixels. When the frame is large, that encode or decode step can't fit in VRAM in one shot. VAE tiling solves it the same way BlockSwap solves the DiT: chop the image into overlapping tiles, process them one at a time, stitch them back together. Smaller tiles, less peak memory, slightly more time and a small risk of visible seams.

The inputs and outputs that matter

For the two required inputs, there's almost nothing to decide:

• model - in practice this is always ema_vae_fp16.safetensors. It's the default and the recommended one; there isn't a meaningful second choice to agonise over.
• device - the GPU you're running on, typically cuda:0.

The optional inputs are where the real work happens, and they come in two matched pairs for the two phases:

• encode_tiled / decode_tiled (both default off) - turn these on to tile the encode and decode passes respectively. Leave them off first; only enable the one whose phase is actually OOMing.
• encode_tile_size / decode_tile_size (default 1024) - the tile dimension in pixels. If tiling on isn't enough, step these down (768, 512…) to shave more VRAM at the cost of speed.
• encode_tile_overlap / decode_tile_overlap (default 128) - how much neighbouring tiles overlap. Raise it if you see seams; lower it if processing drags.

Three more, all situational: tile_debug visualises the tile grid so you can see what's happening; offload_device (default none) can park the VAE on CPU or a second GPU between phases to free VRAM; cache_model keeps it resident between runs for batch work; and torch_compile_args accepts a connection from the SeedVR2 Torch Compile Settings node for a 15–25% VAE speedup.

The single output is SEEDVR2_VAE, which plugs straight into the vae input of the main SeedVR2 Video Upscaler node.

How to install it

It's part of the SeedVR2 pack, so you get it by installing the pack once. In ComfyUI Manager, search ComfyUI-SeedVR2_VideoUpscaler, install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/numz/ComfyUI-SeedVR2_VideoUpscaler

install the requirements.txt with ComfyUI's Python, and restart. The ema_vae_fp16.safetensors weight downloads automatically to ComfyUI/models/SEEDVR2 on first use.

Common issues & troubleshooting

OOM during "Encoding" or "Decoding." This is the node's whole reason to exist. Enable enable_debug on the main upscaler so you can see which phase dies, then turn on the matching tiled option here - encode_tiled for an encoding crash, decode_tiled for a decoding one. Still short? Drop that phase's tile_size. Reducing batch size or resolution is a last resort, because both directly cost you quality.

Visible seams between tiles. Bump the relevant tile_overlap above the default 128. If it's slow instead of seamy, take the overlap back down. tile_debug will show you exactly where the tile boundaries land.

The VAE feels like it's dragging the whole upscale down. It probably is - it's the acknowledged slow stage. The pack's advice is counterintuitive: use a larger batch size on the main node, which amortises the VAE cost across more frames, rather than fighting it here. Wiring in torch.compile via torch_compile_args also helps, but only pays off across many frames or long videos.