Qwen-Image Lora Converter

If you've grabbed a Qwen-Image LoRA off ModelScope and loaded it in ComfyUI only to watch it do absolutely nothing, this is the node you were looking for. It's a one-trick converter: it takes a LoRA trained on Alibaba's ModelScope platform, rewrites its tensor names into the format ComfyUI's LoraLoader expects, and drops a converted .safetensors file next to the original. No API, no key, no internet - it runs entirely local, and it's genuinely the right tool for a very specific, very common failure.

Why this mismatch exists

Here's the situation in 2026: Qwen-Image is the Apache 2.0 family everyone actually builds on - the 20B MMDiT base from Alibaba's Tongyi lab, and the Qwen-Image-Edit line that became the default open instruction editor. A ton of the good LoRAs for it, like DiffSynth-Studio's popular F2P face LoRA, are hosted on ModelScope, Alibaba's own model hub, straight out of its hosted trainer.

The problem is a naming fight. ModelScope's trainer saves LoRAs in the PEFT/diffusers style: keys like transformer_blocks.0.attn.to_q.lora_A.default.weight with the low-rank matrices split into lora_A and lora_B, and a .default.weight suffix tacked on. ComfyUI expects lora.down.weight / lora.up.weight pairs under a diffusion_model. root prefix. Load a ModelScope file through a normal LoraLoader and ComfyUI quietly matches almost nothing - the LoRA "loads" and changes your output by roughly zero. That silent nothing is the trap, because there's no error to chase.

How it works

The node reads your chosen LoRA (safetensors directly, or falls back to torch.load for other formats), then rewrites every key:

• Strips the .default.weight suffix and renames lora_A → lora.down.weight, lora_B → lora.up.weight.
• Prefixes the result with diffusion_model., which is exactly where ComfyUI looks for unet-style weights.
• A second pass patches the transformer_blocks. / transformer.transformer_blocks prefix into diffusion_model.transformer_blocks.

Then it saves the result as original_filename_converted.safetensors in the same folder as the source. That's the whole job, and the whole dependency list: torch, safetensors, and ComfyUI's folder_paths. There's no requirements.txt because everything it imports ships with ComfyUI already.

The input, and the catch

One input: lora_file, a dropdown listing everything in ComfyUI's loras folder (subfolders included). That's the only knob, and it's the whole interface.

The catch is the output side: there are none. RETURN_TYPES is empty and the node is marked as an output node, so you can't wire it into anything. That's by design - it's a utility, not a graph element. You select the file, run the workflow once, and the converted file appears on disk. Then refresh (the README says press R or F5) and your new _converted.safetensors shows up in any LoraLoader dropdown. If you're converting a bunch of files, this means queueing a run per file; it's clunky, but it beats hand-renaming keys in a Python shell.

Install

ComfyUI Manager, or the two commands:

cd ComfyUI/custom_nodes
git clone https://github.com/SaturMars/ComfyUI-QwenImageLoraConverter

Restart ComfyUI and the "Qwen-Image Lora Converter" node appears under its own category. No model downloads, no extra Python packages - just drag in the LoRA you want converted and go.

Where people get burned

Two real gotchas, both grounded in the source. First, the node only converts keys that end in .lora_A / .lora_B; any lora_ key with a different suffix is silently dropped, and non-LoRA keys pass through untouched. So if your ModelScope file uses an unusual naming variant, you get a converted file that's just as dead as the original - check the console output, where the node prints Chinese log lines, and peek at the keys if you want certainty. Second, it's a file-format converter, not a model adapter: a Qwen LoRA stays a Qwen LoRA, and the Edit-line LoRAs that took over the ecosystem won't apply to the base model no matter how many keys you rename. It won't magically make a Qwen LoRA work on Flux, either - architecture lock-in doesn't care about your feelings.

Small thing worth knowing: the author (SaturMars) maintains this as a solo, single-purpose utility - one commit, MIT license, no issue tracker to speak of. For a 30-second rename job, that's fine. Just don't expect a changelog.