LoRA AutoTuner Settings

There are two ways to get AutoTuner's parameter-sweep behavior into your workflow: the standalone LoRA AutoTuner node, which takes its own model/lora_stack inputs and runs independently, or this node, which packages the same sweep logic as an OPTIMIZER_SETTINGS object you plug into the plain LoRA Optimizer's settings input. If you've already got LoRA Optimizer wired into a graph and just want it to sweep instead of using fixed settings, this is less rewiring than swapping in the standalone AutoTuner node.

How it works

Same underlying sweep as LoRA AutoTuner - Pass 1 analysis once, heuristic scoring across candidate configs, real merge-and-measure on the top top_n. The difference is purely architectural: this node doesn't own the merge, it hands its settings to whatever node's settings input it's connected to, and that node runs the actual merge.

The inputs that matter

• top_n (default 3) - how many top-scoring configs get a real merge-and-measure pass. This is the main dial for the speed/thoroughness tradeoff.
• scoring_speed (default turbo) - full scores every weight prefix per candidate (most accurate, slowest - worth it for stacks combining very different LoRAs, like style + character in one stack). fast/turbo/turbo+ sample progressively fewer prefixes; turbo+ is the one to reach for on large models like Flux or WAN, or when you're iterating quickly and can tolerate missing subtle block-level differences.
• scoring_svd (default disabled) - the default fast norm-only scoring is usually enough. merge_quality and lora_rank add SVD-based analysis for more thorough (and slower) scoring; both are hardware-accelerated if Triton is installed.
• diff_cache_mode (default auto) - caches raw LoRA diffs across candidates instead of recomputing them each time, since diffs depend only on the LoRA content, not the merge config. auto uses RAM up to diff_cache_ram_pct and recomputes anything past that budget rather than spilling to disk.
• community_cache (default disabled) - download precomputed results for LoRAs matching your exact file content from a shared Hugging Face dataset, and optionally contribute your own back with upload_and_download (requires an HF_TOKEN environment variable for uploads; downloads need nothing).
• memory_mode (default auto) - persists a tuned result across ComfyUI sessions keyed by LoRA names, strengths, and settings, so re-running the same stack replays the winning config instantly instead of re-sweeping. auto_ignore_strength is worth knowing about specifically if you're sweeping strength values on orthogonal LoRAs, where the ranking usually doesn't change with strength anyway.
• selection (default 1) - which ranked config to actually apply, without re-running the sweep to try alternatives.

Optional connections: merge_settings to inherit shared settings from a Merge Settings node, and evaluator to blend in a custom Python scoring function via Build AutoTuner Python Evaluator.

Output: settings (OPTIMIZER_SETTINGS) - connect to the settings input on LoRA Optimizer.

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 unless you turn on community_cache, which talks to Hugging Face.

Common issues & troubleshooting

Heavy RAM usage on large stacks or video models. This node runs the same sweep machinery as the standalone AutoTuner, and it carries the same real-world cost - a reported case running 3 LoRAs on Wan 2.2 through the AutoTuner sweep nearly filled 96GB of RAM before crashing. Set diff_cache_mode to disk instead of the default auto, and reconsider whether a full sweep is worth it on every iteration for video-model stacks specifically.

Connected this node but the Optimizer still looks like it's using fixed settings. Confirm the settings output is actually wired into LoRA Optimizer's settings input, not left dangling - a settings connection silently overrides tuner_data and defaults, so if it's not connected, nothing about this node's configuration takes effect.

Sweep runs every single execution, even when nothing changed. That's what memory_mode=auto is for - it should replay a cached result rather than re-sweeping once a stack's LoRAs and settings match a previous run. If it's re-sweeping anyway, double check nothing about the stack (even a strength value, unless you're using auto_ignore_strength) actually changed between runs.