Nodes/Mecha Merge Node Pack/Ties Sum Extended
ComfyUI Node

Ties Sum Extended

The full version with geometric median, model stock, and every knob

By ljleb·Created 2 years ago·Updated 30 days ago· 101
Ties Sum Extended
  • models (delta)
  • apply_median (False)
  • apply_stock (False)
  • cos_eps (1e-06)
  • eps (1e-06)
  • ftol (1e-20)
  • k (0.2)
  • maxiter (100)
  • vote_sgn (False)
  • recipe
merge_checkpointingfalse

Ties Sum Extended is what you graduate to after the plain Ties Sum starts feeling limiting. Same core: trim each delta, majority-vote the sign, keep the agreement. But this node exposes the newer machinery from the TIES/mergekit lineage - geometric median aggregation, model-stock rescaling, and a wall of tolerances - so you can tune how the surviving deltas get combined instead of taking the plain average.

Inputs:

  • models (delta) - the list of deltas to merge (via Mecha Recipe List).
  • k (0.2) - trim fraction, top-magnitude values kept. 0.2 is the classic TIES setting; here it's the default rather than the afterthought.
  • vote_sgn (False) - majority vote on sign only.
  • apply_median (False) - if on, aggregate the surviving deltas with a geometric median instead of a mean. More robust to outliers, slower.
  • apply_stock (False) - if on, apply model-stock (mergekit-style) magnitude rescaling instead of the plain t/param_counts normalization.
  • cos_eps (1e-06) - cosine tolerance used by the stock rescaling.
  • eps (1e-06), maxiter (100), ftol (1e-20) - convergence controls for the geometric median solver.

Output is a MECHA_RECIPE in delta space. Add it back to a base via Add Difference to get a model.

Why you'd reach for it

When your TIES merges keep getting dragged by one outlier LoRA. apply_median is the headline feature - the geometric median isn't pulled toward extreme values the way a mean is, which matters when you're merging a stack of LoRAs where one is wildly stronger than the rest. The apply_stock toggle is for people porting recipes over from mergekit who want matching rescaling behavior.

How it works

Trim and sign-vote exactly like plain TIES, then the difference: instead of sum / count, the survivors go through either a geometric-median optimization (an iterative solver governed by eps/maxiter/ftol) or model-stock scaling (which needs cos_eps). Everything streams per tensor key, so it's still memory-cheap even though the median solver is the slowest part of the pack's TIES family.

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

Don't turn on apply_median and apply_stock together out of curiosity - they're two different answers to the same problem (how to combine the survivors), and using both means apply_stock is ignored. And remember the defaults matter: this node's k is 0.2, unlike plain Ties Sum's 1.0, so the two nodes genuinely do different things out of the box. Output is a delta; add it back to a base, or the merge goes nowhere. merge_checkpointing works like the rest of the pack - fp16 CPU caching for stable branches, don't stack with cache units.

Categorymecha

Inputs (10)

NameTypeDefaultDescription
models (delta)optMECHA_RECIPE_LIST
apply_median (False)optMECHA_RECIPEfalse
apply_stock (False)optMECHA_RECIPEfalse
cos_eps (1e-06)optMECHA_RECIPE0.000001
eps (1e-06)optMECHA_RECIPE0.000001
ftol (1e-20)optMECHA_RECIPE1e-20
k (0.2)optMECHA_RECIPE0.2
maxiter (100)optMECHA_RECIPE100
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