JLC LoRA Loader - Multi Model / Shared Block Weight + CLIP

There are two ways to apply a block-weight profile to a stack of LoRAs: one vector per LoRA (powerful, and the node gets visually loud), or one vector that applies to all of them. This is the second one. JLC LoRA Loader - Multi Model / Shared Block Weight + CLIP takes the pack's dynamic ten-slot MODEL+CLIP loader and gives the whole stack a single block_vector, so every active LoRA gets the same MODEL-side block weighting while each keeps its own per-slot MODEL and CLIP strengths.

That trade-off is the whole appeal. You decide "these three style LoRAs should all stop messing with the early encoder blocks," type the vector once, and every LoRA in the stack honors it. The per-slot variant exists for when LoRAs need different profiles; this one exists for when they need the same profile and you'd rather not maintain ten copies of a CSV string.

How it works

Everything you'd expect from the dynamic-LoRA family is here. Ten slots are predeclared; slot_count (1–10, default 1) decides which rows the frontend shows and is authoritative in the backend - hidden slots with nonzero values are ignored but stay serialized in the workflow JSON, so shrinking the node doesn't destroy your setup. Slots with "None" selected or both strengths at 0.0 are skipped, and active LoRAs apply sequentially in slot order.

The one new widget is the shared block_vector, a CSV like:

1,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1

Vector semantics (from the pack's LoRA loader docs): vector[0] is the base ratio for unmatched MODEL keys, vector[1:] is consumed across block indices, the last value repeats if the vector runs short, zeros suppress a patch and nonzeros scale it. The helper recognizes input_blocks, middle_block, output_blocks, double_blocks, and single_blocks, so the same string works across SD1.5/SDXL/Flux. And here's the part the name spells out: the shared vector applies only to the MODEL side. CLIP/text-encoder patching still uses each slot's ordinary strength_clip_XX and is never block-weighted.

Inputs and outputs

• model, clip - checkpoint in, patched out
• slot_count - authoritative active-slot count
• block_vector - one shared MODEL block-weight profile
• per slot: lora_XX, strength_model_XX, strength_clip_XX

Outputs are model and clip, ready for the KSampler and your CLIP text encoders. Standard wiring, no surprises.

Practical notes: if every slot is left at its default strengths (0.0), the node passes your model and clip through untouched - the widgets are all zero until you raise them. And keep the shared-vector constraint in mind: if two LoRAs in the stack want opposite treatments (one should be stronger up front, the other stronger in the back), you can't express that with a single vector, and this node is the wrong tool - that's the per-slot node's job.

Install

ComfyUI Manager (search JLC ComfyUI Nodes, it's on the registry), or:

cd ComfyUI/custom_nodes
git clone https://github.com/Damkohler/jlc-comfyui-nodes.git

Restart ComfyUI after installing or git pull-ing. The loader itself needs no model files and declares no extra Python dependencies - the optional comfyui_controlnet_aux install in the README is only for the pack's ControlNet Aux wrapper.

Honest take: this is the block-weight node I'd start with. One profile, no CSV sprawl, and you can always graduate to per-slot vectors when a specific LoRA refuses to behave. If you don't need CLIP patching at all, the MODEL-only shared-block-weight sibling drops the CLIP input and output and filters text-encoder keys out of LoRA files - slightly less wiring, same idea.