LoRA Training VRAM Requirements: Flux, SDXL and SD 3.5 (2026)

The short answer

LoRA training memory is decided by three things, and network rank is not one of them. What matters is the precision you hold the frozen base model at, whether you cache latents and text embeddings before training starts, and the training resolution.

Rank 16 on attention and MLP for the DiT models, rank 32 on attention for SDXL and SD 1.5, 8-bit AdamW, gradient checkpointing on, latents cached. Change any of it in our LoRA training VRAM calculator, which is where these figures come from.

Why this is a different calculation

If you have read about fine-tuning language models, most of what you learned does not transfer. Two things are structurally different.

You do not choose a sequence length. With a language model you decide how many tokens each training example is. With an image model the resolution decides it for you: the VAE downsamples by 8, the transformer packs 2×2 latent patches into one token, so a 1024×1024 image becomes exactly 4,096 tokens. Train at 1280×1280 and it becomes 6,400. This is the only lever you have on that term, and it is coupled to the quality of what you are training.

Most of the pipeline does not need to be in memory. Generating an image requires the text encoder resident, because every new prompt has to be encoded. Training does not: every caption in your dataset can be encoded once, before the loop starts, and written to disk. Same for the VAE and your training images. After that the training loop only ever touches the transformer.

That second point is why a Flux LoRA trains on hardware that struggles to generate with Flux. It is also the single biggest memory saving available to you, and in most trainers it is a checkbox. For editing an existing image instead of training a style, see our Stable Diffusion inpainting guide.

The caching checkbox is worth about 5GB

Flux uses a T5-XXL text encoder that weighs 9.77GB at full precision. During training it has exactly one job — turning your captions into embeddings — and it does that job once.

With caching on, a Flux LoRA at FP8 and 1024×1024 needs about 15.6GB. With it off, the same run needs about 20.6GB, because the encoder and VAE sit in memory doing nothing for the entire run. That is the difference between a 16GB card and a 24GB one.

In kohya-based trainers this is cache_latents and cache_text_encoder_outputs. In ai-toolkit and SimpleTuner it is on by default or close to it. The cost is a few minutes of preprocessing and some disk space, plus one real constraint: you cannot use random crops or caption shuffling on cached runs, because the cache assumes each image and caption is fixed.

Rank barely matters. Everyone thinks it does.

This is the most persistent misconception in LoRA training threads. The adapter, its gradients and its optimizer state are small next to a frozen multi-billion-parameter base model.

Going from rank 4 to rank 64 — sixteen times the adapter capacity — costs about 2GB. Dropping the base from BF16 to FP8 saves nearly 12GB. If a run will not fit, changing precision is the move; dropping rank is close to pointless and costs you quality ceiling.

What rank genuinely decides is the size of the file you end up with, and how much the adapter can learn. For a character or a style, ranks of 8 to 32 are usually plenty. High ranks mostly buy overfitting. That file is an add-on rather than a model in its own right: how checkpoints, LoRAs and VAEs relate covers why a few hundred megabytes can reshape a seven-gigabyte base model.

What fits on your card

6GB

SD 1.5 at 512×512, around 2.9GB. Comfortable. This is why SD 1.5 LoRA training was so widespread — almost any GPU could do it. Once a LoRA exists, using it well is a separate skill: see matching the base model, weights and stacking.

8GB

SDXL at 1024×1024 comes to about 6.9GB at BF16 with caching and checkpointing on. It fits, with little headroom — close anything else using the GPU. Flux does not fit at any precision here.

12GB

The entry point for Flux, at NF4 and about 10.8GB. Quality at 4-bit is visibly below FP8, so treat this as the tier where Flux becomes possible rather than pleasant. SD 3.5 Large is comfortable at FP8.

16GB

Flux at FP8, about 15.6GB. This is the tier most Flux LoRA guides implicitly assume, and it is tight — 15.6 of 16 leaves nothing for a display. A headless card or a second GPU driving the monitor genuinely helps here.

24GB and above

Flux at FP8 with real headroom, higher resolutions, or larger batch sizes. Full BF16 Flux needs about 27.5GB, so a 32GB card. Qwen-Image at 20.4B parameters is heavier still — about 24.6GB even at FP8.

Our best GPU for AI guide covers what each tier costs and what else it unlocks.

Gradient checkpointing: leave it on

Checkpointing discards most intermediate activations during the forward pass and recomputes them during the backward pass. You pay roughly 20–30% more compute per step and save a large multiple of that in memory.

For diffusion LoRAs the activation term is smaller than it is for long-context language model training, so the saving is less dramatic — but it is free headroom, and the compute cost is modest against a run that takes hours anyway. There is very rarely a reason to turn it off.

A licence warning before you train

A LoRA inherits the licence of the base model it was trained on. FLUX.1 [dev] is non-commercial, and that restriction passes to anything you train on it — including LoRAs you distribute, and images you produce for a client. The Apache-2.0 schnell variant carries no such restriction, and the two need essentially identical VRAM, so the choice is about licence and step count rather than hardware. We cover the difference in Flux dev vs schnell.

SDXL is OpenRAIL++ and SD 3.5 ships under Stability’s community licence, which has its own conditions at scale. Our licence checker covers what each one permits.

How these numbers were calculated

Block counts and hidden sizes come from each model’s transformer/config.json or unet/config.json on Hugging Face. Component weights — transformer, text encoder, VAE — are read from the safetensors files, and are the same figures our image generation calculator uses.

Black Forest Labs’ FLUX repositories are gated, so the architecture was taken from two independent ungated repositories built on the same transformer, which agree exactly: 19 double-stream blocks, 38 single-stream blocks, 24 attention heads of 128. Reconstructing FLUX.1’s parameter count from that architecture gives 11.83B against the 11.90B in its safetensors index — within 1%. SDXL’s config yields 70 transformer blocks and SD 1.5’s yields 16, both matching the published architectures.

Adapter parameter counts are computed from those dimensions rather than estimated. Activation memory is the one approximation, following the standard per-layer accounting of roughly 34 bytes per token per hidden unit with flash attention assumed, and summed across resolution levels for the UNet models. Treat it as a planning figure with headroom.

Figures cover a LoRA on the transformer or UNet only. Adding a text-encoder LoRA increases the adapter term and forces the encoder to stay resident, which removes most of the caching saving.

FAQ

Can I train a Flux LoRA on 8GB?

No. The cheapest configuration in our calculator is about 10.8GB, at NF4 with caching and checkpointing. 12GB is the realistic floor, and 16GB is where it becomes workable.

Why did my run OOM at the same settings that worked yesterday?

Check whether caching is still on, and whether your dataset picked up higher-resolution images — bucketing will train them at their own resolution, and a few 1536px images in the set will push the peak well above what your 1024px images needed.

Is FP8 or NF4 worth the quality loss?

FP8 is widely used for Flux LoRA training and the quality cost is small. NF4 is more aggressive and shows. If NF4 is the only way a run fits, it is better than not training — but if you can reach FP8 by caching or lowering resolution instead, do that first. Before you start a run, check what the base model lets you do with the result — a LoRA trained on a [dev] checkpoint is a Derivative and stays non-commercial, as our guide to Flux LoRA licensing sets out.

Does batch size matter much?

It scales the activation term linearly, which for diffusion LoRAs is a modest share of the total. Going from batch 1 to batch 4 costs less than you might expect. Gradient accumulation gives you the same effective batch size with the memory of batch 1.

What about training on a Mac?

Possible but not the well-trodden path. The mainstream trainers assume CUDA, and the quantization libraries that make FP8 and NF4 work are CUDA-first. Apple Silicon has the memory capacity for it — the tooling is the constraint.

Sources

• Model architectures: transformer/config.json and unet/config.json on Hugging Face
• Component weight sizes: safetensors files in each model’s repository
• LoRA: Hu et al., LoRA: Low-Rank Adaptation of Large Language Models
• Activation memory: per-layer accounting from the Megatron-LM activation-recomputation work
• Optimizer state: bitsandbytes documentation for 8-bit optimizers

Note added 26 September 2026. Every figure above is for FLUX.1, which is what “Flux” meant when this guide was written, and none of them were recomputed. Black Forest Labs has since released FLUX.2 [dev] (25 November 2025) at 32B parameters and the FLUX.2 [klein] family (15 January 2026), where klein 4B is 3.88B and Apache-2.0 — so both the memory cost and the licence position of a FLUX.2 run differ from FLUX.1’s. Which base model you may legally train on is covered in our Flux LoRA licence guide.

Updated September 12, 2026. FLUX.2 roster note added 26 September 2026; the VRAM figures are unchanged.