- VAE
First, the thing that saves people the most confusion: if you're running plain PixArt or DiT, you almost certainly don't need this node. Those models share SD1.5's latent space and decode fine through core ComfyUI's regular VAE loader with an ordinary SD1.5 (or SDXL, for PixArt Sigma) VAE. This node is for the oddball architectures that core ComfyUI's loader has never heard of - a genuine grab-bag of VAE formats the author collected because various DiT-era and research models needed them.
Inputs. Three, all required. vae_name is a dropdown built from your VAE folder - empty until you've downloaded something to put there. vae_type (default kl-f8) tells the node how to actually interpret the file, and this is where the variety lives: kl-f4/f8/f8-d16/f16/f32 and vq-f4/f8/f16 are old CompVis/latent-diffusion and taming-transformers autoencoders; Consistency-Decoder is OpenAI's consistency-model VAE (works via a community conversion); SDV-VideoDecoder is the deflickering decoder baked into Stable Video Diffusion; MoVQ3 is another VQ-style architecture; and dcae-f32c32-sana-1.0 is Sana's compressed DC-AE VAE. dtype sets load precision: auto, FP32, FP16, or BF16.
Output. VAE, wired into VAEDecode (or VAEEncode) exactly like core ComfyUI's own VAE loader output.
Which type to actually pick, and the author's own honest take on some of them. For Sana, dcae-f32c32-sana-1.0 paired with the mit-han-lab DC-AE download. For the Consistency Decoder, grab the converted safetensor - the original OpenAI release is a TorchScript file and won't load here - set dtype to fp16 or bf16 to avoid running out of VRAM, and use tiled VAE decode if you still do. For SDV-VideoDecoder, the README's own verdict is worth quoting rather than paraphrasing: "It doesn't seem particularly good as a normal VAE (color issues, pretty bad with finer details)." It's implemented mostly for completeness, not because it's a good general-purpose choice. As for the old kl-/vq- autoencoders: the README is equally blunt that "vq-f8 can accept latents from the SD unet but... output largely garbage. The rest are completely useless without a matching UNET that uses the correct channel count" - these exist for research/compatibility reasons, not because they're something you should reach for on a normal SD workflow.
Getting the weights. They live scattered across a few sources: the compvis/latent-diffusion repo for the kl- family, ommer-lab.com for both vq- and kl- weights, and the Sana/consistency-decoder links above for those two. Whatever you download, place it in your VAE folder and pick the matching vae_type - mismatching type-to-file is the single most common way this node produces garbage.
Installing the pack. ComfyUI Manager: search "Extra Models for ComfyUI." Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI_ExtraModels
then pip install -r requirements.txt and restart.
Troubleshooting. Wrong output shape or visibly broken decode almost always traces back to vae_type not matching the actual file - this node trusts your selection rather than inspecting the weights to guess. If you're on the Consistency Decoder and running low on VRAM, that's the one place the author explicitly recommends tiled decode as a real fix, not a workaround.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| vae_name | COMBO | 0 options: | |
| vae_type | COMBO | kl-f8 | 12 options: kl-f4, kl-f8, kl-f8-d16, kl-f16, kl-f32, vq-f4, +6 |
| dtype | COMBO | 4 options: auto, FP32, FP16, BF16 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| VAE | VAE | — |