ModelMergeBlocks
The input/middle/out merge that makes your first checkpoint
- model1
- model2
- MODEL
ModelMergeSimple blends two checkpoints evenly everywhere. ModelMergeBlocks lets you pick where the blend happens. Instead of one ratio you get three: input, middle, out. That's the difference between "averaging two models" and "making a real merge" - the thing every checkpoint page on CivitAI is secretly doing.
The idea comes from how a UNet works. The input blocks handle the early, high-level pass - composition, layout, what's in the frame. The middle block is the bottleneck where the model decides the fundamental structure of the image. The output blocks refine and paint in the details - texture, lighting, faces. Because each stage does a different job, you usually don't want one global blend. You want to keep model A's composition and swap in model B's finishing style.
That's the practical recipe people actually run: set input and middle high (keep model1's structure) and out low (let model2's detail take over), or the reverse. One long-time merger's rough starting point in the community: middle and out around 0.7–0.8, input back and forth between 0.5 and 1.0. It's an equalizer, not a science - you wiggle it until the result looks right.
How it works
Under the hood ModelMergeBlocks is exactly ModelMergeSimple, but the ratio is resolved per weight tensor. For every key in model2, it finds the longest matching prefix among the three block groups and applies that group's ratio:
weight = ratio_group · model1 + (1 − ratio_group) · model2
input governs keys under input_blocks.*, middle under middle_block.*, out under output_blocks.* and out.*. Longer prefix wins when names overlap, so the group mapping is unambiguous. Nothing is saved; you get a patched MODEL you can sample immediately.
And here's the thing worth knowing for the rest of this family: every model-specific merge node in ComfyUI is a subclass of ModelMergeBlocks. ModelMergeSDXL just pre-fills the input_blocks.0–output_blocks.8 key names so you don't have to guess the prefixes. If you understand this node, you understand all of them.
The inputs that matter
model1,model2(MODEL) - the two checkpoints.input(FLOAT, default 1.0, 0–1) - how much model1 survives in the encoder/early blocks.middle(FLOAT, default 1.0, 0–1) - same, for the bottleneck blocks.out(FLOAT, default 1.0, 0–1) - same, for the decoder/final blocks.
One MODEL out, straight into a KSampler or another merge. Defaults at 1.0 mean "all model1" - nothing changes until you move a slider, which is a good safe starting state.
Where people get burned
The classic beginner move is setting all three to 0.5 and calling it a merge. That's fine - it's just ModelMergeSimple with extra steps. The actual value of this node is asymmetry, and asymmetry means you have to know which blocks do what. Read a couple of checkpoint pages before you start: good merge pages say which part they took from which parent.
Mismatched architectures are the other trap. The block prefixes are hardcoded for the classic U-Net layout, so this node only merges SD 1.5 / SD 2.x / SDXL-shaped models. Try to force a transformer (Flux, SD3, Qwen-Image) through it and you'll get shape mismatches and warnings - use the model-specific merge nodes for those instead.
How you get it
Core ComfyUI, model/merging category, ships with the program - no installation. The model-specific siblings (ModelMergeSDXL, ModelMergeAuraflow, and friends) are the same node with the block names filled in for you. Once you're comfortable here, grab ModelMergeSDXL and never type a prefix again.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model1 | MODEL | — | |
| model2 | MODEL | — | |
| input | FLOAT | 1.000–1 | — |
| middle | FLOAT | 1.000–1 | — |
| out | FLOAT | 1.000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |