How much VRAM do you need to train a LoRA?

The three things that actually decide it

1. Base precision. The frozen transformer is the largest single term by a wide margin — on Flux it is 23.8GB at BF16, 11.9GB at FP8 and 7.1GB at NF4. Nothing else you change moves the total as much. This is the first dial, not the last.

2. Whether you cache. Trainers can encode every training image through the VAE and every caption through the text encoder before the loop starts, write both to disk, and unload the models. On Flux the T5-XXL encoder alone is 9.77GB at full precision. Caching is usually a checkbox, and on a small card it is the checkbox that matters.

3. Resolution and batch size. These set the activation memory. A 1024x1024 image becomes 4,096 latent tokens; 1280x1280 becomes 6,400. Gradient checkpointing keeps that term small in exchange for roughly 20–30% more compute per step, and there is very rarely a reason to turn it off.

What does not decide it: network rank. The adapter and its optimizer state are small next to a frozen multi-billion-parameter base. Rank changes the quality ceiling and the size of the file you end up with, not whether the run fits.

Where these numbers come from

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

Black Forest Labs' FLUX repositories require authentication. The architecture was taken from two independent ungated repos built on the same transformer, which agree exactly: 19 double-stream blocks, 38 single-stream blocks, 24 heads of 128.

Reconstructing FLUX.1's parameter count from that architecture (attention + MLP + adaLN modulation across 19 double and 38 single blocks at hidden 3072) gives 11.83B against the 11.90B in the model's safetensors index — within 1%. SDXL's config yields 70 transformer blocks and SD 1.5's yields 16, both matching the published architectures.

Activation memory is an estimate, not a measurement. It follows the same per-layer accounting as our LLM fine-tuning calculator (roughly 34 bytes per token per hidden unit, assuming flash attention or SDPA), applied per resolution level for UNet models. Treat it as a planning figure with headroom.

Adapter sizes assume FP16 files and cover the transformer or UNet only, not a text-encoder LoRA. All figures are decimal GB, the same convention as our other calculators. Architecture checked 2026-09-12.

Common questions

How much VRAM do I need to train a Flux LoRA?

At FP8 with latents cached, rank 16 and 1024x1024, roughly 15.6GB — so a 16GB card, with little to spare. NF4 drops it to about 10.8GB, which fits a 12GB card. Full BF16 needs about 27.5GB and therefore a 32GB card. The frozen transformer dominates every one of those figures.

Can I train a LoRA on 8GB of VRAM?

For SDXL, yes — about 6.9GB at BF16, rank 32 on attention, with latents cached and gradient checkpointing on. SD 1.5 is comfortable at around 2.9GB at 512x512. For Flux, no: the cheapest configuration here is about 10.8GB at NF4, so 12GB is the realistic floor.

What does caching latents actually do?

Before training starts, the trainer encodes every image through the VAE and every caption through the text encoder, then writes the results to disk. Both models can then be unloaded, because the training loop only ever touches the transformer. On Flux that frees close to 5GB, which is often the difference between fitting and not.

Does a higher network rank need much more VRAM?

Not much. The adapter, its gradients and its optimizer state are small next to the frozen base model. On Flux at FP8, rank 4 costs 15.1GB and rank 64 costs 17.2GB — a 16-fold increase in adapter capacity for about 2GB. Base precision moves the same total by 17GB. Rank decides the quality ceiling and the file size, not whether the run fits.

Why is training a LoRA sometimes cheaper than generating an image?

Because generation keeps the text encoder resident to process each new prompt, while training encodes every caption once and then frees it. A cached Flux LoRA run at FP8 needs about 15.6GB; generating at FP8 with everything resident needs about 19.8GB.

Do these numbers cover text-encoder training?

No. They cover a LoRA on the transformer or UNet, which is what most current recipes train. Adding a text-encoder LoRA increases the adapter term and requires the encoder to stay resident, which removes most of the caching saving.

Related tools

Worth checking before you start: FLUX.1 [dev] is non-commercial, so a LoRA trained on it inherits that restriction. The Apache-2.0 schnell variant does not — we cover the difference in Flux dev vs schnell and the general rule in open weight vs open source.

Which hardware gives you the headroom these runs need.

• Best Budget GPUs for Local LLMs16GB cards, used RTX 3090s and current street prices.Read the guide
• How Much RAM and VRAM Do You Need to Run Local LLMs?Model weights, KV cache and OS overhead, tier by tier.Read the guide
• RTX 5080 vs RTX 4090: Why 16GB VRAM Is the LimitWhy VRAM capacity beats raw speed for local inference.Read the guide