LoRA training hardware: SD 1.5, SDXL, and Flux without guesswork
Choose a realistic GPU tier and training tool for image-model LoRAs. Understand resolution, rank, optimizer state, gradient checkpointing, caching, and offload before committing to a workflow.
Bottom line
Training memory depends on what stays trainable and resident, not only checkpoint size. SD 1.5 is the forgiving starting point; SDXL raises the baseline; Flux examples often target 24 GB and should not be generalized to every configuration.
Decision table
| Hardware | Best fit | Editorial decision |
|---|---|---|
| 8 GB | SD 1.5 learning and carefully constrained jobs | Start here only if you accept small batches, checkpointing, cached latents, and configuration work. Treat SDXL or Flux success stories as workload-specific experiments, not a dependable baseline. |
| 12 GB | Practical SD 1.5; constrained SDXL | A useful hobby tier. SDXL may require memory-saving options and conservative resolution or batch choices. Validate the exact trainer preset before preparing a large dataset. |
| 16 GB | More comfortable SDXL experimentation | Provides room to iterate on rank and resolution without every choice being dictated by memory. Flux remains configuration-sensitive and may rely on quantization or offload. |
| 24 GB | Serious SDXL and documented Flux LoRA paths | AI Toolkit’s upstream example is framed around training Flux on a 24 GB GPU. That is evidence for one supported path—not a universal guarantee for every model, optimizer, resolution, or extension. |
| 48 GB+ | Fewer compromises, larger experiments, higher throughput | Useful when training time, larger batches, or more trainable components matter. Capacity does not replace dataset quality or disciplined validation. |
Why training uses more memory than inference
Inference primarily stores model weights and temporary execution state. Training also needs gradients, optimizer state, and activations required for backpropagation. A LoRA reduces the number of trainable parameters, but the base model still has to participate in the forward and backward passes.
That is why a checkpoint that generates comfortably on a card may not train comfortably there. “The model fits” and “the training configuration fits” are separate claims.
The settings that move the memory ceiling
Resolution and batch size are the first levers to inspect. Rank changes adapter capacity and memory, but it is not a simple quality dial. Optimizer choice can materially change state memory. Gradient checkpointing trades additional computation for lower activation memory; caching latents or text embeddings changes what must be recomputed and stored.
Offloading and lower-precision components can make a run feasible, while increasing setup complexity and sometimes slowing each step. Record these settings with every result so you can reproduce it.
- Base model and which components are trainable
- Training resolution, crop strategy, and batch size
- LoRA rank/alpha and optimizer
- Gradient checkpointing, latent/text caching, precision, and quantization
- Whether the text encoder or other components are offloaded or trained
OneTrainer or AI Toolkit?
OneTrainer is a broad training application supporting multiple model families and training methods through a GUI and command-line workflow. Its upstream project emphasizes configurable training, concepts, sampling, backup, and multiple optimization options.
AI Toolkit is a more opinionated training toolkit whose upstream repository includes Flux-focused examples and a documented 24 GB consumer-GPU target for a specific configuration. Choose based on the model and reproducible preset you need—not on which interface looks simpler.
- Choose OneTrainer when you want one configurable interface across model families and value built-in concept/dataset controls.
- Choose AI Toolkit when its maintained recipe directly matches your target model and you are comfortable editing configuration files.
- Before switching trainers, export captions, dataset structure, trigger-token decisions, and sampling prompts; trainer-specific config rarely migrates cleanly.
A safer first training plan
Prove the pipeline with a small, inspectable dataset and a short run before scaling. Save regular samples using fixed prompts, and compare for identity, style leakage, and overfitting. More steps cannot repair inconsistent captions or low-quality source images.
If the run only fits after several unofficial workarounds, label it experimental. For repeatable work, prefer an upstream-documented model path that leaves memory headroom and can be resumed after interruption.
How this was researched
This guide uses the official OneTrainer and AI Toolkit repositories and their linked documentation as upstream evidence. Tool capabilities are documented facts; tier recommendations are editorial planning ranges, not benchmark results. Community low-memory recipes are intentionally not presented as official minimums.
Evidence confidence: High for principles; medium for workload-specific fit. “Documented” means an upstream source states the capability. Tier advice and scenario conclusions are editorial synthesis and should be validated against your exact model, settings, and runtime.
Read our complete methodology and corrections policy →Primary sources
- [1]
- [2]AI Toolkit · ostris / GitHub
Official configuration examples, supported training paths, and Flux hardware context.
- [3]Training Overview · Hugging Face Diffusers
Upstream explanation of mixed precision, gradient checkpointing, and memory-efficient training.