Nodes/ComfyUI/ModelMergeWAN2_1
ComfyUI Node Runs on cloud

ModelMergeWAN2_1

The Wan 2.1 merge node, block-count warning included

By Comfy-Org·Created 4 years ago·Updated 30 minutes ago· 129,853
ModelMergeWAN2_1
  • model1
  • model2
  • MODEL
patch_embedding.1.00
time_embedding.1.00
time_projection.1.00
text_embedding.1.00
img_emb.1.00
blocks.0.1.00
blocks.1.1.00
blocks.2.1.00
blocks.3.1.00
blocks.4.1.00
blocks.5.1.00
blocks.6.1.00
blocks.7.1.00
blocks.8.1.00
blocks.9.1.00
blocks.10.1.00
blocks.11.1.00
blocks.12.1.00
blocks.13.1.00
blocks.14.1.00
blocks.15.1.00
blocks.16.1.00
blocks.17.1.00
blocks.18.1.00
blocks.19.1.00
blocks.20.1.00
blocks.21.1.00
blocks.22.1.00
blocks.23.1.00
blocks.24.1.00
blocks.25.1.00
blocks.26.1.00
blocks.27.1.00
blocks.28.1.00
blocks.29.1.00
blocks.30.1.00
blocks.31.1.00
blocks.32.1.00
blocks.33.1.00
blocks.34.1.00
blocks.35.1.00
blocks.36.1.00
blocks.37.1.00
blocks.38.1.00
blocks.39.1.00
head.1.00

Wan is where local video generation consolidated - Alibaba's Apache 2.0 family whose 14B diffusion transformer became the base under a whole layer of community fine-tunes and remixes. That's exactly the situation where merging gets interesting: if there are fine-tunes you like for different things, blending them is the natural next move. This node is the per-block merge for Wan 2.1, and it ships with its own built-in warning in the node description, which is rare enough that it's worth quoting:

"1.3B model has 30 blocks, 14B model has 40 blocks. Image to video model has the extra img_emb."

How it works

The family engine: clone model1 as the base, mix model2's weights per-block with ratio = fraction of model2 (model1_weight * (1 - ratio) + model2_weight * ratio), longest-prefix matching on weight keys. The sliders mirror the Wan 2.1 architecture: patch_embedding., time_embedding., time_projection., text_embedding., img_emb., then blocks.0. through blocks.39. (40 total), and head..

That node description is doing real work, because the node always exposes all 40 blocks regardless of what you feed it. Merge two 14B models and all 40 are real. Feed it a 1.3B model and only 30 of those blocks exist - the extra sliders have no weights to patch, so they're effectively ignored. The img_emb. slider only matters for image-to-video models; text-to-video models don't carry those weights. None of this breaks anything - mismatched keys just don't apply - but it means you should know which variant you loaded.

And yes, the family trap is here too: every slider defaults to 1.0 = "take model2," so an untouched run gives you pure model2, not a blend. Base in model1, flavor in model2, lower sliders to mix.

Wiring and gotchas

Both inputs are MODEL objects (loaders or the standard Wan pipeline nodes), and the output MODEL feeds your video sampler exactly like either input would - same 3D causal VAE, same conditioning. Two things to watch:

  • Same architecture or nothing. Merging a 14B with a 1.3B means most weight keys won't match, and the merge silently becomes a passthrough of model1. Same for any non-Wan model - this node will not merge Wan with LTX or anything else.
  • Merges bake in what's already stacked. If you have LoRAs or other patches applied at load, they ride along into the merged model. Clean loads for a clean merge.

The real-world note

Wan 2.1 is the version this node was written for (it landed March 2025), and the open base has since frozen at Wan 2.2 with the numbered series going API-only. If you're blending the community's 2.1/2.2 fine-tunes, this is the node that covers that architecture - and unlike a lot of the model-specific merges, there's a genuine reason to be here: people do remix Wan fine-tunes, and merging is how you get the "both of these" model without training anything.

Categorymodel/merging/model specific

Inputs (48)

NameTypeDefaultDescription
model1MODEL
model2MODEL
patch_embedding.FLOAT1.000–1
time_embedding.FLOAT1.000–1
time_projection.FLOAT1.000–1
text_embedding.FLOAT1.000–1
img_emb.FLOAT1.000–1
blocks.0.FLOAT1.000–1
blocks.1.FLOAT1.000–1
blocks.2.FLOAT1.000–1
blocks.3.FLOAT1.000–1
blocks.4.FLOAT1.000–1
blocks.5.FLOAT1.000–1
blocks.6.FLOAT1.000–1
blocks.7.FLOAT1.000–1
blocks.8.FLOAT1.000–1
blocks.9.FLOAT1.000–1
blocks.10.FLOAT1.000–1
blocks.11.FLOAT1.000–1
blocks.12.FLOAT1.000–1
blocks.13.FLOAT1.000–1
blocks.14.FLOAT1.000–1
blocks.15.FLOAT1.000–1
blocks.16.FLOAT1.000–1
blocks.17.FLOAT1.000–1
blocks.18.FLOAT1.000–1
blocks.19.FLOAT1.000–1
blocks.20.FLOAT1.000–1
blocks.21.FLOAT1.000–1
blocks.22.FLOAT1.000–1
blocks.23.FLOAT1.000–1
blocks.24.FLOAT1.000–1
blocks.25.FLOAT1.000–1
blocks.26.FLOAT1.000–1
blocks.27.FLOAT1.000–1
blocks.28.FLOAT1.000–1
blocks.29.FLOAT1.000–1
blocks.30.FLOAT1.000–1
blocks.31.FLOAT1.000–1
blocks.32.FLOAT1.000–1
blocks.33.FLOAT1.000–1
blocks.34.FLOAT1.000–1
blocks.35.FLOAT1.000–1
blocks.36.FLOAT1.000–1
blocks.37.FLOAT1.000–1
blocks.38.FLOAT1.000–1
blocks.39.FLOAT1.000–1
head.FLOAT1.000–1

Outputs (1)

NameTypeDescription
MODELMODEL