Flux LoRA Merger
Bake your Flux LoRAs together — before you ever hit the sampler
- unet_model
- model
- merge_report
So you've got the Flux problem everyone has: your good character LoRA lives in one file, your style is in another, and your favorite lighting one is a third. Every workflow means stacking three Lora Loaders, fighting with weights, and re-downloading them for every new graph. Flux LoRA Merger is the "just merge them into one" answer - it takes up to four Flux.1-Dev LoRAs, fuses them into a single UNet inside the graph, and optionally saves the result as a .safetensors you can treat like one model forever after.
Nothing about this calls out to a server, by the way. It's a local weight-math node: you feed it a base UNet and some LoRA files, and it hands you a merged MODEL. No key, no API, no new model downloads - it works with whatever is already sitting in your ComfyUI/models/loras folder, and it's happy with UNet checkpoints in FP8, FP16, or FP32.
How it actually merges
Under the hood it leans on ComfyUI's own comfy.sd.load_lora_for_models, the same patching machinery a normal Lora Loader uses, and then the three merge_strategy choices are what they sound like:
sequential- applies each LoRA on top of the last, one after another. The author's recommended default, and the friendliest to VRAM because it never rebuilds the whole weight tensor at once.additive- computes each LoRA's delta from the base UNet, sums those deltas (scaled by eachloraX_weight), and writes the total back into the base weights.average- the same delta math, but divided by the number of active LoRAs.
One thing worth knowing before you get excited about average: this is weight-space merging, the blunt instrument. The community's lesson from the checkpoint era applies here - averaging two strong but incompatible models tends to give you one that's weaker at both. If your LoRAs are on completely different jobs, sequential almost always behaves better.
There's also a real detail buried in the code: only keys starting with lora_unet get applied. Any text-encoder or other keys are counted and reported as "ignored" rather than silently dropped - which for Flux is usually a non-issue, since most Flux LoRAs are UNet-only anyway. You'll see the tally in the merge_report output.
The inputs that matter
The four LoRA slots are the whole story, so here's the short list:
enable_lora1–enable_lora4(booleans) - a per-slot on/off switch. Nice when you want one workflow that can do a 1-LoRA or 4-LoRA run without rewiring.lora1–lora4- pick the file by name from yourloras/folder.lora1_weight–lora4_weight- the strength multiplier, default 1.0.
Plus unet_model (the base Flux UNet), merge_strategy, and save_model / save_filename for the optional export. The outputs are model - the merged UNet, ready to wire into your sampler - and merge_report, a STRING that spells out how many UNet vs. ignored keys each LoRA contributed, which is genuinely useful when a merge comes out wrong.
Installing it
Through ComfyUI Manager, search for Flux LoRA Merger and hit Install. Or do it by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/tritant/ComfyUI_Flux_Lora_Merger
Then restart ComfyUI. There are no extra Python dependencies and nothing to download - it only uses things ComfyUI already ships (including safetensors), so it's about as low-friction as custom nodes get.
Where people get burned
- OOM when saving. The README's warning is the main real-world gotcha: if saving the merged
.safetensorsblows up VRAM, switch tosequential. It avoids the full weight rebuild thatadditive/averagedo. - Permanence. Baking is a one-way door. Once you merge, the individual
loraX_weightdials are gone - you can't turn the style down at inference time. If you only want them used together per-run, don't merge; stack them with a Power Lora Loader instead. Merge when you want one distributable file or a self-contained checkpoint. - The license follows the base. Flux Dev LoRAs are non-commercial, and a merged model inherits that - don't assume merging launders it.
It's a niche tool, honestly. Most people never need their LoRAs fused. But if you have a fixed combo you're sick of re-adding to every workflow, or you want to ship one file instead of four, this is the node that makes it a two-minute job.
Inputs (16)
| Name | Type | Default | Description |
|---|---|---|---|
| unet_model | MODEL | — | |
| merge_strategy | COMBO | 3 options: sequential, additive, average | |
| enable_lora1 | BOOLEAN | false | — |
| lora1 | COMBO | 0 options: | |
| lora1_weight | FLOAT | 1.00 | — |
| enable_lora2 | BOOLEAN | false | — |
| lora2 | COMBO | 0 options: | |
| lora2_weight | FLOAT | 1.00 | — |
| enable_lora3 | BOOLEAN | false | — |
| lora3 | COMBO | 0 options: | |
| lora3_weight | FLOAT | 1.00 | — |
| enable_lora4 | BOOLEAN | false | — |
| lora4 | COMBO | 0 options: | |
| lora4_weight | FLOAT | 1.00 | — |
| save_model | BOOLEAN | false | — |
| save_filename | STRING | flux_lora_merged.safetensors | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| merge_report | STRING | — |