LoRA Block Filter (Apply)

A LoRA isn't one adapter. It's one small adapter per targeted layer, and a transformer has dozens of layers. The concept you trained - the character, the object, the pose - usually lives in a handful of blocks, while the rest of the file carries small, diffuse changes that compound into a global style shift: extra saturation, contrast, lighting. LoRA Block Filter is the half of the LoRA Block Surgeon pack that lets you say "just the concept blocks, not the rest." It's a drop-in replacement for LoraLoaderModelOnly with a per-block filter: wire it the same way, type 31-35, and only those blocks get patched into the model.

The headline, because it's easy to get wrong: nothing is written to disk. The .safetensors is opened read-only and the block selection is applied to an in-memory copy of the state dict, so your file is byte-identical after every run. There's deliberately no "save pruned copy" path. If you came here hoping to shrink a LoRA file, this isn't that tool - it's about controlling what gets applied at inference time, not what's stored.

How it works

Under the hood it's unglamorous and that's the point. The node loads the LoRA with ComfyUI's own load_torch_file, parses your block spec into a set of indices, builds a filtered copy of the state dict, then hands it to the exact same patcher LoraLoaderModelOnly uses. It caches one loaded file, so flipping a block spec doesn't re-read a 300 MB adapter from disk every run. It also matches the block-numbering conventions across base models - blocks.N, transformer_blocks.N, single_blocks.N, double_blocks.N, and the _N_ variants Kohya-converted files use.

The inputs that matter

Most of the schema reads like any LoRA loader, with one extra field:

• model - your checkpoint, straight from the model loader.
• lora_name - pick from your loras folder. Tooltip: opened read-only, never modified.
• strength_model - same strength dial as every loader, default 1.0.
• blocks - the whole point. 31-35 or 0-2,31,35. Empty string plus keep mode applies no main blocks at all - which is a deliberate behavior, and the node warns you about it in the console.
• mode - keep (apply only these blocks) or drop (apply everything except these).

Current builds also expose four optional toggles - include_main_attention, include_main_mlp, include_token_refiner_attention, include_token_refiner_mlp - all defaulting to on. They matter almost exclusively for MiniMax H3-style checkpoints with a separate token-refiner namespace. Token-refiner blocks carry their own indices and never respond to numeric ranges; they're controlled only by those toggles.

The outputs are model (into your sampler) and applied (a STRING report of exactly which blocks were kept and excluded, with per-group tensor counts). The same report lands in the ComfyUI console under the [LoRABlockSurgeon] prefix - deliberately. A block filter that quietly applies the wrong set looks identical to one that works, so this pack shouts what it did.

One rule worth internalizing: embedders, heads and other tensors with no numbered block are always applied, in both modes. They're not blocks, and dropping them would change the adapter in a way your block spec never asked for.

Install

ComfyUI Manager, search LoRA Block Surgeon, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Hearmeman24/ComfyUI-LoRABlockSurgeon

Then restart ComfyUI. That's the whole install - no requirements.txt, no model downloads, nothing but the torch ComfyUI already ships.

Where people get burned

• Block numbers are base-model specific. The source is verified against Krea (28 blocks), WAN 2.2 (40) and LTX 2.3 (48). A 31-35 that's perfect for one base means something completely different on another, and a spec naming blocks the LoRA doesn't have is ignored - with a console warning, but ignored. Profile first (see LoRA Block Profiler), then copy the range it gives you.
• Phantom-block silence. The whole failure mode the pack is built to prevent is believing you pruned a LoRA while the full thing renders. Watch the console warnings, not just the image.
• strength_model at 0 short-circuits to a passthrough with a clear log line, so you're not left wondering why nothing changed.

It's a niche tool, honestly - most people never need to know where a LoRA's energy lives. But when your character LoRA drags a color cast behind it that you can't prompt away, being able to amputate the diffuse style blocks and keep the concept is the difference between tossing the file and keeping it.