Nodes/Model Utility Toolkit/LoRA Multi-Merge
ComfyUI Node

LoRA Multi-Merge

Combine up to 8 LoRAs into one file, ranks and naming resolved

By silveroxides·Created about a year ago·Updated 4 days ago· 14
LoRA Multi-Merge
    • output_path
    base_modelNone
    lora_count2
    lora_1
    weight_11.00
    lora_2None
    weight_21.00
    lora_3None
    weight_31.00
    lora_4None
    weight_41.00
    lora_5None
    weight_51.00
    lora_6None
    weight_61.00
    lora_7None
    weight_71.00
    lora_8None
    weight_81.00
    merge_modeconcatenate
    output_filenamemerged_lora
    save_dtypefp16
    devicecuda

    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.

    CategoryModelUtils/LoRA/Merge

    Inputs (22)

    NameTypeDefaultDescription
    base_modelCOMBONoneOptional reference model to resolve key naming issues across formats. If None, input keys are preserved verbatim.
    lora_countCOMBO2Number of LoRAs to merge
    lora_1COMBOFirst LoRA
    weight_1FLOAT1.00-10–10
    lora_2COMBONone1 options: None
    weight_2FLOAT1.00-10–10
    lora_3COMBONone1 options: None
    weight_3FLOAT1.00-10–10
    lora_4COMBONone1 options: None
    weight_4FLOAT1.00-10–10
    lora_5COMBONone1 options: None
    weight_5FLOAT1.00-10–10
    lora_6COMBONone1 options: None
    weight_6FLOAT1.00-10–10
    lora_7COMBONone1 options: None
    weight_7FLOAT1.00-10–10
    lora_8COMBONone1 options: None
    weight_8FLOAT1.00-10–10
    merge_modeCOMBOconcatenateconcatenate: safe, increases rank. weighted_sum: fixed rank (to max input rank), mathematically lossy but standard in Kohya.
    output_filenameSTRINGmerged_lora
    save_dtypeCOMBOfp163 options: fp16, bf16, fp32
    deviceCOMBOcuda2 options: cuda, cpu

    Outputs (1)

    NameTypeDescription
    output_pathSTRING