RuntimeError
RuntimeError: Cannot fuse LoRA weights that have not been loaded
Stack trace
Traceback (most recent call last):
File "script.py", line 42, in <module>
pipe.fuse_lora()
File "/usr/local/lib/python3.10/site-packages/diffusers/loaders/lora.py", line 287, in fuse_lora
raise RuntimeError("Cannot fuse LoRA weights that have not been loaded. Call `load_lora_weights()` first.")
RuntimeError: Cannot fuse LoRA weights that have not been loaded. Call `load_lora_weights()` first. Why it happens
The diffusers library requires LoRA weights to be loaded into the pipeline's UNet and text encoder before they can be fused (baked into the base model weights). Calling fuse_lora() before load_lora_weights() attempts to fuse weights that don't exist in memory yet. Additionally, if you load LoRA weights but don't use the correct adapter identifier or the weights fail to load silently, fuse_lora() will still raise this error because it detects the absence of loaded LoRA state.
Detection
Check the order of your pipeline method calls: load_lora_weights() must always come before fuse_lora(). Add logging before fuse_lora() to confirm LoRA weights are loaded: check if the model's lora_scale attribute exists and is non-zero.
Causes & fixes
Calling fuse_lora() without first calling load_lora_weights()
Always call load_lora_weights(lora_model_id) before fuse_lora(). The order is mandatory: load, then fuse.
load_lora_weights() failed silently due to invalid model ID, network error, or permission issue
Wrap load_lora_weights() in try/except to catch errors, verify the model ID exists on Hugging Face Hub, and check your internet connection and authentication token.
Unloading LoRA weights with unload_lora_weights() then trying to fuse_lora() afterward
Do not call unload_lora_weights() if you plan to fuse later. If you must unload, reload the LoRA weights before fuse_lora().
Using fuse_lora() on a pipeline that was never initialized with enable_lora() or created without LoRA support
Ensure your pipeline supports LoRA: SDXL, SD 1.5, Flux all support it. If you're using a custom or unsupported pipeline, enable LoRA support manually via the pipeline's enable_lora() method if available.
Code: broken vs fixed
import torch
import os
from diffusers import StableDiffusionXLPipeline
model_id = 'stabilityai/stable-diffusion-xl-base-1.0'
lora_id = 'ostris/super-detail-xl'
pipe = StableDiffusionXLPipeline.from_pretrained(
model_id,
torch_dtype=torch.float16,
use_safetensors=True
).to('cuda')
# ERROR: Calling fuse_lora() WITHOUT loading LoRA weights first
pipe.fuse_lora() # ← This line raises RuntimeError
image = pipe('a beautiful landscape').images[0]
image.save('output.png')import torch
import os
from diffusers import StableDiffusionXLPipeline
model_id = 'stabilityai/stable-diffusion-xl-base-1.0'
lora_id = 'ostris/super-detail-xl'
pipe = StableDiffusionXLPipeline.from_pretrained(
model_id,
torch_dtype=torch.float16,
use_safetensors=True
).to('cuda')
# FIX: Load LoRA weights BEFORE calling fuse_lora()
pipe.load_lora_weights(lora_id)
pipe.fuse_lora() # ← Now this succeeds
image = pipe('a beautiful landscape').images[0]
image.save('output.png')
print('LoRA fused successfully!')Workaround
If you cannot fuse LoRA weights due to memory constraints or need to keep them separate, skip fuse_lora() entirely and use set_adapters() with enable_lora() instead. This keeps LoRA weights in a separate adapter layer that runs during inference without baking them into the base model, trading memory efficiency for slightly slower generation speed. Call pipe.load_lora_weights(lora_id) and pipe.enable_lora() then run inference normally: the LoRA effect will still apply without the fuse step.
Prevention
Always structure LoRA pipelines in this order: (1) load base pipeline, (2) load_lora_weights(), (3) optionally call fuse_lora() or enable_lora(), (4) generate. Add a helper function that enforces this sequence and validates that LoRA state exists before calling fuse. Use logging to confirm load_lora_weights() completed without exceptions before proceeding to fuse_lora().