[Enhancement] distinguish v1 from v2 LoRA models

[lstein]

Distinguish LoRA/LyCORIS files based on what version of SD they were built on top of

• Attempting to run a prompt with a LoRA based on SD v1.X against a model based on v2.X will now throw an IncompatibleModelException. To import this exception:
  from ldm.modules.lora_manager import IncompatibleModelException (maybe this should be defined in ModelManager?)

• Enhance LoraManager.list_loras() to accept an optional integer argument, token_vector_length. This will filter the returned LoRA models to return only those that match the indicated length. Use:
  768 => for models based on SD v1.X 1024 => for models based on SD v2.X
  Note that this filtering requires each LoRA file to be opened by torch.safetensors. It will take ~8s to scan a directory of 40 files.

• Added new static methods to ldm.modules.kohya_lora_manager:
  - check_model_compatibility()
  - vector_length_from_checkpoint()
  - vector_length_from_checkpoint_file()

• You can now create subdirectories within the loras directory and organize the model files.

[StAlKeR7779]

Maybe create file with info about lora like sha file for checkpoint models?
So, first check will take a bit time, but if lora loaded in past, then just load info file.

[lstein]

Maybe create file with info about lora like sha file for checkpoint models? So, first check will take a bit time, but if lora loaded in past, then just load info file.

H'mmm, makes sense. But we'd have to update the file everytime someone added or removed a LoRA file.

[StAlKeR7779]

Maybe create file with info about lora like sha file for checkpoint models? So, first check will take a bit time, but if lora loaded in past, then just load info file.

H'mmm, makes sense. But we'd have to update the file everytime someone added or removed a LoRA file.

No, i mean creating <lora_file>.info for every lora file.
At least i thinks about it at first, but to be more user friendly we can write it somewhere as a cache, hidden from loras folder. And how it will be done - single or multiple files - i'm not sure which option better.

I saw logic as:
On lora loading if no info exists, then write it.
On model loading check all loras info and if some lora doesn't have info file, then load it to create/get info.
If be paranoid about situation - user deleted lora file and pasted new with same name, i think we can include file length in info, so on checking we will compare this value with current file length and discard info if it's mismatch.(Can be checksum of file, but i don't know impact of calculating file checksum on performance)

[lstein]

I've created a lora cache file in the top-level loras directory that holds information on the lora vector length. It speeds up scanning of the directory from 8s to 0.1s, and uses file locking to avoid one invokeai process overwriting the file while another invokeai has it open. It does not address the possibility that the user will delete the original lora file and replace it with another one of the exact same name derived from a different sized model.

@blessedcoolant I also implemented a routine called list_compatible_loras() that will return a dictionary of all the LoRAs that are compatible with the current model. The keys are the LoRA base name, and the values are the full path to the .safetensors file. I modified invokeai_web_server so that it calls this method in its getLoraModels event, and it works to the extent that when the loras first load they are filtered to be compatible with the initial model. However, I don't know how to force the list of loras to be reloaded whenever the model changes. Is this something you can do?

[blessedcoolant]

However, I don't know how to force the list of loras to be reloaded whenever the model changes. Is this something you can do?

You could try the following.

In listeners.ts find the onModelChanged function. Prior to dispatch(setIsProcessing(false)); add dispatch(getLoraModels()); and auto-import the getLoraModels function into the ifle..

This should effectively call the lora models again when a new model is loaded. And if the backend sends back only compatible models, it should work as intended.

[lstein]

However, I don't know how to force the list of loras to be reloaded whenever the model changes. Is this something you can do?

You could try the following.

In listeners.ts find the onModelChanged function. Prior to dispatch(setIsProcessing(false)); add dispatch(getLoraModels()); and auto-import the getLoraModels function into the ifle..

This should effectively call the lora models again when a new model is loaded. And if the backend sends back only compatible models, it should work as intended.

Worked like a charm on the first try. Thanks so much!

I think this is PR is ready for a review now.

[blessedcoolant]

@lstein The frontend is not built correctly. index.js is missing.

[lstein]

@lstein The frontend is not built correctly. index.js is missing.

I've rebuilt the frontend and added the missing .js file. @blessedcoolant Do you mind giving this PR a review? It should be working now.