Convert Lora Keys

LoRA files are just dictionaries of tensors, and the thing that decides whether a LoRA works on a given base model is mostly its keys. Different trainers, different pipelines, and different architectures expect different naming conventions - lora_down.weight here, lora_A.weight there, whole prefixes that change depending on the model family. Convert Lora Keys is the node that rewrites those names: you hand it a mapping of old keys to new keys, and it produces a renamed copy of the LoRA.

It's an oddly niche power tool, and you'll know you need it the day you need it. Say you're porting a LoRA from one trainer's export format to another, or adapting a file to a naming convention a new workflow expects. Or you downloaded a LoRA whose keys don't match the model family you actually want to run - remapping the keys is the last-ditch way to make it at least attempt to load somewhere it doesn't natively belong.

The mechanism is dead simple. It takes your lora state dict and a mapping_json string - a JSON object where each key is a current LoRA key and each value is the target key. For every entry it clones the tensor and files it under the new name; what comes out is a fresh dict of renamed tensors on the converted_lora output. The heavy lifting isn't the node, it's the mapping, and that's where people get hurt.

The big gotcha is hard to spot until it's too late: the output only contains keys present in the mapping. Anything you didn't map is silently dropped, not passed through. Feed it a half-finished mapping and you'll get a half-finished LoRA with no error, no warning, just quietly missing layers. So either feed it a complete mapping or accept that you're deliberately building a partial LoRA. The second gotcha is quality of mapping itself - a wrong mapping doesn't fail, it produces a LoRA that loads but does nothing useful, and debugging that is miserable.

Where does the mapping come from? You can hand-write one for a small, surgical conversion. For anything bigger, the pack's other mapping node, Create Lora Mapping Json, will guess a full mapping between two LoRAs by matching their structure - but it's a guesser, so review its output before trusting it. A natural pattern is to run Create Lora Mapping Json, read the JSON in a text node, eyeball the suspicious rows, then paste the final version into this node's mapping_json field.

Installation is the pack's standard two-liner with no extra dependencies (pure torch and safetensors):

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/Comfyui-LoraUtils

Restart ComfyUI and you'll find the nodes under LoraUtils. ComfyUI Manager users can search Comfyui-LoraUtils instead. It's a small pack from lrzjason (a.k.a. xiaozhijason on Civitai) with a quiet community footprint, so it behaves like a focused hobbyist tool: the mechanism is clean, the edge cases are yours, and the "verify before you trust" lesson is the actual cost of admission.