Nodes/ComfyUI-DualLoraStack/Knishika Dual Lora Stack
ComfyUI Node

Knishika Dual Lora Stack

Same LoRAs, two checkpoints, one shared CLIP — the A/B testing node

By knishika62·Created 7 months ago·Updated 7 months ago· 1
Knishika Dual Lora Stack
  • model_1
  • model_2
  • clip
  • model_1
  • model_2
  • clip
lora_01
lora_01_strength1.00
lora_02
lora_02_strength1.00
lora_03
lora_03_strength1.00
lora_04
lora_04_strength1.00
lora_05
lora_05_strength1.00
lora_06
lora_06_strength1.00

Want to compare two checkpoints fairly? Then the problem is you can't. Every time you swap the checkpoint you have to re-apply your whole LoRA stack by hand, and half the time you realize one side got the LoRAs at 0.8 and the other at 1.0, so the comparison is worthless. Knishika Dual Lora Stack exists so that a LoRA stack is applied identically to two separate models at once, driven by one shared CLIP. It's a niche tool, but it's the right niche: this is the cleanest way I've found to A/B two models under identical conditions.

The author's framing (the README is Japanese, from knishika62) is exactly that: apply the same LoRAs to two models, share one CLIP between them, up to six LoRAs with individual strength control. There's nothing else in the pack - one node, one job.

When you'd reach for it

  • Base vs distilled checkpoints. There's a well-worn pattern in the LoRA world where you train on the undistilled base and run on the distilled Turbo variant - they don't behave the same, so you want to see both under one LoRA stack. This node wires both in one pass.
  • Checkpoint comparison. New merge dropped and you're deciding whether to switch? Lock the seed, feed the same stack and same prompt through both branches, and the checkpoint is the only variable. That's exactly the "change one variable at a time" discipline everyone in the community keeps telling you to follow.
  • Character consistency across two outputs. Same character/style LoRAs on two different bases, two results with the same conditioning.

How it works

Under the hood it's a thin wrapper around ComfyUI's built-in LoraLoader - no extra dependencies, no model downloads, nothing to configure. For each of its six slots it grabs the selected LoRA and calls LoraLoader.load_lora once on the first model branch and once on the second, with the same strength for both. The shared CLIP flows through the same stack, so both models see identical text conditioning. Skip the deep-dive; the one thing worth knowing is that a single strength value here patches both the model and the CLIP - same as the default ComfyUI LoraLoader. If you're used to LoraLoaderModelOnly to keep the CLIP untouched, know that this node isn't that.

The inputs that matter

The full list is short and mostly self-explanatory:

  • model_1 and model_2 (MODEL) - your two checkpoints.
  • clip (CLIP) - one CLIP for both branches.
  • lora_01 through lora_06 - six LoRA slots, dropdowns populated from your models/loras folder. Set to None to skip a slot.
  • lora_01_strengthlora_06_strength - per-LoRA strength, default 1.0, range −10.0 to 10.0. Negative values invert the LoRA's effect; 0 disables it.

Outputs are three: patched model_1, patched model_2, and the shared clip. Wire each patched model into its own sampler, and feed both samplers' positive/negative conditioning from the single clip output.

Installing it

ComfyUI Manager - search Knishika Dual Lora Stack - or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/knishika62/ComfyUI-DualLoraStack

Restart ComfyUI. There's no requirements.txt and no weights to fetch; it only imports folder_paths and the bundled nodes.LoraLoader. That's the whole install.

Troubleshooting

Most problems here aren't the node's fault - they're LoRA problems. The classic ones apply twice over because you now have two models in play:

  • Architecture lock-in. A Flux LoRA won't work on an SDXL model, period. The node will happily load anything you pick, so make sure each branch's LoRAs actually match that branch's base. Pony/Illustrious/SDXL share code and will all appear selectable, but they're often not cross-compatible in practice.
  • LoRA "not applying". Check the slot isn't set to None and the strength isn't 0 - the node silently skips both.
  • Shared CLIP, shared limitations. Because one CLIP feeds both models, a CLIP-skip setting that suits one branch (anime LoRAs often want Clip Set Last Layer at −2) applies to both. If your two checkpoints want different CLIP behavior, this node isn't the fit.

Is it overhyped? No - it's barely hyped at all, and that's the thing. It's a small, single-purpose utility from a small author, unproven in the wild (zero install signal to speak of). Don't expect updates or polish. But if you do any model-comparison work, it collapses a fiddly multi-node setup into one graph, and that's worth having.

Categoryknishika/loaders

Inputs (15)

NameTypeDefaultDescription
model_1MODEL
model_2MODEL
clipCLIP
lora_01COMBO1 options: None
lora_01_strengthFLOAT1.00-10–10
lora_02COMBO1 options: None
lora_02_strengthFLOAT1.00-10–10
lora_03COMBO1 options: None
lora_03_strengthFLOAT1.00-10–10
lora_04COMBO1 options: None
lora_04_strengthFLOAT1.00-10–10
lora_05COMBO1 options: None
lora_05_strengthFLOAT1.00-10–10
lora_06COMBO1 options: None
lora_06_strengthFLOAT1.00-10–10

Outputs (3)

NameTypeDescription
model_1MODEL
model_2MODEL
clipCLIP