ComfyUI Node

PM TIES

TIES for stacking several LoRAs without the interference

By larsupb·Created 2 years ago·Updated 30 days ago· 75
PM TIES
    • MergeMethod
    rescale_normdefault
    average_weightsfalse
    density0.90

    You're merging three LoRAs and the result looks like nobody's - every adapter's edges got rounded off, nothing keeps its identity. That's parameter interference, and TIES is the specific fix for it. Short for "Task Arithmetic with Interference Elimination and Sign consensus," it's the node you graduate to once plain Task Arithmetic starts giving you mush.

    Here's the trick that makes it work. TIES starts from the same task vectors as Task Arithmetic (each LoRA's delta from the base model), then adds two steps that stop LoRAs from cancelling each other out:

    1. Sparsify. Each task vector is pruned down to its largest-magnitude deltas - by default, the top 90% (density = 0.9). Small noise edits get dropped, leaving each LoRA's signature changes.
    2. Sign consensus. For every weight position, the LoRAs vote on the sign of the change (positive or negative). Only the contributions that agree with the majority are kept. Conflicting edits - where one LoRA pushes a weight up and another pushes it down - cancel out instead of muddying the result.

    Then the surviving, sign-agreeing deltas get summed and added back to the base. The upshot: each LoRA keeps its strongest, most confident contributions, and the things they fight over just vanish. That's why TIES is the standard answer when someone says "merging 4 LoRAs ruined everything" - and it's the sign-consensus engine underneath the dare_ties variant too, so it's the same idea that powers other Mergekit recipes.

    The pack runs this on the LoRA deltas in "delta space" - its own generalized-task-arithmetic path that mirrors Mergekit's sparsify math in pure torch - then refactors the merged delta back into a real LoRA via randomized SVD (energy_rSVD by default, keeping 99% of the delta's energy). A nice grounded detail: the sparsify step runs on the GPU via a histogram instead of a full sort, so giant Flux layers don't OOM your VRAM the way the naive top-k path did.

    The inputs that matter

    • density - the fraction of weights retained per task vector, default 0.9. This is the one you'll actually fiddle with. Lower it (0.5–0.7) for more aggressive pruning, which handles larger merges but trims each LoRA's effect; keep it high when you only have two or three adapters and want them at full strength. The tooltip's phrasing is precise: "fraction of weights in differences from the base model to retain."
    • rescale_norm - same rescaling strategy as the pack's other GTA methods, default "default" (auto-select). Leave it alone until you're debugging weak or over-amplified merges.
    • normalize - normalizes the contributing weights per tensor (default true). Same as Task Arithmetic; the defaults are right for almost everyone.

    Output is a MergeMethod value - wire it into the method input of PM LoRA Merger (Mergekit). The chain is identical to the pack's other methods:

    PM LoRA Stacker → PM LoRA Stack Decompose → PM Ties (Mergekit)
       → PM LoRA Merger (Mergekit) → PM LoRA Apply (or PM LoRA Save)
    

    Installing

    TIES ships in larsupb/LoRA-Merger-ComfyUI ("LoRA Power-Merger ComfyUI"). ComfyUI Manager: search for "LoRA Power-Merger" and install, then restart. Or by hand:

    cd ComfyUI/custom_nodes
    git clone https://github.com/larsupb/LoRA-Merger-ComfyUI.git
    cd LoRA-Merger-ComfyUI
    pip install -r requirements.txt
    

    Restart ComfyUI after. The requirements install mergekit from GitHub (git+https://github.com/arcee-ai/mergekit.git) plus lxml - so a working git and network in your ComfyUI environment are required, and that's the install step people commonly trip on. It's a heavier pack than the average custom node, but TIES (and the DARE/Breadcrumbs family around it) are the reason it's worth the footprint.

    Where people get burned: dropping density too low "to be safe" and wondering why the merge got weak, or skipping the Decompose node entirely. Start at 0.9, merge, then sweep density down only if the result is still noisy. TIES won't give you perfect merges - nothing does - but for three-plus LoRAs that plain task arithmetic would turn to soup, it's the difference between a salvageable adapter and a delete. It's the node I reach for first when the stack grows past two.

    CategoryLoRA PowerMerge/Task Arithmetic

    Inputs (3)

    NameTypeDefaultDescription
    rescale_normCOMBOdefaultRescaling strategy: • default: Auto-select (L1 for methods needing it, none otherwise) • l1: L1 norm preservation (precise, preserves magnitude sum) • l2: L2 norm preservation (precise, preserves Euclidean norm) • linf: L-infinity norm (preserves max absolute value, prevents amplification) • none: No rescaling (may reduce merge strength)
    average_weightsBOOLEANfalseON: divide by the per-element sum of contributing weights — a weighted AVERAGE, so per-LoRA strengths act as ratios (two LoRAs at strength 1.0 each land at ~50%). OFF: additive SUM, so strengths act as gains and stacked LoRAs keep full magnitude (matches ComfyUI's native LoRA stacking, the default). Turn ON only to blend/interpolate LoRAs.
    densityFLOAT0.900–1Fraction of weights in differences from the base model to retain.

    Outputs (1)

    NameTypeDescription
    MergeMethodMergeMethod