Wan21 Block Lora Select

A LoRA doesn't apply evenly. Trained weights concentrate in some transformer blocks and barely touch others - one block might be doing most of the work for a character's face, another for overall style, a third contributing almost nothing useful and mostly adding bleed. This node lets you decide, block by block, which of Wan's transformer layers a LoRA is actually allowed to touch, instead of accepting the all-or-nothing strength slider everyone starts with.

This is a real, if niche, technique the community has been chasing lately - selectively toggling LoRA blocks to reduce bleed, isolate a face LoRA from a style LoRA, or chain two LoRAs where each only owns the blocks it's good at. It's a different move from Kohya's block-swapping (which offloads blocks to CPU RAM to save VRAM during training) - this is purely an inference-time decision about which of an already-trained LoRA's blocks get used at all.

How it works

The node exposes forty sliders - one for each transformer block in Wan 2.1's diffusion model, blocks.0. through blocks.39. - each an alpha multiplier for that block. The description is direct about what a value of 0 means: "a value of 0 removes the block altogether." Set a block to a non-zero value and the LoRA's weights for that block get applied, scaled by that number; leave it at 0 and that block is skipped entirely, as if the LoRA had never touched it.

Here's the part that catches people out on the first try: every block defaults to 0. That means straight out of the box, this node excludes all forty blocks - a LoRA routed through it with every slider left untouched does nothing at all. You have to deliberately raise the blocks you want engaged. That's by design, not a bug: it's built for isolating a handful of blocks rather than starting from "everything on" and pruning down. Community testing on this kind of block-selective loading has found things like a character's likeness concentrating in one contiguous stretch of blocks while style spreads across the rest - worth actually testing on your own LoRA rather than guessing, since which blocks matter varies by what the LoRA was trained on.

The sliders technically go up to 1000, but treat that as headroom, not a target - a normal LoRA alpha lives close to 1.0, and most people will only nudge a handful of blocks a small amount above or below the LoRA's own baseline strength, not run any of them anywhere near the slider's ceiling.

The output - and a quirk worth flagging

The single output is named blocks, typed SELECTEDDITBLOCKS - not a MODEL. Despite the field's tooltip text reading "The modified diffusion model," this node doesn't touch your model directly; the output type makes clear it's packaging your forty alpha choices into a block-selection map. That map is meant to be wired into whichever Wan LoRA-loading node in your workflow accepts a block selection alongside the actual LoRA file - that's where your model actually gets patched. Don't wire this node's output straight into a KSampler expecting a model; the type won't match, and it isn't what this node does.

How to install it

Part of the KJNodes pack. Through ComfyUI Manager: search "KJNodes for ComfyUI," install, restart. Manually: cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt (portable Windows build: python_embeded\python.exe -m pip install -r ...), then restart. This node needs no extra models of its own - it's working with a LoRA and Wan model you've already got loaded elsewhere in the graph.

Common issues & troubleshooting

The LoRA seems to do nothing at all. Check your sliders first. Every block starts at 0, meaning zero blocks are active by default - you have to turn blocks on yourself. This is the single most common trap with this node.

You have no idea which blocks to raise. There's no shortcut here beyond testing - bump a contiguous range, render, compare, adjust. Community experience with block-selective LoRA tools points at likeness and style often occupying different, largely separable ranges of blocks, but the exact split is specific to how each LoRA was trained, not a universal number you can copy.

Wiring it into the wrong downstream node. The output is a block-selection map (SELECTEDDITBLOCKS), not a model. It needs a Wan LoRA loader that specifically accepts a block selection input - a generic LoRA loader or a plain model input won't take it.