LoRA Merge 🍌

Stacking two LoRA loaders one after another is the normal way to combine effects, and it's fine most of the time. LoRA Merge does something different: it takes two LoRAs and produces a single new LoRA object that's the mathematical combination of both. That matters when you want the combined effect to behave like one adapter rather than two independently-applied ones - fewer moving parts downstream, and one thing to reuse instead of two.

How it fits the pack

This node is part of cgem156's lora_merger family, which splits "define a LoRA + its weight" from "apply it to a model" into separate nodes. LoraLoaderWeightOnly builds the LoRA object this node consumes; LoraLoaderFromWeight is what actually patches a model with it afterward. Think of Merge as sitting between those two steps: object in, object out.

Inputs and outputs that matter

• lora_1 (required) and lora_2 (optional) - LoRA objects, not raw files. You get these from LoraLoaderWeightOnly or another merge upstream. If you only plug in lora_1, you're effectively just resizing/re-processing one LoRA rather than combining two.
• mode - the merge strategy, picked from the node's dropdown in the UI. The pack doesn't document each option in prose, so the practical move is to try the default first and compare against a couple of the alternatives on your actual LoRA pair - merge behavior is genuinely sensitive to what's inside the files being combined.
• rank (default 16, 1–320) - the target rank of the merged output. Merging two LoRAs of different ranks (or wanting a smaller file than either input) is exactly what this controls.
• threshold (default 1, 0–1) - a cutoff used during the merge math; leave it at the default unless you're deliberately chasing a specific truncation behavior.
• device / dtype - where the merge computation runs (CPU/GPU) and what precision it uses. GPU + fp16 is the fast path if you're not VRAM-starved.
• Output: LoRA - feed this into LoraLoaderFromWeight to actually apply it to a model, or chain it into another LoraMerger to combine a third LoRA in.

Installing it

ComfyUI Manager → search cgem156-ComfyUI🍌 → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/laksjdjf/cgem156-ComfyUI

then restart. Nothing extra to download for this node specifically.

Common issues & troubleshooting

Merged result looks nothing like either LoRA. This is the normal risk of algebraically combining two adapters that were trained independently - they weren't designed to be added together, so the merge can land somewhere odd. Try a different mode, or fall back to stacking two separate loaders at reduced strength instead of merging, if the result isn't converging to what you want.

Rank mismatch confusion. If your two source LoRAs have very different ranks, setting rank too low relative to both can lose detail from the higher-rank one. Start near the higher of the two input ranks and shrink from there if you actually need a smaller file.

Only one LoRA connected. lora_2 is optional - if you leave it empty, you're not really "merging" anything, you're just running one LoRA through the resize/re-encode path. That's a legitimate use (shrinking a LoRA's rank), just not the two-in-one-out case the node is named for.

Architecture mismatch. Like all LoRAs, both inputs need to target the same base model family - an SDXL LoRA and a Flux LoRA won't merge into anything usable, regardless of what the node does with the math.