ModelMergeQwenImage

ModelMergeQwenImage is the block-merge node for Qwen-Image, Alibaba's 20B MMDiT - the model that won the open editing crown even though its text-to-image generation model was never anyone's daily driver. The KB on Qwen-Image is blunt about it: the 20B generator wasn't the community's go-to T2I base, but the family (Edit, Layered) became the default open instruction-editing stack, and everything in it is Apache 2.0. Merging is a niche thing to do with Qwen-Image, but this is the node for when you want to do it right.

Why would you bother? Two real reasons. First, the same "blend two fine-tunes block-by-block" reason as every other merge node in this family. Second - and this is where Qwen-Image is actually interesting - the block structure is a plain 60-block transformer with no U-Net encoder/decoder split, so you can do surprisingly surgical things: keep one model's early blocks (semantic structure, layout) and swap in another model's later blocks (texture, detail). Because the model is so big, that granularity is worth having.

How it works

Same family mechanism: it subclasses ModelMergeBlocks, so each weight tensor becomes ratio · model1 + (1 − ratio) · model2, with the ratio chosen by longest matching key prefix. The key map is Qwen-Image's architecture:

• pos_embeds. - positional embeddings.
• img_in. - image patch embedding (Qwen-Image uses a special patch embedder, hence no "x_embedder" name).
• txt_norm., txt_in. - text encoder output normalization and the text token projection into the DiT.
• time_text_embed. - combined timestep + text conditioning.
• transformer_blocks.0–59 - the 60 main transformer blocks. This is the model; everything meaningful happens here.
• proj_out. - the output projection to latent space.

All sliders default to 1.0 (all model1). If you're going to touch anything, it's the transformer_blocks range - the embedders are small and you'll rarely want to disturb them.

The inputs that matter

For a first experiment: model1, model2, and a small block of transformer_blocks ratios moved together. The node's real value is that you can set e.g. blocks 0–19 at 1.0 and blocks 20–59 at 0.0 and get a coherent "first quarter from model1, rest from model2" - a surgical swap no single-ratio merge can express. Output is one MODEL for your KSampler, or into Save Checkpoint.

One practical note: Qwen-Image needs its text encoder handled separately. This node merges the diffusion model only - you still load Qwen's own CLIP/LLM text encoder around it. If you want to blend the text encoders themselves, that's CLIPMergeSimple/Add/Subtract territory, and the community has genuinely done odd things there (merging a larger Qwen3 encoder in via the CLIP merge nodes to dodge shape-mismatch errors - it works because only the diffusion model enforces the encoder size).

Where people get burned

The usual suspects: both inputs must be the same architecture (20B generation model, not Qwen-Image-Edit's different variant), and merging averages defects just like every other merge - Qwen-Image's known text-rendering quirks will show up in the blend if either parent has them. This is also a heavy node to run: 20B in memory twice during the merge. It's the price of the Apache-2.0 family.

How you get it

Core ComfyUI, model/merging/model specific, added August 2025 when Qwen-Image support landed. No installation.