Mpi Double Lora Loader

Most LoRA workflows apply one LoRA to one model. MpiDoubleLora is for the weird-but-real case where the same LoRA needs to go onto two different models and their clips at once - a model swap workflow, an ensemble where two backbones run side by side, a compare harness that feeds two samplers from one LoRA choice. It's a LoRA loader with a copy-paste built in: pick the file once, and both model+clip pairs get it in the same call.

How it works

Two required MODEL inputs (model_a, model_b), two optional CLIP inputs (clip_a, clip_b), and one lora_name dropdown built from whatever's in your models/loras folder (with a "None" entry on top). The strength_model and strength_clip FLOATs apply to both pairs simultaneously - same strength for A and B, no separate per-side controls.

Under the hood it's calling ComfyUI's own load_lora_for_models twice, once per model/clip pair, reusing a cached LoRA load so you're not reading the weights off disk twice. If strength_model and strength_clip are both 0 - or lora_name is "None" - it short-circuits and passes the inputs straight through untouched, which is the intended way to bypass the branch entirely.

Outputs: model_a_out, model_b_out, clip_a_out, clip_b_out - each pair's LoRA'd model and clip, ready to wire to its own sampler or encoder.

The inputs that matter

• lora_name - the shared LoRA. One choice drives both models.
• strength_model - model weights strength; 1.0 is a full application, and it's the one you'll actually tune.
• strength_clip - defaults to 0, which is right for most SD/SDXL LoRAs where you mostly care about the model side; raise it when the LoRA is trained to also steer prompting.

The two clips are optional because not every workflow encodes from a LoRA-touched clip - leave them unconnected and the node still applies the model side cleanly.

Where people get burned

Two things worth knowing. First, this is a shared-strength loader: there's no way to give model A strength 0.7 and model B 1.0 in one node. If your two sides need different strengths, wire two single LoRA loaders instead - the pack's MpiLoraModel / MpiLoraModelClip are the per-model versions. Second, if your LoRA doesn't show up in the dropdown, it isn't in models/loras - the list is read from disk, so drop the file in and refresh.

There's also a quirk in the version on disk worth a heads-up if you feed different clips to A and B: the two clip outputs come back from the underlying call in swapped order relative to their names. In the common case - same clip both sides, or clips left disconnected - it never matters, but if you're routing distinct clips to distinct encoders, sanity-check which clip lands on which output rather than trusting the labels blindly.

Install

From the MadPonyInteractive/ComfyUi-MpiNodes pack. ComfyUI Manager → search ComfyUi-MpiNodes (publisher mad-pony-interactive), install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

then restart. No extra Python packages - LoRA loading uses ComfyUI's built-in machinery, and your LoRA files live in ComfyUI/models/loras as usual. The pack is AGPL-3.0 (≤ 1.2.6 MIT) and is the node library behind the author's Cubric Vision app.

The verdict

For a standard single-model workflow, don't bother - a normal LoRA loader is simpler. But if you're building a two-backbone workflow where one style LoRA must land on both models identically, this saves you from two loader nodes that can silently drift apart. Same file, same strength, one place to change it.