Model Merge HiDream
Merge HiDream models block by block, not as one blob
- model1
- model2
- MODEL
HiDream-I1 shipped Full, Dev, and Fast variants - same architecture, different training budgets - and the classic question was always "can I have Dev's prompt adherence with Fast's snappiness?" A plain checkpoint merge slaps both models together with one global ratio and hopes. Model Merge HiDream is the surgical version: 48 per-block ratio sliders, one for every meaningful part of the architecture, so you blend where you want to, not everywhere at once.
This is merging as the community actually does it - a weighted interpolation of weights, no training, minutes not days - but at block granularity. You take parent 1 as the base, parent 2 as the donor, and dial in how much of the donor's double-stream and single-stream blocks you want.
How it works
Two model inputs, one output. It clones model1, pulls model2's key patches, and for every weight uses a longest-prefix match against your ratio sliders: value 0.0 keeps model1's weight, 1.0 takes model2's, 0.5 is a 50/50 blend. The blending happens through add_patches, so nothing mutates the originals - you always get a fresh merged model on the output socket, ready to wire into a sampler for live testing.
The layer layout is fixed to the HiDream series the author targeted: x_embedder, t_embedder, caption_projection, then double_stream_blocks 0–12 and single_stream_blocks 0–31. If your HiDream checkpoint uses a different block count, the sliders simply won't map - check with the pack's Key Name Inspector if things feel off.
The inputs that matter
The ratio sliders all run 0.0–1.0 in 0.01 steps, defaulting to 1.0 (full donor). Realistically:
- model1 / model2 - the two models. Wire Full/Dev/Fast in either order; the sliders define the direction.
- caption_projection - how strongly model2's text-caption projection wins. This is the single most noticeable knob for prompt adherence differences between HiDream variants.
- double_stream_blocks.N - the earlier, denser attention blocks; the place most of the "understanding" lives.
- single_stream_blocks.N - the later blocks, closer to the output and more about detail/style. Many merge experiments blend these differently from the double-stream rows - that's the whole point of a per-block node.
Output is one MODEL, straight into your sampler or a preview.
Install
Search Easygoing in the ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/easygoing0114/ComfyUI-easygoing-nodes.git
Restart ComfyUI. No pip extras; requires a ComfyUI build with the V3 node API.
Where people get burned
The usual merge traps apply with extra force here. HiDream-I1 is a 17B latent model - heavy to hold two of them plus the merged result in VRAM, so expect a memory ceiling and keep both loaders' models offloaded where you can. And per-block merging is powerful but harder to reason about than a single ratio: change a few sliders, sample a handful of seeds, and compare against both parents before you commit. Also remember this merge is in-graph only - if you want the result as a file, you'll need to save it, and that's where this pack's Load Original Model + Model Save with Original pair comes in for a clean round-trip.
Inputs (50)
| Name | Type | Default | Description |
|---|---|---|---|
| model1 | MODEL | — | |
| model2 | MODEL | — | |
| x_embedder. | FLOAT | 1.000–1 | — |
| t_embedder. | FLOAT | 1.000–1 | — |
| caption_projection. | FLOAT | 1.000–1 | — |
| double_stream_blocks.0. | FLOAT | 1.000–1 | — |
| double_stream_blocks.1. | FLOAT | 1.000–1 | — |
| double_stream_blocks.2. | FLOAT | 1.000–1 | — |
| double_stream_blocks.3. | FLOAT | 1.000–1 | — |
| double_stream_blocks.4. | FLOAT | 1.000–1 | — |
| double_stream_blocks.5. | FLOAT | 1.000–1 | — |
| double_stream_blocks.6. | FLOAT | 1.000–1 | — |
| double_stream_blocks.7. | FLOAT | 1.000–1 | — |
| double_stream_blocks.8. | FLOAT | 1.000–1 | — |
| double_stream_blocks.9. | FLOAT | 1.000–1 | — |
| double_stream_blocks.10. | FLOAT | 1.000–1 | — |
| double_stream_blocks.11. | FLOAT | 1.000–1 | — |
| double_stream_blocks.12. | FLOAT | 1.000–1 | — |
| single_stream_blocks.0. | FLOAT | 1.000–1 | — |
| single_stream_blocks.1. | FLOAT | 1.000–1 | — |
| single_stream_blocks.2. | FLOAT | 1.000–1 | — |
| single_stream_blocks.3. | FLOAT | 1.000–1 | — |
| single_stream_blocks.4. | FLOAT | 1.000–1 | — |
| single_stream_blocks.5. | FLOAT | 1.000–1 | — |
| single_stream_blocks.6. | FLOAT | 1.000–1 | — |
| single_stream_blocks.7. | FLOAT | 1.000–1 | — |
| single_stream_blocks.8. | FLOAT | 1.000–1 | — |
| single_stream_blocks.9. | FLOAT | 1.000–1 | — |
| single_stream_blocks.10. | FLOAT | 1.000–1 | — |
| single_stream_blocks.11. | FLOAT | 1.000–1 | — |
| single_stream_blocks.12. | FLOAT | 1.000–1 | — |
| single_stream_blocks.13. | FLOAT | 1.000–1 | — |
| single_stream_blocks.14. | FLOAT | 1.000–1 | — |
| single_stream_blocks.15. | FLOAT | 1.000–1 | — |
| single_stream_blocks.16. | FLOAT | 1.000–1 | — |
| single_stream_blocks.17. | FLOAT | 1.000–1 | — |
| single_stream_blocks.18. | FLOAT | 1.000–1 | — |
| single_stream_blocks.19. | FLOAT | 1.000–1 | — |
| single_stream_blocks.20. | FLOAT | 1.000–1 | — |
| single_stream_blocks.21. | FLOAT | 1.000–1 | — |
| single_stream_blocks.22. | FLOAT | 1.000–1 | — |
| single_stream_blocks.23. | FLOAT | 1.000–1 | — |
| single_stream_blocks.24. | FLOAT | 1.000–1 | — |
| single_stream_blocks.25. | FLOAT | 1.000–1 | — |
| single_stream_blocks.26. | FLOAT | 1.000–1 | — |
| single_stream_blocks.27. | FLOAT | 1.000–1 | — |
| single_stream_blocks.28. | FLOAT | 1.000–1 | — |
| single_stream_blocks.29. | FLOAT | 1.000–1 | — |
| single_stream_blocks.30. | FLOAT | 1.000–1 | — |
| single_stream_blocks.31. | FLOAT | 1.000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |