You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some specific (optimized) version of Lora are developed (https://github.com/KohakuBlueleaf/LyCORIS) and are available (https://civitai.com/models/37053/michael-jordan) with pretty cool features (ability to make distinctions between trained concepts, etc.). It could be nice, as support for loading .safetensors is made, to have the possibility to load also LyCORIS models.
What do you think ?
Thanks a lot !
Open source status
The model implementation is available
The model weights are available (Only relevant if addition is not a scheduler).
I would love to see this feature as well. However, most implementations will bake it into their LoRA implementations. So maybe extending LoRAs to use these and not check metadata names vigorously would be a start.
I encountered an issue while using version 0.17.1 of the library, specifically when calling the load_lora_weights method. I received the following error:
I encountered an issue while using version 0.17.1 of the library, specifically when calling the load_lora_weights method. I received the following error:
@sayakpaul The constraint you mention indeed assumes that all network_alphas are same, as you stated. This assumption comes from the simplification of propagating network_alpha through a single variable. To correct this, we could potentially propagate all network_alphas that correspond to each lora-weight. I believe we should incorporate this improvement when we address the LoCon revisions. From what I've gathered, some LoCon files have unique network_alphas, while others do not.
I believe the LoCon support essentially extends the methodology of #3756. Therefore, I think it would be best to first finalize #3756 as the mechanism, and then create a separate PR for LoCon support.
@sayakpaulThe first comment is mostly with network_alpha=4, but there are some parts where network_alpha=1. This key is unfamiliar to me, so I think this might be the LoCon part.
@carl10086 we will first have support for the rest of blocks as mentioned in #3087 (comment). Then we will revisit this as this concerns a change in how we deal with network_alphas in the LoRA layers.
Seems like Lycoris LoCon models are supported, but the LoHA variant is not working with the latest version of diffusers (v26). Should this issue be reopened?
I just trained this a few hours ago on kohya_ss using some default settings. Ironically I wanted to check it was supported before training so found this thread, read the bottom few messages and it seemed to be supported, which is why I went ahead with it.
Hope this helps !
(EDIT: just tested with a random LoCon LoRa as well, can confirm it seems to be working)
Since LoHA checkpoints haven’t been that popular compared to others, we didn’t prioritize it. Would you maybe like to work with us on this through a PR?
LoHa and LoKr are implemented in PEFT, though there is currently some work to re-implement them based on LyCORIS (huggingface/peft#2133).
Regarding the integration into diffusers, even though it relies on PEFT, I think this would be quite a big refactor. If there is any way to gauge the demand for this first, this should be done first.
An idea that I wondered about: In the end, LoRA, LoKr, and LoHa can be condensed to: result = base_result + something_on_top, with something_on_top being different depending on the method. I wonder if there is a clever way to convert, or at least approximate, LoKr/LoHA with LoRA weights. Then we could convert them to LoRA and just use the normal LoRA code.
If anyone needs a temporary workaround to load these LoRA weights before the formal solution is out, it's possible to merge LoRA weights (of any type) into a .ckpt diffusion model with kohya_ss. Then convert the merged .ckpt weight back into diffusers format and load it like how normal models are loaded. See here: https://github.com/Darkbblue/diffusion-content-shift/blob/main/lora_guide.md#output-processing.
@Darkbblue thanks so much for your note! Would you maybe like to try this out on a LoHA checkpoint for the users (including us, the maintainers) to refer to?
@Darkbblue thanks so much for your note! Would you maybe like to try this out on a LoHA checkpoint for the users (including us, the maintainers) to refer to?
I've tried this on LoCon. Not tried it on LoHA but I'm pretty confident it can work. I might not be able to try this currently, but in a few days I may have the time.
@Darkbblue thanks so much for your note! Would you maybe like to try this out on a LoHA checkpoint for the users (including us, the maintainers) to refer to?
Hey I just tried a LoHA checkpoint and it worked. I had to update the conversion scripts in the link though, but everything's done now.
Wow, thank you! Would you be interesting in contributing this to diffusers? I can always reuse your code but if you contribute it, it will be more appropriate is what I feel.
Wow, thank you! Would you be interesting in contributing this to diffusers? I can always reuse your code but if you contribute it, it will be more appropriate is what I feel.
Since this approach involves functions provided by an external platform, kohya_ss, I don't think it'll be very suitable to integrate the entire process into diffusers... I think it should be considered only as a temporary workaround.
Activity
JemiloII commentedon May 13, 2023
I would love to see this feature as well. However, most implementations will bake it into their LoRA implementations. So maybe extending LoRAs to use these and not check metadata names vigorously would be a start.
JemiloII commentedon May 15, 2023
#3294 there is a pr here to support it.
carl10086 commentedon Jun 21, 2023
I encountered an issue while using version 0.17.1 of the library, specifically when calling the load_lora_weights method. I received the following error:
To bypass this error, I tried commenting out the following lines of code:
The code now runs, but this is not the appropriate solution.
I would appreciate any suggestions or advice on how to properly handle this
patrickvonplaten commentedon Jun 21, 2023
cc @sayakpaul
sayakpaul commentedon Jun 22, 2023
Did you get the expected outputs for this? We added that check for robustness in the module. Cc: @takuma104.
There can be different configurations for LyCORIS and from the get-go, it's not possible to support all of them. So, we started supporting them minimally: https://huggingface.co/docs/diffusers/main/en/training/lora#supporting-a1111-themed-lora-checkpoints-from-diffusers.
Question for @takuma104:
Do we want to relax this constraint?
diffusers/src/diffusers/loaders.py
Line 1242 in 0bab447
I think that might break things as that would mean different alphas for different LoRA layers, no?
carl10086 commentedon Jun 22, 2023
I am in full agreement with your current viewpoint, which is why I have chosen to raise this issue in this particular thread concerning LyCORIS.
LyCORIS in a1111 does have an array of formats, making it indeed challenging to support them all at once.
LyCORIS getting more and more in civitai :)
takuma104 commentedon Jun 22, 2023
@sayakpaul The constraint you mention indeed assumes that all
network_alphas are same, as you stated. This assumption comes from the simplification of propagatingnetwork_alphathrough a single variable. To correct this, we could potentially propagate allnetwork_alphas that correspond to each lora-weight. I believe we should incorporate this improvement when we address the LoCon revisions. From what I've gathered, some LoCon files have unique network_alphas, while others do not.I believe the LoCon support essentially extends the methodology of #3756. Therefore, I think it would be best to first finalize #3756 as the mechanism, and then create a separate PR for LoCon support.
sayakpaul commentedon Jun 23, 2023
I concur with your thoughts, @takuma104. #3778 is about to be get merged soon. So, we can start #3756 and what you have gathered pretty soon.
Cc: @patrickvonplaten
sayakpaul commentedon Jun 23, 2023
@takuma104 went through https://gist.github.com/takuma104/dcf4626fe2b0564d02c6edd4e9fcb616 I saw either 4 or 32 for the LoRAs you have listed there. But within the same LoRA, the alpha value didn't change. Perhaps, I missed something?
takuma104 commentedon Jun 23, 2023
@sayakpaul The first comment is mostly with
network_alpha=4, but there are some parts wherenetwork_alpha=1. This key is unfamiliar to me, so I think this might be the LoCon part.sayakpaul commentedon Jun 29, 2023
@carl10086 we will first have support for the rest of blocks as mentioned in #3087 (comment). Then we will revisit this as this concerns a change in how we deal with
network_alphas in the LoRA layers.Feel free to bug us in the coming weeks :)
FurkanGozukara commentedon Jul 11, 2023
dear @sayakpaul , @patrickvonplaten
lets say i have trained a LoRA safetensors via Kohya
How can I implement it to the below pipeline?
pipe = DiffusionPipeline.from_pretrained(model_key_base, torch_dtype=torch.float16, use_auth_token=access_token)sayakpaul commentedon Jul 11, 2023
You can follow this method:
https://huggingface.co/docs/diffusers/main/en/training/lora#supporting-a1111-themed-lora-checkpoints-from-diffusers but note that there might be incompatibilities as discussed in #3725.
23 remaining items
JustMaier commentedon Jan 31, 2024
Looks like this is supported now. This probably should be closed as complete:
#5102
sayakpaul commentedon Jan 31, 2024
Happily closing then :)
Scorpinaus commentedon Feb 1, 2024
Seems like Lycoris LoCon models are supported, but the LoHA variant is not working with the latest version of diffusers (v26). Should this issue be reopened?
sayakpaul commentedon Feb 2, 2024
If they were working with a previous version and are not working with the latest version, they, yes. Please also supply a fully reproducible snippet.
zzbuzzard commentedon Oct 4, 2024
@sayakpaul it seems LoHA support is still not implemented, so I feel this should be re-opened.
diffusers: 0.30.3
safetensors: 0.4.5
torch: 1.13.1
gives
I just trained this a few hours ago on kohya_ss using some default settings. Ironically I wanted to check it was supported before training so found this thread, read the bottom few messages and it seemed to be supported, which is why I went ahead with it.
Hope this helps !
(EDIT: just tested with a random LoCon LoRa as well, can confirm it seems to be working)
sayakpaul commentedon Oct 4, 2024
Thanks for checking in!
Since LoHA checkpoints haven’t been that popular compared to others, we didn’t prioritize it. Would you maybe like to work with us on this through a PR?
cc: @BenjaminBossan for peft.
BenjaminBossan commentedon Oct 7, 2024
LoHa and LoKr are implemented in PEFT, though there is currently some work to re-implement them based on LyCORIS (huggingface/peft#2133).
Regarding the integration into diffusers, even though it relies on PEFT, I think this would be quite a big refactor. If there is any way to gauge the demand for this first, this should be done first.
An idea that I wondered about: In the end, LoRA, LoKr, and LoHa can be condensed to:
result = base_result + something_on_top, withsomething_on_topbeing different depending on the method. I wonder if there is a clever way to convert, or at least approximate, LoKr/LoHA with LoRA weights. Then we could convert them to LoRA and just use the normal LoRA code.Darkbblue commentedon Oct 9, 2024
If anyone needs a temporary workaround to load these LoRA weights before the formal solution is out, it's possible to merge LoRA weights (of any type) into a .ckpt diffusion model with kohya_ss. Then convert the merged .ckpt weight back into diffusers format and load it like how normal models are loaded. See here: https://github.com/Darkbblue/diffusion-content-shift/blob/main/lora_guide.md#output-processing.
sayakpaul commentedon Oct 9, 2024
@Darkbblue thanks so much for your note! Would you maybe like to try this out on a LoHA checkpoint for the users (including us, the maintainers) to refer to?
Darkbblue commentedon Oct 9, 2024
I've tried this on LoCon. Not tried it on LoHA but I'm pretty confident it can work. I might not be able to try this currently, but in a few days I may have the time.
Darkbblue commentedon Oct 17, 2024
Hey I just tried a LoHA checkpoint and it worked. I had to update the conversion scripts in the link though, but everything's done now.
sayakpaul commentedon Oct 17, 2024
Wow, thank you! Would you be interesting in contributing this to
diffusers? I can always reuse your code but if you contribute it, it will be more appropriate is what I feel.Darkbblue commentedon Oct 18, 2024
Since this approach involves functions provided by an external platform, kohya_ss, I don't think it'll be very suitable to integrate the entire process into diffusers... I think it should be considered only as a temporary workaround.
document LyCORIS support gap — diffusers load_lora_weights covers LoR…