Nodes/Mecha Merge Node Pack/Ties Sum With Dropout
ComfyUI Node

Ties Sum With Dropout

The LoRA-packing node for big style stacks

By ljleb·Created 3 years ago·Updated about a month ago· 101
Ties Sum With Dropout
  • 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
merge_checkpointingfalse

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, via Mecha Recipe List.
  • probability (0.9) - dropout rate. Each delta value is kept with probability 1 − probability, so 0.9 means ~90% are dropped. Higher = more aggressive pruning.
  • rescale (True) - divide the result by 1 − probability so 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.

Categorymecha

Inputs (14)

NameTypeDefaultDescription
deltas (delta)optMECHA_RECIPE_LIST
apply_median (False)optMECHA_RECIPEfalse
apply_stock (False)optMECHA_RECIPEfalse
cos_eps (1e-06)optMECHA_RECIPE0.000001
della_eps (0.0)optMECHA_RECIPE0
eps (1e-06)optMECHA_RECIPE0.000001
ftol (1e-20)optMECHA_RECIPE1e-20
k (0.2)optMECHA_RECIPE0.2
maxiter (100)optMECHA_RECIPE100
probability (0.9)optMECHA_RECIPE0.9
rescale (True)optMECHA_RECIPEtrue
seed (None)optMECHA_RECIPE
vote_sgn (False)optMECHA_RECIPEfalse
merge_checkpointingoptBOOLEANfalseSpeeds 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)

NameTypeDescription
recipeMECHA_RECIPE