Nodes/LoRA-Merger-ComfyUI/Load LoRA from Weight
ComfyUI Node

Load LoRA from Weight

Where a merged or block-weighted LoRA finally touches your model

By laksjdjf·Created 3 years ago·Updated 2 years ago· 23
Load LoRA from Weight
  • model
  • clip
  • lora
  • MODEL
  • CLIP

Every other node in the LoRA-Merger pack deals in LoRA objects - tensors floating in memory. This one is where they stop floating and actually change your image. It's the apply half of the pack: it takes a LoRA object and welds it onto your MODEL and CLIP, which is exactly what ComfyUI's built-in LoraLoader does with a file on disk.

Which means if you just want to load a LoRA normally, use the built-in node. Reach for this one when your LoRA didn't come from disk - a merge result, a block-weighted variant, something you want to preview before you save it as a file. It's the output end of the canonical chain: Load LoRA Weight OnlyMerge LoRAthis node → KSampler, with a Save LoRA node hanging off the merge if you want a permanent file.

Inputs and the one thing that trips everyone

Three inputs, all required: model, clip, and lora. Outputs are the modified MODEL and CLIP. That's the entire surface - and that's the gotcha. There is no strength slider on this node. The strength comes from inside the LoRA object you feed it, set back on Load LoRA Weight Only (or baked in by Merge LoRA, which outputs strength 1/1). Beginners stare at this node for a while looking for a weight field that isn't there. It isn't missing; the design just puts the knob upstream.

Mechanically it's a thin wrapper: it calls ComfyUI's own load_lora_for_models with the object's stored strength_model and strength_clip. If both are zero it returns your model untouched. Beyond that there's no magic - which is good news, because it means a merged LoRA behaves identically to a normally-loaded one at generation time. A LoRA is a patch, not a model; you can stack it, you can't run it on a base it wasn't made for, and this node is where both facts show up.

Wiring and troubleshooting

Wire both outputs. The CLIP output is easy to forget, but for SD 1.5 and SDXL a big chunk of a LoRA's effect lives in the text encoder, and skipping that wire silently halves the result. You can tee the same merged LoRA into this node and into Save LoRA in parallel - preview and persist in one queue run, which is the workflow this pack is built around.

When it "doesn't do anything," work the chain backward: check the strengths on the loader node, not here; confirm the LoRA object is a merge output and not an empty result; and remember the author's caveats still apply - LyCORIS LoHA/LoKr files won't load, and LoRAs trained with different training scripts can fail to merge into something usable. If the merge combined incompatible bases (say an SDXL LoRA with an SD 1.5 one), no node downstream can rescue that.

Install

cd ComfyUI/custom_nodes && git clone https://github.com/laksjdjf/LoRA-Merger-ComfyUI

then restart ComfyUI. No requirements.txt, no model downloads - it only needs ComfyUI's own comfy.sd internals, so install is about as clean as custom nodes get. ComfyUI Manager finds it by "LoRA-Merger-ComfyUI", but beware the name collision with larsupb's far more popular LoRA Power-Merger; install the one by laksjdjf (of Attention Couple fame). The repo is archived - the README now points to laksjdjf/cgem156-ComfyUI/scripts/lora_merger - so it's stable-but-frozen code. Don't hold your breath for new features, but what it does, it does using ComfyUI's own loader under the hood, which is about the most maintenance-proof thing a custom node can be.

Categorylora_merge

Inputs (3)

NameTypeDefaultDescription
modelMODEL
clipCLIP
loraLoRA

Outputs (2)

NameTypeDescription
MODELMODEL
CLIPCLIP