Lora Loader (Key Fix)

If you've spent any time reading ComfyUI's console, you've seen lora key not loaded. It's one of the most common warnings in the ecosystem - it shows up in hundreds of threads a year - and almost nobody explains what to do about it beyond "your LoRA is for a different model, probably." Sometimes that's right. Sometimes ComfyUI is dropping tensors it could have loaded, because the file uses a key convention its loader doesn't map.

This node renames those keys before handing the file to ComfyUI's own loader.

What's actually happening

ComfyUI applies a LoRA tensor only when the key names a module it maps for that model. Everything else gets skipped, with a console line and nothing else. Two families of file lose tensors that way:

• lightx2v's Wan 2.2 distill LoRAs store a block's modulation difference as <block>.diff_m. Core reads a modulation difference only as <block>.modulation.diff. So the file loads, looks fine, and that whole set of tensors is missing.
• PEFT files exported outside ComfyUI (DiffSynth's, which is where the official SVI 2.0 files come from) name modules without the diffusion_model. prefix. Core maps no key of a Wan model without that prefix, so none of the tensors load.

The second one is the sneaky case: the node runs, the console fills with lora key not loaded, and the LoRA does nothing at all. If you've ever concluded a distill LoRA was "weak" or broken, this may be why.

What the node does, precisely

It goes through ComfyUI's own format conversion first, so it sees the same keys core's loader sees, then renames:

| In the file | Renamed to | Origin | | --- | --- | --- | | <block>.diff_m | <block>.modulation.diff | lightx2v Wan 2.2 distills | | blocks.N.<module>.lora_A.default.weight, no prefix | diffusion_model.blocks.N.<module>… | PEFT exports (DiffSynth, SVI 2.0) |

The rules are conservative, which is why it's safe to leave in your graph unconditionally: a key core already maps is never touched, and a rename only happens if the new name is mapped and no other tensor in the file already holds it. So no tensor gets overwritten, and a LoRA core loads fine comes through unchanged.

Every run prints one line to the console:

my_lora.safetensors: 1500 keys, 41 renamed (41 .diff_m -> .modulation.diff, 0 given the diffusion_model. prefix), 0 match no module of this model

That line is the actual value here. "41 renamed" tells you the fix did something. "N match no module of this model" - as a warning naming the first five - tells you the file is for a different architecture, or that you're loading the image branch of a Wan 2.1 I2V LoRA on Wan 2.2, or that it carries text-encoder keys the model doesn't have. That's the diagnosis you don't currently get.

Inputs and outputs

Small on purpose:

• model - the diffusion model.
• lora_name - a file from models/loras. The combo is empty until you have LoRAs in there.
• strength - default 1, −100 to 100, step 0.01. 0 returns the model untouched.
• Output: MODEL.

No CLIP in or out - this is the LoraLoaderModelOnly shape. The LoRA goes to the model, via ComfyUI's own load_lora_for_models(model, None, …). So it chains like any other model-only loader, and you don't have to feed a CLIP you didn't want touched. If you want several in one node, the same pack ships a Power Lora Loader whose rows each get this same key fix.

Install

Manager, search ComfyUI-BCNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/0xBeycan/ComfyUI-BCNodes
pip install -r ComfyUI-BCNodes/requirements.txt

Restart and search BCNodes in the node library (it's under BCNodes/loaders). The requirements are opencv-python, postfx and caption-audit, none of which this node touches. Delete a leftover ComfyUI-AutoBypass folder from the pack's old name.

Where it bites

It fixes keys, not compatibility. A LoRA trained for a different architecture's module names still won't load - that's what the "match no module" count is telling you, and no rename is going to invent a module. The genuinely cross-compatible cases (same architecture, different export convention) are the ones it wins.

Second: some LoRAs also carry text-encoder tensors. This node only applies to the model, so those keys can't load here and will show up in the count. That's expected, not a failure - and it's the same reason LoraLoaderModelOnly exists.

Third: watch the console. The whole point of the node is a line of text you have to actually read. If you never open the console, you get the same silent partial load you started with, just for different reasons.