OneTrainer LoRA Training Guide: A Repeatable First Run

Step 1 — Install OneTrainer from the Official Repository

The current README requires Python 3.10 or newer and below 3.14. Clone Nerogar/OneTrainer, then use install.bat on Windows or install.sh on Linux and macOS. Manual virtual-environment installation is also documented.

Start the GUI with start-ui.bat on Windows or start-ui.sh on Unix-like systems. Confirm the application opens and sees the expected GPU before downloading or indexing a large dataset.

Record the commit or release used for a successful project. Update between experiments, not halfway through one. If a reproducible problem remains after updating, the project asks for an exported debug report with issue submissions.

Step 2 — Create a Clean Workspace

Give every training experiment an empty workspace directory. OneTrainer uses it for backup, sample, and TensorBoard data, which makes the workspace your run history.

Use a predictable structure:

• Source: Original images that never change during the experiment.
• Training set: Cleaned images and matching captions.
• Workspace: OneTrainer's run state, samples, and backups.
• Exports: Final inference-ready LoRA files and configs.
• Evaluation: Fixed prompts, seeds, contact sheets, and notes.

Don't point two active experiments at the same workspace. Mixed samples and backups make it hard to prove which settings produced a checkpoint.

Step 3 — Prepare and Caption the Dataset

Remove duplicates, blurred failures, irrelevant images, watermarks, and contradictory examples. Keep the concept consistent while preserving useful variation in pose, framing, background, lighting, and composition.

OneTrainer's quick start supports prompts from same-name .txt files, image filenames, or a separate text file selected in the concept. Same-name caption files are the easiest format to inspect and move between tools.

Automatic captioning is a draft, not a final authority. Review every caption, normalize spelling, remove hallucinated details, and decide which permanent concept traits belong behind the trigger token. The dedicated dataset and captioning guide gives a complete cleanup process.

Keep a few images outside training. Validation images won't calculate magic quality scores, but they help you test whether the learned concept generalizes beyond repeated training compositions.

Step 4 — Select a Preset and Input Model

Choose the preset matching both the architecture and training method. Then select the exact base model and identify its model type correctly.

The quick start says OneTrainer accepts:

• Checkpoint files: .ckpt or .safetensors where supported.
• Diffusers directories: A local model folder in Diffusers format.
• Hugging Face identifiers: A repository name when access and connectivity allow it.
• OneTrainer backups: For continuing training, not as inference files.

Save the base model's source, license, filename, and hash. A LoRA trained on SDXL won't become a Flux LoRA by changing the output filename.

Step 5 — Add and Inspect the Concept

Create a concept configuration, add the concept, and point it at the training directory. Select the actual prompt source. If captions are beside images, verify OneTrainer resolves several random pairs before training.

Enable aspect-ratio bucketing when the set contains varied shapes. OneTrainer's documentation says images are resized to roughly the same target pixel count within generated buckets.

Use augmentation only when it preserves meaning. Horizontal flips are wrong for readable text, one-sided details, and directional designs. Color or brightness changes can also weaken a color-specific style or identity.

If latent caching is enabled, remember that data-setting changes can make an old cache invalid. The quick start says to clear the cache or use a new cache directory when related settings change.

Step 6 — Set Training and LoRA Controls

Confirm epochs, batch size, gradient accumulation, learning rate, scheduler, precision, resolution, trained components, rank, alpha, and dropout. Don't edit every field because a forum screenshot did.

• Batch size: Larger batches require more VRAM. Accumulation can approximate a larger effective batch at the cost of time.
• Learning rate: Too high can damage the run; too low may produce little visible learning. Valid ranges depend on optimizer and model.
• Train data type: Mixed precision trades numerical precision for speed and memory. Hardware support matters.
• Rank and alpha: These control adapter capacity and scaling. Higher rank increases capacity, size, and memorization risk.
• Trained components: UNet/transformer and text-encoder choices are architecture-specific. Follow the current preset and model guide.

For SDXL, use the dedicated SDXL guide rather than a Flux or SD 1.5 recipe. For Flux, use OneTrainer's current wiki and our Flux guide; the project's Flux page changes as maintainers learn more.

Step 7 — Configure Samples, Saves, and Backups

Add several fixed sampling prompts before the run:

• Trigger prompt: Shows whether the core concept appears.
• Variation prompt: Changes setting, pose, lighting, or framing.
• Composition prompt: Tests whether the LoRA follows other prompt details.
• No-trigger prompt: Reveals unintended effect when the trigger is absent.

Use fixed seeds, dimensions, sampler settings, and prompt text. Visual comparison becomes meaningless if every checkpoint receives a different random test.

Configure regular model saves and backups. The quick start makes a critical distinction: a backup contains training state for continuation, but it isn't meant to load in Forge, SwarmUI, or another inference UI. Export or save the model in the intended inference format.

Step 8 — Run a Smoke Test

Start with a short run that proves the complete pipeline. Confirm image loading, prompt loading, cache creation, samples, backups, and model saves all work.

Inspect TensorBoard, but don't treat falling loss as visual quality. Open generated samples and check that the trigger changes output in the intended direction.

If the application runs out of memory, lower batch size first, close other GPU applications, and confirm precision and caching settings are supported for the architecture. Don't randomly reduce resolution below the model's useful training range just to force a run.

Step 9 — Train and Compare Checkpoints

Run the baseline without changing its data midstream. Review samples at every save interval and record the first checkpoint where the concept becomes recognizable.

Later isn't always better. Overtraining often appears as repeated poses, baked-in backgrounds, unwanted clothing, harsh texture, color drift, or reduced response to other prompt details.

Compare several checkpoints at multiple LoRA weights. A usable model usually has a controllable range rather than working at one exact weight. Keep the baseline even if a later experiment looks stronger; it is your reference.

Step 10 — Export and Validate in Your Real UI

Save or convert the winning checkpoint into the inference format you need. Load it in your actual application with the exact base model used for training.

Build an evaluation grid with fixed prompts and seeds. Include:

• A close match to the training domain
• A new background and composition
• Different framing or aspect ratio
• A difficult prompt with competing details
• A no-trigger control

Archive the final LoRA, OneTrainer config, concept config, sample prompts, base-model hash, dataset manifest, and notes. State the tested architecture, checkpoint, trigger, recommended weight range, and known failures when sharing.

Common OneTrainer Mistakes

• Reusing a dirty workspace: Old cache, samples, and backups blur the boundary between runs.
• Confusing backups with exports: Training backups are for continuation; model saves are for inference.
• Trusting generated captions: Automatic labels need human cleanup.
• Wrong prompt source: A concept can point at images while failing to read the captions you expected.
• Uncontrolled augmentation: Flips and color changes can teach the wrong invariances.
• Changing data during training: A baseline isn't reproducible if files or captions change halfway through.
• Judging only loss: The best numerical loss isn't guaranteed to be the most flexible visual checkpoint.

Troubleshooting

The LoRA does nothing: Confirm the exported file loads, the base architecture matches, the trigger exists in training captions and inference prompts, and the test weight is visible.

Samples look memorized: Stop at an earlier checkpoint, remove duplicates, add meaningful variation, reduce total exposure, or use less adapter capacity.

Training changed after caption edits: Clear the relevant cache or create a new workspace/cache. Cached intermediates can preserve stale data assumptions.

You can't continue a run: Select the OneTrainer backup directory as the input source and keep compatible settings. Don't try to resume from an inference-only LoRA export.

Next Steps

Read the overview pillar, then finish the separate dataset and captioning checklists before starting a long job. Use the model-specific Flux requirements or SDXL training guide for architecture choices, and validate the export in a clean local Stable Diffusion setup.

Your second experiment should alter one variable: data, learning rate, rank, total exposure, or trained components. One controlled comparison beats a folder of mystery checkpoints.