LoRA Multi-Merge
Combine up to 8 LoRAs into one file, ranks and naming resolved
- output_path
This is the LoRA-aware sibling of LoRATwoMerger/LoRAThreeMerger, and if you're combining trained LoRAs on purpose - not blending two arbitrary weight sets - this is the node you actually want. The node's own description says it plainly: it takes 1–8 LoRAs and merges them into a single LoRA file, and it specifically "resolves different ranks and naming conventions." That's the whole reason it exists. Two LoRAs from different trainers rarely agree on rank or on what to call their tensors internally, and a naive merge either errors out or quietly ignores half the mismatched layers. This node is built to not do that.
How it works
Up to eight slots - lora_1 through lora_8 - each with its own weight_N (default 1, range −10 to 10). Only lora_1 is required; the rest default to None, so a two-LoRA merge just means leaving slots 3–8 empty. lora_count (default "2") tells the node how many of those slots are actually in play.
base_model is the interesting field, and its tooltip spells out exactly what it's for: "Optional reference model to resolve key naming issues across formats. If None, input keys are preserved verbatim." In plain terms - if your LoRAs came from different trainers that named their tensors slightly differently (a real, common problem when you're combining, say, a Kohya-trained LoRA with one from a different toolchain), pointing base_model at the checkpoint they were all trained against lets the node use that model's own key names as the reference and reconcile the mismatches. Skip it and the node trusts your input files' key names as-is.
merge_mode is the other field worth reading closely, because the tooltip lays out a real tradeoff rather than hiding it: concatenate is "safe, increases rank" - it stacks the LoRAs' low-rank matrices together rather than blending them, so nothing is lost, but your output file gets bigger (and technically higher-rank) than any single input. weighted_sum is "fixed rank (to max input rank), mathematically lossy but standard in Kohya" - it reconstructs the combined effect at a fixed rank instead of growing it, which keeps the file size sane but is a lossier operation, in the same spirit as how Kohya's own LoRA tooling handles multi-LoRA merges. If file size doesn't matter and you want to be conservative, use concatenate. If you want a portable, standard-sized result and can accept some loss, use weighted_sum.
Round it out with output_filename (default merged_lora), save_dtype (default fp16), and device (default cuda, presumably falls back to CPU if you pick it - slower, but works without VRAM headroom). Output is a single output_path string, and this is a save node (is_output_node: true) - running it writes the merged file to disk.
Installing it
ComfyUI Manager: search Model Utility Toolkit, install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-ModelUtils
Restart ComfyUI. No model downloads - the LoRA extraction and merge tooling in this pack draws its approach from kohya-ss/sd-scripts and KohakuBlueleaf's LyCORIS (credited in the README), but doesn't need either installed separately.
Where people get burned
The default weight of 1 on every slot means an unweighted eight-LoRA merge stacks everything at full strength - that's rarely what you want, and it's the fastest way to get a muddy, overcooked result even before you consider rank issues. Set weights deliberately, especially past two or three LoRAs; the community's general finding on stacking multiple LoRAs is that balance matters more than the count, and cranking every slot to 1 is the mistake people make first.
If your merged LoRA behaves oddly at inference - barely visible, or one source clearly dominating regardless of its weight - check whether you actually needed base_model set. Two LoRAs with genuinely different internal naming, merged without a reference model to reconcile them, can silently merge the wrong tensors against each other rather than erroring. And if the output file is much larger than expected, that's concatenate doing exactly what its tooltip says; switch to weighted_sum if you wanted a fixed-rank result instead.
Inputs (22)
| Name | Type | Default | Description |
|---|---|---|---|
| base_model | COMBO | None | Optional reference model to resolve key naming issues across formats. If None, input keys are preserved verbatim. |
| lora_count | COMBO | 2 | Number of LoRAs to merge |
| lora_1 | COMBO | First LoRA | |
| weight_1 | FLOAT | 1.00-10–10 | — |
| lora_2 | COMBO | None | 1 options: None |
| weight_2 | FLOAT | 1.00-10–10 | — |
| lora_3 | COMBO | None | 1 options: None |
| weight_3 | FLOAT | 1.00-10–10 | — |
| lora_4 | COMBO | None | 1 options: None |
| weight_4 | FLOAT | 1.00-10–10 | — |
| lora_5 | COMBO | None | 1 options: None |
| weight_5 | FLOAT | 1.00-10–10 | — |
| lora_6 | COMBO | None | 1 options: None |
| weight_6 | FLOAT | 1.00-10–10 | — |
| lora_7 | COMBO | None | 1 options: None |
| weight_7 | FLOAT | 1.00-10–10 | — |
| lora_8 | COMBO | None | 1 options: None |
| weight_8 | FLOAT | 1.00-10–10 | — |
| merge_mode | COMBO | concatenate | concatenate: safe, increases rank. weighted_sum: fixed rank (to max input rank), mathematically lossy but standard in Kohya. |
| output_filename | STRING | merged_lora | — |
| save_dtype | COMBO | fp16 | 3 options: fp16, bf16, fp32 |
| device | COMBO | cuda | 2 options: cuda, cpu |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output_path | STRING | — |