VAE Merge Simple
Blend two VAEs when one's color and the other's texture both need to win
- vae1
- vae2
- VAE
Most people never touch a VAE merge, and that's fine - your checkpoint's own VAE is almost always the right one. But there's one genuinely common situation where a blend earns its keep, and it's the reason to remember this node exists.
In 2026 the recurring VAE complaint flipped from "my colors are washed out" to "my images are too smooth." The Qwen-Image VAE is the usual suspect: it's built on the Wan 2.1 architecture with the encoder frozen and the decoder retuned specifically to render small text legibly, which trades away fine texture. The community's workaround - swap in the Wan 2.1 decoder, which is a real drop-in because the latent spaces are identical - works, but it's all-or-nothing. VAE Merge Simple gives you the dial in between: keep Qwen's color and text behavior, pull in just enough Wan texture to stop the plastic look.
How it works
Under the hood it's one line of math applied to the whole VAE at once:
vae1[key] * (1 - ratio) + vae2[key] * ratio
for every weight that exists in both state dicts. ratio runs 0 to 1: at 0 you get vae1 unchanged, at 1 you get vae2 unchanged, anything between is a straight element-wise blend. Keys that only exist in vae2 get copied in as-is. The result is a brand-new VAE built in memory - not a patch, a fully materialized merged state dict.
Inputs and output
vae1/vae2- the two VAEs. Load them with a VAE Loader or pull them from your checkpoint.ratio- the blend amount, default 1.0 (all vae2). Drop it to ~0.5 for a half-and-half.
One VAE comes out the bottom, and you wire it into VAEDecode just like a loaded VAE. If you want to keep the result for later, save it with a VAE-save node (this one doesn't write anything to disk).
Where it goes wrong
The one rule that matters: only blend VAEs of the same architecture and channel count. SDXL's VAE is 4-channel; Flux, Wan, Qwen and their peers are 16-channel. Cross-breed them and you don't get a "sort of" image, you get noise or flat color - the latent geometry just doesn't line up. That's why the Qwen/Wan blend works at all: shared architecture, frozen encoder, identical latent space. When people say "the Wan decoder is compatible," this is exactly why.
Also keep expectations calibrated. VAE blending is a texture/contrast knob, not a fix-all - the Qwen "worst VAE" claim itself is contested, and half the comparisons people cite are VAE decode at 1024px against a 4096px pixel-diffusion upscaler, which isn't a fair fight. If you want to actually judge a VAE, run encode→decode at the same resolution.
Installing it
In ComfyUI Manager, search Easygoing and install from the registry, or:
cd ComfyUI/custom_nodes
git clone https://github.com/easygoing0114/ComfyUI-easygoing-nodes.git
Restart. No model files to download, no extra pip packages - the pack runs on ComfyUI's own stack. One requirement worth repeating: it's written against the V3 node API, so a current ComfyUI build is mandatory; on an old one the nodes won't even appear. And if you're upgrading the pack from v1.x, and a node renders broken afterward, delete it and re-add it - the author's migration can miss in some environments.
This is a niche tool, but if you've ever squinted at a Qwen-Image render and wished for the texture back without losing the colors, it's the one you'd reach for.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| vae1 | VAE | — | |
| vae2 | VAE | — | |
| ratio | FLOAT | 1.000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| VAE | VAE | — |