ModelMergeFlux1
Merging Flux checkpoints, block by block
- model1
- model2
- MODEL
FLUX.1 is the 12B family from Black Forest Labs that became the open-weights quality bar in 2024, and once people started fine-tuning it, they naturally started wanting to blend those fine-tunes together. This node is the per-block merge for the Flux.1 transformer: wire in two Flux models, and each slider decides how much of model2's weights replace model1's in that part of the network. It's the Flux-flavored version of the classic SD1.5 block merge, and the one merge node in this family people actually reach for.
How the merge actually works
Under the hood this is ModelMergeBlocks wearing a Flux costume. It clones model1 as the base, then for every weight tensor in model2 it finds the slider whose name is the longest prefix of that tensor's key - double_blocks.7. covers everything inside double block 7 - and mixes them as model1_weight * (1 - ratio) + model2_weight * ratio.
Here's the gotcha almost everyone trips on the first time: every slider defaults to 1.0, which means "take model2." A value of 0 keeps model1's weights, 1.0 takes model2's outright, 0.5 is a straight average. Wire in your two models, hit run without touching anything, and you get pure model2 - not the 50/50 blend you were picturing. If you want model1 as the base and model2 as the flavor, wire them in that order and then lower the sliders.
The inputs that matter
Both model inputs are plain MODEL objects, usually from two CheckpointLoaderSimple or UNETLoader nodes. The output is a single MODEL that plugs straight into a sampler - same T5 + CLIP pipeline as any other Flux checkpoint, since the architecture hasn't changed, only the weights.
Flux's transformer has two kinds of blocks, and they're named honestly: the 19 double_blocks (0–18) process the text and image streams together; the 38 single_blocks (0–37) run the merged diagonal stream where most of the network actually lives. Then there are the little embedder sliders - img_in., txt_in., time_in., guidance_in, vector_in. - and final_layer.. For a style blend you'll mostly be dragging double_blocks and single_blocks, and the honest answer is nobody's going to hand you a magic recipe; the SD1.5-era folklore ("early blocks = layout, middle = content, late = detail") maps onto these blocks loosely, so treat it as a starting point and iterate.
Common issues
- Output looks exactly like model2. You left the sliders at their 1.0 defaults. Lower them.
- Output looks exactly like model1. You fed it mismatched models. Merging needs the same architecture - both inputs must be actual Flux.1 models. Drop an SDXL model in and no weight keys match, so the merge silently does nothing.
- Ugly output. That's the nature of merges. Community experience says blending two models with similar aesthetics is far more consistent than forcing two wildly different ones to have a baby.
Flux merges only help if the merge recipe is good, and half of that is knowing what you're blending. Grab two fine-tunes you actually like separately first, then merge.
This node landed in ComfyUI in August 2024, right when Flux support itself shipped, and it ships with core - no install needed.
Inputs (65)
| Name | Type | Default | Description |
|---|---|---|---|
| model1 | MODEL | — | |
| model2 | MODEL | — | |
| img_in. | FLOAT | 1.000–1 | — |
| time_in. | FLOAT | 1.000–1 | — |
| guidance_in | FLOAT | 1.000–1 | — |
| vector_in. | FLOAT | 1.000–1 | — |
| txt_in. | FLOAT | 1.000–1 | — |
| double_blocks.0. | FLOAT | 1.000–1 | — |
| double_blocks.1. | FLOAT | 1.000–1 | — |
| double_blocks.2. | FLOAT | 1.000–1 | — |
| double_blocks.3. | FLOAT | 1.000–1 | — |
| double_blocks.4. | FLOAT | 1.000–1 | — |
| double_blocks.5. | FLOAT | 1.000–1 | — |
| double_blocks.6. | FLOAT | 1.000–1 | — |
| double_blocks.7. | FLOAT | 1.000–1 | — |
| double_blocks.8. | FLOAT | 1.000–1 | — |
| double_blocks.9. | FLOAT | 1.000–1 | — |
| double_blocks.10. | FLOAT | 1.000–1 | — |
| double_blocks.11. | FLOAT | 1.000–1 | — |
| double_blocks.12. | FLOAT | 1.000–1 | — |
| double_blocks.13. | FLOAT | 1.000–1 | — |
| double_blocks.14. | FLOAT | 1.000–1 | — |
| double_blocks.15. | FLOAT | 1.000–1 | — |
| double_blocks.16. | FLOAT | 1.000–1 | — |
| double_blocks.17. | FLOAT | 1.000–1 | — |
| double_blocks.18. | FLOAT | 1.000–1 | — |
| single_blocks.0. | FLOAT | 1.000–1 | — |
| single_blocks.1. | FLOAT | 1.000–1 | — |
| single_blocks.2. | FLOAT | 1.000–1 | — |
| single_blocks.3. | FLOAT | 1.000–1 | — |
| single_blocks.4. | FLOAT | 1.000–1 | — |
| single_blocks.5. | FLOAT | 1.000–1 | — |
| single_blocks.6. | FLOAT | 1.000–1 | — |
| single_blocks.7. | FLOAT | 1.000–1 | — |
| single_blocks.8. | FLOAT | 1.000–1 | — |
| single_blocks.9. | FLOAT | 1.000–1 | — |
| single_blocks.10. | FLOAT | 1.000–1 | — |
| single_blocks.11. | FLOAT | 1.000–1 | — |
| single_blocks.12. | FLOAT | 1.000–1 | — |
| single_blocks.13. | FLOAT | 1.000–1 | — |
| single_blocks.14. | FLOAT | 1.000–1 | — |
| single_blocks.15. | FLOAT | 1.000–1 | — |
| single_blocks.16. | FLOAT | 1.000–1 | — |
| single_blocks.17. | FLOAT | 1.000–1 | — |
| single_blocks.18. | FLOAT | 1.000–1 | — |
| single_blocks.19. | FLOAT | 1.000–1 | — |
| single_blocks.20. | FLOAT | 1.000–1 | — |
| single_blocks.21. | FLOAT | 1.000–1 | — |
| single_blocks.22. | FLOAT | 1.000–1 | — |
| single_blocks.23. | FLOAT | 1.000–1 | — |
| single_blocks.24. | FLOAT | 1.000–1 | — |
| single_blocks.25. | FLOAT | 1.000–1 | — |
| single_blocks.26. | FLOAT | 1.000–1 | — |
| single_blocks.27. | FLOAT | 1.000–1 | — |
| single_blocks.28. | FLOAT | 1.000–1 | — |
| single_blocks.29. | FLOAT | 1.000–1 | — |
| single_blocks.30. | FLOAT | 1.000–1 | — |
| single_blocks.31. | FLOAT | 1.000–1 | — |
| single_blocks.32. | FLOAT | 1.000–1 | — |
| single_blocks.33. | FLOAT | 1.000–1 | — |
| single_blocks.34. | FLOAT | 1.000–1 | — |
| single_blocks.35. | FLOAT | 1.000–1 | — |
| single_blocks.36. | FLOAT | 1.000–1 | — |
| single_blocks.37. | FLOAT | 1.000–1 | — |
| final_layer. | FLOAT | 1.000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |