Top K Tensor Sum
Keep the important weights, graft in the other model's values
- a (delta|param|weight)
- b (delta|param|weight)
- width (1.0)
- offset (0.0)
- recipe
Top K Tensor Sum is the pickier cousin of Tensor Sum. Where Tensor Sum copies a contiguous window of B into A, this one decides which positions matter first: it finds the top-k magnitude values in A's tensor, then pulls B's values into exactly those positions, ranked to match. It's an "importance-weighted splice" - the big weights of A get replaced by B's corresponding values, the small weights stay put.
Inputs:
a (delta|param|weight)- the base tensor setb (delta|param|weight)- the values you graft inwidth (1.0)- the fraction of each tensor's positions that count as "top". 1.0 means all of them.offset (0.0)- shifts which band of magnitudes is selected
Output is a MECHA_RECIPE in the same space as the inputs, ready for Mecha Merger or further recipe math.
What it's actually for
It's a mechanism from the model-merging literature where you don't want an average - you want to transplant the "strong" weights. With width at 1.0 it degenerates toward copying everything from B; shrink it and you keep only B's values at A's most significant positions. In practice it's an experimental knife: people use it when a plain sum or blend keeps producing washed-out results and they want to force one model's salient weights into another. It's not the tool you reach for first, but it's the tool you reach for when the obvious ones fail.
How it works
Per tensor, the node sorts A's values by magnitude, computes the selection band from width/offset, and computes an index mask of which positions fall in it. Then it redistributes B's values by rank so that the selected positions in the output hold B's values ordered by magnitude, and unselected positions keep A's originals. It's heavier than Tensor Sum - it sorts and argsorts per key - but still streams one key at a time.
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
The naming similarity to Tensor Sum will trick you into swapping them; they're different algorithms with different defaults (width 1.0 here vs 0.5 there), so double-check which one you dragged in. And because selection is by magnitude, its effect depends a lot on how weight distributions differ between your two models - two checkpoints that look "similar" can behave very differently through this node. Keep width small and sample. The merge_checkpointing toggle behaves like the rest of the pack: fp16 CPU caching for stable branches, don't stack it with cache units.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| a (delta|param|weight) | MECHA_RECIPE | — | |
| b (delta|param|weight) | MECHA_RECIPE | — | |
| width (1.0)opt | MECHA_RECIPE | 1 | — |
| offset (0.0)opt | MECHA_RECIPE | 0 | — |
| 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 | — |