LoRA Merge To Model
Bake up to 8 LoRAs permanently into a checkpoint
- output_path
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.
Inputs (24)
| Name | Type | Default | Description |
|---|---|---|---|
| base_model | COMBO | Base model the LoRAs were trained on | |
| lora_count | COMBO | 2 | Number of LoRAs to merge |
| lora_1 | COMBO | First LoRA | |
| weight_1 | FLOAT | 1.00-10–10 | Weight strength for LoRA 1 |
| lora_2 | COMBO | None | Second LoRA |
| weight_2 | FLOAT | 1.00-10–10 | Weight strength for LoRA 2 |
| lora_3 | COMBO | None | Third LoRA |
| weight_3 | FLOAT | 1.00-10–10 | Weight strength for LoRA 3 |
| lora_4 | COMBO | None | Fourth LoRA |
| weight_4 | FLOAT | 1.00-10–10 | Weight strength for LoRA 4 |
| lora_5 | COMBO | None | Fifth LoRA |
| weight_5 | FLOAT | 1.00-10–10 | Weight strength for LoRA 5 |
| lora_6 | COMBO | None | Sixth LoRA |
| weight_6 | FLOAT | 1.00-10–10 | Weight strength for LoRA 6 |
| lora_7 | COMBO | None | Seventh LoRA |
| weight_7 | FLOAT | 1.00-10–10 | Weight strength for LoRA 7 |
| lora_8 | COMBO | None | Eighth LoRA |
| weight_8 | FLOAT | 1.00-10–10 | Weight strength for LoRA 8 |
| skip_patterns | STRING | Regex patterns for layers to skip | |
| output_filename | STRING | merged_model | — |
| save_dtype | COMBO | fp16 | 3 options: fp16, bf16, fp32 |
| device | COMBO | cuda | 2 options: cuda, cpu |
| lazy_load | BOOLEAN | true | Low memory mode: load tensors from disk on demand |
| force_clear_cache | BOOLEAN | false | Clear CUDA cache after each layer (slower but saves VRAM) |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output_path | STRING | — |