Lodestone Merge LoRAs (3)

Three LoRAs is where naive stacking really starts to fall apart. Character plus style plus a lighting/atmosphere LoRA, all fighting over the same attention layers at partial strengths, gives you unpredictable mush - and three LoRA passes per render. Lodestone Merge LoRAs (3) is the fixed three-slot version of the pack's Lodestone merger: it expands each LoRA into its full per-layer weight change, combines the dense deltas with the norm-aware method you pick, and writes a single merged .safetensors to your loras folder.

Everything that makes the two-input sibling worth using applies here, just with a third equal-strength contributor. The mechanism is the real selling point: instead of averaging the compressed low-rank factors the way most merge tools do, each LoRA is expanded to its actual effect on the weights (up @ down, with alpha normalized out first) and those are merged. Three overlapping LoRAs get combined on the level where their overlap actually lives, then saved as a canonical full-difference .diff LoRA.

The inputs that matter

• lora_1, lora_2, lora_3 - dropdowns of your loras folder. lora_1 is the anchor: it supplies metadata and defines the output layer set.
• calc_mode (default sum) - with three inputs, the norm-aware choices get more interesting. mean gives each contributor equal weight; slotnorm first scales every input's delta to the median Frobenius magnitude, so a shouty LoRA stops drowning out its quieter siblings; normmatch preserves the summed direction but rescales the result back to a typical magnitude so a three-way sum doesn't blow past intended strength. slotnorm-normmatch stacks both. When three LoRAs don't naturally sit at the same strength, that pairing is usually the first thing worth trying after plain sum.
• mismatch_mode (default skip) - layer coverage gets patchier with three files trained independently. skip keeps LoRA 1's layer, zeros counts a missing input as zero change, error stops the merge rather than produce a file with guessed layers.
• output_filename - name of the new file, no extension needed.
• save_dtype (default bf16) and process_device (default cuda) - saved precision and where the per-layer expansion runs. A VRAM-hungry layer automatically retries on CPU.

Output is a single output_filename value - the node is terminal and makes files, not model patches.

Straightforward use

Wire three LoRAs in, pick calc_mode, name the output, queue once. It processes a layer at a time and only replaces the destination file after a fully successful write, so a failed merge never clobbers an existing LoRA of the same name. The saved file's metadata records merge_method: lodestone:<mode> - genuinely useful when you return to a folder of merged LoRAs weeks later.

Watch the same traps as the two-input version: canonical factor-pair LoRAs only (DoRA-scale or quantized/low-bit LoRAs raise rather than merge), matching layer keys, and unique output names unless you intend to overwrite. There's no reason to hand-pick between this and the 2-input node beyond how many LoRAs you're merging - if the answer is occasionally four or more, the Lodestone LoRA Multi-Merge variant stretches to eight with a lora_count selector.

Installing it

Same pack, same steps as its siblings. ComfyUI Manager: search Model Utility Toolkit. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-ModelUtils

Restart ComfyUI. No keys, no downloads - it reads only the LoRAs already in models/loras. Find it under ModelUtils → LoRA → Merge → Lodestone, or search "Lodestone". One honest note: like the rest of this merge family, these are fresh, low-footprint nodes from an author with a solid track record (same person behind ComfyUI_SamplingUtils) but little community battle-testing yet - treat an unusual result as worth double-checking against a plain two-or-three-LoRA stack before you trust the merged file.