Better lora loader?

[Hearmeman24]

I absolutely love the video wrapper but loading LoRAs is a nightmare. Is there any way to add a lora loading stack or add support to existing ones?

[alastaira]

"...loading LoRAs is a nightmare...."

How so? I just pass them in to the LoraLoaderModelOnly and... they work?

[Hearmeman24]

"...loading LoRAs is a nightmare...."

How so? I just pass them in to the LoraLoaderModelOnly and... they work?

With the wrapper nodes?

[moonwhaler]

I wrote a little (dynamic) WAN LoRA stacker for my personal use, but if you like you can try it out. It behaves similar to the 'Switch Any' node from rgthree. I work heavily with Group Muter nodes in my workflows and this made it a lot easier to work with.

It's in my repo here (just git clone it to your custom_nodes folder):

https://github.com/moonwhaler/comfyui-moonpack

I will add a readme soon, because there are some other helper nodes in there, too. Like a string (concat) stacker.

[gwntd541]

I wrote a little (dynamic) WAN LoRA stacker for my personal use, but if you like you can try it out. It behaves similar to the 'Switch Any' node from rgthree. I work heavily with Group Muter nodes in my workflows and this made it a lot easier to work with.

It's in my repo here (just git clone it to your custom_nodes folder):

https://github.com/moonwhaler/comfyui-moonpack

I will add a readme soon, because there are some other helper nodes in there, too. Like a string (concat) stacker.

I tried your Dynamic LoRA Stack, it's not much difference from just chaining multiple WanVideo Lora Selects. A little better on the eyes, is it possible to setup something similar to PowerLoraLoader from rgthree with the same concept of loading multiple loras from one node but for WanVideo?

For cleaner lora loading, @kijai is it possible to separate the clip out of Load WanVideo T5 TextEncoder->wan_t5_model and plug into Power Lora Loader (rgthree)->clip .

[Santodan]

so, is there any alternative to the lora loading on every run at this moment?

[kijai]

so, is there any alternative to the lora loading on every run at this moment?

It's not on every run, but it is on every change on the model/loras. It was initially designed that way because it was only way to use loras with compile, and because it would be complicated to implement the comfy patching system to a wrapper.

However now with the GGUF update, when using GGUF models and loras, the loras aren't merged at all but applied on the fly, which is requirement in general when using GGUF + LoRAs, so that's one way to avoid the issue.

[Santodan]

since I'm doing tests with loras ( changing their weights ) then it makes sense it is always apply this. my problem is more the time it takes, it is always around 3 minutes to get the loras loaded. just one doubt @kijai, you say in the README that we should use the native if all features are available, do you know which features are not available in native? I'll be going to try to create a workflow in native with torch compile, sage attention and block swap ( this is the only one that I'm in doubt if it is available in native )

[kijai]

since I'm doing tests with loras ( changing their weights ) then it makes sense it is always apply this. my problem is more the time it takes, it is always around 3 minutes to get the loras loaded. just one doubt @kijai, you say in the README that we should use the native if all features are available, do you know which features are not available in native? I'll be going to try to create a workflow in native with torch compile, sage attention and block swap ( this is the only one that I'm in doubt if it is available in native )

I would need to make a list, I've lost track so far, but from top of my head, it's mostly models:

• Fantasytalking and Multitalk
• UniAnimate
• Recammaster
• ATI (though I have experimental node for native too)
• MiniMaxRemover
• Uni3C (camera control)
• context windows

Today also added FreeInit implementation, remains to be seen how useful that is

[Windecay]

since I'm doing tests with loras ( changing their weights ) then it makes sense it is always apply this. my problem is more the time it takes, it is always around 3 minutes to get the loras loaded. just one doubt @kijai, you say in the README that we should use the native if all features are available, do you know which features are not available in native? I'll be going to try to create a workflow in native with torch compile, sage attention and block swap ( this is the only one that I'm in doubt if it is available in native )

I would need to make a list, I've lost track so far, but from top of my head, it's mostly models:

• Fantasytalking and Multitalk
• UniAnimate
• Recammaster
• ATI (though I have experimental node for native too)
• MiniMaxRemover
• Uni3C (camera control)
• context windows

Today also added FreeInit implementation, remains to be seen how useful that is

I observed that when I use two samplers for generation, and each sampler uses a different LoRA, during the second LoRA merging operation, the physical or virtual memory usage dramatically increases by 30GB (model:i2v 480p fp8e4m3). Many users do not have that much virtual memory, which causes the Comfy console to crash.

How to solve this problem?thanks

[kijai]

since I'm doing tests with loras ( changing their weights ) then it makes sense it is always apply this. my problem is more the time it takes, it is always around 3 minutes to get the loras loaded. just one doubt @kijai, you say in the README that we should use the native if all features are available, do you know which features are not available in native? I'll be going to try to create a workflow in native with torch compile, sage attention and block swap ( this is the only one that I'm in doubt if it is available in native )

I would need to make a list, I've lost track so far, but from top of my head, it's mostly models:

• Fantasytalking and Multitalk
• UniAnimate
• Recammaster
• ATI (though I have experimental node for native too)
• MiniMaxRemover
• Uni3C (camera control)
• context windows

Today also added FreeInit implementation, remains to be seen how useful that is

I observed that when I use two samplers for generation, and each sampler uses a different LoRA, during the second LoRA merging operation, the physical or virtual memory usage dramatically increases by 30GB (model:i2v 480p fp8e4m3). Many users do not have that much virtual memory, which causes the Comfy console to crash.

How to solve this problem?thanks

Using GGUF models now would help a bit with the LoRA issue as then LoRAs are not merged and main model should stay the same in memory, though I have not tried that yet. Multiple sampler workflows are always going to be better in native as it's fully designed around enabling that.

[kijai]

Also have made lora merging optional for other than GGUF models and added SetLoRAs -node to change them without reloading the model.

[MannySJH]

Did you find anything for this?