Best Local Image Generation Models by VRAM (2026)

Open image models sized for real GPUs, with the text encoder counted in and the licence checked. FLUX 3, Z-Image, Qwen-Image 2.1 and SD3.5 compared.

Updated October 27, 2026

What changed (2026-10-27): Two generations landed since this page was last checked and both are now covered. Black Forest Labs released FLUX 3 image klein (5.55B parameters, October 2026) and Alibaba released Qwen-Image-2.1 and Qwen-Image-2.1-Turbo (7.12B parameters, September and October 2026). Qwen-Image 2.1 moved off Apache 2.0 onto a Qwen Research licence that is non-commercial, which changes who can use it for paid work. Two claims on this page were wrong and have been corrected. The line saying every FLUX repository here is access-gated was false: FLUX.2-klein-4B is ungated. The line saying SDXL has the largest fine-tune ecosystem of any model on this page by a wide margin was also false, and the corrected counts are in the recommendation section. Re-checked against the Hugging Face API and the live GGUF trees and left unchanged: every parameter count, every licence tag, the gating state of every repository, and every GGUF blob size quoted below.

Image generation is the one local AI workload where the number on the model card is the least useful number on the page. A diffusion model is a pipeline, not a file, and the part people size their card against is often not the part that fills it.

This guide gives the real totals, and it puts licensing first, because the most capable open image models are the ones you are least allowed to use.

The mistake people bring from running LLMs

A language model is one file. An image model is three: the diffusion transformer, one or more text encoders, and a VAE decoder. The text encoder is the one that ruins the budget.

FLUX.1-dev at Q4_0 is 6.79GB, which sounds like an easy fit on a 12GB card. Then it needs T5-XXL, which ComfyUI ships at 9.79GB in fp16 or 4.89GB in fp8, plus CLIP-L at 0.25GB. The honest total at fp16 is about 16.8GB, not 6.79GB.

ComponentSize
T5-XXL text encoder, fp169.79 GB
T5-XXL text encoder, fp84.89 GB
T5-XXL text encoder, Q4_K_M GGUF2.90 GB
CLIP-L text encoder0.25 GB
Qwen3-VL-8B text encoder, bf16 (Qwen-Image 2.1)17.53 GB
Qwen3-VL-8B text encoder, int8 (Qwen-Image 2.1)9.35 GB
Qwen3-VL-8B text encoder, w4a8 (Qwen-Image 2.1)6.31 GB
Qwen3-VL-4B text encoder, bf16 (FLUX 3)8.88 GB
Qwen3-VL-4B text encoder, int8 (FLUX 3)4.86 GB
Flux2 VAE (FLUX 3)0.34 GB
Qwen-Image 2.1 VAE0.68 GB

The encoder quantises too, and quantising it is usually the highest-value move available: going from fp16 to a Q4_K_M GGUF saves 6.9GB, which is more than most people save by downgrading the diffusion model itself.

The two newest models make this worse rather than better, because they replaced T5-XXL with a Qwen3-VL encoder. Qwen-Image 2.1 needs the 8B one at 17.53GB in bf16, and FLUX 3 needs the 4B one at 8.88GB. The ComfyUI repackages ship int8 and w4a8 builds of both, and Qwen’s own GGUF builds of Qwen3-VL-4B-Instruct and Qwen3-VL-8B-Instruct list Q4_K_M files at 2.50GB and 5.03GB; check that your tool accepts a GGUF encoder before relying on them.

Two mitigations matter as much as the numbers. Most tools can run the text encoder, produce the conditioning, then unload it before the diffusion steps begin, so peak memory is lower than the sum. And CPU offload for the encoder is cheap here in a way it never is for an LLM, because the encoder runs once per prompt rather than once per token.

Licences first, because this is where the traps are

More than any other category on this site, the strongest open image models are not open in the sense people assume. Every Black Forest Labs FLUX repository here except FLUX.2-klein-4B is also access-gated, and the two most recent additions come with the terms you have to read most carefully.

ModelParamsLicenceCommercial use
Z-Image-Turbo6.15BApache 2.0Yes
FLUX.2-klein-4B3.88BApache 2.0Yes
FLUX.1-schnell11.89BApache 2.0Yes
Qwen-Image20.43BApache 2.0Yes, previous generation
SDXL base 1.02.57BOpenRAIL++Yes, with use restrictions
SD 3.5 Large8.15BStability AI CommunityConditional
SD 3.5 Medium2.47BStability AI CommunityConditional
FLUX 3 image klein5.55BFLUX KommunityConditional, under $5M revenue
Krea-2-Turbo12.82BKrea 2 CommunityConditional
Qwen-Image-2.17.12BQwen ResearchNo
Qwen-Image-2.1-Turbo7.12BQwen ResearchNo
FLUX.1-dev11.90BFLUX.1-dev non-commercialNo
FLUX.2-klein-9B9.08BFLUX non-commercialNo
FLUX.2-dev32.22BFLUX non-commercialNo
Ideogram 49.28BIdeogram 4 non-commercialNo

The pattern is worth stating plainly. FLUX.1-dev, FLUX.2-klein-9B and FLUX.2-dev are non-commercial, and only FLUX.1-schnell and FLUX.2-klein-4B are plainly permissive. FLUX 3 image klein sits in between: its Kommunity licence allows commercial output generation only by users whose gross annualised revenue, including affiliates, is under US$5 million, and only alongside content filtering or pre-publication review of the output plus an AI disclosure. Qwen-Image 2.1 is the sharpest change on this page. The 1.0 release is Apache 2.0, and the 2.1 release is under the Qwen Research licence, which grants non-commercial use only and requires a separate licence from Qwen for anything commercial.

If the output is going anywhere near a client deliverable, a product, or a page with ads on it, your realistic shortlist is Z-Image-Turbo, FLUX.2-klein-4B, FLUX.1-schnell, Qwen-Image and SDXL. FLUX 3 image klein joins that list if you are under the $5 million revenue line, because its commercial-output rights depend on your revenue.

By VRAM tier

Sizes below are the diffusion model only, from published GGUF blobs. Add the encoder from the first table.

8GB. Z-Image-Turbo at Q4_K_M is 5.02GB, or 3.64GB at Q2_K, and it is Apache 2.0. Pair it with a Q4_K_M T5 encoder and you are at roughly 7.9GB, which fits with the encoder unloaded before sampling. FLUX 3 image klein also reaches this tier at its smallest build: 2.62GB for the diffusion model at UD-Q2_K_XL, plus 4.86GB for the Qwen3-VL-4B encoder in int8 and 0.34GB for the VAE, about 7.8GB in total, and the encoder can be unloaded before sampling. SDXL remains the other genuine 8GB option at 2.57B parameters.

12GB. Z-Image-Turbo at Q8_0 is 7.22GB, or FLUX.2-klein-4B at 3.88B parameters if you want the newer architecture with a commercial licence. SD 3.5 Large at Q4_0 is 4.77GB and fits comfortably, subject to its community licence. FLUX 3 image klein at its recommended UD-Q4_K_XL build is 3.93GB, and with the int8 encoder and the VAE it lands at about 9.1GB. Qwen-Image-2.1-Turbo at Q4_K_M is 4.20GB, and with the w4a8 Qwen3-VL-8B encoder and its 0.68GB VAE it comes to about 11.2GB. FLUX 3 is gated, and both new models carry weaker terms than the Apache 2.0 options above.

16GB. FLUX.1-dev at Q4_0 (6.79GB) plus an fp8 encoder is about 11.9GB, which is the first tier where the full FLUX pipeline is relaxed rather than tight. Non-commercial only. FLUX.1-schnell is the same size class and Apache 2.0, at fewer sampling steps and lower detail. Qwen-Image-2.1-Turbo gets more comfortable here, because the Qwen3-VL-8B encoder can stay in int8 at 9.35GB and the total comes to about 14.2GB.

24GB. Z-Image-Turbo at BF16 is 12.31GB and SD 3.5 Large at F16 is 16.29GB, so this is where you stop quantising the diffusion model at all. FLUX 3 image klein at BF16 is 11.10GB, and with the bf16 Qwen3-VL-4B encoder and the VAE it reaches about 20.3GB. Qwen-Image remains practical at Q2_K to Q3_K_M, 7.06 to 9.68GB, though at 20.43B parameters its higher quants stay out of reach.

32GB and up. Qwen-Image at Q4 and above, or FLUX.1-dev at F16 (23.80GB) with an fp16 encoder. Qwen-Image at BF16 is 40.87GB and does not fit a consumer card, but Qwen-Image 2.1 at F16 is 14.23GB and does, so the newer generation is the one to size for at this tier.

What to actually run

If the work is commercial: Z-Image-Turbo. It is Apache 2.0, ungated, 6.15B parameters, and its GGUF ladder runs from 3.64GB to 12.31GB, so it scales across every tier on this page. Being a turbo model it targets few sampling steps, which makes it fast on modest hardware.

If you want the newest generation: FLUX 3 image klein. It is a 5.55B parameter distilled checkpoint added in October 2026, its GGUF ladder runs from 2.62GB to 11.10GB, and it is gated. The Kommunity licence is the catch: commercial use is tied to staying under $5 million in revenue, so it suits an individual or a small studio and not an enterprise.

If it is personal work and you want the FLUX line’s flagship: FLUX.1-dev, accepting the non-commercial licence and the gated download. It is the checkpoint the FLUX.1 fine-tune ecosystem is built on, and at 11.90B parameters it is the heaviest of the FLUX.1 text-to-image weights.

If you want the newest Qwen image model: Qwen-Image-2.1-Turbo. It is 7.12B parameters, handles text-to-image and image editing in one model, has an 8-step checkpoint, and its GGUF ladder runs from 2.47GB to 14.23GB. The licence is the catch: Qwen Research, so non-commercial unless you take a separate licence from Qwen.

If you want a long fine-tune ecosystem: SDXL. Older and lower fidelity out of the box, and the ecosystem is no longer the largest here. Counting every model on Hugging Face that declares a given base model, using the Hugging Face API’s filter=base_model: parameter, returned 11,049 for stabilityai/stable-diffusion-xl-base-1.0 and 43,425 for black-forest-labs/FLUX.1-dev on 27 October 2026; most of the FLUX.1-dev total is adapters (LoRAs), while SDXL still lists more full fine-tunes in its Hugging Face model tree (1,234 against 620 on 1 November 2026). These counts cover Hugging Face only.

One thing this guide does not do is rank these models by output quality. No primary benchmark was verified for this update, and image quality comparisons are unusually subjective and prompt-dependent. The ordering above is by what fits, what you are licensed to do, and what the architecture is built for. Treat any confident quality ranking you read elsewhere, including a leaderboard, as weaker evidence than generating twenty images from your own prompts.

For the rest of the local stack, the VRAM index covers chat, coding, vision and the rest, and which quantization to use explains why none of the Q4 builds above are actually four bits per weight.