FlashVSR_SM_Vae

A normal ComfyUI graph has a VAELoader and you never think about it again. This pack can't do that, because FlashVSR's latent isn't a stock Wan 2.1 latent - it's been widened with projected features, and the thing that turns it back into pixels comes in four flavours with wildly different speed and quality. FlashVSR_SM_Vae is the node that picks one.

You only need one of its three slots filled. Which one you fill decides almost everything about how the decode behaves.

What the three slots actually load

vae takes files from ComfyUI/models/vae. It accepts the stock Wan 2.1 VAE (.pth or .safetensors) and a couple of specialised ones. A .safetensors here is loaded as a Wan autoencoder; a .pth goes through the diffsynth pipeline loader. This is the highest-quality path and the slowest.

tcd_encoder is the interesting one. It lists files from ComfyUI/models/FlashVSR whose names contain "tcd" - which in practice means TCDecoder.ckpt, the tiny decoder that FlashVSR ships. It reconstructs the latent in one shot at a fraction of the VAE's cost. It's also the only decoder that works in long-video mode, so if you're using tiny_long on the Model node, this is your answer whether you like it or not.

lite_vae takes the light/TAE autoencoders out of models/vae: lightvaew2_1, taew2_1, lighttaew2_1. These are thumbnail-quality decoders - blazing, visibly softer. The pack also handles whatever else you point it at through an upscale-2× path, which is a different tool for a different job.

Precedence is fixed and greedy: vae wins, then tcd_encoder, then lite_vae. Filling more than one slot doesn't blend them; the node just walks past the others. Fill all three with "none" and it raises rather than guessing.

The author's own note in the bundled workflow ranks them: light is fastest, then tcd, then the vae.safetensors path, then .pth. Use tcd as your default. Reach for the full VAE when you're rendering something you care about and have the patience, and the light decoders only when you're previewing a parameter change and the frames are throwaway.

Why bother splitting it out

Doing the decode in its own node isn't gratuitous. The split lets you decode once at high quality for the final render while iterating on cheap decodes, and - more importantly - lets the decode skip the GPU while the DiT is still resident. The decode is also where VRAM spikes: it's the step that turns a small latent into a full-resolution frame stack, which is exactly the "works fine, dies at the last second" failure everybody hits with video upscalers.

One thing this node is not: it doesn't decode anything. It hands a configured object to FlashVSR_SM_Decoder, which is where full_tiled and the colour correction live. If you wire the Vae node's output into a create-video node directly you've skipped the decode entirely.

Output

A vae (VAE type) that goes into FlashVSR_SM_Decoder's vae input. That's it.

Install

Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_FlashVSR
cd ComfyUI_FlashVSR && pip install -r requirements.txt

Then the files, in two different folders - this is the trap:

ComfyUI/models/vae/
├── Wan2.1_VAE.pth                                  # or .safetensors
├── lightvaew2_1.pth                                # optional, fast preview
└── Wan2.1_VAE_upscale2x_imageonly_real_v1_diff.safetensors

ComfyUI/models/FlashVSR/
└── TCDecoder.ckpt                                  # note: FlashVSR, not vae

TCDecoder.ckpt will not appear in tcd_encoder if you drop it in models/vae, and no amount of refreshing helps. If you use the plus release, use its own TCDecoder - the pack prints a warning when the weight coverage is too low, which is what a mismatched decoder looks like.

Troubleshooting

vae_path, tcd_encoder_path, lite_vae_path is None. All three slots are empty. Pick one.

No module named diffusers. The requirements file doesn't list diffusers, but the .safetensors VAE path imports AutoencoderKLWan from it. pip install diffusers and restart.

Decode output is bright green, noisy, or obviously garbage. Your decoder doesn't match the model family. A v1.0 TCDecoder against v1.1 weights, or a plus checkpoint against a v1.1 DiT, decodes into nonsense. Match the release end to end.

Long video fails immediately after a tcd-less setup. Long mode requires tcd_encoder. It says so, in the decode error, but it's easy to miss because the message arrives after several minutes of sampling.

Frames look soft and plasticky at high resolution. That's the light decoder doing exactly what you asked. Switch to tcd or the full VAE before you start tuning the sampler.