Nodes/Flux LoRA Merger/Flux LoRA Merger
ComfyUI Node

Flux LoRA Merger

Bake your Flux LoRAs together — before you ever hit the sampler

By tritant·Created about a year ago·Updated about a year ago· 3
Flux LoRA Merger
  • unet_model
  • model
  • merge_report
merge_strategy
enable_lora1false
lora1
lora1_weight1.00
enable_lora2false
lora2
lora2_weight1.00
enable_lora3false
lora3
lora3_weight1.00
enable_lora4false
lora4
lora4_weight1.00
save_modelfalse
save_filenameflux_lora_merged.safetensors

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 each loraX_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_lora1enable_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.
  • lora1lora4 - pick the file by name from your loras/ folder.
  • lora1_weightlora4_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 .safetensors blows up VRAM, switch to sequential. It avoids the full weight rebuild that additive/average do.
  • Permanence. Baking is a one-way door. Once you merge, the individual loraX_weight dials 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.

Categoryflux/dev

Inputs (16)

NameTypeDefaultDescription
unet_modelMODEL
merge_strategyCOMBO3 options: sequential, additive, average
enable_lora1BOOLEANfalse
lora1COMBO0 options:
lora1_weightFLOAT1.00
enable_lora2BOOLEANfalse
lora2COMBO0 options:
lora2_weightFLOAT1.00
enable_lora3BOOLEANfalse
lora3COMBO0 options:
lora3_weightFLOAT1.00
enable_lora4BOOLEANfalse
lora4COMBO0 options:
lora4_weightFLOAT1.00
save_modelBOOLEANfalse
save_filenameSTRINGflux_lora_merged.safetensors

Outputs (2)

NameTypeDescription
modelMODEL
merge_reportSTRING