LoadLoraQwenImage (Selective Qwen Image layers from ai-toolkit)

The standard LoRA loader is a floodlight: it slaps the whole LoRA onto the whole network, every transformer block at once. Most of the time that's fine. Then you load an AnyPose-style pose LoRA on Qwen-Image-Edit and it starts dragging its own style across every image you touch, and you wish you could tell it to only bother the layers that do the posing. That's the exact problem LoadLoraQwenImage exists for. It's a LoRA loader with a laser pointer.

What it actually does

It's a drop-in replacement for the ordinary LoRA loader in a Qwen Image Edit workflow - same MODEL in, same MODEL out, same lora_name combo pulled from models/loras. The difference is that before it patches the model it walks the UNet's layer map, keeps only the layers whose weight paths match keywords you give it, and leaves everything else untouched.

Under the hood it's using ComfyUI's own LoRA machinery - model_lora_keys_unet() to enumerate layers, load_lora() to build patches, add_patches() to apply them - so it's not reinventing anything, just filtering. It also runs the LoRA state through comfy.lora_convert.convert_lora() first, which is why it handles ai-toolkit's PEFT-flavored naming without drama. LoRA state is cached per file, so reusing the same LoRA across a workflow doesn't reload it every run.

The inputs that matter

There are really only three you'll touch, and two of them are strings:

• layer_filter - comma- or newline-separated keywords matched as substrings against layer weight paths. transformer_blocks.0 means "only the first transformer block." Leave it empty and the LoRA applies to every available layer, i.e. the node behaves like a normal loader.
• exclude_filter - same format, but it removes layers. Applied after layer_filter, and it wins when both are set. Handy for the common case: "apply everywhere except the attention blocks" → exclude attn.
• strength_model - the usual 1.0 default, range −10 to 10, and yes, negatives are allowed if you want to try un-learning something.

Output is a single patched MODEL that goes straight into your KSampler. Workflow is boring in the best way: Checkpoint Loader (Qwen Image) → LoadLoraQwenImage → KSampler → VAE Decode.

One thing to know before you get fancy: Qwen Image's backbone has 60 transformer blocks (transformer_blocks.0 through .59), and the match is a substring check. transformer_blocks.0 doesn't mean just block 0 - it also matches blocks 10, 20, 30, 40 and 50, because .0 is inside all of them. If you really want only block 0, include transformer_blocks.0, in exclude_filter and cross your fingers about the neighbors. This is the trap, and the README's own examples quietly walk into it.

Install

The usual two routes, and there are no hidden dependencies - it only imports ComfyUI's own comfy.lora and folder_paths, so no extra packages, no model downloads beyond the LoRA itself:

cd ComfyUI/custom_nodes
git clone https://github.com/GZK1108/Comfyui-QwenLoraLoaderSelective
# restart ComfyUI

Or ComfyUI Manager → Install Custom Nodes → search "Comfyui-QwenLoraLoaderSelective". It shows up under loaders as LoadLoraQwenImage (Selective Qwen Image layers from ai-toolkit).

Where people get burned

The big one is the silent no-op. Filtering happens before patching, and missing keys are logged quietly (log_missing=False), so if your keywords don't match anything the node just returns the model unchanged and you get the exact same image out with zero error to explain it. When "nothing changed," first clear layer_filter entirely and confirm the LoRA does something at all, then re-add keywords. Same logic applies if your two filters cancel each other out - exclude everything and you've excluded everything.

Second, this was validated against LoRAs trained with ai-toolkit, the trainer that had Qwen-Image support first. LoRAs from other toolchains may name their keys differently, in which case your carefully chosen keywords won't match. Test on your own setup.

Honest take: if you're running one LoRA at strength 1.0 and it behaves, the stock loader is fine and this node is optional. It earns its keep when a LoRA is fighting your workflow - pose or expression LoRAs stamping their style onto unrelated edits, or two LoRAs colliding on the same blocks. That's a niche, but it's a real one, and this is the only loader I've seen that solves it without hand-editing a patch graph.