LoRA Layers Operation

You've felt this one. You stack a character LoRA on a style LoRA and suddenly the faces are right but the composition is weird, or the style LoRA's "signature" - the thing that makes every image look like the trainer's portfolio - is smeared all over your output. Dropping the whole LoRA's strength fixes it about half the time and breaks the rest. What you actually want is to silence a handful of layers and leave the rest alone. That's what LoRA Layers Operation does: pick the layers, scale them or wipe them, get a new LoRA out the other end.

The lineage here is the old LoRA block weight idea from the A1111 world, where people tweaked "IN/OUT/MIDD" block groups to control whether a LoRA shaped structure or fine detail. This node is that concept with a scalpel instead of a hatchet: instead of three big groups, you name exact transformer blocks and operate on them directly.

The mechanism is straightforward. The node takes your LoRA state dict, runs a regex pattern over every key name, and uses a captured group as the layer index. Then for any key whose index is in your layer_indices list, it either multiplies the weights by the scale_factor - or, when scale is 0, replaces them with zeros. Everything else is left untouched, and it clones the tensors first, so your input LoRA is never mutated in place.

Three inputs do the work:

• layer_pattern - the regex that finds layer indices in key names. The default, .*transformer_blocks\.(\d+)\., matches SDXL/Illustrious/Flux-style keys like ...transformer_blocks.11.attn1... and extracts 11 as the index.
• layer_indices - a comma-separated list with range support. 59 targets one layer; 10,11,12 targets three; 50-53 targets 50 through 53. Leave it empty and the LoRA passes through unchanged.
• scale_factor - the multiplier applied to matched layers, or 0 to wipe them entirely. It can go negative, though inverting a layer usually isn't what you want; zero and mild positive scaling are the real dials.

The output modified_lora feeds the rest of the pack - Merge LoRA to Model to apply it, Save LoRA to persist it as a new file.

Two gotchas bite everyone once. First, the default pattern only understands transformer_blocks naming. LoRAs trained with different conventions - or an SD1.5 UNet LoRA, which uses input_blocks.N... / output_blocks.N... names - won't match, and the node will quietly do nothing while printing a cheery log line about modifying zero parameters. Second, you need to know which indices exist in the first place. Run LoRA Stat Viewer on the same LoRA to see the block indices in the file; guessing "layer 59" because someone's Flux LoRA had 59 blocks will miss on a 12-block SDXL LoRA.

Installation is the standard two-step, with no extra dependencies - the pack only uses torch and safetensors, both already in ComfyUI:

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

Restart ComfyUI and the nodes live under LoraUtils. ComfyUI Manager users can just search for Comfyui-LoraUtils. It's a small pack by lrzjason (also xiaozhijason on Civitai) with a quiet community footprint, so treat it as a hobbyist tool - solid, but you're on your own for support.

Worth saying plainly: per-layer surgery is fiddly and easy to overdo. Zeroing out the wrong layer range will just nerf the LoRA. Start with the layers the LoRA's own training recipe cared about, test at a fixed seed, and compare before you commit. When it lands, though, it lands hard - this is the one node in the pack that does something stock ComfyUI genuinely can't.