ComfyUI Node

Patch LoRA (adaLN)

Your LoRA hits a KeyError for adaLN weights? This node adds the keys it never trained

By Franklyc·Created about a year ago·Updated 12 months ago· 7
Patch LoRA (adaLN)
    • patched_lora_name
    • patch_status
    lora_name

    So you downloaded a perfectly good LoRA, dropped it in, queued the prompt, and got something like KeyError: 'lora_unet_final_layer_adaLN_modulation_1.lora_down.weight' not found. The model loads. The LoRA loads. The combination doesn't, because the architecture the LoRA was trained on never had an adaLN_modulation_1 module in its final layer, and the loader on your side expects those keys to be there.

    That's exactly the moment Patch LoRA (adaLN) exists for. It's a one-trick utility node: it opens the LoRA file, finds the missing adaLN_modulation_1 weights, fills them with zeros, and writes out a patched copy. That's the whole job, and it does it without touching your original file.

    Why this happens

    LoRA compatibility isn't all-or-nothing in the way "a Flux LoRA won't run on SDXL" is - that's still true, and no patcher fixes it. The subtler case is two checkpoints that are nearly the same architecture, where one dropped a module. The known real-world trigger is Flux LoRAs loaded through the Nunchaku path (quantized Flux for low VRAM), whose LoRA loader is stricter about final_layer keys than the stock one. Some community-trained Flux LoRAs were made on pruned or variant checkpoints that lack those weights, so they load fine everywhere else and then die specifically there. Rather than regenerate the LoRA, you just give the loader the keys it wants.

    How the node works

    Under the hood it's the hotfix script from tazztone/patch_comfyui_nunchaku_lora, wrapped in a GUI. It loads the state dict with safe_open, then checks three common key prefixes - lora_unet_final_layer, final_layer, and base_model.model.final_layer. For whichever matches, if it finds ..._linear.lora_down.weight and ..._linear.lora_up.weight but not the matching adaLN_modulation_1 pair, it creates zero tensors with the same shapes as the linear ones and adds them.

    Here's the reassuring part: because the added weights are all zeros, the LoRA's math is untouched. The delta a LoRA applies is up @ down, and zero times anything is zero. You're not changing the artistic output - you're just making the loader stop complaining. The node saves the result as my_lora_patched.safetensors right next to the original, then skips future runs: anything with _patched in the name gets skipped, and if the patched file already exists it returns it without reworking.

    Inputs and outputs

    Only one input matters, and it's a dropdown:

    • lora_name - picks from every .safetensors in your models/loras folder. That's it.

    Two string outputs, and here's the trap: neither is a LoRA tensor. You don't wire these into a LoraLoader. They're for you:

    • patched_lora_name - the filename of the new _patched.safetensors.
    • patch_status - a human-readable message ("Success!", "Skipped", "No patch needed").

    Run the node once, read the status, then use the patched file in your normal LoraLoader.

    Installing and running it

    Install it the usual way, via ComfyUI Manager (search "ComfyUI LoRA adaLN Patcher Node") or:

    cd ComfyUI/custom_nodes/
    git clone https://github.com/Franklyc/comfyui-lora-adain-patcher-node.git
    

    Restart ComfyUI, and it appears under Add Node > loaders/patchers > Patch LoRA (adaLN). No requirements.txt, no model downloads, no GPU needed - it only depends on torch and safetensors, which ComfyUI already ships. You're not even running inference; it's a file editor with a nicer face.

    The gotchas that will bite you

    • Refresh your browser after it succeeds. The README calls this out and it's the #1 "it doesn't work" moment: ComfyUI won't see _patched.safetensors in your LoRA dropdown until you hit refresh. This is a one-time operation - patch, refresh, load, delete the node from your workflow.
    • "No patch needed" is good news. It means your LoRA already has the keys; the failure you're seeing is coming from somewhere else, and this node can't help.
    • It only reads safetensors. A .ckpt LoRA won't even get in the door.
    • Don't run it as a fix for architecture lock-in. A Flux LoRA on an SDXL model is incompatible in a way no amount of zero-weight keys repairs.

    It's a narrow tool for a narrow, miserable, and weirdly common failure. Keep it in your back pocket for the next time a LoRA decides its keys don't exist.

    Categoryloaders/patchers

    Inputs (1)

    NameTypeDefaultDescription
    lora_nameCOMBO0 options:

    Outputs (2)

    NameTypeDescription
    patched_lora_nameSTRING
    patch_statusSTRING