Merge Selector

LoRA AutoTuner's default output is its #1-ranked config, applied automatically. But #1 by the AutoTuner's scoring isn't always #1 by your actual taste - sometimes the second- or third-best candidate genuinely looks better to you, and re-running the whole sweep just to try it would be wasted compute, since the sweep already evaluated it. Merge Selector is how you apply any of those already-ranked alternatives directly.

What it is and why you'd use it

Both LoRA AutoTuner and LoRA Merge Estimator emit a TUNER_DATA object containing not just the winner but the full ranked list they considered. Merge Selector takes that data plus your original model and stack, and applies whichever ranked entry you point it at - no new sweep, no new analysis pass, just applying a config that was already computed. It's also how you use a saved tuner file: connect Load Tuner Data's output here to reapply a result from a previous session.

How it works

You give it the same model and lora_stack you originally fed to the AutoTuner (or Estimator), plus the tuner_data those nodes produced, and it looks up the config at index selection and runs just that merge.

The inputs and outputs that matter

• model / lora_stack (required) - must be the same ones connected to the original AutoTuner or Estimator run; the tuner data was computed against them specifically.
• tuner_data (required) - from LoRA AutoTuner's, LoRA Merge Estimator's, or Load Tuner Data's output.
• selection (default 1) - which ranked config to apply. 1 is the top-ranked, 2 the next, and so on.
• output_strength (default 1.0, -1 for auto) - same master-volume semantics as the plain Optimizer.
• clip / clip_strength_multiplier (optional) - same as elsewhere in the pack.
• auto_strength_floor (default -1, meaning architecture-aware default) - how far auto-strength is allowed to shrink your LoRA strengths. 1.0 means don't shrink at all; 0 removes the floor entirely. This only matters if the selected config used auto-strength.
• decision_smoothing (default 0.25) - must match the value the original AutoTuner run used if per-group decisions in that config depended on smoothing; mismatching it can shift which strategy gets applied where.
• vram_budget (default 0, meaning all patches on CPU) - how much free VRAM to use for storing merged patches, reducing RAM usage on systems with spare GPU memory.

Outputs: model/clip for your sampler, report for a Show Text node, lora_data for Save Merged LoRA.

How to install it

ComfyUI Manager: search "LoRA Optimizer", install, restart. Manually:

cd ComfyUI/custom_nodes/
git clone https://github.com/ethanfel/ComfyUI-LoRA-Optimizer.git

Restart - nodes appear under loaders. No downloads; it applies configs already computed by an AutoTuner or Estimator run.

Common issues & troubleshooting

Result doesn't match what you saw in the AutoTuner's report for that rank. Check decision_smoothing - if the original sweep used a non-default value and this node is left at its own default 0.25, per-group decisions can resolve differently. Match the value the AutoTuner run actually used.

selection out of range. The AutoTuner and Estimator only rank as many candidates as they actually evaluated (top_n on the AutoTuner, top_n_output on the Estimator). Setting selection higher than that doesn't get you a new option - check the original tuner_data source's report to see how many ranked entries actually exist.

Using a different lora_stack than the original run. This node applies the config from the ranked entry, but it still runs the merge against whatever lora_stack you connect here. If that's not the same stack the AutoTuner analyzed, the config it's applying was tuned for different LoRAs - results won't be meaningful. Keep the stack identical to the one that produced the tuner_data you're selecting from.