WAS Power LoRA Merger Options

This node produces nothing on its own - it's a settings bundle you plug into the options input on WAS Power LoRA Merger (its own article, and the node that actually does the merging). It's optional there, so you only need this when the merger's own defaults for your chosen mode aren't giving you what you want.

How it works

The fields are grouped by which merge mode they affect, and most of them are inert unless the Merger is set to the matching mode. Roughly:

SVD / rank group (affects svd, rebase, add-diff, add-orth, diff-export, moe): rank (default 32; set to 0 for auto-rank based on an energy threshold), auto_rank_threshold (default 0.99, only used when rank is 0 - higher keeps more singular-value energy, meaning a larger effective rank), preserve_norm (svd only - keeps the average per-module delta norm stable after merging, so overall strength doesn't drift), and cap_mult_enable/cap_mult (svd only - hard-caps the merged module norm to cap_mult × mean(source norms), a safety rail against one LoRA's contribution dominating).

Precision: dtype (default bf16 - what gets saved to disk), compute_dtype (default auto - the internal merge math precision; auto prefers bf16 when it hits mixed input dtypes), and cpu (force the merge onto CPU instead of GPU - slower, but frees VRAM if your GPU is busy).

Filtering: include_patterns/exclude_patterns - comma-separated substrings matched against module name prefixes, so you can restrict a merge to (say) only attention blocks, or exclude specific modules, without touching the rest of the LoRA.

MoE group (only used in the Merger's moe mode): moe_temperature (default 1 - softmax temperature for expert gating; lower means sharper, more winner-take-all selection) and moe_hard (skip the soft mixture and hard-pick a single best expert per module instead).

Block-mix group (only used in the Merger's block-mix mode): block_mix_method (svd = delta-merge-then-recompress, stack = exact rank stacking with no compression), block_mix_preset (routing families that match how different architectures actually name their blocks - zimg-turbo, flux, wan, qwen, sd, sdxl, or generic/auto), block_mix_weighted (turns hard A-or-B routing into a blend), and block_mix_concept_mix/block_mix_style_mix (when weighted, what fraction of LoRA A survives in concept/attention versus style/feed-forward modules - 0.5 splits evenly).

The inputs and outputs that matter

For a first merge you mostly need rank and dtype - leave the moe_* and block_mix_* groups alone unless the Merger node's mode is actually moe or block-mix, where they're otherwise inert. Output is a single options (WAS_LORA_MERGE_OPTIONS) socket that only plugs into the Merger's options input - nowhere else.

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.

Common issues & troubleshooting

Changed block_mix_* or moe_* settings and nothing happened. Check the Merger node's mode dropdown first - those groups are only read in block-mix and moe mode respectively. Everything else ignores them.

Merged LoRA looks washed out or has lost detail. rank too low, or auto_rank_threshold set too aggressively for an SVD-family mode - raise the rank, or push the threshold closer to 1.0 to keep more of the singular-value energy.

A merge that should take seconds is taking minutes. Check whether cpu got left on - it trades speed for VRAM headroom, and it's easy to forget you enabled it for a previous run.

Confused about dtype vs compute_dtype. dtype is what gets written to your .safetensors file. compute_dtype is only the precision used during the merge math itself - you can compute in fp32 for accuracy and still save the result as bf16 to keep the file small.