Fallback
Use A, and only fall back to default where A is missing
- a (delta|param|weight)
- default (delta|param|weight)
- recipe
Fallback Mecha Recipe answers a boring question that nonetheless kills merges: what happens when two models don't have the same keys? The answer, in this pack, is a node that goes key by key and says - if a has this tensor, take it from a; if a is missing it, take it from default. It's a per-key or operation, and it's the escape hatch for models whose key layouts disagree.
Why this exists
Merging assumes your inputs share a key structure - that's the contract of the pack's "any model, as long as they share keys" promise. In practice that breaks: a fine-tune that dropped a component, a merged checkpoint that lost its vae keys, a LoRA-style recipe that only covers part of a model. Plain additive merges either crash on the missing key or silently skip it. Fallback gives you the "fill the holes" behavior instead: A wins everywhere it exists, and only the gaps come from default.
Because it operates per key, it's also a building block for "progressive" merges - you can fall back from a customized recipe to a base recipe, and any key the custom side doesn't cover reverts to base. That's a different thing from blending, and sometimes exactly what you want.
Inputs
a (delta|param|weight)- the primary source; its keys win.default (delta|param|weight)- the fill-in source for keysalacks.merge_checkpointing- the usual branch-cache toggle.
Output: one recipe (MECHA_RECIPE). No alpha, no strength - this is a structural operation, not a blend. If you want a blend between two models' overlapping keys, use Weighted Sum; if you want "A, except where A doesn't exist, then default," this is it.
Install & gotchas
ComfyUI Manager → search mecha → Mecha Merge Node Pack, or:
cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt
Restart; only dependency is sd-mecha==1.1.7.
Where it bites: fallback hides problems. If your model is missing keys because it's corrupted or the wrong architecture, Fallback will silently paper over it with the default's weights, and you'll ship a merge that's secretly a frankenstein. Use it deliberately - to bridge a known key difference (like a missing VAE, which the pack's Merger can also just omit_vae) - and not as a reflex for "it wouldn't merge." And keep both inputs in the same merge space; falling back across weight and delta spaces is a recipe for nonsense even if it doesn't error.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| a (delta|param|weight) | MECHA_RECIPE | — | |
| default (delta|param|weight) | MECHA_RECIPE | — | |
| merge_checkpointingopt | BOOLEAN | false | Speeds up an entire branch of a merge graph that does not change often in exchange of memory. - true: store the first output of this recipe node on cpu memory in fp16. On subsequent workflow executions, as long as the inputs do not change, the cached keys are returned after being cast to the original device and dtype. - false: do not store the output. The recipe and its inputs will re-execute on subsequent workflow executions. Note that the memory used to checkpoint the output is distinct from the cache feature. In general, you probably want to either use this *or* a cache unit, but not both at the same time because the memory adds up. The difference between merge checkpointing and cache is that merge checkpointing completely re-merges from scratch if any input changes. Merge checkpointing is also generally much faster than cache in the fast path. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| recipe | MECHA_RECIPE | — |