LoRA Stack

This isn't the node you screenshot for a tutorial - it's the plumbing everything else in LoRA Optimizer sits on top of. LoRAStack takes one LoRA file plus its settings and turns it into a LORA_STACK entry that the rest of the suite (the Optimizer, the AutoTuner, the Conflict Editor) can actually see. Load a LoRA the normal way with a plain Load LoRA node and none of that machinery knows it exists - the whole point of this pack is deciding how several LoRAs should interact, and it can't do that with LoRAs it can't see.

The reason that matters: stacking LoRAs and hoping for the best is a known way to get oversaturated, melted-looking results, especially on the newer distilled models. Z-Image Turbo in particular has thin headroom for it - community testing found it "can only handle a maximum of 2 LoRAs with strengths not exceeding 1.4," while a chunkier model like Flux 2 Klein 9B tolerates three at full strength. LoRAStack's per-LoRA settings exist because of that ceiling - they're how you tell the optimizer which LoRA should win when two of them start fighting over the same weights, instead of just fighting silently in your output.

How it works

Each LoRAStack node holds exactly one LoRA. To combine several, chain them: wire the optional lora_stack input on node #2 to the output of node #1, and so on, building up the list one node at a time. If that sounds tedious for anything beyond two or three LoRAs, it is - that's what LoRA Stack (Dynamic) is for, which puts up to 10 slots on a single node. LoRAStack is the atomic version; reach for it when you want one LoRA with fine control, or when you're chaining output from another node (like an extracted LoRA) into an existing stack.

The inputs that matter

• lora_name - pick the file. strength - how hard it hits, default 1.0, range -10 to 10 (in practice you'll live in 0–1.5).
• conflict_mode - all (default, applies everywhere), low_conflict (only where this LoRA agrees with the rest of the stack - the safe choice), or high_conflict (only where it disagrees, forcing it to dominate contested weights).
• key_filter - usually leave at all. The other options exist for specific architecture quirks: shared_only/unique_only strip or isolate variant-specific keys (handy for making a Wan I2V LoRA behave on T2V), and audio_only/no_audio split the audio layers on LTX-2 or ACE-Step so you can merge two clips but keep only one's voice.
• preserve - marks this as a protected style LoRA so it's never trimmed by sparsification and never loses its minority-sign direction in a TIES merge. Flip this on when a style LoRA keeps vanishing after you merge it with a character LoRA.

Output is just lora_stack - feed it to LoRA Optimizer, LoRA AutoTuner, LoRA Conflict Editor, or any of the other consumers in the pack.

How to install it

Easiest path: open ComfyUI Manager, search "LoRA Optimizer", install, restart. Manually:

cd ComfyUI/custom_nodes/
git clone https://github.com/ethanfel/ComfyUI-LoRA-Optimizer.git

Restart ComfyUI - the nodes land under the loaders category. No model downloads, no extra checkpoints; it works against the LoRA files you already have.

Common issues & troubleshooting

It also accepts stacks from other packs. LoRAStack reads standard (lora_name, model_strength, clip_strength) tuples from Efficiency Nodes, Comfyroll, and similar - so migrating an existing stacking workflow into this pack doesn't mean rebuilding it from scratch.

Don't manually fight strength at this level. If your merge looks blown out, the fix usually isn't dialing every strength down here - that's what auto_strength on the downstream Optimizer is built to handle automatically, and it does a better job than eyeballing it.

key_filter is per-LoRA and easy to forget. If you're merging a T2V and an I2V Wan LoRA and getting odd artifacts, check whether you actually set key_filter on the I2V one rather than leaving both at all.

preserve isn't a volume knob. It changes how the LoRA survives conflict resolution, not how strong it is - pair it with strength, don't substitute for it.