FLUX LoRA Training VRAM Guide
FLUX LoRA training can fit on very different GPUs because VRAM is only one part of the memory plan. The exact footprint changes with the FLUX variant, base precision, quantizer, adapter targets, optimizer state, image resolution, batch size, cached embeddings, gradient checkpointing, attention backend, and validation settings. A card that completes one low-bit run may fail on an unquantized preset before the first training step.
This guide is a memory planning and troubleshooting reference, not another general FLUX requirements page. It explains how to interpret published measurements, estimate pressure before a run, trade GPU memory for system RAM or speed, and prove that a configuration is stable with a smoke test. The goal is to choose a documented memory profile and measure it on your machine. It is not to promise that every GPU with the same advertised capacity will behave identically.
Quick Answer
Start with the current documentation for your exact trainer and FLUX model. SimpleTuner currently reports a little above 30 GB of VRAM for an unquantized rank 16 FLUX.1 LoRA example, a little above 18 GB with int8, above 13 GB with int4, and above 9 GB with NF4 or int2 under named settings. These are measured configurations, not universal tiers.
For a constrained GPU, use a supported low-bit base model, gradient checkpointing, batch size 1, conservative resolution, a memory-aware optimizer, and cached text embeddings where the trainer supports them. Expect slower training, substantial system RAM use, and possible startup peaks. Measure allocated and reserved memory during model loading, cache creation, the first backward pass, checkpoint saving, and validation.
Why Capacity Labels Are Not Guarantees
Two 12 GB cards can have different results because architecture, driver, CUDA build, attention kernels, and other processes affect usable memory. Trainers may also reserve memory differently. The largest peak is not always during the steady training loop.
A run has several memory phases:
- Loading the transformer, VAE, and text encoders.
- Quantizing components, sometimes on the GPU and sometimes on the CPU.
- Encoding images, captions, or validation prompts.
- Creating gradients and optimizer state on the first backward pass.
- Saving an adapter and optimizer checkpoint.
- Loading components needed for validation images.
A preset that looks safe after ten steps can still fail when validation begins. Track the whole run lifecycle.
Read Published FLUX Measurements Correctly
SimpleTuner's FLUX quickstart provides unusually useful measured footprints, but each number belongs to the documented combination of model flavor, rank, precision, quantization, optimizer, resolution, and software version. Use those figures as comparison points.
The published low end around 9 GB uses aggressive quantization and a tightly defined setup. It does not mean every FLUX model, operating system, optimizer, or 1024 pixel dataset fits in 10 GB. The same guide notes that higher resolution needs more room and identifies roughly 50 GB of system memory for startup quantization in its described path.
A practical interpretation is:
- Above 30 GB gives room for the documented unquantized rank 16 example, but other settings can still exceed it.
- Around 18 GB is associated with a documented int8 path.
- Around 13 GB is associated with a documented int4 path.
- Around 9 GB is associated with specific NF4 or int2 paths and tighter constraints.
Do not turn these examples into a GPU shopping table without retaining their conditions.
The Main VRAM Variables
Base model precision and quantization
The frozen FLUX transformer is the largest resident component. Quantizing it usually creates the biggest memory reduction. NF4, int4, int8, FP8, and BF16 are not interchangeable labels. Hardware support, training quality, optimizer compatibility, and export behavior differ.
Follow one trainer's supported path. Do not combine flags from SimpleTuner, AI Toolkit, sd-scripts, and Diffusers as though they describe one implementation.
Resolution and aspect ratio buckets
Activation memory rises with pixel count. A 1024 by 1024 bucket contains four times as many pixels as 512 by 512. Mixed aspect ratios can also create unexpected large buckets if dataset limits are loose.
Inspect the actual bucket list. If a low-memory smoke test uses 512 class images, its success does not prove that the planned 1024 class run will fit.
Batch size and accumulation
Physical batch size directly affects activation memory. Gradient accumulation can approximate a larger effective batch without holding all examples at once, although it changes speed and may interact with optimization.
Begin with physical batch size 1 when fit is uncertain. Increase only after recording peak use through validation.
Adapter rank and targets
Higher rank adds trainable parameters, gradients, and optimizer state. Targeting feed-forward layers in addition to attention can add more. The base model remains the dominant weight load in many LoRA runs, but a wide adapter and broad targets still matter on a tight card.
Start with the trainer's default target set and a modest rank. Increase capacity because comparison samples show under-capacity, not because spare VRAM exists.
Optimizer state
Adam-style optimizers keep additional state for trainable parameters. Eight-bit or paged variants can lower pressure, but they add dependencies and may change performance. Use an optimizer explicitly supported by the selected trainer and platform.
Validation
Validation can reload a VAE or text encoder, create larger latents, or use multiple prompts. Keep the first test prompt small and the validation batch conservative. Then restore the full evaluation grid after the training loop proves stable.
Memory Controls and Their Costs
Gradient checkpointing recomputes activations instead of retaining all of them. It commonly lowers memory use and slows each step.
Base-model quantization cuts frozen-weight memory. It can increase startup system RAM, impose GPU capability requirements, and narrow compatible optimizers or attention backends.
Cached latents avoid repeated VAE encoding. They consume disk or RAM and restrict image augmentations that would need fresh encoding.
Cached text embeddings avoid repeatedly running large text encoders. Caption changes, shuffling, or text-encoder training may become unavailable after caching.
CPU offload or block swapping moves components away from GPU memory. This can make a run fit at the cost of system RAM, transfer overhead, and lower throughput.
Memory-efficient attention can reduce activation pressure, but supported backends vary by GPU, operating system, precision, and model implementation.
Use one control at a time when diagnosing. If five options change together, you will not know which one fixed fit or caused instability.
System RAM Is Part of the Budget
Offloading and CPU-side quantization move pressure, not eliminate it. SimpleTuner documents about 50 GB of system RAM for startup quantization in one FLUX.1 workflow. Leave additional room for the operating system, dataset workers, caches, and checkpoint serialization.
Watch committed memory as well as physical RAM on Windows. Heavy paging may prevent a crash while making training impractically slow. On Linux, an out-of-memory killer can terminate a process even when GPU monitoring looked normal.
Fast SSD space also matters. Keep enough free storage for base components, latent and text caches, multiple checkpoints, logs, and temporary save files.
Build a Reproducible VRAM Test
1. Record the complete configuration
Save the exact model ID and revision, trainer commit, GPU, driver, operating system, precision, quantizer, optimizer, rank, targets, resolution, buckets, batch, accumulation, caches, checkpointing, and offload choices.
2. Close competing GPU processes
Stop inference applications, browsers using hardware acceleration, and abandoned Python jobs. Record free memory immediately before launch.
3. Use a representative mini dataset
Include several aspect ratios and real captions. A single square image does not exercise bucketing or data loading realistically.
4. Complete every memory phase
Let the run load, quantize, cache, perform several backward passes, save a checkpoint, and render at least one validation image. Record the peak at each phase.
5. Leave operating margin
A run that leaves only a few megabytes is fragile. Dataset buckets, validation prompts, allocator fragmentation, or a minor library update can exceed that result.
6. Scale one dimension at a time
Increase resolution, rank, target coverage, or batch separately. Keep a small table in the run log with peak VRAM, system RAM, seconds per step, and validation success.
Diagnosing Out-of-Memory Failures
Failure during model load: confirm that quantization is enabled for the intended component and that the selected precision is supported.
Failure during cache creation: reduce cache concurrency, verify system RAM, and check the largest image bucket.
Failure on the first backward pass: lower physical batch size, enable gradient checkpointing, reduce rank or targets, or choose a documented lower-memory optimizer.
Failure only during validation: lower validation dimensions or batch, reduce simultaneous prompts, and inspect which components are reloaded.
Failure after several checkpoints: inspect fragmentation, retained sample tensors, disk pressure, and whether the trainer version has a known leak.
The dedicated out-of-memory troubleshooting page covers recovery steps. This page should remain your planning record.
Choosing Between Local and Cloud GPUs
A low-memory local run may be economical when iteration speed is acceptable and private data must remain on your machine. A rented 24 GB or larger GPU can be cheaper when offload turns each experiment into a long job.
Compare total experiment cost, not hourly price. Include upload time, persistent storage, failed setup attempts, checkpoint downloads, and the number of controlled comparisons you need.
Bottom Line
FLUX VRAM planning is configuration matching. Pick an authoritative measured example, preserve every condition attached to it, and run a lifecycle smoke test on your hardware. Quantization, checkpointing, caching, and offload can make constrained cards useful, but each saving has a cost in RAM, disk, speed, flexibility, or compatibility.
Keep the final memory profile beside the dataset and model revision. That record is more valuable than a claim that a certain GPU is enough.