LoRA Block Weight Custom (SD3.5 Large)
Type 38 weights, stop guessing
- model
- clip
- model
- clip
- info
Every node in this pack before this one is about finding out what a LoRA's blocks do. LoRA Block Weight Custom (SD3.5 Large) is where you act on it. It's a LoraLoader replacement with no sweep logic at all - you hand it one comma-separated list of 38 weights, one per joint block in J00..J37 order, and it loads the LoRA exactly that way, every render. It's the "save my recipe" node.
This is the end of the workflow the README lays out. Round one, you sweep and rank. Round two, you identify dead weight. Round three happens here: critical blocks stay at 1.0, negligible blocks get zeroed, and the middle blocks become your dial - try 0.5, compare against full, walk them up past 1.0 if you want more of the LoRA's look. Zeroing those near-dead blocks is the lowest-risk, highest-ROI edit in the whole technique: it barely changes the image, frees capacity for prompt adherence, and reduces interference when you stack other LoRAs on top.
The inputs
- model, clip, lora_name - the standard loader trio.
- weights - 38 comma-separated values in
J00..J37order (default all1.0). - baseline_weight - a fallback for anything not covered. (In practice every block is in the list, so this rarely bites.)
- clip_strength - the CLIP/text-encoder side of the LoRA. SD3.5 uses a triple encoder (CLIP-L + CLIP-G + T5-XXL), and the clip half can carry real identity, so leave this at 1.0 unless you've tested otherwise.
Outputs: patched model and clip into a KSampler (SD3.5 Large runs happy around cfg=4.5, euler, sgm_uniform, 20 steps), plus an info STRING with patch counts.
The design choice you'll either love or curse
The parser is strict, and it's strict on purpose. The list must contain exactly one numeric value per block - 38 for SD3.5 - or the node raises a ValueError instead of quietly doing something sensible. The source comments put it plainly: a typo should fail loudly, not turn into a different experiment. So yes, a missing comma means an error screen, but you'll never ship a grid that silently ran the wrong weights. Keep a copy of your known-good list somewhere; you'll paste it in and forget it.
Install
Via ComfyUI Manager, search "LoraBlockWeight". Or:
cd <ComfyUI>/custom_nodes
git clone https://github.com/Baldwinzc/ComfyUI-LoraBlockWeight.git
Restart ComfyUI. No extra dependencies, no model downloads, no API key.
Gotchas
The trap here isn't the node - it's treating a single sweep's ranking as permanent truth. MSE is a pixel-delta for one prompt, seed, and resolution, and the README is explicit that a block ranked negligible in one run isn't proven useless everywhere. If you zero blocks based on one sweep and a LoRA starts behaving oddly on another prompt, re-check the ranking before you assume the node broke. And don't skip round one: pasting all 1.0s into this node is just a normal LoRA loader with extra steps.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| lora_name | COMBO | 0 options: | |
| weights | STRING | 1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0 | 38 comma-separated weights in order: J00,...,J37 |
| baseline_weight | FLOAT | 1.000–2 | — |
| clip_strength | FLOAT | 1.00-2–2 | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |
| info | STRING | — |