LoRA Merge (Knobs)

Merging LoRAs is usually a messy business - most recipes amount to "apply both at once and hope," which stacks whole LoRAs whether you want them stacked or not. LoRA Merge (Knobs) from ComfyUI-RecipeMerge does it properly: it merges two LoRA files into one new LoRA, with a knob for every block×element deciding how much of LoRA #2 goes into that spot. And it needs no checkpoint at all - it's purely file-to-file, which makes it fast, VRAM-cheap, and reproducible.

The interface is the pack's synth-style matrix (the same panel from the merge/LoRA-matrix nodes), and here a knob is the share of lora2: 0 = that key is lora1's value, 1 = lora2's, 0.5 = half-and-half. A fresh node starts everything at 0, so it's lora1 until you deliberately blend something in. The text-encoder side can't be block-split, so it gets a single uniform control, te_ratio.

The workflow the author built for it

Two modes, and they're meant to be used in sequence.

Try it while generating. Connect model (and clip) and the merged result gets applied on the fly - no file is written. Fix your seed, turn a knob, Queue, look at the picture, repeat. This is the "iterate on the merge by looking at output" loop that used to mean exporting a file every attempt.

Commit it. When you're happy, flip save_file ON and run once - it writes merged_lora.safetensors to models/loras (auto-suffixed with a number if the name's taken), usable by any LoRA loader. The merge recipe is embedded in the file's metadata for reproducibility; a metadata editor can strip it if you don't want it distributed. The preview and the saved file use the same merge math, so what you previewed is what you get.

Pick a mode - if save_file is OFF and no model is connected, the node raises a "nothing to do" error rather than silently doing nothing. That's a feature.

How the merge actually works

The mechanism matters here because it's not the naive averaging that gives merged checkpoints their bad reputation. This uses concat: each LoRA is a low-rank pair ΔW ≈ down·up, and the merge builds a new pair by concatenating the two down/up matrices along the rank axis, scaled by (1-t) and t. The result is mathematically a weighted sum with zero degradation - you lose none of either LoRA's learned signal. The trade-off: the output rank is the sum of the two input ranks (a dim-32 + dim-64 LoRA becomes dim-96), so the file gets fatter. If that bothers you, kohya's resize_lora.py can SVD-compress the result back down afterwards.

Format support is where people hit walls. kohya-style key names (lora_unet_input_blocks_...) are native. Diffusers-style keys get auto-converted to kohya naming inside the node - the README still says they're rejected, but the shipped code converts them and reports the conversion count, so the code wins that argument. LoHa/LoKr/DoRA and convs with Tucker decompositions aren't supported and show up as a skip count in the report. Keys present in only one LoRA survive at that side's ratio - set the ratio to 0 and they're dropped entirely.

Inputs, outputs, install

lora1_name and lora2_name are the parents (both dropdowns from models/loras), plus matrix, te_ratio, filename, save_file, and optional model/clip for the test mode. Outputs: model, clip, and report - this node is flagged as an output node, and the report includes the save path plus per-key stats (paired / only-in-1 / only-in-2 / dropped / skipped / max dim). Read it once; it tells you whether the merge actually did what you thought.

Install is pack-standard and dependency-free (Manager search "ComfyUI-RecipeMerge", or git clone https://github.com/galigali-san/ComfyUI-RecipeMerge into custom_nodes, restart). UI labels are Japanese for now. And the usual caveat applies to the output: you're creating a derivative of two LoRAs, so check both source licenses before sharing the result - merged artifacts inherit their parents' terms. If your goal was per-key application rather than a saved file, that's the pack's LoRA Elemental Apply / LoRA Elemental Matrix nodes instead.