Ties Sum With Dropout
The LoRA-packing node for big style stacks
- deltas (delta)
- apply_median (False)
- apply_stock (False)
- cos_eps (1e-06)
- della_eps (0.0)
- eps (1e-06)
- ftol (1e-20)
- k (0.2)
- maxiter (100)
- probability (0.9)
- rescale (True)
- seed (None)
- vote_sgn (False)
- recipe
The DARE insight is a weird one: you can randomly drop the vast majority of a delta's values, and the model barely notices - the surviving few carry nearly all the information. Combine that with TIES' trim-and-vote and you get the merge technique people reach for when they want to pack a big stack of LoRAs into one without the whole pile degrading into noise. Ties Sum With Dropout is that combination, exposed as a single comfy-mecha node.
Inputs (all in delta space):
deltas (delta)- the list of deltas, viaMecha Recipe List.probability (0.9)- dropout rate. Each delta value is kept with probability1 − probability, so 0.9 means ~90% are dropped. Higher = more aggressive pruning.rescale (True)- divide the result by1 − probabilityso magnitudes aren't shrunk by the dropout. Leave it on.della_eps (0.0)- a window on the rank distribution that biases which values get dropped (the "DELLA" variant). 0 disables it.seed (None)- makes the random dropout reproducible; set a non-negative value to lock it.k (0.2)- TIES trim fraction; 0.2 is the classic setting.vote_sgn (False),apply_median (False),apply_stock (False),cos_eps (1e-06),eps (1e-06),maxiter (100),ftol (1e-20)- the full TIES Extended surface for combining the survivors.
Output is a MECHA_RECIPE in delta space. Add it back to a base via Add Difference.
How it works
Per tensor, each delta gets its values randomly masked by a Bernoulli draw (seeded if you set seed), then the survivors run through the same trim → sign-vote → aggregate pipeline as TIES Extended. The rescale step is what stops the merged delta from ending up ~10× too small; drop it and your merge will look like it did nothing.
Why you'd reach for it
This is the community's answer to "I have fifteen style LoRAs and want one LoRA that keeps them all." The dropout acts as a regularizer - it stops similar LoRAs from reinforcing their overlaps into oversaturation while TIES' sign vote stops outright conflict. It's also the node where seed starts to matter: with dropout, the same merge run twice can give slightly different results, and reproducibility is nice when you're comparing recipes.
Install
Pack-level: 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 ComfyUI. Only dependency is sd-mecha; no model downloads.
Gotchas
Three classic missteps. Inputs must be deltas, not checkpoints - the (delta) label is doing work. Output is a delta: add it to a base or it's a dead end. And if you raise probability toward 0.99, keep rescale on, because the rescaling math gets extreme and you'll chase faint results otherwise. If the run-to-run variation bothers you, set seed. merge_checkpointing behaves like the rest of the pack: fp16 CPU caching for stable branches, don't stack with cache units.
Inputs (14)
| Name | Type | Default | Description |
|---|---|---|---|
| deltas (delta)opt | MECHA_RECIPE_LIST | — | |
| apply_median (False)opt | MECHA_RECIPE | false | — |
| apply_stock (False)opt | MECHA_RECIPE | false | — |
| cos_eps (1e-06)opt | MECHA_RECIPE | 0.000001 | — |
| della_eps (0.0)opt | MECHA_RECIPE | 0 | — |
| eps (1e-06)opt | MECHA_RECIPE | 0.000001 | — |
| ftol (1e-20)opt | MECHA_RECIPE | 1e-20 | — |
| k (0.2)opt | MECHA_RECIPE | 0.2 | — |
| maxiter (100)opt | MECHA_RECIPE | 100 | — |
| probability (0.9)opt | MECHA_RECIPE | 0.9 | — |
| rescale (True)opt | MECHA_RECIPE | true | — |
| seed (None)opt | MECHA_RECIPE | — | |
| vote_sgn (False)opt | MECHA_RECIPE | false | — |
| 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 | — |