LoRA Merge Estimator

LoRA AutoTuner is thorough but not cheap - it runs a real merge-and-measure pass on multiple candidates. This node is the shortcut version: instead of sweeping your specific stack, it looks up similar combinations that other people have already tuned, in a shared community dataset, and predicts a good config from their results. No sweep, no per-candidate merging - just a lookup.

What it is and why you'd use it

The pack's rationale, straight from the README, is that LoRA analysis results are hardware-agnostic: the same LoRA files produce the same conflict metrics regardless of whose GPU ran the analysis. That means someone else's AutoTuner sweep on a similar combination of LoRAs is genuinely reusable data, not just a rough guess. The Estimator builds a k-nearest-neighbors index over a public dataset of previously-tuned configs (keyed by content hash, not filename, so it matches across different folder layouts), analyzes your stack once with a lightweight Phase 1 pass, and retrieves the closest matches.

Use it as your first move on a new LoRA combination, especially one that resembles things other people are likely to have tried - character or style LoRAs on a popular base model, for instance. Fall back to the full LoRA AutoTuner if the Estimator's report says No neighbors (meaning the index has nothing close enough to your specific family and combo size) or if the predicted config just doesn't perform well in practice.

How it works

Connect your model and stack the same way you would for the Optimizer or AutoTuner. The first run downloads the community cache and builds a local k-NN index under ComfyUI/models/estimator/ - the README puts this at roughly 30–60 seconds. Every run after that reuses the local index and completes in seconds, since there's no Phase 2 sweep and no merge-quality pass involved at all.

The inputs and outputs that matter

• model / lora_stack (required) - same as the Optimizer and AutoTuner.
• clip (optional) - only used during the Phase 1 analysis; doesn't otherwise change the estimate.
• k (default 5, range 1–20) - how many nearest neighbors to retrieve from the index.
• rebuild_index (default auto) - auto rebuilds when the underlying dataset or index schema changes, force always rebuilds, skip never rebuilds and errors if the index is missing entirely.
• top_n_output (default 3) - how many aggregated candidate configs to emit.

Outputs: tuner_data - feed this straight into LoRA Optimizer's tuner_data input to apply the predicted config, or into a Merge Selector to try one of the alternate top-N predictions. estimator_report - a STRING listing the predicted configs, their aggregated scores, and how far the retrieved neighbors were from your stack - wire it to Show Text to see whether the match is actually close or a stretch.

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 - it's under loaders. The node itself needs no extra pip install, but expect a one-time download of the community dataset on first use - that's separate from the pack's own install and happens automatically the first time this node runs.

Common issues & troubleshooting

First run is noticeably slow, then it's fast. That's expected - the 30–60 second cost is the one-time index build. If every run feels slow, check rebuild_index isn't stuck on force, which rebuilds every single execution instead of reusing the cached index.

Report says No neighbors. The index genuinely has nothing close enough to your specific LoRA family and combo size. This isn't an error - it means the community dataset doesn't cover this case yet. Fall back to LoRA AutoTuner for a real sweep on this particular stack.

Predicted config underperforms. The Estimator is a prediction from similar-but-not-identical combinations, not a guarantee. If the applied config looks off, that's the signal to run the full AutoTuner instead of trusting the estimate - the README frames this explicitly as the tradeoff: fast prediction versus authoritative, measured search.