Nodes/Model Utility Toolkit/LoRA Merge To Model
ComfyUI Node

LoRA Merge To Model

Bake up to 8 LoRAs permanently into a checkpoint

By silveroxides·Created about a year ago·Updated 4 days ago· 14
LoRA Merge To Model
    • output_path
    base_model
    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
    skip_patterns
    output_filenamemerged_model
    save_dtypefp16
    devicecuda
    lazy_loadtrue
    force_clear_cachefalse

    This one doesn't merge LoRAs with each other - it merges LoRAs into a base model, permanently. The node's own description is unambiguous: "Merge 1-8 LoRAs into a base model and save the result. Saves to base model directory." Instead of loading a checkpoint and a LoRA loader every time you generate, you run this once and get back a checkpoint that already has the LoRA's effect baked into its weights. No LoRA loader node needed downstream, no strength slider at inference time - whatever weight you set here is locked in.

    Why you'd actually do this

    The obvious use case is distribution and convenience: if you always run a checkpoint with the same one or two LoRAs at the same strength, baking them in once means every future workflow is simpler and every future generation is a touch faster (no LoRA patching step at runtime). It's also how people used to hand out "pre-mixed" checkpoints before LoRA loaders were universal - this node just does it cleanly and locally instead of you hand-rolling the math.

    The tradeoff is the one you'd expect: it's permanent (per output file), and unlike a LoRA loader you lose the ability to dial strength per-generation without redoing the merge. If you're still experimenting with weights, use a normal LoRA loader in your workflow until you've settled on numbers you're happy with, then bake them in with this node for the final version.

    The inputs and outputs that matter

    base_model is the checkpoint the LoRAs were trained on - the tooltip says so directly, and it matters: this isn't a place to try mixing a LoRA into an unrelated architecture. lora_count (default "2") sets how many of the eight lora_N slots are active; only lora_1 is required, lora_2 through lora_8 default to None. Each slot has its own weight_N (default 1, range −10 to 10) with a tooltip naming exactly what it is - "Weight strength for LoRA N" - so cranking a single LoRA past 1 pushes its effect harder than it was trained at, same as any LoRA strength slider.

    skip_patterns is a multiline regex field for excluding specific layers from the merge - useful if one of your LoRAs touches something you specifically don't want baked in. output_filename (default merged_model), save_dtype (default fp16), and device (default cuda) round out the save settings. lazy_load (default on) streams tensors from disk instead of holding the full base model and all active LoRAs in memory at once; force_clear_cache (default off here, unlike most of this pack's other nodes) trades speed for VRAM headroom if you flip it on. Output is a single output_path string, and this is a save node (is_output_node: true) - running it writes the merged checkpoint to your base-model directory.

    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 extra downloads - this operates on a base model and LoRAs you already have.

    Where people get burned

    Architecture mismatch is absolute and non-negotiable here, more so than with a runtime LoRA loader (which will usually just fail loudly if you try to apply a LoRA to the wrong model): merging a LoRA into a base model it wasn't trained against doesn't produce a smaller, gentler version of the effect, it produces garbage baked permanently into a multi-gigabyte file. Double-check base_model matches what every lora_N was actually trained on before you run this.

    The other real trap is disk usage creeping up on you - every run of this node writes a brand-new full checkpoint file, and it's easy to accumulate several gigabytes of "merged_model_v2_final_actually_final" variants in your base-model directory if you're iterating on weights. Keep output_filename deliberate, and clean up the ones you don't need; nothing in the node does that for you.

    CategoryModelUtils/LoRA/Merge

    Inputs (24)

    NameTypeDefaultDescription
    base_modelCOMBOBase model the LoRAs were trained on
    lora_countCOMBO2Number of LoRAs to merge
    lora_1COMBOFirst LoRA
    weight_1FLOAT1.00-10–10Weight strength for LoRA 1
    lora_2COMBONoneSecond LoRA
    weight_2FLOAT1.00-10–10Weight strength for LoRA 2
    lora_3COMBONoneThird LoRA
    weight_3FLOAT1.00-10–10Weight strength for LoRA 3
    lora_4COMBONoneFourth LoRA
    weight_4FLOAT1.00-10–10Weight strength for LoRA 4
    lora_5COMBONoneFifth LoRA
    weight_5FLOAT1.00-10–10Weight strength for LoRA 5
    lora_6COMBONoneSixth LoRA
    weight_6FLOAT1.00-10–10Weight strength for LoRA 6
    lora_7COMBONoneSeventh LoRA
    weight_7FLOAT1.00-10–10Weight strength for LoRA 7
    lora_8COMBONoneEighth LoRA
    weight_8FLOAT1.00-10–10Weight strength for LoRA 8
    skip_patternsSTRINGRegex patterns for layers to skip
    output_filenameSTRINGmerged_model
    save_dtypeCOMBOfp163 options: fp16, bf16, fp32
    deviceCOMBOcuda2 options: cuda, cpu
    lazy_loadBOOLEANtrueLow memory mode: load tensors from disk on demand
    force_clear_cacheBOOLEANfalseClear CUDA cache after each layer (slower but saves VRAM)

    Outputs (1)

    NameTypeDescription
    output_pathSTRING