Rebasin
Align models by permuting their weights
- a (delta|param|weight)
- ref (delta|param|weight)
- iters (10)
- recipe
Rebasin (class Rebasin Mecha Recipe) is the node that implements the famous "Git Re-Basin" idea - the 2022 paper that showed separately trained neural networks often contain the same knowledge, just with their weights permuted in different orders. If you find the permutation that maps model A's weight arrangement onto model B's, the two models "fall into the same basin" of the loss landscape and merge far better than naive averaging.
In practice, that means: give this node two SDXL models, and it returns a permuted copy of the first that's aligned with the second, so that subsequent merging treats two models as if they were trained in the same arrangement. It's the closest thing the pack has to a "magic alignment" button, and it's the reason some multi-model merges work at all.
How it works
sd-mecha builds a permutation graph from the architecture: attention heads (q/k and v/o pairs must move together), feed-forward widths (rows of the up-projection move with columns of the down-projection), and so on. Rebasin then solves, for each permutation group, the assignment problem of how to reorder model A's weights to best match model B's - using the Hungarian algorithm (scipy's linear_sum_assignment) on the similarity between the two models' weights. Because the groups interact, it iterates: re-solve each group against the current best alignment until nothing changes or you hit the iteration cap.
The inputs that matter:
- a (
MECHA_RECIPE, required) - the model that gets permuted/aligned. - ref (
MECHA_RECIPE, required) - the reference model to align against. - iters (10) - how many passes of the alternating solve to run. More iterations = better convergence, slower execution. Default 10 is the sane starting point; crank it up if alignment looks incomplete.
- recipe (output) - model
a, permuted to align withref.
The expected flow: rebasin-align your fine-tunes to a reference, then average or TIES-merge the aligned models. The alignment is what makes averaging not destroy each model's individual strengths.
Install
This ships in the Mecha Merge Node Pack (ljleb/comfy-mecha):
- ComfyUI Manager → Install Custom Nodes → search "mecha" → Mecha Merge Node Pack, or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt
Restart ComfyUI; the node is under mecha. The pack's only dependency is sd-mecha==1.1.7 (which pulls in scipy for the Hungarian solver). No model downloads.
Common issues
- SDXL-only in the built-in. Like
Randperm, the permutation graph is defined for the SDXL-SGM config. If you feed it SD1, the config guard will stop you. That's the current state of the built-in, not a misconfiguration. - It's slow, and
itersscales it. Alignment runs a full assignment solve per group per iteration, across the whole model. If a run feels interminable, dropitersto 5 and see if the result still holds; only raise it when quality demands. - Align, then merge - in that order. Rebasin's output is an aligned copy of
a, not a finished merge. Feed the aligned models intoN AverageorAdd Difference Ties, then merge. Rebasinning the final result does nothing for you. - Memory is actually fine. Thanks to sd-mecha's key-by-key streaming, alignment doesn't need both full models resident at once - one of the pack's genuine strengths over naive implementations.
Rebasin is the "trust the science" node. It's expensive, it's SDXL-scoped, and it occasionally underwhelms on models that were already trained similarly - but when you're merging genuinely different checkpoints, the alignment it provides can be the difference between a muddy average and a merge that keeps both parents' strengths.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| a (delta|param|weight) | MECHA_RECIPE | — | |
| ref (delta|param|weight) | MECHA_RECIPE | — | |
| iters (10)opt | MECHA_RECIPE | 10 | — |
| 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 | — |