Running FLUX on 8GB of VRAM

FLUX.1 launched as a 12-billion-parameter text-to-image model with prompt quality that rivaled closed-source systems. That performance came with a cost: the full fp16 model and its text encoder can exceed the memory budget of an 8GB GPU. If you want to run FLUX locally on 8GB VRAM, fp8 quantization, GGUF offloading, and the right step budget are not optional tuning choices—they are the conditions that make the workflow complete at all.

This article covers the verified differences between FLUX.1-schnell and FLUX.1-dev, the fp8 and GGUF paths, what to offload, and the resolution and step count that users consistently report completing on 8GB VRAM.

TL;DR

• Use FLUX.1-schnell with 4 steps and Euler sampling for the only reliably fast local path on 8GB VRAM; FLUX.1-dev generally needs more steps and more memory headroom.
• Load the fp8 UNet or a GGUF-quantized model through the ComfyUI-GGUF custom node, and place ae.safetensors plus the expected CLIP files in their standard folders.
• Budget system memory and disk carefully: loading can consume roughly 32GB of RAM and needs around 25GB of free disk space, or the workflow may fail before the first step.

FLUX.1-schnell versus FLUX.1-dev

Black Forest Labs positions the two open-weight models differently. FLUX.1-schnell is distilled for speed and can generate images in 1 to 4 steps without an LCM sampler. FLUX.1-dev is also distilled, but it is trained for quality and non-commercial use, which usually means more inference steps and higher memory pressure during generation. The practical effect for 8GB VRAM owners is that schnell is the realistic local candidate; dev is better viewed as a higher-quality target for hardware with more headroom.

License also differs. FLUX.1-schnell is released under Apache 2.0, while FLUX.1-dev uses a non-commercial license. If you are evaluating models for a project that includes commercial use, schnell is the safer starting point.

ComfyUI expects UNet, VAE, and CLIP checkpoints in specific folders; confirm your install's folder layout before copying files.

Does FLUX run on 8GB VRAM without quantization?

Not in fp16. The standard FLUX checkpoint and its text encoder together can exceed the memory budget of an 8GB card before generation even starts. The community consistently uses two detours around that ceiling: fp8 quantized UNets and GGUF loaders that can spill inactive weights to system RAM or disk. Without one of those paths, the workflow usually halts with an out-of-memory failure or stalls during the loading phase.

For the wider picture of what each model needs, see VRAM requirements by model.

How fp8 quantization cuts the memory footprint

FP8 in FLUX context usually means float8_e4m3fn, an 8-bit storage format for the model weights. Because fp16 stores each weight in 16 bits and fp8 stores it in 8 bits, the weight memory footprint is roughly halved. The diffusers quantization documentation (bitsandbytes) notes that 8-bit quantization "multiplies outliers in fp16 with non-outliers in int8, converts the non-outlier values back to fp16, and then adds them together to return the weights in fp16," which preserves output behavior while reducing weight memory. For FLUX, the same principle applies to fp8 variants.

A widely used fp8 distribution is the Kijai flux-fp8 repository, which offers fp8 variants for both FLUX.1-schnell and FLUX.1-dev. When using fp8 in ComfyUI, users report placing the files in specific folders:

• flux1-schnell-fp8.safetensors in ComfyUI/models/unet
• ae.safetensors in ComfyUI/models/vae
• CLIP files such as clip_l.safetensors and t5xxl_fp16.safetensors in ComfyUI/models/clip

Note: the VAE filename changed to ae.safetensors in fp8 workflows, so older tutorials that reference older sd3-style names can mislead users during setup.

Can GGUF run FLUX on even lower VRAM?

GGUF stores model weights in a quantized form that can be loaded piecewise, which makes it attractive for GPUs with very limited VRAM. The ComfyUI-GGUF custom node provides a GGUF UNet loader and GGUF-aware CLIP loaders that fit into regular workflows, with pre-quantized FLUX.1-schnell and FLUX.1-dev releases already available.

Its README says transformer-style models such as FLUX seem less affected by quantization than older UNet convolutional architectures, so lower-bit GGUF quants can remain usable on cards with 8GB VRAM or less. In practice, a community workflow attachment shows successful generation on a 3050 notebook GPU with only 4GB VRAM, so GGUF is the path when fp8 is still too heavy.

Once it runs, the settings that matter are covered in FLUX LoRA training parameters for training and in our samplers and schedulers guide for generation.

What resolution and step budget actually complete on 8GB

On 8GB VRAM with the fp8 or GGUF paths, the only consistently reported fast local budget is FLUX.1-schnell plus 4 steps using Euler sampling. Community reports describe 1024x768 output completing in about 2 minutes at that setting. In return, loading the model is slow: the same community reports describe total generation times around 20 minutes when model loading is included.

If you are comparing that to cloud or higher-end local hardware, the bottleneck is not the sampler—it is the weight movement between CPU RAM and GPU VRAM. The step budget above is therefore realistic rather than aspirational; dev-style quality at 20–50 steps is usually impractical inside an 8GB VRAM envelope.

What should you offload to CPU?

The practical offloading route is enable_model_cpu_offload(), which moves model weights to system RAM while they are not actively needed on the GPU. That keeps peak VRAM lower, but it adds latency as weights move back and forth during generation. The trade-off is unavoidable on 8GB cards: offloading makes the workflow complete, but it also extends loading time.

Users report that the loading phase itself is memory-hungry. Roughly 32GB of system RAM can be consumed while the model is being prepared, and once installation files are present, around 25GB of free disk space is needed to avoid loading failures. If your SSD or HDD is near capacity, that is the first bottleneck to clear before debugging GPU settings.

Common errors and fixes

FAQ

How much VRAM does FLUX.1-schnell need for 4-step inference? The model can technically run on 8GB VRAM when paired with fp8 or GGUF quantization and CPU offloading, but performance depends heavily on whether system RAM and disk are also sufficient. Full fp16 schnell usually exceeds an 8GB card, so quantization is the practical path.

Can FLUX run on an 8GB GPU at all? Yes. Community workflows demonstrate FLUX.1-schnell running on 8GB cards using fp8 or GGUF quantization, with ComfyUI-GGUF also enabling runs on hardware with as little as 4GB VRAM. Success depends on file placement, offloading behavior, and available system RAM.

What is the difference between FLUX.1-schnell fp8 and GGUF? fp8 reduces weight precision in a standard safetensors form factor, while GGUF uses a quantized container with built-in support for low-VRAM loading and partial offloading. fp8 fits ordinary ComfyUI loaders; GGUF requires the ComfyUI-GGUF custom node and gives more aggressive VRAM savings.

Why does FLUX take so long to load? On 8GB VRAM systems, that process can consume roughly 32GB of system RAM and take long enough that total generation time is dominated by startup, not sampling.

What resolution can FLUX generate on 8GB VRAM? Community reports cite 1024x768 with Euler sampling at 4 steps as a realistic budget. Higher resolutions increase memory and compute demand, so they are more likely to fail or require even more aggressive quantization or offloading.

Sources

• FLUX.1-schnell model card
• FLUX.1-dev model card
• FLUX usage docs
• Kijai flux-fp8 repository
• ComfyUI-GGUF README
• Black Forest Labs announcement
• diffusers quantization docs (bitsandbytes)
• Fast tutorial to run FLUX on 8GB VRAM
• Comfyui workflow for FLUX schnell fp8 8GB
• Low VRAM Flux Comfy Workflow