ZImage LoRA Merger (2 LoRAs)

ZImageLoraMergerAdvanced - display name "ZImage LoRA Merger (2 LoRAs)" - takes exactly two LoRAs and squashes them into a single LoRA file, so you can run character + style, or two styles, as one adapter instead of stacking two loaders.

That's more useful on Z-Image than it sounds, because stacking is Z-Image's known weak spot. The community has repeatedly found that loading more than one LoRA at once tends to make quality collapse - one of the model's most-cited limitations. Merging them into one file first is the workaround: you bake the combination permanently, then load a single LoRA at whatever strength you want. It also lets you pre-mix weights the way checkpoint makers do, so you get one curated "this is my character at this style" adapter instead of juggling strengths at generation time.

How it works

Pure tensor math, all on CPU. It loads both LoRAs, detects whether each is in sd-scripts or ComfyUI layout, and converts them both to the sd-scripts form so the merge is apples-to-apples. Then for every parameter it does a weighted average:

• alpha values get a weighted average
• lora_down and lora_up matrices get weighted sums using your two weights
• when the two LoRAs have different ranks, it pads to the larger shape or runs SVD to hit your target output_rank

The result is written to ComfyUI/output/ as a .safetensors, and the node's single status string output tells you what happened. Because both inputs get normalized into one format first, you can merge a ComfyUI-converted LoRA with a raw trainer-output one and it just works.

The inputs that matter

Only three really need your attention:

• lora1 / weight1, lora2 / weight2 - the two adapters from your models/loras folder and how strongly each contributes. Weights run 0–10, default 1.0.
• auto_normalize - this is the one that surprises people. On (default), weights are rescaled so they sum to 1. So 1.0 + 1.0 becomes a 50/50 mix, not a double-strength one. If you want one LoRA dominant, set it to, say, 0.8 and 0.2.
• output_rank - the merged LoRA's rank, 1–128, default 16. It'll SVD-reduce (or zero-pad) to hit this.

output_name is just the filename, and convert_to_comfy_format (default on) writes the result in the layout ComfyUI's LoraLoader expects, so the merged file drops straight in.

A couple of honest warnings. Both LoRA dropdowns must be set or the node returns an error - there's no "merge with nothing" mode. And like its sibling bake/extract node in this pack, it only understands Z-Image key naming; feed it SDXL or Flux LoRAs and you'll get warnings about keys that can't be found, not a useful merge. This is a Z-Image-family tool.

Installing it

Same story as the pack's other node - this one ships in the same repo, so one install gets you both. No model downloads and no extra dependencies; it only needs torch and safetensors, both of which ship with ComfyUI. ComfyUI Manager is easiest (search the pack title), or:

cd ComfyUI/custom_nodes
git clone https://github.com/GraftingRayman/ComfyUI-ZImage-Bake-Extract

Restart ComfyUI and it shows up under the ZImage category.

The honest take

Is merging worth it versus just stacking in the workflow? On most models, no - live stacking keeps every LoRA independent and tweakable. On Z-Image specifically, yes, because the stack itself is the problem: a merged file sidesteps the quality collapse and gives you one strength slider for the whole combination. Start with auto_normalize on and equal weights, then check the output before you get clever. If your merged result drifts, re-run with the weight shifted toward whichever LoRA you care about more - that's the whole tuning loop, and it beats fighting two loaders at once.