Embeddr LoRA Stack
Stack LoRAs in one node — but it only touches the model, not the clip
- model
- model
LoRA Stack applies multiple LoRAs to a model in one node, instead of stringing together a chain of LoraLoader nodes. You drop it after your checkpoint, pick LoRAs from a dropdown, set a strength for each, and it loads and applies them all, returning the merged model.
The pitch is the same one that made rgthree's Power Lora Loader a fixture - one node instead of a stack of them - but with an honest caveat this pack's own description glosses over: this node outputs only a MODEL, not a CLIP. The source calls load_lora_for_models with the clip set to None, so text-encoder LoRAs and any clip-side strength changes are dropped on the floor. If you're using prompt-tuned LoRAs (the common case), the clip side is usually a no-op anyway - but if you were relying on the standard LoraLoader's model-and-clip output, this changes what you wire.
What you actually set
The schema declares one slot - lora_1 (a combo populated from your ComfyUI loras folder, so it lists the same files LoraLoader sees) and strength_1 (default 1.0, range −10 to +10, so negative strengths for "anti-LoRA" tricks work) - plus the model input. The source comments explain the rest: "Add 1 slot initially, frontend will handle the rest." The extension's UI adds more slots for you (lora_2 / strength_2, and so on), so the node grows to fit however many LoRAs you need.
Mechanically, for each populated slot it resolves the file path from your loras folder, load_torch_file with safe_load=True, and applies it via comfy.sd.load_lora_for_models. Order follows the slot numbers, which matters when LoRAs fight over the same concepts.
The honest take
If you're using the Embeddr pack for the library side but this is the only model node you reach for, know that it's really a generic "N-slot LoraLoader" wearing an Embeddr name - it reads from your local loras folder, not from your Embeddr library. That's fine, but it means it doesn't unlock anything Embeddr-specific. Its real value is convenience: one node, multiple LoRAs, and the dynamic slots keep the graph clean. If you're already comfortable with a chained LoraLoader, there's no urgent reason to switch; if you dislike the chain, this is a tidy single-node alternative.
Install & notes
Pack install as always: embeddr serve running, pack via ComfyUI Manager or a release into custom_nodes, restart ComfyUI. No extra Python deps beyond requests - this node uses torch and the ComfyUI model-loading utilities your host already has.
Troubleshooting is minimal because the node is simple. LoRA not applying? Check the slot's dropdown actually shows the file (it's read from loras at node creation) and that strength isn't at 0. One gotcha to remember: because there's no clip output, any workflow that expected the standard loader's (model, clip) pair needs its clip sourced from elsewhere. And if you set a negative strength_1, you're deliberately subtracting the LoRA - keep it subtle; big negative values are how people make artifacts, not fixes.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| lora_1 | COMBO | None | 1 options: None |
| strength_1 | FLOAT | 1.00-10–10 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |