Load LoRA from Weight
Where a merged or block-weighted LoRA finally touches your model
- 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 Only → Merge LoRA → this 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.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| lora | LoRA | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |