Nodes/WAS_Extras/WAS Apply Reweighted LoRA
ComfyUI Node

WAS Apply Reweighted LoRA

Per-block LoRA strength for WAN, Qwen, Flux and friends

By WASasquatch·Created 3 years ago·Updated 17 days ago· 43
WAS Apply Reweighted LoRA
  • model
  • clip
  • model
  • clip
  • stats
lora_name
strength_model0.80
strength_clip0.80
global_scale1.00
front_scale1.00
mid_scale1.00
back_scale1.00
last_block_scale1.00
scale_targetup_only
block_presetauto
filter_by_block_rangetrue
save_reweightedtrue
output_filename
verify_roundtriptrue

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 your models/loras folder, 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. auto tries 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 .safetensors file to output/ 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.

Categorymodel/LoRA

Inputs (16)

NameTypeDefaultDescription
modelMODEL
clipCLIP
lora_nameCOMBOLoRA filename from models/loras
strength_modelFLOAT0.80-5–5
strength_clipFLOAT0.80-5–5
global_scaleFLOAT1.00-5–5
front_scaleFLOAT1.00-5–5
mid_scaleFLOAT1.00-5–5
back_scaleFLOAT1.00-5–5
last_block_scaleFLOAT1.00-5–5
scale_targetCOMBOup_only3 options: up_only, down_only, both
block_presetCOMBOauto8 options: auto, wan, qwen, flux, zimg-turbo, sd, +2
filter_by_block_rangeBOOLEANtrue
save_reweightedBOOLEANtrue
output_filenameSTRINGOptional; leave blank for auto-naming
verify_roundtripBOOLEANtrue

Outputs (3)

NameTypeDescription
modelMODEL
clipCLIP
statsDICT