Lora Weight Auto Optimizer

If you've ever stacked three LoRAs and then spent an evening nudging one weight from 0.75 to 0.8 to 0.9 in a pointless game of weight whack-a-mole, this node is aimed straight at you. Lora Weight Auto Optimizer (class LoraOptimizer) turns that fiddling into an actual search: it samples a batch of candidate weight combos, you generate an image per candidate, you rank them, and it evolves the next batch toward whatever you liked. You are the fitness function. It does the moving.

The honest up-front take: this is a lab tool, not a proven workflow staple. The repo is one commit old, there's essentially zero community footprint for it anywhere, and the author's own README ends with the caveat that it's "maybe not as good as manually selecting every lora weight." That's refreshingly honest. Use it as an experiment to find a good starting point, not as a magic auto-tune button.

How it works

At generation one the optimizer samples batch_size random weight vectors (one per LoRA in your stack, clamped to each LoRA's bounds). Each of your generated images uses a different candidate. You look at the batch, decide which is best, and type the ranking as a comma-separated string - "3,1,2" means candidate 3 is best, then 1, then 2. On the next run, the node feeds that ranking to the optimizer and evolves a fresh batch.

Two algorithms, selectable on the method dropdown:

• CMA-ES (default) - adapts a full covariance matrix to model the search distribution. The one to use when LoRA weights interact in messy ways, which is most of the time.
• Tournament GA - tournament selection, blend crossover, per-gene Gaussian mutation with elitism. Simpler, cruder, more exploratory. Nice if you want a wider sweep before narrowing in.

Every generation is written to ComfyUI/custom_nodes/Comfyui-lora-weight-auto-optimization/logs/<log_name>/optimization_log.json, so runs are resumable. Same log_name, same LoRA list, same method and batch_size? It picks up exactly where you left off.

The inputs that matter

Only a few are worth your attention:

• index (forced input) - the position of the current image in the batch, 0-based. This is the fiddly bit: you need a counter or a loop that hands out 0, 1, 2… one per image, or every image uses candidate 0 and nothing ever evolves. The author's example workflow drives it with an Easy-Use for-loop.
• batch_size - candidates per generation. README says make it at least the number of LoRAs you're tuning; more gives the optimizer more to learn from per round, at the cost of more images to rank.
• ranking - a full permutation of 1..batch_size, no ties, no gaps. Only processed when index is 0, which is how the node avoids double-updating mid-batch.
• log_name - names the session; a new one starts fresh, an existing one resumes.

The three optional LORA_STACK inputs are the same stack fed into three different bound slots: lora_stack_0_1 ([0, 1] - the usual range), lora_stack_neg1_1 (lets it go negative, handy for subtracting a LoRA's influence), and lora_stack_0_2 (headroom above 1 for weak LoRAs). Use whichever range fits the LoRA you're tuning.

Outputs

lora_stack is the winner for the current index - wire it into any model-loading node that accepts a LORA_STACK, like the Easy-Use Efficient Loader in the example. status tells you sigma, mean change, and whether it's flagged converged or near (sigma below 0.005 or 0.02). filename_prefix is meant to be linked to your image saver's prefix so you can tell which candidate produced which image.

Installing it

ComfyUI Manager → search Comfyui-lora-weight-auto-optimization → install, or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/Akitsuki4852/Comfyui-lora-weight-auto-optimization

Restart ComfyUI. That's it - the only dependency is numpy, which ComfyUI ships anyway. No model downloads.

Gotchas

Ranking that isn't a perfect permutation throws an error, so count your candidates carefully. Resuming a log with a changed LoRA list, method, or batch_size also errors out - that's by design, keep the run consistent. And remember "converged" just means the search stopped exploring: with a tiny batch and noisy human rankings, early convergence is usually the optimizer giving up, not finding truth. If a candidate looks great but you want finer control afterward, note its weights from lora_stack_text and hardcode them in a plain LoRA loader. That's the part the author's caveat is about, and it's genuinely where this tool shines - finding a smart starting point, not replacing the fine-tuning.