Nodes/TechNodes/VAE Merge
ComfyUI Node

VAE Merge

Blend two (or three) VAEs together, block by block

By TechnoByteJS·Created 2 years ago·Updated 2 years ago· 14
VAE Merge
  • vae_a
  • vae_b
  • vae_c
  • VAE
merge_mode
alpha0.50
beta0.50
brightness0.00
contrast0.00
use_blocksfalse
block_conv_out0.50
block_norm_out0.50
block_00.50
block_10.50
block_20.50
block_30.50
block_mid0.50
block_conv_in0.50
block_quant_conv0.50

Checkpoint merging is a whole culture on CivitAI - thousands of merged models, entire threads dissecting which blend of which two checkpoints looks best. VAE merging is not that. VAEs are the one part of the ecosystem nobody bothers averaging: only 199 have ever been published to CivitAI, against three-quarters of a million LoRAs, because most people either use the one baked into their checkpoint or grab a known-good standalone file and move on. So this node is a niche tool for a niche problem - but it's a real one. Maybe you like 80% of what one VAE does and want to nudge it toward another's color response. Maybe you're doing the increasingly common 2026 move of swapping in a different model's decoder to fix over-smoothing, and a hard swap is too much - you want something in between. That's what VAE Merge is for.

How it works

It's the VAE-specific half of this pack's merge tooling (the checkpoint-level sibling is SDNext Merge). You give it two VAEs - vae_a and vae_b - plus a merge_mode, and it blends them. There are 12 modes on offer, and they fall into three rough buckets: straight interpolation (weighted_sum, tensor_sum, sum_twice, triple_sum), difference-based grafting (add_difference, multiply_difference, euclidean_add_difference), and a newer set (similarity_add_difference, top_k_tensor_sum, distribution_crossover, ties_add_difference) that reads like it was lifted from LLM checkpoint-merging research rather than invented for diffusion. If you don't know which to pick, weighted_sum at the default alpha of 0.5 is a plain 50/50 blend and the sane starting point. The difference-family modes want a third VAE (vae_c, optional) as the reference point they're diffing against - leave it unwired and you'll get a bad merge, not an error.

For finer control there's use_blocks (off by default). Flip it on and the node stops applying one global alpha and instead reads a separate weight for each internal block of the VAE - block_conv_in, block_0 through block_3, block_mid, block_conv_out, block_norm_out, block_quant_conv - all 0–1, all defaulting to 0.5. Leave every block at 0.5 and it's identical to a flat merge; you have to actually move sliders to see the effect, and honestly, this is deep-in-the-weeds territory most people will never touch. brightness and contrast (-1 to 1, both default 0) are simpler post-merge tweaks - small pushes to the decoded output rather than the merge itself.

Inputs and output

  • vae_a, vae_b (required) - the two VAEs to blend. vae_c (optional) - only matters for the difference-family modes.
  • alpha / beta - the blend ratios most modes read; 0.5 is neutral.
  • use_blocks + the block_* sliders - per-block override, off unless you turn it on.
  • brightness / contrast - a small post-merge nudge.

Output is a single VAE - plug it into VAE Decode or VAE Encode exactly like any loaded VAE.

Installing it

ComfyUI Manager: search TechNodes, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/TechnoByteJS/ComfyUI-TechNodes --depth 1

No models to download and no heavy dependencies - the whole pack is logic that runs on VAE/model tensors you've already loaded.

Where people get burned

The one that actually bites: merging VAEs from different base architectures. SD 1.5 and SDXL both use 4-channel latents but they're still incompatible autoencoders, and Flux-and-later models use 16-channel latents entirely - merging across that boundary doesn't produce a compromise, it produces noise or a flat-color mess, because the two VAEs don't agree on what their numbers mean. Only merge VAEs built for the same checkpoint family. Second: picking a difference-mode without wiring vae_c - the schema lets you do it, the merge just comes out wrong. And third, a reminder that isn't specific to this node but is worth having in your head whenever you're comparing merge results - every VAE encode/decode round trip is lossy on its own, so a merged VAE that looks a little softer than either parent isn't necessarily a bad merge; it might just be what a second pass through a codec always does.

CategoryTechNodes/merging

Inputs (18)

NameTypeDefaultDescription
vae_aVAE
vae_bVAE
merge_modeCOMBO12 options: weighted_sum, weighted_subtraction, tensor_sum, add_difference, sum_twice, triple_sum, +6
alphaFLOAT0.500–1
betaFLOAT0.500–1
brightnessFLOAT0.00-1–1
contrastFLOAT0.00-1–1
use_blocksBOOLEANfalse
block_conv_outFLOAT0.500–1
block_norm_outFLOAT0.500–1
block_0FLOAT0.500–1
block_1FLOAT0.500–1
block_2FLOAT0.500–1
block_3FLOAT0.500–1
block_midFLOAT0.500–1
block_conv_inFLOAT0.500–1
block_quant_convFLOAT0.500–1
vae_coptVAE

Outputs (1)

NameTypeDescription
VAEVAE