Merge LoRA Models(merge)

If you've ever kept an old A1111 install around for one plugin, it was probably SuperMerger - the KB's own notes call it the single extension people cite for keeping a legacy WebUI setup. This node is that feature, rebuilt for ComfyUI: merge up to four LoRAs into one, in the graph, with no base model sitting in your VRAM and no dependence on the order you plug them in.

Why merge at all when you can just stack LoRAs? Stacking is per-generation - you need all the files, all the memory, and every sampler run pays for patching each one. Merging bakes several LoRAs into a single file you can load once, share, or run at one clean strength. The community reaches for the offline kohya merge_lora.py for the permanent version of this; this node is the "merge on the fly, right in the workflow" version.

How the merge works

The math is the interesting part, and it's why the node can claim order-independence. For every module (layer) it reads the LoRA's alpha - from explicit .alpha keys, or falling back to the lora_down dimension - then averages the alphas across all input LoRAs to get a base value. Each LoRA's contribution per module is scaled by √(alpha_i / base_alpha) × weight. That per-module normalization is what stops one big-alpha LoRA from bulldozing the others, and because the scaling is symmetric, A+B at equal weights gives the same result as B+A.

A few details worth knowing: LoRAs with weight exactly 0 are dropped entirely, and negative weights behave the SuperMerger way (the lora_up tensor stays positive so you can do subtractive "remove this style" merges). You're not limited to two either - model3 and model4 are optional slots, so 3- and 4-way merges work.

The inputs that matter

• model1 / model2 + weight1 / weight2 (default 1) - the two required LoRAs and their ratios.
• model3 / model4 (optional) with weight3 / weight4 (default 0).
• force_same_strength - set yes and each weight becomes √weight, matching SuperMerger's "Strength" mode for equal-impact merging.
• save_dtype - fp16 (default), float, or bf16. fp16 is fine unless you're chasing the last bit of precision.

Here's the gotcha nobody warns you about: allow_overwrite and reset_dim are in the UI but the shipped code never touches them. Open the source and they're accepted as parameters, then ignored - dead switches. Don't set reset_dim expecting a rank change, because nothing will happen in this version.

Output is merged_model - and like its loader sibling, it's a raw state dict wearing a MODEL label. It goes into this pack's SaveLoRAModels, not into a sampler.

Wiring and installing

Feed it the raw state dicts from OnlyLoadLoRAsModel - not models from a CheckpointLoader. The inputs are typed MODEL but actually expect the raw dicts that loader produces; wiring a real applied model in errors the moment the merge tries to index it. That's the number one reason this node fails on first use.

cd ComfyUI/custom_nodes
git clone https://github.com/LingSss9/comfyui-merge

Restart, or use ComfyUI Manager. No model downloads, no heavy deps.

If the result is broken

The classic community symptom with ComfyUI LoRA mergers is a ~1 KB .safetensors coming out the other end - that's an effectively empty merge, almost always because the inputs weren't the state dicts the node expects, or every weight ended up 0 (model3/model4 default to 0 and are dropped). Check the wiring first, then the weights. And remember the LoRA architecture rule from the troubleshooting checklist: merging only makes sense within one family - an SDXL LoRA and an Illustrious LoRA in the same merge is asking for garbage, since cross-compatibility between those is already unreliable.