LoRA Block Weight Batch (FLUX.1)

The single-block FLUX.1 node is a scalpel, but it's designed to be driven by an XY Plot, which means installing Efficiency Nodes and wiring up the axes. LoRA Block Weight Batch (FLUX.1) skips all that: it's a self-contained sweep machine. Feed it a model, a VAE, conditioning and a latent, and it loops over every (block, value) pair internally - patching, sampling, decoding, and stacking the results into one batched IMAGE for you. No external orchestration required.

It exists because the author's actual research workflow needed 95–285 images per sweep, and wiring that through a plot node was the wrong shape. This is the node behind every demo grid in the README.

The inputs

You get the full sampler stack plus the sweep controls:

• model, vae, positive, negative, latent_image - the usual KSampler ingredients.
• seed, steps, cfg, sampler_name (default euler), scheduler (default simple), denoise - set these like you would on a KSampler for FLUX.1.
• block_list - comma-separated block tags, defaulting to all 57 (D00..S37). This is the input you'll actually trim.
• value_list - the strengths to try per block, default 0,0.25,0.5,0.75,1.0.
• baseline_weight - 1.0 for knock-out mode (each block removed in turn), 0.0 for solo mode (each block in isolation).

Outputs are four: images (the batched IMAGE, in block-major, value-minor order), an info STRING summarizing the sweep, and blocks_used / values_used - the exact strings you ran, which you feed straight into the Save Grid node so the labels can't drift out of sync.

The honest cost

A full sweep is 57 blocks × 5 values = 285 images. On a consumer card that's hours. The README's first-round recipe scans just the 19 double blocks (95 images) and treats that as enough signal to start, expanding to the single blocks only if you need more. There's also a sparse 10–12 block recipe in USAGE.md if you want the active neighbourhood in under 100 renders. Don't skip this planning step; a full sweep on a 4070 is a "start it before bed" operation, not a "let me tweak the prompt and rerun" one.

The one real limitation

Read this twice: CLIP-side LoRA patches don't apply here. The positive/negative conditioning is already encoded upstream, so the node's contribution is transformer-only. If your LoRA's effect lives partly in the text encoder, the batch result understates it - for a complete picture, use the single-block node with an XY Plot instead, where the CLIP side is patched via clip_strength.

Install and dependencies

Via ComfyUI Manager, search "LoraBlockWeight". Or:

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

Restart ComfyUI. No extra dependencies beyond what ComfyUI already ships (numpy, Pillow, torch), no model downloads, no API key. The pack leans on stable comfy.lora / comfy.sample internals, so a ComfyUI refactor can break loading - check the repo issues if a future update stops it from working.

Gotchas

Out-of-range or mistyped block tags raise a loud error rather than silently producing a wrong grid - that's deliberate, and it'll save you from mislabeled results. And don't trust a single sweep's ranking as gospel: MSE is a pixel-delta proxy for one prompt, seed, and resolution. Treat the sweep as a starting map, not a permanent prune list.