Stable Diffusion LoRA: Matching the Base Model, Weights and Stacking

Quick answer

• A LoRA only works on the base model it was trained against. An SDXL LoRA will not load onto SD 1.5 or Flux. This is the single most common reason a LoRA “does nothing”.
• You never have to guess which base it needs. Every LoRA on Hugging Face declares a base_model field in its metadata — check it before you download.
• Strength is a dial, not a switch. A scale of 0 is the base model alone, 1 is the LoRA fully applied; most style LoRAs look better somewhere between.
• You can stack them. set_adapters() takes a list of LoRAs and a list of weights, and equal weights produce an average of the two.
• Fuse when you are done experimenting — it speeds up inference and cuts memory, at the cost of flexibility.

This covers using LoRAs. If you want to know what one is structurally, we cover that in checkpoints, LoRAs and VAEs explained; for what it costs to train one, see the LoRA training VRAM guide.

The base model is not optional

A LoRA is a set of low-rank adjustments applied to specific layers of a specific architecture. The shapes have to match. That is why an SDXL LoRA cannot be applied to SD 1.5 — the layers it was trained to modify are a different size, and often are not there at all.

The practical consequence is that “Stable Diffusion LoRA” is not one compatible category. SD 1.5, SDXL, SD 3.5 and Flux each have their own incompatible LoRA ecosystems, and a file downloaded from the wrong one will either error or quietly do nothing.

How to check in five seconds

Hugging Face records the base model as structured metadata on every adapter repository, both in the model card and as a machine-readable base_model: tag. Checked on 29 September 2026:

Note the third row. lordjia/by-feng-zikai has nothing in its name to tell you it is SDXL — the filename fengzikai_v1.0_XL.safetensors hints at it, but the metadata states it outright. Prefer the field over the name, because plenty of LoRAs are named after their style and nothing else.

Added 1 October 2026 — one caveat to that. The field is hand-written, so it can be wrong. While researching ControlNet models we found diffusers/controlnet-canny-sdxl-1.0 declaring base_model: runwayml/stable-diffusion-v1-5 in its metadata and tags, while its own card body says the weights were trained on SDXL. So: read the field and the card body, and where they disagree, trust the prose.

Loading one, and setting its strength

In diffusers, a LoRA loads into a pipeline you have already built. The docs describe these as lightweight by design: “LoRA checkpoints are typically only a couple hundred MBs in size, so they’re very lightweight and easy to store.”

pipeline.load_lora_weights(
    "ostris/ikea-instructions-lora-sdxl",
    weight_name="ikea_instructions_xl_v1_5.safetensors",
    adapter_name="ikea",
)
pipeline.set_adapters("ikea", adapter_weights=0.7)

That 0.7 is the part people leave alone and should not. The scale parameter controls how much of the LoRA is applied: per the documentation, “A value of 0 is equivalent to only using the base model weights and a value of 1 is equivalent to fully using the LoRA.”

Full strength is rarely the best result for a style LoRA. At 1.0 the style tends to dominate composition and prompt adherence; somewhere between 0.6 and 0.8 usually keeps the look while letting the prompt still steer. That is a starting range to test from, not a rule — it depends on the LoRA and how it was trained.

Stacking two or more

This is where LoRAs get genuinely interesting, and where most guides stop. set_adapters() accepts lists:

pipeline.set_adapters(["ikea", "feng"], adapter_weights=[0.7, 0.8])

The mechanism is worth knowing because it explains the failure mode. The documentation states that set_adapters() “merges LoRA adapters by concatenating their weighted matrices”, and that with adapter_weights=[0.5, 0.5], “the merged LoRA output is an average of both LoRAs”.

An average is exactly what it sounds like. Stack two strong, opinionated style LoRAs at equal weight and you often get something muddier than either alone rather than a combination of both. If a stack looks washed out, drop one weight rather than raising the other.

There is also a more sophisticated route. Diffusers exposes PEFT’s add_weighted_adapter, which it describes as “an experimental method” providing “access to more efficient merging method such as TIES and DARE”. Worth knowing it exists if simple averaging is not giving you what you want — but “experimental” is the operative word, and it needs current diffusers and PEFT installed.

Fusing: faster, but one-way in practice

Once you have settled on a combination, you can bake it in:

pipeline.fuse_lora(adapter_names=["ikea"], lora_scale=1.0)
pipeline.unload_lora_weights()

The documentation’s stated purpose is “to improve inference speed and reduce memory-usage of merged LoRAs”. The trade-off is flexibility: fusing writes the LoRA into the model weights in memory, so you can no longer adjust the scale or swap adapters without rebuilding the pipeline. Fuse when you are generating a batch at settings you have already chosen, not while you are still experimenting.

Why a LoRA appears to do nothing

In rough order of how often each one is the actual cause:

• Wrong base model. Check the base_model field. This is most of them.
• Loaded but never activated. load_lora_weights() puts it in place; set_adapters() switches it on. Missing the second call is silent.
• Scale too low — or genuinely at 0.
• No trigger word. Many LoRAs are trained against a specific token and do comparatively little without it. The model card is the only place that tells you.
• Stacked into an average that cancels out the effect you wanted.

In a graphical tool the same logic applies with different names — a Load LoRA node in ComfyUI carries the same strength value, and the base-model rule is identical. Our ComfyUI templates guide covers the workflows that ship with it, and which Stable Diffusion editors are still maintained covers where to run any of this.

A licence note

The LoRA’s licence and the base model’s licence are separate, and the restrictive one governs. A permissively licensed SDXL LoRA does not make a non-commercial base model commercially usable, and a LoRA trained on FLUX.1 [dev] inherits that model’s non-commercial terms — we work that chain through in the Flux LoRA licence guide.

FAQ

Can I use an SDXL LoRA with SD 1.5?

No. A LoRA modifies specific layers of a specific architecture, and the shapes do not match across base models. Check the base_model field on the LoRA’s Hugging Face page before downloading.

What LoRA strength should I use?

0 applies none of it and 1 applies it fully. For style LoRAs, 0.6 to 0.8 is a sensible range to test first — full strength often overwhelms the prompt.

Can I use two LoRAs at once?

Yes. set_adapters() takes a list of names and a list of weights. Be aware that equal weights average the two, which can dilute both rather than combine them.

Should I fuse a LoRA?

Only once you have settled on the combination and scale. Fusing improves inference speed and memory use but removes your ability to change the weighting without rebuilding the pipeline.

Sources

• Loading adapters, weight scale, and fuse_lora (Diffusers: LoRA inference)
• set_adapters() merge behaviour and add_weighted_adapter (Diffusers: Merge LoRAs)
• base_model metadata read from the Hugging Face API on 29 September 2026, e.g. ostris/ikea-instructions-lora-sdxl

Updated 29 September 2026: API names and documented behaviour verified against the Diffusers documentation on this date, and base-model metadata read from the Hugging Face API.