Apply Reweighted LoRA
Per-block LoRA strength for WAN, Qwen, Flux and friends
- model
- clip
- model
- clip
- stats
A LoRA's strength slider is one number for the whole thing. If a LoRA is warping composition too much in early blocks but you love what it does to detail late, a single strength_model value can't separate those two effects - turning it down fixes the composition problem and kills the detail you wanted. Per-block LoRA control has been a known fix for this since the A1111/Forge-era "Lora Block Weight" extension let people dial IN/MID/OUT blocks independently. This node brings that same idea natively into ComfyUI, with presets that know how to map "front/mid/back" onto the actual block layout of modern architectures like WAN, Qwen, and Flux rather than just SD1.5/SDXL.
How it works
Under the hood it detects the LoRA's block indices (or you can tell it explicitly which architecture's layout to assume via block_preset) and applies separate multipliers to different regions of the network: front_scale, mid_scale, back_scale, and last_block_scale each bias the LoRA's influence toward or away from a stage of the model, on top of the overall global_scale and the standard strength_model/strength_clip you'd set on any LoRA loader. scale_target decides whether the block scaling applies to the LoRA's "up" weights, "down" weights, or both - standard LoRA A/B-matrix terminology, and not something to touch unless you already understand which half of a LoRA you're trying to affect.
The node's own description spells out what happens to the result: it reweights the LoRA in memory, and if save_reweighted is on (default true) it writes the exact reweighted tensor dict out to your output/ folder as a new .safetensors file - so the specific combination you land on is reproducible and reusable outside this one graph, not just a runtime patch. verify_roundtrip (default true) does a sanity check on that saved file; treat a failed roundtrip as a reason to distrust the output rather than something to ignore.
The inputs and outputs that matter
model/clip(MODEL / CLIP) - the base model and CLIP to apply the reweighted LoRA to.lora_name- picked from yourmodels/lorasfolder, same as any LoRA loader.block_preset(auto / wan / qwen / flux / zimg-turbo / sd / sdxl / generic) - tell the node which architecture's block layout to assume.autotries to detect it; picking the correct one explicitly is safer if you're working with an architecture the auto-detect might not recognize well.front_scale/mid_scale/back_scale/last_block_scale(default 1 each, -5 to 5) - the actual per-region dials. Start by moving just one at a time from 1.0 rather than adjusting several simultaneously - it's hard to attribute a change otherwise.save_reweighted(default true) - writes a real new.safetensorsfile tooutput/every run.
Three outputs: model, clip (the reweighted, applied versions - wire these onward exactly like a normal LoRA loader's outputs), and stats (a DICT of information about what the node did, useful for a Debug Input node if you want to inspect it).
How to install it
Via ComfyUI Manager: search "WAS_Extras", install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/WAS_Extras
Restart ComfyUI. No extra dependencies for this node - it operates on LoRA files you already have downloaded.
Common issues & troubleshooting
Adjusting front/mid/back scales does nothing noticeable. The most likely cause is block_preset guessing the wrong architecture - if auto misdetects the layout, the front/mid/back split lands on the wrong tensor indices and the scaling has no meaningful effect. Set block_preset explicitly to match your base model instead of trusting auto blindly, especially on less common architectures.
Output folder is filling up with .safetensors files. save_reweighted writes a new file on every run by default. If you're iterating quickly through many combinations, either turn it off while experimenting and only re-enable it once you've settled on values, or reuse output_filename so runs overwrite instead of accumulate.
verify_roundtrip failed. Don't trust the output as-is - a failed roundtrip means what got saved doesn't cleanly reload as what was applied, which is exactly the kind of silent corruption this check exists to catch.
Went looking for a general "reduce this LoRA's effect on composition" preset and there isn't one. There isn't - this node gives you the dials (front_scale and friends), not a solved recipe. The A1111-era block-weight community wisdom (pull down "IN" blocks to tame overall composition influence while leaving detail blocks alone) is the closest analogy, but the exact block mapping is architecture-specific, which is the whole reason block_preset exists.
Inputs (16)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | The model the reweighted LoRA is applied to. | |
| clip | CLIP | The clip the LoRA's text-encoder half is applied to. A LoRA with no text-encoder tensors leaves it untouched. | |
| lora_name | COMBO | The LoRA file to reweight, from your LoRA folder. It is read from disk on every run, so the original file is never modified. | |
| strength_model | FLOAT | 0.80-5–5 | How strongly the reweighted LoRA is applied to the model, before any block scaling. 1.0 is full strength; a negative value pushes away from what the LoRA learned. |
| strength_clip | FLOAT | 0.80-5–5 | The same for the clip. Lowering it while leaving strength_model alone keeps the LoRA's look without its trigger words dominating the prompt. |
| global_scale | FLOAT | 1.00-5–5 | Multiplier applied to every block before the three below. 1.0 changes nothing; use it to turn the whole reweighting up or down once the balance between the thirds is right. |
| front_scale | FLOAT | 1.00-5–5 | Extra multiplier for the first third of the blocks, which carry composition and overall shape. Lower it to keep a LoRA's style while letting the prompt decide the layout. |
| mid_scale | FLOAT | 1.00-5–5 | Extra multiplier for the middle third, which carries subject and structure. This is the third to lower when a character LoRA is overriding the face you asked for. |
| back_scale | FLOAT | 1.00-5–5 | Extra multiplier for the last third, which carries detail, texture and surface style. Raise it to keep a LoRA's look while its subject influence is turned down. |
| last_block_scale | FLOAT | 1.00-5–5 | A further multiplier for the final block alone, on top of its third's. That block sits closest to the output, so small changes here show up strongly in fine detail. |
| scale_target | COMBO | up_only | Which half of each LoRA pair is scaled. `up_only` is the usual choice and scales the result linearly. `both` scales the two halves and so squares the effect, which is much stronger for the same numbers. `down_only` is there for comparison. |
| block_preset | COMBO | auto | Which model family's block naming is read to find each block's number. `auto` works it out from the LoRA's own keys and is right almost always; name the family if the stats output reports 0 blocks detected. |
| filter_by_block_range | BOOLEAN | true | Drop tensors for blocks the connected model does not have. This is what lets a LoRA trained on a larger version of a model be applied to a smaller one instead of failing. |
| save_reweighted | BOOLEAN | true | Write the reweighted LoRA to output/loras. Switch it off while hunting for the right numbers, then on for the run worth keeping. |
| output_filename | STRING | Name for the saved copy. Left empty, a name is built from the source file and every scale, such as 'style.reweighted.up_only.g1.00.f1.0.m1.0.b1.0.L1.0.safetensors', so two settings never overwrite each other. | |
| verify_roundtrip | BOOLEAN | true | Read the saved file back and compare it tensor by tensor with what was applied, reporting the answer in the stats output. Costs a second read of the file; it is what proves the saved copy behaves the same as this run. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| model | MODEL | The model with the reweighted LoRA applied. |
| clip | CLIP | The clip with the reweighted LoRA applied. |
| stats | DICT | What the run did: which naming scheme was detected, how many blocks were found, how many tensors were scaled, dropped and kept, where the copy was saved with its SHA-256, and whether the round-trip check passed. Feed it to a debug node to see why a reweighting had no effect. |