Nodes/ComfyUI-RecipeMerge/Block Sliders Merge (MBW)
ComfyUI Node

Block Sliders Merge (MBW)

SuperMerger's block sliders, now on ComfyUI

By galigali-san·Created 2 months ago·Updated 2 months ago· 1
Block Sliders Merge (MBW)
  • model1
  • model2
  • model
  • report
BASE0.50
IN000.50
IN010.50
IN020.50
IN030.50
IN040.50
IN050.50
IN060.50
IN070.50
IN080.50
IN090.50
IN100.50
IN110.50
M000.50
OUT000.50
OUT010.50
OUT020.50
OUT030.50
OUT040.50
OUT050.50
OUT060.50
OUT070.50
OUT080.50
OUT090.50
OUT100.50
OUT110.50
elemental
sweep_value0.500

If you came up on the old Merge Block Weighted (MBW) GUI in A1111, you think in blocks: IN07 is where faces live, OUT is the renderer's output side, BASE is the whole vibe. SuperMerger kept that layout alive on the A1111 side while ComfyUI had basically nothing equivalent - until ComfyUI-RecipeMerge.

Block Sliders Merge (MBW) is the ComfyUI transplant of that idea: 27 sliders, one per UNet block, in the classic MBW order - BASE, IN00IN11, M00, OUT00OUT11. Drag a block's slider and you're choosing how much of model2 goes into that block. It's the tactile middle ground between "one global ratio" and the full elemental depth of the recipe and matrix nodes in the same pack.

How it works

Under the hood it's the same per-key merge engine as the pack's recipe node: each slider becomes a block-wide rule ("every key in IN07 at 0.8"), applied to model2's UNet patches against model1. The elemental text field sits on top - write attn2:0.8 or IN04:attn2:0.9 and those rules override the sliders, giving you block-level control plus surgical element tweaks without opening a separate node. Slider syntax and element names are identical to the pack's recipe grammar, so whatever you learned there carries over.

Two things to internalize before you queue anything:

  • Ratio is model2's share. 0.5 = half and half, 1.0 = that block is now model2. This is SuperMerger's alpha direction, the reverse of ComfyUI's ModelMergeSimple.
  • A fresh node defaults every slider to 0.5. This catches everyone. The knob matrix node in the same pack starts at 0 (model1 untouched), but this one drops you straight into a full 50/50 merge the moment you connect two models and hit Queue. If that's not what you wanted, zero the sliders first.

Inputs and outputs that matter

model1 and model2 are your parents. The 27 sliders are the main event - BASE plus the four block groups. elemental is a multiline text field for overrides (leave it empty and the sliders run the show; __VAL__ works here too). sweep_value replaces __VAL__ in the elemental field, same XY-plot trick as the recipe node: right-click it, Convert to Input, sweep.

Outputs: model (straight into a KSampler) and report - the STRING that tells you exactly which blocks received which rules and how many keys each hit. On SDXL, blocks IN09IN11 and OUT09OUT11 don't exist (SDXL's encoder runs 9 blocks deep, not 12), so those sliders do nothing and the report shows them at 0 keys. That's correct behavior, not a bug - SD1.5 full-size checkpoints just have more blocks than SDXL.

Install

No dependencies at all - pyproject.toml lists dependencies = [], and it runs on stock ComfyUI. Grab it via ComfyUI Manager (search "ComfyUI-RecipeMerge") or:

cd ComfyUI/custom_nodes
git clone https://github.com/galigali-san/ComfyUI-RecipeMerge

Restart ComfyUI. The node is under advanced/model_merging, and the UI text is currently Japanese (the pack is by galigali, a Japanese dev - an English UI pass is on the roadmap, so don't let the ノード名 scare you).

Common issues

  • "Why is my merge already 50/50?" The defaults. Sliders start at 0.5; zero them if you want model1 until you deliberately blend.
  • Some sliders do nothing. On SDXL, IN09+ and OUT09+ are dead blocks - check the report for the 0-key confirmation.
  • Elemental overrides not winning. The elemental rules are designed to beat sliders; if one still "loses," check the report - a means the rule matched zero keys (typo or a block that doesn't exist).
  • Distributing the result. Same drill as any merge: check both source licenses (merges inherit restrictions and defects, per the checkpoint knowledge base), and know the merge recipe is baked into the checkpoint metadata via CheckpointSave - --disable-metadata strips it.

If the slider-per-block model is how your brain already works, this is the node you'll live in. Want element-level precision instead? The Elemental Merge (Recipe) and Elemental Matrix Merge (Knobs) siblings do that - same engine, sharper tools.

Categoryadvanced/model_merging

Inputs (30)

NameTypeDefaultDescription
model1MODEL
model2MODEL
BASEFLOAT0.500–1
IN00FLOAT0.500–1
IN01FLOAT0.500–1
IN02FLOAT0.500–1
IN03FLOAT0.500–1
IN04FLOAT0.500–1
IN05FLOAT0.500–1
IN06FLOAT0.500–1
IN07FLOAT0.500–1
IN08FLOAT0.500–1
IN09FLOAT0.500–1
IN10FLOAT0.500–1
IN11FLOAT0.500–1
M00FLOAT0.500–1
OUT00FLOAT0.500–1
OUT01FLOAT0.500–1
OUT02FLOAT0.500–1
OUT03FLOAT0.500–1
OUT04FLOAT0.500–1
OUT05FLOAT0.500–1
OUT06FLOAT0.500–1
OUT07FLOAT0.500–1
OUT08FLOAT0.500–1
OUT09FLOAT0.500–1
OUT10FLOAT0.500–1
OUT11FLOAT0.500–1
elementalSTRING要素の上書き(例: attn2:0.8 / IN04:attn2:0.9)。スライダーより優先される。空でもOK
sweep_valueFLOAT0.500-1–2elemental内の __VAL__ を置換(XYプロット用)

Outputs (2)

NameTypeDescription
modelMODEL
reportSTRING