lllyasviel / lllyasviel/stable-diffusion-webui-forge
LoRA model detected but not applying (SDXL / WebUI Forge)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 13k
- Forks
- 1.7k
- PR merge metrics
- No merged PRs in 30d
Description
Hi everyone,
I’m experiencing an issue where my LoRA model is detected in Stable Diffusion WebUI Forge (on RunPod) but does not affect the generated images. It seems like the model is loaded but not applied.
Here are the details:
-Base Model: Tested multiple ones (SDXL, DreamShaper, RealisticVision, JuggernautXL).
- LoRA Model: A custom-trained LoRA (Elana.safetensors), which previously worked fine.
- LoRA Directory: The file is present in workspace/stable-diffusion-webui-forge/models/Lora and appears in the WebUI.
- Prompting: Using or , but no visible change in the images.
- Test Case: Even using a basic prompt like woman does not reflect the LoRA.
- Worked before! I successfully used my LoRA with different models (even non-SDXL) in the past with the same template
Here some more details about the LoRA model:
ss_adaptive_noise_scale | None
ss_base_model_version | sdxl_base_v1-0
ss_batch_size_per_device | 3
ss_bucket_info |
ss_bucket_no_upscale | False
ss_cache_latents | True
ss_caption_dropout_every_n_epochs | 0
ss_caption_dropout_rate | 0.0
ss_caption_tag_dropout_rate | 0.0
ss_clip_skip | 1
ss_color_aug | False
ss_dataset_dirs |
ss_debiased_estimation | False
ss_enable_bucket | True
ss_epoch | 8
ss_face_crop_aug_range | None
ss_flip_aug | False
ss_full_fp16 | False
ss_gradient_accumulation_steps | 1
ss_gradient_checkpointing | False
ss_huber_c | 0.1
ss_huber_schedule | snr
ss_ip_noise_gamma | None
ss_ip_noise_gamma_random_strength | False
ss_keep_tokens | 0
ss_learning_rate | 0.0002
ss_loss_type | l2
ss_lowram | False
ss_lr_scheduler | constant
ss_lr_warmup_steps | 0
ss_max_bucket_reso | 2048
ss_max_grad_norm | 1
ss_max_token_length | 75
ss_max_train_steps | 1600
ss_min_bucket_reso | 256
ss_min_snr_gamma | None
ss_mixed_precision | fp16
ss_multires_noise_discount | 0.3
ss_multires_noise_iterations | None
ss_network_alpha | 16
ss_network_dim | 32
ss_network_dropout | None
ss_network_module | networks.lora
ss_new_sd_model_hash | 31e35c80fc4829d14f90153f4c74cd59c90b779f6afe05a74cd6120b893f7e5b
ss_noise_offset | None
ss_noise_offset_random_strength | False
ss_num_batches_per_epoch | 222
ss_num_epochs | 8
ss_num_reg_images | 0
ss_num_train_images | 665
ss_optimizer | bitsandbytes.optim.adamw.AdamW8bit
ss_output_name | Elana
ss_prior_loss_weight | 1
ss_random_crop | False
ss_resolution | (1024, 1024)
ss_scale_weight_norms | None
ss_sd_model_hash | be9edd61
ss_sd_model_name | sd_xl_base_1.0.safetensors
ss_sd_scripts_commit_hash | b8896aad400222c8c4441b217fda0f9bb0807ffd
ss_seed | 711237885
ss_session_id | 3077836623
ss_shuffle_caption | False
ss_steps | 1600
ss_tag_frequency |
ss_text_encoder_lr | 0.0002
ss_total_batch_size | 3
ss_training_comment | None
ss_training_finished_at | 1739650512.5185318
ss_training_started_at | 1739649052.529426
ss_unet_lr | 0.0002
ss_v2 | False
ss_zero_terminal_snr | False
sshs_legacy_hash | c903d216
sshs_model_hash | 9b8fdfc1e16e7cd49d80724764c87cf6f18edbbaa35d63bb18dabbcfb0b7aaf5
Does anyone have an idea why my LoRA model is not applying despite being detected?
Are there any known SDXL-specific LoRA issues with WebUI Forge?
If any logs or further details are needed, I can provide them.
Thanks in advance for your help! 🙏
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source files or tests are named. Reproduce the report in WebUI Forge on RunPod with the listed SDXL models, Elana.safetensors, and the prompt; gather the requested logs and compare behavior with a known-working LoRA. Done means identifying whether the LoRA is loaded but ignored and documenting a confirmed cause or fix.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- machine-learning
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100