Combine LoRAs

The usual way to use two LoRAs is to stack them: LoraModelLoader, feed the model into a second LoraModelLoader, done. That's runtime stacking - every generation re-applies both adapters separately. Combine LoRAs does something different: it fuses two LoRA files into a single merged LoRA that you can load (or save to disk) as one unit. You'd reach for it when the blend is permanent - a character plus a style you always use together - or when you keep tweaking betas of the same LoRA and want one "meta" version instead of juggling four loader slots. Credit where it's due: the original concept was Snowshoes311's; this pack's enhancements (the merge methods, the compatibility checks) came from @sweetmax797, and LukeCoulson1 packaged it.

How it works

Pick two files from your loras folder and this node loads both with ComfyUI's own load_torch_file. Then it walks the union of tensor keys: for keys both LoRAs share it computes strength1 * lora1[key] + strength2 * lora2[key], and for keys only one LoRA has it just scales that one. That's the whole core, and it's honest about it - no API, no key, no secret sauce, just weighted tensor addition.

The merge_method dropdown is where it gets interesting:

• linear - the direct weighted addition above. Fastest, most literal, zero-pads any shape mismatch.
• concatenation - instead of adding, it stacks each LoRA's lora_down/lora_up (or lora_A/lora_B) matrices along the rank dimension, scaling by the square root of weight * alpha/rank. You end up with a higher-rank adapter that keeps both LoRAs' structure intact. If additive blending would cancel the two adapters out, this preserves them.
• weighted_average - normalizes your strengths so |s1| + |s2| sums to 1 before adding, which stops a 1.0 + 1.0 merge from doubling the effect.

There's also a check_compatibility toggle (on by default) that compares key sets, tries to detect the LoRA family (standard vs. PEFT vs. transformer-style), and checks dimensions on shared keys. If it smells like you're merging an SDXL LoRA into a Flux one, it raises a clear error instead of silently producing garbage.

The inputs that matter

• lora_name1 / lora_name2 - the two LoRA files from your loras folder.
• strength1 / strength2 - each runs -100.0 to 100.0, default 1.0. Negative strengths let you subtract a concept, which is a neat trick most people never try.
• merge_method and check_compatibility - covered above; linear + check on is the sane default.

Output: a single LORA_MODEL. Wire it into a LoraModelLoader to apply it right there in the graph, or into ComfyUI's core Save LoRA Weights node to write the merged file into your loras folder - after that it's just another LoRA you can load like any other.

Install

Two ways, both painless:

# ComfyUI Manager: search "ComfyUI LoRA Combine", install, restart.

# or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/LukeCoulson1/Comfyui_LoraCombine

Restart ComfyUI and it appears as "Combine LoRAs" under the loaders category. Dependencies are just safetensors and torch - you already have both if ComfyUI runs. No model downloads; it merges whatever's already sitting in your loras folder.

Where people get burned

• "LoRA compatibility check failed!" - almost always an architecture mismatch: an SDXL LoRA and a Flux LoRA have no business in the same file. LoRAs are architecture-bound; merge within one family, or uncheck the box and accept the consequences.
• The merged result overpowers the image. The pack's own example scripts warn about this: keep the sum of your strengths around 0.9–1.2. A 1.0 + 1.0 linear merge is effectively double-strength - drop the sliders, or switch to weighted_average.
• Concatenation quietly failing. If the concat merge hits a structure it can't reconcile, the node prints "Falling back to linear merge" and keeps going. If your merged file looks weak, that's what happened - check the console.

One more gotcha hidden in the code: the compatibility check and the fancy merge methods live in an info/ module that imports safetensors. If that import fails, the node silently degrades to plain linear merging. It's installed by requirements.txt, so this only bites you if you've stripped your Python env - but now you know what "everything is linear" means.