Train LoRA adapters for SDXL and FLUX on 8 GB of VRAM, or on an Apple Silicon Mac.
Most LoRA guides assume a 24 GB card. Below that, the usual experience is an out of memory error forty minutes into a run, followed by an evening of guessing which setting to change. slim-lora replaces the guessing with a memory budget you can read before starting, reference configurations that fit the hardware they claim to fit, and dataset checks that catch the problems which quietly ruin an adapter.
Tells you whether a run fits, before it starts. slim-lora plan adds up model
weights, adapter parameters, gradients, optimizer state and activations, compares
that against your card, and names the setting to change if it does not fit.
$ slim-lora plan configs/sdxl/8gb-character.toml
vram budget for character-v1
base model 2.51 GB 2.6B parameters at fp8
text encoder - outputs cached to disk, encoder unloaded before training
vae - latents cached to disk, vae unloaded before training
adapter weights 0.20 GB 101M trainable parameters (lora, rank 16)
gradients 0.20 GB one gradient per trainable parameter
optimizer state 0.20 GB adamw8bit, 2 bytes per parameter
activations 0.88 GB 768 px, batch 1, gradient checkpointing on (gradient accumulation does not add memory)
runtime overhead 0.41 GB cuda context and allocator
fragmentation 0.22 GB 5 percent allocator headroom
total 4.61 GB of 7.40 GB usable (62 percent)
verdict fits
Checks the dataset before you spend the GPU time on it. slim-lora inspect
reports resolution outliers, near duplicates found by perceptual hash, bucket
distribution, and the caption mistakes that fuse unrelated concepts into your
trigger word.
Prepares images into aspect ratio buckets instead of squashing everything square, and lays the folders out the way the trainer expects them.
Runs on two backends. On NVIDIA it drives sd-scripts; on Apple Silicon it trains the adapter in process with MLX.
Not on PyPI yet; install from the repository:
git clone https://github.com/AlexDesign420/slim-lora
cd slim-lora
pip install -e . # planning, dataset tooling, reports
pip install -e ".[mlx]" # plus the Apple Silicon backendThe CUDA backend drives an existing sd-scripts checkout:
git clone https://github.com/kohya-ss/sd-scripts
export SLIM_LORA_SD_SCRIPTS=$PWD/sd-scriptsslim-lora plan configs/sdxl/8gb-character.toml # will it fit
slim-lora prepare configs/sdxl/8gb-character.toml --source ~/photos
slim-lora caption configs/sdxl/8gb-character.toml # normalize, trigger word first
slim-lora inspect configs/sdxl/8gb-character.toml # is the data good enough
slim-lora train configs/sdxl/8gb-character.toml
slim-lora report output # contact sheet of the samplesEvery subcommand except report takes one configuration file; report takes the
output directory. examples/walkthrough.md runs through a
complete character LoRA from twenty photographs, including what to look for in the
results.
Every one of these is checked against the estimator in CI and by the test suite
(tests/test_budget.py), so a configuration that stops fitting its own hardware
section fails the build rather than your evening.
| Configuration | Model | Weights | Adapter | Resolution | Estimated peak | Verdict |
|---|---|---|---|---|---|---|
configs/sdxl/8gb-character.toml |
SDXL | fp8 | LoRA rank 16 | 768 | 4.6 GB | fits |
configs/sdxl/8gb-concept.toml |
SDXL | fp8 | LoRA rank 8 | 768 | 5.2 GB | fits |
configs/sdxl/8gb-style.toml |
SDXL | fp8 | LoCon rank 32 | 896 | 6.1 GB | fits |
configs/flux/8gb-lokr.toml |
FLUX.1 | fp8 | LoKr rank 16 | 512 | 5.7 GB | fits |
configs/mlx/sdxl-apple-silicon.toml |
SDXL | bf16 | LoRA rank 16 | 768 | 7.7 GB | fits |
The 8 GB presets all load the base model in fp8. That is not a stylistic choice: SDXL in fp16 occupies 5.1 GB of weights alone, which leaves roughly 2 GB for everything else and caps the usable training resolution near 640 px. The reasoning, and what fp8 costs in quality, is in docs/backends.md.
The estimator is built from published parameter counts and six calibration
constants, all listed with their sources and error margins in
docs/vram-budget.md. It is deliberately pessimistic:
reporting fits for a run that then dies is a worse failure than reporting
tight for one that succeeds. Expect it to be within roughly 15 percent of the
real peak, and to be least accurate for activation memory, which depends on the
attention implementation your build of PyTorch selected.
If you run a configuration and measure the peak, the Measured run issue
template exists for exactly that. Reported measurements are what correct the
constants.
- No CUDA run has been verified by the author. slim-lora was developed on an Apple Silicon machine. The CUDA backend's argument generation is covered by tests against the sd-scripts command line, and the reference configurations are checked against the estimator, but no full NVIDIA training run has been executed here. Treat the CUDA numbers as derived rather than measured.
- The MLX backend does not ship a diffusion model loader. It provides the
adapter, the injection pass and the training loop, and it takes the model and
loss function from you. For SDXL weights on MLX, see
mlx-examples.
There is no command line
trainon MLX for this reason; the Python API is the entry point. - FLUX on 8 GB depends on block swapping. The transformer is 11.9B parameters, which does not fit at any precision. The preset streams 40 of 57 blocks from system RAM, which works and is slow. Expect several times the step time of SDXL.
- fp8 base weights need Ada or newer for the fast path. On Ampere the flag works but the speed advantage does not.
- docs/vram-budget.md — how the estimate is derived, constant by constant
- docs/dataset-guide.md — image selection, resolution, buckets, captions
- docs/backends.md — CUDA and MLX: what each one can do
- docs/troubleshooting.md — real error messages and their causes
MIT