LoRA Training Settings: What Works and What Doesn't

TL;DR

• Manual cropping over bucketing is a workflow choice, not a proven technique. Both exist in the tooling; no controlled comparison exists.
• Removing auto-generated regularization images reportedly helped one user, but no A/B test supports it. The mechanism is plausible but remains a single observation.
• Low repeats with high epochs (5/50) vs. high repeats with low epochs (10/20) is an untested trade-off. The docs don't prescribe either.
• Rank 64 with alpha 32 matches the documented alpha ≈ 0.5 × dim rule, but no evidence ranks this combo above alternatives.
• "15–20 minutes on RTX 3080" cannot be independently verified — it depends on dataset size, batch size, and checkpoint.

LoRA Setting Claims That Hold Up

Several community settings align with the official Kohya_ss sd-scripts documentation [1,2].

Terminology note: the community source writes "Koya_ss." The correct name is Kohya_ss (kohya-ss/sd-scripts) ^[1] — a misspelling, not a different tool.

Setting Claims That Cannot Be Verified

These specific configurations appear only as personal recommendations with no independent corroboration:

• Rank 64 / alpha 32 with cosine_with_restarts and 12 LR cycles — each component is documented, but no controlled test compares this against alternatives like rank 32 with constant LR.
• 5 repeats / 50 epochs vs. 10 repeats / 20 epochs — the author's self-correction ("Edit 7-19") is a single observation, not a replicated finding.
• "Full LoRA in 15–20 minutes on RTX 3080" — depends on dataset size (225 and 79 images in source), batch size, and checkpoint. No benchmark exists.

Treat these as starting points for your own testing, not as evidence-based recommendations.

The Regulation Image Claim

The most striking claim: removing 2,500 auto-generated regulation images improved LoRA quality ^[7]. The author reports going from "OK to poor results" to "quite good" after discarding them.

The mechanism is plausible: auto-generated captioned images from the source model can create a feedback loop where the LoRA reproduces the source model's biases rather than learning the dataset's concept — a known fine-tuning risk.

But this was uncontrolled. The author did not compare with/without side by side, nor isolate regulation images as the sole variable (dataset curation, cropping, and tag editing changed simultaneously). A controlled test would train two LoRAs with identical datasets except for regulation images, then evaluate blind.

Manual Cropping vs. Aspect Ratio Bucketing

The author ditched bucketing and manually cropped to 512×512 using Inbac ^[3], citing control over composition and smoother training.

Kohya_ss supports both via enable_bucket in the dataset TOML ^[1]. Bucketing groups by aspect ratio to avoid distortion — critical for non-square images. Manual cropping gives frame-level control but discards aspect-ratio diversity.

No controlled comparison exists. Choose based on your data: if images are near-square and curated, manual cropping works. If aspect ratios vary, bucketing avoids aggressive cropping.

WD14 Tagging and Tag Editing

The workflow uses WD14 tagger (in Automatic1111 and sd-scripts) for auto-captioning, then BooruDatasetTagManager [4,5] for editing. The author cuts eye-color and hair-color tags because the tagger "gets it wrong a lot."

BooruDatasetTagManager's documented purpose is a tag editor for hypernetwork, embedding, and LoRA datasets with batch editing and auto-tagging via AiApiServer ^[4]. It supports weighted tags, translation, and booru-style autocompletion ^[4].

Whether WD14's eye/hair color errors are common enough to warrant routine removal is untested. The practice is a reasonable heuristic but may discard semantic information that helps distinguish similar subjects.

How to Run Your Own Controlled Comparison

Isolate one variable at a time:

1. Pick a fixed base model. (sd-legacy/stable-diffusion-v1-5 on HuggingFace is widely used.)
2. Prepare two identical datasets. Same images, captions, train/test splits. Only the tested variable differs.
3. Log every run. Save outputs per epoch, per prompt, fixed seeds. Kohya_ss supports --save_state for this.
4. Evaluate blind. A second person (or yourself after a delay) ranks outputs without knowing which settings produced them.
5. Measure, don't guess. Use consistent evaluation prompts and compare side by side.

All community-mentioned settings (network_dim, network_alpha, learning_rate, lr_scheduler, mixed_precision, save_every_n_epochs) are Kohya_ss command-line arguments ^[1], making single-variable swaps straightforward. See our Kohya_ss LoRA training guide for a full flag reference.

Common Errors and Fixes

FAQ

What is the best network rank for LoRA training? No universal best. Ranks 4–128 are common; docs default to 16 ^[1]. Higher ranks increase expressiveness, file size, and compute. Rank 64 suits complex concepts but produces larger files.

Should I use cosine_with_restarts or constant learning rate? Both are valid ^[1]. Cosine_with_restarts periodically raises LR (num_cycles controls restarts ^[2]), which may help escape local minima on long runs. Constant is simpler and effective for many workflows.

How many repeats do I need? The source used 10 repeats for 225 images and 20 for 79, later suggesting 5/50 as alternative ^[7]. No evidence favors either. The docs don't prescribe repeat counts. Start with what fits your budget, then evaluate output quality over step count. Can I use SD v1.5 for LoRA training and apply the LoRA to other models? The author reports training on sd-legacy/stable-diffusion-v1-5 and testing with Photon V1 and Reliberate V10 ^[7]. Cross-model LoRA transferability is not documented in any verified source. Results vary by target architecture and base checkpoint compatibility. See our LoRA cross-model compatibility guide for more.

What mixed precision should I use? Use bf16 if your GPU supports it (Ampere and newer); fp16 on older hardware ^[1]. bf16 reduces VRAM and can improve speed on supported GPUs. Fall back to fp16 if bf16 is unstable.

Is manual cropping better than aspect ratio bucketing? Neither is systematically better ^[1]. Bucketing avoids distortion for non-square images; manual cropping gives frame-level control. Both are supported.

How do I know which epoch is the sweet spot? Save every epoch (save_every_n_epochs=1), then evaluate different epochs. The author recommends starting at epoch 10 and working forward/backward ^[7].

What is the difference between network_dim and network_alpha? Network_dim is the LoRA rank — the adapter matrix dimensionality. Network_alpha scales LoRA weights during training; docs recommend ~half of network_dim ^[1]. A rank-64 LoRA with alpha 32 trains at half the effective LR of rank-64 with alpha 64.

Sources

• https://civitai.com/articles/1161 — Community LoRA training post by doublerig (Jul 2023)
• https://civitai.com/articles/1019 — TecnoIA proposal for organized LoRA training labs (Jul 2023)
• https://civitai.com/articles/11684 — No Need LoRA post by Kisaku_KK77 (Feb 2025)
• https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network.md — Official Kohya_ss LoRA training docs; confirms network_dim, network_alpha, learning_rate, lr_scheduler, mixed_precision
• https://github.com/weclaw1/inbac — Inbac: interactive batch image cropper; confirms pip install, aspect-ratio selection, resize
• https://github.com/starik222/BooruDatasetTagManager — BooruDatasetTagManager; confirms dataset tag editing, auto-tagging, multi-image workflows
• https://github.com/kohya-ss/sd-scripts/blob/main/docs/train_network_advanced.md — Kohya_ss advanced docs; confirms SDXL network_dim guidance and LR scheduler num_cycles
• https://huggingface.co/sd-legacy/stable-diffusion-v1-5 — HuggingFace model card for sd-legacy/stable-diffusion-v1-5; confirms checkpoint, training data (595k steps at 512×512 on laion-aesthetics v2 5+), compatible frameworks
• https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Features#wd14-tagger — WebUI wiki; confirms WD14 tagger as auto-tagging feature