Z-Image LoRA True Merge
The only one that handles mixed-rank LoRAs
- model
- clip
- model
- clip
Every other node in this pack either rescales strengths or merges tensors that have to line up. True Merge attacks the hard case: combining LoRAs of different ranks. A rank-32 and a rank-256 LoRA have A/B matrices of different shapes, so you can't average them tensor-by-tensor, and Merge to Single will degrade quietly on mismatched keys. True Merge sidesteps the whole problem by never comparing the LoRA matrices directly.
How it works
For each LoRA and each layer, it reconstructs the full weight delta first - diff = up @ down × (alpha / rank) - reshaped to the target weight's shape. A weight delta has the same shape as the weight it patches, regardless of what rank produced it, so rank stops mattering. It then merges those deltas (all the same shape, by construction) and patches the model once with a single "diff" patch. It even understands the key formats floating around out there: regular .lora_up/.lora_down, diffusers A/B naming, and LoCon mid matrices.
Three merge modes, echoing the pack's pattern:
- weighted_average (default): each delta weighted by strength, then averaged.
- weighted_sum: adds the deltas; brighter, can overdo it.
- normalize: rescales so the sum of squared weights lands at 1 - the energy normalization from the main Merger, applied to the merge itself.
output_strength (0–2) scales the result, up to four LoRAs fit, and clip_strength_multiplier handles the CLIP side. Outputs are model and clip as usual.
The tradeoff is spelled out
The author's own comparison table calls it: this is the slow, memory-hungry option. It materializes full dense weight deltas in float32 for every layer it can map, which is a lot of VRAM on a big model. You don't reach for this to fix a burned Z-Image image - the plain Merger does that for free. You reach for it when you've got genuinely mixed-rank LoRAs and nothing else in the pack will merge them honestly. For same-rank pairs, Merge to Single is cheaper and nearly equivalent.
Practical notes
- Watch your VRAM. If you OOM, this is the node doing it; step down to Merge to Single or the plain Merger for that combination.
- The model/CLIP split is a heuristic - patches whose keys start with "clip" go to the CLIP, everything else to the model. Exotic key layouts might land in an unexpected place, though most Z-Image LoRAs map cleanly in practice.
- The console logs "Processed N weight keys" per run. If that number looks suspiciously low or the image doesn't change, your LoRAs may be using key formats the node didn't recognize.
Install
Standard for the pack, no dependencies or downloads - ComfyUI Manager → search "Z-Image LoRA Merger", or:
cd ComfyUI/custom_nodes
git clone https://github.com/DanrisiUA/ComfyUI-ZImage-LoRA-Merger
Restart, find it in loaders/lora. It's the node with zero fanfare and arguably the most impressive job in the pack - nobody searches for it, and it's the only one that does exactly what its name claims.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | The model to apply LoRA to | |
| clip | CLIP | The CLIP model | |
| merge_mode | COMBO | weighted_average | 3 options: weighted_average, weighted_sum, normalize |
| output_strength | FLOAT | 1.000–2 | Strength of the merged effect |
| lora_1 | COMBO | 1 options: None | |
| strength_1 | FLOAT | 1.00-10–10 | — |
| lora_2 | COMBO | 1 options: None | |
| strength_2 | FLOAT | 1.00-10–10 | — |
| lora_3opt | COMBO | 1 options: None | |
| strength_3opt | FLOAT | 1.00-10–10 | — |
| lora_4opt | COMBO | 1 options: None | |
| strength_4opt | FLOAT | 1.00-10–10 | — |
| clip_strength_multiplieropt | FLOAT | 1.000–2 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |