a2569875 / stable-diffusion-webui-composable-lora

This extension replaces the built-in LoRA forward procedure.
GNU Affero General Public License v3.0
155 stars 14 forks source link

SD model is "remembered" until webui restart #6

Closed warong closed 1 year ago

warong commented 1 year ago

Thanks for this fork of Composable LoRA. I've been enjoying it in opparco's hiatus.

Lately (maybe after webui's 89f9faa update?), I've been noticing that whatever SD model I start using Composable LoRA with, the extension seems to get "stuck" with that model, even if I select other models for subsequent generations.

I can reproduce this behavior every time, by toggling the extension off and on, and notice that when off, the images are generated in the style of the new model (though with messed up characters since LoRAs are now mixed). Once I re-enable it, again with the new SD model still selected, the style of the previous model gets recalled.

If I want to use a new model, I can leave the new model selected in the dropdown and restart webui. Only then can I use Composable LoRA with that new model, where it would again be "remembered" until another restart.

a2569875 commented 1 year ago

@warong see this https://github.com/a2569875/stable-diffusion-webui-composable-lora/issues/4#issuecomment-1551216941

The new version of the WebUI has made changes to the implementation of LoRA in order to speed up the process. Instead of applying LoRA directly during the drawing phase, the WebUI now creates a LoRA cache before starting the drawing process. It only begins drawing after the LoRA cache is established, and the cache is updated only when LoRA is canceled or changed.

Although referred to as a cache, it actually involves backing up the weights of the Base Model Checkpoint. Prior to starting the drawing process, the WebUI incorporates the LoRA mentioned in the prompt into the Base Model Checkpoint, eliminating the need to apply LoRA during the drawing process, which saves time. When the next drawing is initiated, if any changes in LoRA are detected in the prompt, the backup weights of the Base Model Checkpoint are restored, and LoRA is re-integrated into the Base Model Checkpoint.

The advantage of this approach is that the drawing process no longer requires LoRA calculations, resulting in a significant speed boost. However, the downside is that it no longer allows for dynamic updates of LoRA weights based on the wording of the prompt, rendering Composable LoRA completely ineffective.

To maintain the effectiveness of Composable LoRA, my solution is to clear the LoRA cache and manually provide LoRA input. However, this creates a problem of disrupting the built-in caching mechanism used by the WebUI for LoRA.

As a result, sometimes after disabling the Composable LoRA extension, the LoRA that was just used may temporarily become ineffective, or it may not be removed properly (since I cleared the LoRA cache to apply Composable LoRA, but the WebUI assumes the cache is still present and does not apply it).

If the problem persists, please clear all LoRA prompts, generate an image without loading any LoRA, and then switch to loading another LoRA that hasn't been loaded before, generate an image, triggering a forced update of the LoRA cache to see if there is any improvement.

If the issue remains unresolved, switch the Base Model Checkpoint to force the recalculation of the caches for both LoRA and LyCoris, and see if there is any improvement.

Thank you.

warong commented 1 year ago

I gotcha. A flexibility trade-off for speed. One would hope for this caching behavior to be a toggle or something in the future.

Thanks for the thorough explanation. I'll go the long route and restart every model change I need. Keep up the great work!