SSR-Merge Calibration

Merging two LoRAs is usually a blind guess. You pick a strength ratio, add the matrices, hope. SSR-Merge Calibration is the opposite: it runs a real (short) sampling pass first, watches what actually happens inside the model, and uses those activation statistics to decide how the two LoRAs should be mixed - per layer, not with one global slider. Then it hands you a merged payload you apply with its sibling node. It's from the SSR-Merge paper (subspace signal routing), and as of right now it's about as bleeding-edge as LoRA merging gets - the pack shipped in mid-2026 and there's essentially no community lore around it yet, so you're a pioneer either way.

How the calibration works

This is the part that makes SSR-Merge different from every merge node you've used. When the node executes, it:

1. Loads both LoRAs and extracts their model-side layers (linear and 1×1-conv only).
2. For each LoRA, runs a single-step sampling pass through your actual sampler - steps are locked to 1 and CFG to 1.0, that's fixed in the code - while registering forward hooks on the model's layers. Those hooks collect second-order activation statistics (how the LoRA's down-projected features correlate, in practice).
3. Solves an analytic router per layer - a small linear solve with lambda_reg ridge regularization - that says "this LoRA takes the wheel here, that one there."
4. Absorbs the router into the up-projection and emits a merged LoRA payload.

So the merge is data-driven: it routes signal based on what your two LoRAs actually do to the model at inference time, instead of assuming a fixed ratio is right everywhere.

Inputs and outputs you'll actually set

• lora_1 / lora_2 - the two LoRAs. Must be different files; the node validates this and refuses identical ones.
• prompt_1 / prompt_2 - describe what each LoRA contributes (e.g. the subject for one, the style for the other). These get encoded and drive the calibration samples, so they matter more than you'd think - a prompt that never activates some layer leaves that layer with an identity router and a warning.
• negative_prompt - shared negative for both calibration passes.
• lambda_reg (default 0.0001) - ridge regularization on the correlation matrix. Bump it up if the merge gets unstable; otherwise leave it.
• seed, width, height, sampler_name, scheduler - the calibration inference's settings. Resolution defaults to 1024×1024; the sampler/scheduler are genuinely selectable, unlike steps and CFG.

Outputs: an ssr merge payload (custom SSR_MERGE type - feed it straight into SSR-Merge Loader) and a calibration info string summarizing layers, hooks, and lambda. Two honest gotchas: the calibration re-runs every time you hit Queue (deliberately, so results are never stale - but that means the node is slowish and VRAM-heavy, since it loads both LoRAs and runs two sampling passes). And if any layer never fires during calibration, you get an identity-router fallback with a warning in the info string - usually a sign your prompt or LoRA isn't activating something.

What it deliberately won't merge

CLIP-side LoRA, spatial LoCon kernels, DoRA, LoHa, and LoKr are excluded on purpose, per the README - the math only handles conventional linear/1×1-conv model-side LoRA, and it'd rather skip than corrupt. It also requires a CLIP input (it errors if you feed it None) because it needs to encode the calibration prompts.

Install is the same as the rest of this pack - ComfyUI Manager ("LoRA Merge EXPERIMENTAL") or:

cd ComfyUI/custom_nodes
git clone https://github.com/hybskgks28275/ComfyUI-LoRA-Merge-EXPERIMENTAL

Then restart and find it under loaders/LoRA. No extra dependencies and no model downloads, but the pack needs ComfyUI's V3 extension API, so if the node never appears, update ComfyUI before you blame the install. Then wire SSR-Merge Calibration → SSR-Merge Loader → KSampler, and treat the calibration pass as the new "one weird knob" - worth the wait for merges the naive way keeps botching.