Power LoRA Merger

If you've ever chained four LoraLoader nodes to combine a character LoRA with a style LoRA and a couple of detail-boost LoRAs, you already know the annoyance: every run reloads and reapplies all four, and sharing the workflow means sharing four separate files. WAS Power LoRA Merger merges them once into a single .safetensors you can drop into models/loras and load normally from then on - with a choice of real merge strategies, not just a naive average.

The "Power" in the name isn't an accident - it's the same convention rgthree uses for its Power Lora Loader, and it means the same thing here: the LoRA files you're actually merging aren't separate graph inputs. You add them through the node's own on-node UI. If you're staring at this node hunting for lora_1/lora_2 sockets to wire up, that's why you won't find them.

How it works

You pick a mode, optionally tune it further with a WAS Power LoRA Merger Options node (its own article - plug it into the optional options input), and the merger writes the result to models/loras. If you also wire in a model and clip, it applies the freshly-merged LoRA to them immediately, so the merge and the apply happen in one run instead of needing a separate LoraLoader afterward.

The modes, per the node's own tooltip:

• svd (default) - recompress the merged delta via SVD. The general-purpose choice.
• rebase - SVD-recompress a single LoRA on its own.
• add - exact linear stacking, no compression.
• add-diff - start from a base LoRA and add weighted diffs toward the others.
• add-orth - same idea, but orthogonalizes the contributions so they don't cancel each other out.
• diff-export - exports only the difference between the first two, useful for extracting what one LoRA added on top of another.
• moe - routes each module through a mixture-of-experts gate across your source LoRAs.
• obfuscate - a stack-equivalent factor rebasis that skips SVD.
• block-mix - routes specific modules to LoRA A or B by a block_mix_recipe, then merges via stack or SVD.

SVD-based LoRA merging isn't new - Kohya's GUI has shipped a "Merge LoRA (SVD)" option for a while, valued because it copes better with mismatched ranks and architectures than a straight stack. This node brings that idea, plus several other strategies, natively into ComfyUI.

block_mix_recipe only matters in block-mix mode: the default concept_a_style_b keeps concept/attention blocks from LoRA A and style/feed-forward blocks from B, with mirror-image and image/text-stream variants for different architectures.

The inputs and outputs that matter

• mode / block_mix_recipe - the strategy, as above.
• output_filename (default merged_lora.safetensors) - relative to models/loras; .safetensors gets appended if you leave it off.
• output_model_strength / output_clip_strength (default 1) - only relevant if you wired in model/clip; how hard the new LoRA gets applied to those pass-throughs.
• Optional model / clip - apply the merge result to these immediately.
• Optional options - a WAS_LORA_MERGE_OPTIONS from the companion Options node.

Outputs: model, clip (pass-through, patched if you wired inputs in), and lora_path (STRING) - where it landed, worth routing into a text/preview node to confirm the merge succeeded before you go hunting through models/loras.

How to install it

Via ComfyUI Manager: search WAS_Extras, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/WAS_Extras

Restart ComfyUI. No extra dependencies for this node specifically.

Common issues & troubleshooting

Merged result barely resembles either source LoRA. SVD-family modes are lossy compression by nature - a low rank or an aggressive auto_rank_threshold on the Options node throws away real signal. Raise the rank before assuming the algorithm is broken.

Picked moe or block-mix and it made things worse. Those modes are aimed at combining LoRAs that specialize in genuinely different things - identity from one, style from another. For merging near-duplicate training runs of the same subject, add or the default svd is the saner starting point.

Strength sliders don't seem to do anything. output_model_strength/output_clip_strength only matter if model/clip are actually wired in. If you're just here to bake a .safetensors and load it later with a normal LoraLoader, leave those inputs disconnected and ignore the sliders.