Mpi Lora Model Clip
Model and clip tuned independently
- model
- clip
- model
- clip
- lora_name
- strength_model
- strength_clip
Most LoRA loaders give you one strength knob for everything. Mpi Lora Model Clip splits the difference: it applies a LoRA to both the model and the CLIP text encoder, but with independent strength_model and strength_clip sliders. That's the node you want on SD/SDXL-era models, where a LoRA's text half genuinely matters - the CLIP side is what makes trigger words and style tokens work - and where "full weight on the model, lighter on the text" is a real tuning move rather than a curiosity.
Interface: model and clip in, lora_name from your loras/ folder dropdown (with None listed first, the pack's convention), and the two strengths, both FLOAT from −10 to 10, default 1. Out the other side: model, clip (both patched), plus lora_name, strength_model, and strength_clip echoed back as outputs. That echo is the pack's signature move - the values you applied come out as wires, so a host app or a downstream node can read exactly what the graph did.
The edges are handled the way you'd hope: if lora_name is None, or both strengths are 0, the model and clip pass through untouched - no load, no patch. Otherwise it's ComfyUI's own load_lora_for_models under the hood, and the author caches LoRA loads so re-applying the same file in a session doesn't re-read it from disk every time.
When would you actually want to diverge the two strengths? The classic case is a style LoRA where the CLIP half is doing the heavy lifting on vocabulary, and you want the image side gentler. Or the reverse - a character LoRA where you want strong visual identity (high strength_model) but you don't want the trigger token to overwhelm the caption (lower strength_clip). Negative strengths are allowed on both, which is useful for counteracting a LoRA that's over-applied in a merged file - though if you're routinely going below zero to fight a model, that's usually a sign the LoRA itself is too hot.
The contrast with the pack's other LoRA node is the thing to internalize: Mpi Lora Model is model-only, built for Flux-era models where the text encoder is a language model and you don't train the text encoder any more (as the KB's LoRA training notes put it). This node is the full-fidelity SD/SDXL workhorse. Pick model-only for modern flow-matching bases; pick this one when the CLIP half is a real part of the equation.
Install is the pack's standard no-drama deal: ComfyUI Manager → search "ComfyUi-MpiNodes" → install → restart, or
cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes
No pip dependencies; just put your LoRA files in ComfyUI/models/loras/. It's part of the Mad Pony Interactive utility pack (engine behind Cubric Vision), and if you're on SDXL it's arguably the LoRA loader to reach for daily - two knobs instead of one is a small thing that turns out to be a real tuning lever.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| lora_name | COMBO | 1 options: None | |
| strength_model | FLOAT | 1.00-10–10 | — |
| strength_clip | FLOAT | 1.00-10–10 | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |
| lora_name | * | — |
| strength_model | FLOAT | — |
| strength_clip | FLOAT | — |