Krea2 Merge • Merge LoRAs

This is the node the whole pack exists for. Krea2 Merge • Merge LoRAs takes two to four LoRA state dicts and produces one merged state dict, and the reason it had to be written at all is a key-naming mess: Krea 2 LoRAs ship in PEFT/Diffusers format, with lora_A and lora_B weights, while the merge tools the community already had only understood Kohya's lora_down/lora_up. Cross them and the classic tools silently ignore half the file. This fork reads both conventions, and its default mode, exact_concat, does the merge the mathematically right way.

What "exact" means here

LoRA merging has a trap most people never notice. A LoRA is a low-rank pair - a down matrix and an up matrix - and a naive weighted merge just scales each factor and adds them, which introduces cross terms between LoRA A and LoRA B that were never trained into either. exact_concat avoids that by concatenating complete A/B pairs along the rank axis instead of adding their factors. The result is an exact weighted sum of the two LoRAs' effects, no phantom interference, and it even works when the ranks differ: a rank-4 and a rank-16 module become a rank-20 module rather than refusing to merge. Weights are applied on the up/B side as ratio × alpha / rank, and negative weights are handled by flipping the sign once on the up matrix (matching SuperMerger's convention), so you can actually subtract a style instead of just adding.

The cost is that concatenation grows the rank. Two rank-32 LoRAs become rank 64; four become rank 128. That means a bigger file and more work while ComfyUI applies it, which is the price of exactness.

The inputs that matter

• model1 / model2 (required) and model3 / model4 (optional) - these come from the pack's Load LoRA nodes, not from a model loader. A connected third or fourth LoRA with a zero weight is ignored with a console warning.
• weight1–weight4 - floats from -4.0 to 4.0. New nodes default to a balanced 0.5 / 0.5, which is the even blend. Remember that alpha is inferred as alpha = rank when a PEFT checkpoint has no embedded alpha tensors - the only value recoverable from a bare state dict.
• merge_mode - exact_concat is the default and what you want. legacy_linear is the old approximate factor-space behavior from the upstream comfyui-merge; it's there to keep old saved workflows loading, introduces cross terms, and requires matching shapes and ranks. Leave it alone.
• save_dtype - fp16 is the practical default; pick bf16 if that's what the rest of your Krea 2 setup uses.
• force_same_strength - legacy mode only; exact_concat ignores it entirely.

The output, merged_model, is another state dict that plugs straight into the pack's Save LoRA node.

Install

Search Krea2 Merge in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/cyberdeliaAI/comfyui-krea2-merge

Restart ComfyUI. The only dependency is safetensors, already present in standard installs, and the merge runs entirely on the LoRA files - the Krea 2 base model is never loaded, let alone saved.

The honest take and the gotchas

Before you merge, ask whether you should. The community is genuinely split on LoRA merging: you trade away the ability to tune each LoRA's strength at runtime, which is one of the main reasons people like LoRAs in the first place. The sensible uses are baking a couple of style LoRAs into a single shareable file, slimming a huge lora folder, or deployment where runtime loading isn't an option. Merging to "fix" quality is a trap.

When it does error, it's usually informative: "no complete lora_A/lora_B or lora_down/lora_up pairs" means the file isn't a compatible LoRA; DoRA magnitude vectors and LoCon lora_mid tensors are rejected outright rather than silently mangled, and mixing PEFT and Kohya keys within one module errors too. If you see "at least two LoRAs with a non-zero weight," you zeroed out both. All of those are guardrails, not bugs - the author would rather you get an error than a subtly wrong merged file.