Lora Simple Add
The no-frills way to add two same-rank LoRAs together
- loraA
- loraB
- combined_lora
Some tools are impressive because they're clever. Lora Simple Add is impressive because it refuses to be. It takes two LoRAs, adds their tensors together with a weight on each side, and returns a combined LoRA. That's the entire feature list, and for a big slice of real-world merging that's exactly right.
The one hard requirement: both LoRAs need the same rank, which means the matching tensors have identical shapes. When they do, every shared key becomes alpha_a * A + alpha_b * B, keys only one side has are carried along, and you get a combined_lora out the back. That's a plain weighted addition - no SVD, no rank alignment, no surprise math.
Where does same-rank merging actually come up? More than you'd think. If you train your own LoRAs, you usually train them all at the same rank on the same base - two rank-16 style LoRAs, say, or a character and a style you both trained at rank 32. Those merge cleanly here. Same-rank files from different trainers also merge fine as long as the key naming matches. This is also the node to reach for when you want the fast, cheap version of a merge and don't need Lora Add's rank-alignment machinery at all.
The four inputs are self-explanatory: loraA and loraB from Load LoRA Only, plus alpha_a and alpha_b - the multipliers for each side, both defaulting to 1.0. Negative values are allowed if you want to subtract one LoRA's contribution instead of adding it.
Where people get burned: feed it two different-rank LoRAs and it dies with a tensor shape error - no graceful fallback, no "use Lora Add instead" hint. That's the intended division of labor, so just remember: same ranks here, different ranks over in Lora Add. One subtle quirk worth knowing if you're doing weighted blending: keys that only exist in LoRA A are copied through at their original values and don't get scaled by alpha_a - only shared keys see the weight. For most merges that's invisible, but if you're doing aggressive mixing with low weights, you might notice one LoRA's unique layers punching through harder than the math suggests.
It's also worth being clear-eyed about what merging gets you. A merged file is convenient - one LoRA to load, one strength to tune, no stacking-order headaches - but it's not the same as stacking two LoRAs at runtime, and merging two good LoRAs does not reliably give you a good LoRA. Keep the originals, compare at a fixed seed, and treat the merge as a packaging step rather than a quality upgrade. The community has spent years arguing about whether merged LoRAs beat stacked ones; the honest answer is "it depends," which is why keeping the originals around is non-negotiable.
Installation is the same two-liner this whole pack uses, and it drags in no extra dependencies - torch and safetensors are already part of ComfyUI:
cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/Comfyui-LoraUtils
Restart ComfyUI and look under LoraUtils. ComfyUI Manager users can search Comfyui-LoraUtils instead. It's a small utility pack from lrzjason (a.k.a. xiaozhijason on Civitai) with a quiet community footprint - the code is straightforward, the edge cases are yours, and for a node this simple that's a fair trade.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| loraA | LORA | First LoRA to add (base LoRA). | |
| loraB | LORA | Second LoRA to add (will be added to base LoRA). | |
| alpha_a | FLOAT | 1.00-10–10 | Weight for LoRA A (multiplier for first LoRA). |
| alpha_b | FLOAT | 1.00-10–10 | Weight for LoRA B (multiplier for second LoRA). |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| combined_lora | LORA | — |