Kohya vs OneTrainer for LoRA Training

Installation and Updates

Kohya_ss currently documents local installation through uv or pip, with separate Windows, Linux, and macOS instructions. It also documents Docker, Colab, and hosted GPU paths. The project recommends uv first for a faster, more isolated environment.

OneTrainer currently requires Python 3.10 or newer and below 3.14. Its automatic path uses install.bat on Windows or install.sh on Linux and macOS, then start-ui.bat or start-ui.sh.

Neither project should be updated casually in the middle of a proven training run. Save the config, note the repository commit or release, and finish the baseline first. Training dependencies change quickly enough that an update can alter speed, memory use, defaults, or supported model paths.

Winner: OneTrainer has the simpler conceptual installation flow. Kohya has more documented environment choices, which is useful for local, container, and hosted setups.

Model and Training Method Support

Both current READMEs list SD 1.5, SDXL, and Flux support. Both also cover model families beyond those three, but a name in a support list isn't proof that every training method, precision, optimizer, or export format behaves identically.

Kohya_ss lists LoRA, LoHa, LoKr, DreamBooth, fine-tuning, Textual Inversion, and LECO concept editing. OneTrainer lists LoRA, full fine-tuning, and embeddings, plus masked training and EMA.

Kohya is the stronger choice when a project depends on a specific sd-scripts feature or network type. OneTrainer covers the mainstream LoRA workflow and adds integrated project tools that reduce context switching.

Winner: Kohya for training-method breadth and direct sd-scripts alignment. Tie for ordinary LoRA work, pending the exact model family.

Dataset and Captioning Workflow

Dataset quality dominates both tools. You still need to remove duplicates, weak images, unwanted watermarks, contradictory examples, and captions that describe the wrong traits.

OneTrainer makes dataset work feel more unified. Concepts can use prompts from same-name text files, image filenames, or a separate multi-line text source. The official feature list includes automatic BLIP, BLIP2, and WD-1.4 captions plus ClipSeg and Rembg masks. Its concept settings also cover augmentation, subdirectories, and prompt sources.

Kohya offers established dataset configuration patterns and captioning utilities in its broader GUI workflow, including WD tagger support. Its strength is flexibility, but users need to understand folder structures, repeats, subset configuration, and architecture-specific data settings.

Automatic captions from either tool need human review. Normalize names, remove hallucinated details, preserve the trigger token, and decide which features should vary. Our dataset and captioning guide covers this process without tying it to one trainer.

Winner: OneTrainer for first-run organization. Kohya for trainers who already have a structured dataset pipeline.

Presets and Parameter Control

Kohya's dense interface is an advantage only when you understand the fields. It exposes the arguments needed for nuanced sd-scripts recipes and can generate the underlying CLI command. That makes a run easier to audit when a guide specifies exact arguments.

OneTrainer uses presets to provide a starting configuration, then organizes input model, output, data, concepts, training, LoRA, sampling, backup, and other settings into a project flow. Presets reduce setup time but don't remove the need to inspect model type, resolution, learning rate, trained components, rank, alpha, precision, and total exposure.

A preset is not scientific evidence. Save it as a baseline, change one variable, and compare with fixed prompts. Copying a preset between SD 1.5, SDXL, and Flux is a common way to waste a run.

Winner: Kohya for experts who need exact parameter access. OneTrainer for users who want a stronger default path through the controls.

Workspaces, Backups, and Reproducibility

OneTrainer's workspace concept is its clearest operational advantage. A workspace stores the backup, sample, and TensorBoard data for one run. Automatic backups can preserve the state needed to continue training.

The catch is important: OneTrainer's official quick start says backups aren't files for Forge, SwarmUI, or other inference tools. You need a model save or converted export for inference.

Kohya can produce repeatable runs through saved configurations, generated commands, logs, sample prompts, and checkpoints. It gives you the pieces, but you must enforce the folder structure and naming discipline yourself.

A reproducible project in either tool needs the final LoRA, configuration, dataset manifest, caption snapshot, base-model hash, repository version, fixed sample prompts, seeds, and evaluation notes.

Winner: OneTrainer for built-in run organization and continuation. Kohya can match it with disciplined external project management.

Sampling and Monitoring

Kohya supports sample generation during training from a prompt file. Its README documents prompt options for negative text, width, height, seed, guidance, and sampling steps. This is enough to build a fixed evaluation grid.

OneTrainer includes a sampling UI and TensorBoard integration, with outputs attached to the workspace. This lowers the friction of checking visual progress while the run continues.

Don't choose a checkpoint from loss alone. Loss can help identify instability, but it doesn't measure prompt flexibility, identity, style strength, leakage, or whether a later checkpoint memorized the dataset.

For either trainer, use the same prompts, seeds, dimensions, sampler, and LoRA weights at every checkpoint. Include a trigger prompt, a variation prompt, a difficult composition, and a no-trigger control.

Winner: OneTrainer for integrated monitoring. Kohya's prompt-file method is equally valid when you already have an evaluation script.

SDXL and Flux Differences

Architecture matters more than trainer choice. SDXL and Flux should not share a generic preset.

Kohya's LoRA resource guide recommends at least 1024×1024 for SDXL, at least 12 GB GPU memory, and UNet-only training to avoid unexpected results from SDXL's dual text encoders. Treat this as a project baseline and test it against your dataset.

OneTrainer's quick start explains resolution, bucketing, mixed precision, component training, and multiple resolutions. Its Flux wiki calls Flux large and slow, recommends LoRA for ordinary training, and gives evolving model-specific guidance. The page explicitly says it is a work in progress.

Use our dedicated SDXL guide and Flux requirements guide after choosing the trainer. They separate architecture decisions from interface navigation.

Winner: Tie. The correct choice depends on which project currently supports the exact architecture, method, and hardware path you need.

Hardware and Memory

Don't choose a trainer based on one screenshot claiming a universal VRAM minimum. Batch size, resolution, precision, optimizer, caching, model format, trained components, and software version all affect memory.

Both tools can reduce pressure through architecture-appropriate settings, but the names and combinations differ. Start with batch size one for a smoke test, close inference applications, and confirm the run completes before scaling up.

SD 1.5 remains the easiest architecture for learning the process. SDXL raises resolution and memory demands. Flux is heavier again and needs its current project documentation.

Winner: Tie. The architecture and configuration dominate; neither interface creates free VRAM.

Output Quality

Neither trainer has an inherent quality button. Given the same architecture, clean dataset, equivalent objective, sensible settings, and stopping point, both can create useful LoRAs.

Differences appear because the workflows encourage different behavior. Kohya makes fine-grained experiments easier when you know which argument to change. OneTrainer makes run organization, backups, and integrated sampling easier, which can improve decision quality.

The biggest quality failures are tool-independent:

• Noisy data: Duplicates and contradictory examples weaken the target.
• Bad captions: Missing triggers or overdescribed permanent traits confuse associations.
• Wrong exposure: Too few steps underfit; too many lock in poses and backgrounds.
• Weak evaluation: Testing one prompt at one LoRA weight hides brittleness.
• Architecture mismatch: A model can save successfully and still be unusable with the intended base.

Winner: Tie. Process quality beats trainer branding.

Common Decision Mistakes

• Choosing by interface alone: A cleaner screen doesn't prove the required model path works.
• Assuming shared settings: Similar field names can have different valid values across architectures and optimizers.
• Calling OneTrainer a Kohya fork: The official project materials don't support that claim.
• Ignoring licenses: Kohya_ss is Apache 2.0 and OneTrainer is AGPL-3.0; base models and datasets have separate terms.
• Skipping a smoke test: A ten-minute pipeline check can catch missing captions and wrong output formats before a long run.
• Comparing uncontrolled outputs: Different seeds and prompts don't show which checkpoint improved.

Next Steps

Start with the overview pillar and the separate dataset and captioning guides. Then choose the dedicated Flux requirements or SDXL guide for model-specific setup. Use the existing local Stable Diffusion setup article to build a separate inference environment and test exports outside the trainer.

Run one short baseline in your chosen tool. Archive its config, samples, model hash, and repository version before changing any parameter.

Who should use what

Use Kohya_ss if:

• You want direct alignment with sd-scripts and community configs built around its arguments.
• You need LoHa, LoKr, DreamBooth, Textual Inversion, or another method explicitly listed by Kohya.
• You already understand dataset configuration and want finer parameter control.
• You prefer generated CLI commands and external experiment organization.

Use OneTrainer if:

• You want concepts, prompt sources, captions, masks, augmentation, samples, backups, and TensorBoard in one application.
• You value clean workspaces and resumable training state.
• You want a preset-led first run without giving up GUI and CLI options.
• You understand that backups are for continuation and exports are for inference.

Our recommendation: Start with OneTrainer for your first conventional LoRA when its current preset supports the target model. Move to Kohya_ss when a proven sd-scripts recipe, specialized network type, or exact argument requires it. If you already have a reliable Kohya workflow, don't switch tools for novelty; improve the dataset and evaluation process first.