Model Merge
Merge two models at runtime, and keep the recipe in the image
- base_model
- merge_model
- model
Merging checkpoints usually means a separate tool: SuperMerger, a CLI, a merge script, and a baked .safetensors file sitting on disk. Model Merge from this pack takes the opposite approach - it merges on demand, inside the graph, at sampling time, and it records the merge as a recipe rather than a result. Give it two IPT-Model selections and a ratio, and it returns a third IPT-Model value that describes "60% of model A, 40% of model B." The actual weight merge happens later, only when that value reaches the pack's Load New Model node.
That's the distinction that makes it interesting: you never produce a merged file. You produce a description of a merge, which travels in image_info, gets serialized into the saved image's infotext, and reconstructs itself when you load the image back. The README calls this out explicitly - the metadata stores the merge configuration, not the merged weights, so the source model files must still exist locally when you replay it.
How it works
The node packages base_model and merge_model with two ratios into a new IPT-Model value:
model_ratio(0 to 1, default 1) - the interpolation between the two; 0 keeps the base entirely, 1 keeps the merge model entirely.clip_ratio(0 to 1, default 1) - independently blends the CLIP side of a checkpoint merge. Ignored for diffusion-model merges.
When the value reaches Load New Model, the pack runs the equivalent of ModelMergeSimple and CLIPMergeSimple on the actual weights. It also enforces one hard rule: base_model and merge_model must both be checkpoints, or both be diffusion models - mixing types raises an error. Checkpoint merges keep the VAE from the base.
Why you'd use this instead of a merge tool
Two reasons, and they're both about the workflow, not the math.
First, no disk bloat. A merge is just arithmetic on weights; baking it writes a multi-GB file. Doing it at runtime means you keep the two sources and describe the blend in the graph - change the ratio from 0.6 to 0.7 and rerun, no re-bake. If you iterate on blends a lot, that's a genuinely better loop.
Second, the recipe survives the image. Save the output with Image Saver and the merge configuration rides along as JSON in the infotext, tagged as Model Merge, Refiner Merge, or Detailer Merge depending on which slot the value fed. Load it later with Image Reader and the merge reconstructs, source files permitting. That's a level of reproducibility a baked file can't give you - the image itself says "60/40 of these two models," not "some checkpoint you can't identify."
Where people get burned
The big one is expecting the merged weights to be saved. They aren't - this is a recipe node, so if you delete or move the source checkpoints, the merge breaks with a missing-file error at load time. Relatedly, don't confuse this with ComfyUI's own ModelMergeSimple node, which merges already-loaded models in place; this one merges choices lazily.
The type-mixing error trips people too: you can't merge a checkpoint with a diffusion-model selection. And since clip_ratio is silently ignored for diffusion models, don't expect it to do anything there.
Installing
Part of kinorax/comfyui-info-prompt-toolkit:
cd ComfyUI/custom_nodes
git clone https://github.com/kinorax/comfyui-info-prompt-toolkit.git
cd comfyui-info-prompt-toolkit
pip install -r requirements.txt
or install "Info-Prompt-Toolkit" via ComfyUI Manager, then restart. No model files. You'll feed it from the pack's Checkpoint Selector / Diffusion Model Selector and consume it via Load New Model - all in the same pack.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| base_model | IPT-Model | Base IPT-Model. ratio=0 keeps this side. | |
| merge_model | IPT-Model | Second IPT-Model. ratio=1 keeps this side. | |
| model_ratio | FLOAT | 1.000–1 | ModelMergeSimple ratio passed to runtime merge |
| clip_ratio | FLOAT | 1.000–1 | CLIPMergeSimple ratio. Ignored for diffusion_models |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | IPT-Model | — |