PM LoRA Modifier

Most LoRA strength dials are global - one knob for the whole network. But different blocks do different jobs: early UNet blocks handle coarse structure, the middle block holds the model's "identity," late blocks sharpen details. This node lets you scale a LoRA's layers block by block, so you can boost the style-carrying middle block while taming a loud early block. It's block-weight-style control, implemented cleanly for the pack's merge pipeline.

Where does it fit? It sits between your stack and the merge: take a LoRAStack, apply block scales, and pass the modified stack onward. It's also genuinely useful before sampling, to test whether a LoRA's effect is coming from the blocks you think it is.

How it works

You give it a JSON string describing which blocks to scale and by how much. The node parses it, matches blocks by their key names (it auto-detects SD/SDXL vs DiT architecture), and produces a scaled copy of the stack - non-destructively, so the original is untouched. The format is explicit:

{
  "mode": "sdxl_unet",
  "blockScales": {
    "input_blocks.0": 1.0,
    "input_blocks.1": 0.8,
    "middle_block.1": 1.2,
    "output_blocks.0": 0.9
  }
}

mode is sdxl_unet, sd_unet, or dit, and the block names follow the ComfyUI key conventions - input_blocks.N, middle_block.N, output_blocks.N for UNet-style, layer indices for transformers. Scale 1.0 = leave alone, above 1.0 = boost, below = reduce.

The inputs that matter

• key_dicts - the LoRAStack to modify.
• blocks_store - the JSON string above. This is the field you'll spend your time on; it's a plain string widget, so paste carefully.

Output is a modified LoRAStack with the same shape, ready for decompose/merge or the stack sampler.

Installing

Part of the LoRA Power-Merger pack. ComfyUI Manager (search "LoRA Power-Merger") or:

cd ComfyUI/custom_nodes
git clone https://github.com/larsupb/LoRA-Merger-ComfyUI
cd LoRA-Merger-ComfyUI
pip install -r requirements.txt

Restart ComfyUI. Dependencies: PyTorch, lxml, mergekit.

Common issues

JSON syntax errors are the #1 failure - a missing comma or quote and the node rejects the whole string, and the error is often terse. Validate the JSON in any linter before pasting. The second trap is mismatching the mode to your architecture: an SDXL key scheme against a DiT LoRA silently matches nothing, and you get an unmodified stack (no error). And block names are exact - input_blocks.0 isn't the same as input_blocks_0. If you want to compare variants, this pairs naturally with the Stack Sampler: modify, sample, compare.