🧬 Merge Flux

Merge Flux blends two Flux models block-by-block, giving you a per-block weight over the merge instead of one blunt "50/50" slider. This is the model-merging equivalent of the old SD 1.5 block-weight-merge tooling, ported to Flux's transformer layout - a power-user toy for people who want to graft the double blocks of one Flux fine-tune onto the single blocks of another, or fade one model in gradually across the network's depth.

To use it you need to understand Flux's structure, because the two inputs map straight onto it. Flux has 19 double blocks (indices 0–18) and 38 single blocks (0–37), and this node exposes each group as a text field: double_blocks (default 0-9:1,10-18:1) and single_blocks (default 0-37:1). The syntax is the pack's merge grammar - {range}:{weight}, comma-separated, where a weight of 1 means "take model2 fully for these blocks" and 0 means "keep model1," with anything unlisted inheriting the last value you gave. So 0-9:0, 10-18:1 on the double blocks means the first ten double blocks stay model1 and the back nine come from model2. It's the same idea as block-weight LoRA merging from the WebUI days, just spelled out per range.

The inputs, then, are those two block strings plus two optional models - model1 and model2 - and that's the whole surface. Outputs are the merged model and an mbw STRING, which is the fully-expanded block-weight recipe the node computed. That mbw string is genuinely useful: it's the reproducible record of exactly what you merged, so you can log it, tweak it, or paste it back to recreate a result. Feed the merged model into your normal Flux sampler and see what you got.

Being straight about this one: it's niche, and it's fiddly, and merging Flux models is a lot less popular than merging SDXL checkpoints was, partly because Flux fine-tunes are heavier and partly because the block-level effects are harder to predict on a rectified-flow transformer than they were on a U-Net. This is not a node most people need. Where it earns its keep is experimentation - you have two Flux models with different strengths (one great at composition, one great at texture, say) and you want to find out whether a depth-selective merge gets you both. That's a real, if specialized, use, and having per-block control beats hoping a flat average lands well.

Install comes with the pack. ComfyUI Manager, search SDVN_Comfy_node; or cd ComfyUI/custom_nodes && git clone https://github.com/StableDiffusionVN/SDVN_Comfy_node, then pip install -r custom_nodes/SDVN_Comfy_node/requirements.txt from your ComfyUI root and restart. No extra weights for the node itself - you bring the two Flux models you're merging.

Troubleshooting. The most common way to get nonsense out is a block-string typo - if your ranges don't cover the real block count (0–18 for double, 0–37 for single) the unlisted blocks fall through to the last weight, which may not be what you meant, so read the mbw output to see what actually got applied. Merging is also memory-hungry: two full Flux models in play at once is a lot of VRAM/RAM, and an out-of-memory kill mid-merge is the environment, not the node. And keep the two models in the same family - this merges Flux with Flux; it's not a bridge between Flux and some other architecture. Start from the defaults, change one range at a time, and read the recipe string each pass; that's the sane way to explore it.