PM Block Selector

Ever merged two LoRAs and wished you could take the character blocks out of one and the style blocks out of the other? That's the whole job of PM Block Selector. It's the node that turns a plain "merge these two files" into "merge them, but only the layers I actually want from each."

It's part of LoRA Power-Merger (larsupb/LoRA-Merger-ComfyUI), the actively maintained fork of laksjdjf's LoRA Merger that's been around since mid-2024 and now ships 8+ merge algorithms with native support for SD, SDXL, DiT, Flux, Wan, and Qwen-era LoRAs. The pipeline it fits into looks like this: PM LoRA Power Stacker → PM LoRA Stack Decompose → a merge method node (TIES, DARE, SLERP, …) → PM LoRA Merger → Apply/Save. The Block Selector sits right before decompose, as an optional block_selection input on PM LoRA Stack Decompose. It's a pure config node - no model files, no math of its own, just a recipe that tells the merger which layers of which LoRA to scale.

How it works

Block Selector itself is deliberately dumb, and that's a feature. It takes a block definition - the per-model weight map produced by a sibling node like PM FLUX.2.Klein Blocks or PM KREA 2 Blocks - and an index, and packages them into a BlockSelection object. When decompose gets that object, it resolves the index against the actual LoRA stack order, matches each layer key of that LoRA against the definition's regex patterns, and scales the LoRA's up factor by the block's weight. A weight of 0 drops that block's contribution from the merge entirely.

Two mechanical details worth knowing, because they shape everything else:

• Block weights apply only to the up factor, not up and down together. Scaling both would square the weight, so a 0.5 would become a 0.25 - linear scaling keeps weight × delta behaving the way you expect.
• Only non-1.0 weights are stored. If a definition doesn't match a LoRA's architecture, every key resolves to 1.0 and the node quietly does nothing. That's the trap to watch for.

The inputs that matter

• block_definition - required. The BlockDefinition output of a model-specific block node. Feed it from the one that matches your LoRA's architecture.
• index - required, default 0. Which LoRA in the stack (0-based) to weight, per the tooltip. This is positional, not by name.
• block_selection - optional. The output of another Block Selector, for chaining.

The single output, block_selection, wires into PM LoRA Stack Decompose's optional block_selection input.

To weight more than one LoRA, chain selectors: each one merges its (index, definition) pair into the growing selection. Try to give two selectors the same index and the node raises a ValueError instead of silently overriding - annoying at first, but it catches real mistakes.

Installing it

Same as the whole pack. In ComfyUI Manager, search "LoRA Power-Merger" and install, or do it by hand:

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

requirements.txt is short but specific: mergekit (installed from Arcee AI's git repo, not PyPI) and lxml. Mergekit is the only heavy dependency, and it's the engine behind the SLERP/TIES/DARE family of merge methods. There are no model files to download - this node works on LoRAs you already have. Restart ComfyUI after installing.

Where people get burned

The biggest one is a breaking change from v2.4.0: Block Selector no longer takes a lora_stack input. Older saved workflows have the stack wired in and will load with a missing connection. The README is explicit - selectors now chain through index-based configs, so reconnect old chains by feeding one selector's block_selection output into the next.

Then there's the positional-index gotcha. The index refers to the stack's insertion order from the Power Stacker, not a filename. Reorder your LoRAs and every index silently points at a different file. If a merge suddenly ignores your careful weights, check the stack order first.

And if nothing seems to happen at all: check the console. The node logs [PM Block Selector] ... selection now covers N LoRA(s) - an empty selection means your definition didn't match the architecture, so everything stayed at 1.0.

Is it worth it? If you're stacking two LoRAs and the whole-file strength slider is doing the job, skip it. If you're merging three style LoRAs and one of them has a signature block you want to keep at full strength while taming the rest, this is the cleanest way to get surgical about it - no file surgery, no re-training, just a weighted merge.