LoRA Block Weight (FLUX.1)

Every FLUX.1 LoRA loads through a single strength scalar, and that's the whole problem when a LoRA misbehaves. It overpowers your prompt, bleeds its style onto things you didn't ask for, or fights the other LoRAs stacked on top of it - and with a normal loader you can't reach inside to fix any of it. LoRA Block Weight (FLUX.1) is the tool that cracks the case open. It's a drop-in LoraLoader replacement that patches FLUX.1's transformer one block at a time, so you can see exactly which of the 57 blocks carry the effect you want and which are dead weight (or actively harmful).

The technique is older than FLUX. Per-block LoRA weighting has been a staple of A1111 since hako-mikan's sd-webui-lora-block-weight - the extension people grab when a second LoRA starts wrecking an image. This node ports that idea to ComfyUI's DiT world, and it fits naturally: FLUX.1's transformer is 19 double-stream blocks (D00–D18) followed by 38 single-stream blocks (S00–S37), a clean structure to slice on.

How it works

The node loads your LoRA file and groups its keys by block index, using per-model regexes against the state-dict keys (e.g. diffusion_model.double_blocks.{N}.). Each group is then applied with its own scalar strength via ComfyUI's add_patches, instead of one global weight. You name a single target block, and everything else holds at a baseline.

The inputs that matter are just four:

• target_block - the block to vary, D00..S37. Leave it empty or unknown and nothing is targeted: the whole LoRA just sits at baseline_weight, which is handy as a control.
• target_value - strength for that one block, 0–2.
• baseline_weight - strength for every other block. Set it to 1.0 for knock-out mode ("what breaks when this block is removed?") or 0.0 for solo mode ("what does this block contribute alone?").
• clip_strength - the CLIP/text-encoder half of the LoRA, applied uniformly.

The transformer's input/output layers (img_in, txt_in, time_in, vector_in, guidance_in, final_layer) always follow baseline_weight and are never sweep targets - they have no block index.

Outputs are a patched model, a patched clip (wire both straight into a KSampler), and a small info STRING that reports how many patches applied and how many keys were skipped. That counter is genuinely useful: it tells you when a LoRA was trained for a subtly different architecture and half its keys don't resolve.

What it's actually for

Be honest with yourself: this is a diagnostic microscope, not a daily driver. You don't use it to load every LoRA - you use it when one misbehaves. The intended workflow is to drive it from an Efficiency Nodes XY Plot: put the block tags on the X axis, 0,0.25,0.5,0.75,1.0 on the Y, and render a 57×5 grid. Columns that look identical at every strength are blocks you can lower freely; columns that visibly change are the blocks carrying the LoRA's identity. Once you know the layout, you move the recipe to the pack's Custom node for the final tuned load.

Install

Via ComfyUI Manager, search "LoraBlockWeight" and install. Or manually:

cd <ComfyUI>/custom_nodes
git clone https://github.com/Baldwinzc/ComfyUI-LoraBlockWeight.git

Then restart ComfyUI. No extra dependencies, no model downloads, no API key - the node only needs numpy, Pillow, and torch, which ComfyUI already pulls in. (The repo is listed as Baldwinzc/ComfyUI-LoraBlockSweep on comfy.icu, but the author's own README and pyproject call the package ComfyUI-LoraBlockWeight; the clone URL above is what the README tells you to use.)

Gotchas

The pack relies on stable comfy.lora / comfy.sample internals, so a future ComfyUI refactor can break loading - the author says to open an issue if it does. And remember the number one trap with block weighting: the MSE ranking is experiment-specific. A block that reads as negligible for one prompt/seed can matter on the next, so re-check before you permanently zero anything.