Nodes/ComfyUI ModelPack/ModelPack LoRA
ComfyUI Node

ModelPack LoRA

Stack LoRAs From a Registry (and Why strength 0 Is a Feature)

By SiLeader·Created 24 days ago·Updated 21 days ago· 1
ModelPack LoRA
  • model
  • clip
  • MODEL
  • CLIP
◄reference►
◄file►
◄strength_model1.00►
◄strength_clip1.00►

A LoRA is a patch, not a model - a few hundred megabytes of adjustments bolted onto a checkpoint's attention layers, usually 10–200 MB of actual adapter weights. ModelPack LoRA applies one that lives in an OCI registry rather than in your models/loras folder. Same contract as core's LoraLoader, so if you've ever chained two of those, you already know this node.

Inputs and outputs

Six required inputs, which is the part people trip over: it needs the model and the clip, because a LoRA can hit both.

  • model - a MODEL from any loader (including ModelPack Checkpoint or ModelPack Diffusion Model).
  • clip - a CLIP from any text encoder loader.
  • reference - the OCI reference for the LoRA artifact. Empty = local mode.
  • file - path inside the artifact, or a filename from models/loras in local mode.
  • strength_model - float, default 1.0, range −100 to 100.
  • strength_clip - same, and deliberately separate.

Outputs are the updated MODEL and CLIP. Wire them into the sampler and the text encode (or into the next LoRA node) - the originals are untouched, so this is chainable. Three LoRAs means three of these in a line; the ecosystem's habit of putting a dozen in one node is a different design, not the required one.

The mechanism, and the two details that matter

The node pulls the file, loads it with safe_load=True and pulls out the weights and the metadata, then calls comfy.sd.load_lora_for_models passing that metadata through. It is ComfyUI's own LoRA math - no bespoke patching path.

Detail one: that metadata pass-through is why the pack declares ComfyUI 0.22.0 as a minimum. The lora_metadata argument didn't exist before that version, so on an older build you'll get a TypeError out of this node while the other five in the pack work fine. If exactly one node in the pack won't load, check your ComfyUI version before you start reinstalling things.

Detail two, and the nicer bit: the node caches the loaded weights in memory, keyed by the resolved path, so changing only the strengths after a run doesn't re-read the file from disk. Dialing a LoRA from 0.8 to 0.9 to 1.1 stops being a disk read each time. The cache holds one file at a time, so a chain of LoRAs will evict each other - that's normal, not a bug.

The strength-0 trick

Set both strengths to 0 and the node returns your model and clip unchanged without touching disk at all. That makes it a free bypass switch: leave a LoRA node in the graph at 0/0 while you're A/B testing whether it's helping, instead of muting it and losing the wiring. One less thing to re-enable in the wrong order.

The two strengths are separate for a real reason. LoRAs often carry a text-encoder component alongside their UNet component, and dropping strength_clip to 0 while keeping strength_model at 1 keeps the conditional encoding stock. When a LoRA is dragging your prompt interpretation around but the style is what you wanted, that's the dial. Negative values are allowed, but most people spend their life between 0 and 1.5 - past that, composition starts paying for the style.

Installing it

Manager: search ComfyUI ModelPack (cerussite). Or:

cd ComfyUI/custom_nodes
git clone https://github.com/SiLeader/ComfyUI-ModelPack comfyui-modelpack
python -m pip install -r comfyui-modelpack/requirements.txt

Restart. The dependency is modelpack-client (which pulls oras, jsonschema, zstandard) - no torch changes. Use the Python that runs ComfyUI; the portable Windows build's is python_embedded\python.exe. Python 3.10+, ComfyUI 0.22.0+.

Gotchas

The compatibility rule is the same as it has always been: an SDXL LoRA on a Flux model does nothing good, and a LoRA trained on a different text encoder than the one you loaded is worse than useless. strength_clip being a widget won't save you from that.

The one that's specific to quantized bases: LoRAs on a quantized model cost more than on fp16, because the pipeline has to dequantize, patch, and put the layer back. The KB's advice from the GGUF side applies here too - if you are memory-capped, dropping a quant level so the base and the LoRA both fit beats fighting it at the higher precision. And if you're pulling a LoRA as an artifact, remember the cache: the download directory is keyed on the reference string, so :v1 and :latest of the same weights are two copies on your disk. Digest references are the ones that stick around and don't re-check.

Finally, on pull errors: leave file blank on a multi-weight LoRA artifact and the error message lists every weight path in it. That's the intended way to find out what's inside, and it's faster than guessing.

CategoryModelPack/loaders

Inputs (6)

NameTypeDefaultDescription
referenceSTRINGOCI reference, e.g. registry.example.com/models/foo:v1. Leave empty to select a local file.
fileSTRINGPath within the artifact if it has multiple weights, or local ComfyUI model filename.
modelMODEL—
clipCLIP—
strength_modelFLOAT1.00-100–100—
strength_clipFLOAT1.00-100–100—

Outputs (2)

NameTypeDescription
MODELMODEL—
CLIPCLIP—