Convert LoRA Keys (Yogurt Nodes)

Every so often you download a LoRA and the loader just refuses it. No crash, no drama - it loads "fine" and then does nothing, or it throws a mismatch error because the tensor keys don't line up with what the model expects. That's the problem this node exists for. Convert LoRA Keys renames the keys inside a LoRA state based on a mapping you give it as JSON. Old key goes in, new key comes out, and suddenly the LoRA the community said was broken works.

The mechanism

A LoRA file is mostly a dict of named tensors - lora_unet_down_blocks_0_attentions_0_to_q.weight, that style of thing. The names encode where each tensor plugs in. Different trainers and different base architectures use different naming schemes, and if a LoRA was trained (or converted) with keys that don't match what your loader expects, the tensors get ignored or the whole apply fails. Renaming the keys rewrites those addresses, which is exactly how people port SD 1.5 LoRAs to SDXL-era naming, clean up LoCon vs. standard naming, or fix a LoRA someone re-exported with mangled keys.

The node does the rename in memory and hands you the fixed LoRA back - it doesn't touch your file on disk. You feed it the LoRA as a LORA object (this pack's "LoRA Load Only" node loads one without applying it, which is the intended pairing), plus a JSON object mapping old keys to new keys. The converted_count output tells you how many keys actually got renamed, which is your first sanity check: if it's zero, your mapping doesn't match the file's real key names.

The pack ships two helpers that make this practical: LoRA Stat Viewer (inspect the actual key patterns in a file) and Create LoRA Mapping JSON (builds a best-effort old→new mapping automatically). The workflow that makes sense: peek at the keys, generate the mapping, eyeball it, then convert. Hand-writing a full mapping from memory is how you get zero matches.

Inputs

• lora - the LoRA state to convert. Load it with the pack's LoRA Load Only node (or anything that emits a LORA object) rather than a regular LoRA loader, which applies it to the model immediately.
• mapping_json - a JSON object like {"old_key": "new_key"}. Multiline, so you can paste a big mapping without squishing it.

Outputs

• converted_lora - the renamed LoRA, ready to feed a loader, a merge node, or the pack's Save LoRA to write it back to disk as a new file.
• converted_count - how many keys matched and were renamed. Zero means your mapping is wrong, not that the node is broken.

Install

Standard Yogurt Nodes install. ComfyUI Manager → search "ComfyUI-YogurtNodes", or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/yogurt7771/ComfyUI-YogurtNodes.git
cd ComfyUI-YogurtNodes && pip install -r requirements.txt

Then restart ComfyUI. No extra downloads - this node is pure tensor surgery, no model files required.

Where people get burned

The trap is treating this as a magic cross-architecture converter. Renaming keys makes a LoRA load, but it cannot make a LoRA trained for one architecture's math work on another. As the training knowledge base puts it bluntly: a Flux LoRA does not run on SDXL, and renaming won't fix that - the layer structure itself differs. Key renaming is for fixing naming-scheme mismatches on compatible architectures, cleaning up bad exports, and re-targeting keys within a model family. If a genuinely incompatible LoRA still produces garbage after the rename, that's not the node's fault and no mapping will save it.

Also: always convert with the specific target in mind. The same keys can map differently depending on whether you're loading into a UNet, a DiT, or an SDXL structure, so test with converted_count and a single generation before you batch-convert your whole folder.