FLUX Explained: Black Forest Labs’ Image-Generation Model (2026)

FLUX Explained: Black Forest Labs’ Image-Generation Model (2026)

FLUX Image Generation Model: Architecture, Benchmarks and Deployment in 2026

Most teams that adopted open-weight image models in 2024 did it for one reason: they could run the weights themselves, fine-tune on their own data, and never ship a customer photo to someone else’s API. The FLUX image generation model became the default choice for that crowd almost overnight, and in 2026 it sits at an awkward, interesting crossroads — the open tiers are bigger and smarter than ever, yet the flagship quality now lives behind an API, and the licenses have real commercial teeth.

This matters now because the second-generation family, FLUX.2, has reshuffled every assumption from the first release. The text encoder changed. The parameter count nearly tripled. The tier structure grew a fourth member. And the benchmark story is no longer “FLUX beats Stable Diffusion” — it is a crowded arena where GPT Image 2 and Google’s Nano Banana sit ahead of it.

What this covers: the lineage from Latent Diffusion to FLUX.2, the rectified-flow transformer architecture, the training recipe, real benchmark numbers with their caveats, every weight tier and its exact license, the VRAM and cost to self-host, honest failure modes, and how FLUX compares to its 2026 rivals.

What is the FLUX image generation model?

The FLUX image generation model is a family of text-to-image and image-editing models built by Black Forest Labs, the Freiburg-based lab founded in early 2024 by the core researchers behind Stable Diffusion. The current flagship is FLUX.2, a rectified-flow transformer whose largest open checkpoint holds 32 billion parameters. It ships in API and open-weight tiers with sharply different licenses.

FLUX was born from pedigree. Robin Rombach, Andreas Blattmann and Patrick Esser — three of the people who authored the original Latent Diffusion Models paper and shipped Stable Diffusion at Stability AI — left to found Black Forest Labs (BFL). Their first release, FLUX.1, landed on 1 August 2024 and immediately became the reference open model. FLUX.2 arrived in late November 2025, and the small, fast [klein] variant followed on 15 January 2026. So when practitioners say “FLUX” in mid-2026, they almost always mean FLUX.2.

The one-line reason it matters: the FLUX image generation model is the highest-quality image model you can legally download, run on your own GPU, and fine-tune — even if the very best per-image quality now sits in the API-only tier.

Lineage and context: from Latent Diffusion to FLUX.2

To understand FLUX you have to understand what its founders built before it. Latent Diffusion Models, published in 2022, moved the diffusion process out of raw pixel space and into a compressed latent space produced by a variational autoencoder (VAE) — a neural network that encodes an image into a small tensor and decodes it back. Running diffusion in that latent space is what made Stable Diffusion cheap enough to run on consumer hardware.

Stable Diffusion 1.x and 2.x used a U-Net backbone: a convolutional encoder-decoder with skip connections. The architectural pivot came with Stable Diffusion 3, which replaced the U-Net with a transformer — specifically a multimodal diffusion transformer, or MMDiT — and swapped the classic noise-prediction objective for flow matching. That SD3 design is the direct ancestor of FLUX, because the same people designed both.

FLUX.1 took the SD3 recipe and scaled it. It was a 12-billion-parameter hybrid MMDiT: reported as 19 double-stream transformer blocks followed by 38 single-stream blocks, conditioned by two text encoders — the 4.7-billion-parameter T5-XXL plus CLIP-L — over a 16-channel VAE latent. It shipped in three tiers whose names became shorthand across the community: [schnell] (German for “fast”), [dev], and [pro]. Later came FLUX1.1 [pro] and [pro] Ultra for higher resolution, and FLUX.1 Kontext for instruction-based editing.

FLUX.2 changed the ingredients more aggressively than the version number suggests. It roughly tripled the transformer to 32 billion parameters, threw out the dual T5-plus-CLIP encoder stack, and replaced it with a single large vision-language model. That single change — covered in detail below — is the defining architectural story of the 2026 generation. If you want to see how a comparable generational jump plays out in a different modality, the unified AI video model from Kling tells a parallel story about consolidating capabilities into one backbone.

Architecture: rectified flow and the MMDiT transformer

Architecture diagram of the FLUX image generation model rectified-flow transformer

Figure 1: The FLUX.2 generation pipeline, from prompt and reference images through the MMDiT transformer and rectified-flow solver to the decoded image.

Figure 1 traces the data path through the FLUX image generation model. A text prompt goes into the Mistral-3 vision-language encoder; optional reference images are encoded to latent tokens by the VAE; a noise latent enters the double-stream MMDiT blocks; the single-stream blocks refine it; a rectified-flow ODE solver integrates the trajectory; and the VAE decoder renders the final image at up to four megapixels. Each stage is worth unpacking.

Rectified flow versus classic diffusion

Classic diffusion models like the original Stable Diffusion train on a denoising objective. During training you add Gaussian noise to an image across many timesteps, and the network learns to predict that noise so it can be subtracted step by step. Sampling then walks a stochastic differential equation (SDE) backward from pure noise, often needing 30 to 50 steps for good results.

Rectified flow reframes the problem. Instead of a noisy stochastic path, it learns a velocity field that maps a sample of noise to a sample of data along an approximately straight line. Formally it solves an ordinary differential equation (ODE) rather than an SDE. The straighter the path, the fewer integration steps you need to travel it accurately.

This is why the distilled tiers are so fast. If the trajectory from noise to image is nearly a straight line, you can take a handful of large steps instead of dozens of small ones. FLUX.1 [schnell] produced usable images in one to four steps for exactly this reason, and FLUX.2 [klein] 4B generates in about four steps.

The MMDiT double-stream and single-stream blocks

MMDiT stands for multimodal diffusion transformer. “Multimodal” here means text tokens and image latent tokens flow through the same transformer rather than being fused only through cross-attention, as older U-Net designs did.

FLUX uses a two-phase block structure. In the double-stream blocks, text and image tokens keep separate weight streams — separate projections and feed-forward networks — but attend to each other inside a joint attention operation. This lets each modality maintain its own representation while still exchanging information. In the later single-stream blocks, the two token sets are concatenated and processed by a single shared stream, which is more parameter-efficient once the modalities are aligned.

For FLUX.1 the reported split was 19 double-stream blocks and 38 single-stream blocks at 12 billion parameters total. Black Forest Labs has not published a comparably granular layer breakdown for the 32-billion-parameter FLUX.2 [dev] transformer, so treat any exact per-block count you see for FLUX.2 as unverified. The confirmed number is the 32-billion parameter total from the official model card.

The text encoder: from T5 plus CLIP to Mistral-3

This is FLUX.2’s biggest architectural break. FLUX.1 used two frozen text encoders — T5-XXL for linguistic structure and spelling, CLIP-L for high-level visual concepts. FLUX.2 replaces both with a single vision-language model: Mistral-3 (Mistral Small, 24 billion parameters), used as a multimodal embedder.

Two consequences follow. First, using one encoder simplifies the pipeline — there is a single prompt-embedding path instead of two that must be concatenated. Second, a 24-billion-parameter language model brings far stronger prompt comprehension than a 4.7-billion T5, which is a large part of why FLUX.2 follows long, compositional instructions better than its predecessor.

The implementation detail is worth noting for anyone building on the open weights. Rather than reading only the final hidden state, the FLUX.2 embedder extracts and concatenates hidden states from three intermediate layers of the Mistral model — the reference code pulls layers 10, 20 and 30. That gives the transformer both low-level token semantics and higher-level conceptual features in one representation.

The VAE latent and resolution handling

FLUX.1 used a 16-channel VAE with low compression to preserve fine detail like text and skin texture. FLUX.2 ships a redesigned VAE, retrained from scratch, that Black Forest Labs describes as targeting the “learnability, quality, compression” trilemma — the tension between a latent that is easy for the transformer to learn, faithful on decode, and small enough to be efficient.

FLUX.2 handles a wide span of resolutions and aspect ratios, up to four megapixels — for example 2048×2048 — with dimensions constrained to multiples of 16. The same backbone does text-to-image, single-reference editing, and multi-reference composition, so you feed it zero, one, or several reference images through the same VAE-encoded token path shown in Figure 1.

Training: flow matching, distillation and preference tuning

Training pipeline of the FLUX image generation model from data to distilled checkpoints

Figure 2: The reported FLUX training pipeline — web-scale data, safety filtering, flow-matching pre-training, guidance distillation, preference tuning, and the released tiers.

Figure 2 shows the reported flow from raw data to the shipped checkpoints of the FLUX image generation model. Black Forest Labs discloses very little about its training corpus, so parts of this section are labelled “undisclosed” or “reported” deliberately. Do not treat the data scale as a published number — it is not.

The flow-matching objective

FLUX is trained with a flow-matching objective. In flow matching, the network learns to predict the velocity that carries a point from the noise distribution to the data distribution along a defined probability path. Rectified flow is the specific variant that targets straight-line paths. The training loss is a simple regression on that velocity field, which is numerically stable and scales cleanly with model size and data.

The practical payoff is the one described in the architecture section: straighter learned trajectories mean fewer sampling steps at inference. But the base [dev] and [pro] models still benefit from many steps — the reference FLUX.2 [dev] code suggests up to 50 steps for best quality, with 28 as a good speed-quality trade-off.

Guidance distillation and why the fast tiers exist

Standard diffusion sampling uses classifier-free guidance (CFG), which runs the network twice per step — once with the prompt, once without — and extrapolates between them to sharpen prompt adherence. That doubles inference cost.

Guidance distillation trains a student model to reproduce the guided output in a single forward pass, folding the guidance behavior into the weights. FLUX.2 [dev]’s model card explicitly states it was “trained using guidance distillation,” which makes it more efficient than a naive guided model. The [schnell] and [klein] tiers push distillation further, also compressing the number of sampling steps, which is how [klein] 4B reaches four-step generation and sub-second latency on server hardware.

Post-training and safety fine-tuning

After pre-training, the models go through preference-oriented and safety fine-tuning. Black Forest Labs describes multiple rounds of targeted fine-tuning before release, including filtering pre-training data for NSFW and known child sexual abuse material (in partnership with the Internet Watch Foundation), and adversarial red-teaming against text-to-image and image-to-image misuse. The released open checkpoint is the post-safety-fine-tuning version, not the raw pre-trained model. This is a genuine engineering stage, not a marketing footnote — it changes the weights you download.

Capabilities and benchmarks

Benchmark comparison chart for the FLUX image generation model on the image arena

Figure 3: Approximate standing of leading 2026 image models on the Artificial Analysis image arena Elo, based on reported figures. Exact values move as the arena collects votes.

Figure 3 sketches where FLUX.2 sits among 2026 image models. The honest headline: FLUX.2 is excellent but no longer the arena leader. Read the numbers below with their caveats — image benchmarks are noisy, and several of these figures are community-reported rather than officially published.

Human-preference arena

The Artificial Analysis Text-to-Image Arena runs blind pairwise comparisons: users see two images from the same prompt without knowing which model made each, and pick the better one. Those votes produce an Elo rating, the same rating system used in chess.

On that arena in 2026, FLUX.2’s flagship sits around an Elo of roughly 1,190 by reported figures. That places it behind OpenAI’s GPT Image 2, which reportedly tops the board near 1,339 — described as one of the largest first-to-second gaps the leaderboard has recorded — and behind Google’s Nano Banana Pro, while sitting ahead of Google Imagen 4 and well ahead of Stable Diffusion 3.5. Treat the exact numbers as approximate; the ordering is the durable signal.

GenEval, DPG-Bench and structured metrics

GenEval measures object-focused prompt adherence — did the model produce the right count, colors, and spatial relations. DPG-Bench (Dense Prompt Graph) tests dense, compositional prompts. These are more objective than arena votes but easier to overfit.

Here I have to be careful. Black Forest Labs has not published a headline GenEval or DPG-Bench score for FLUX.2 in the sources I could verify, so I will not invent one. For calibration, FLUX.1 [dev] historically scored in the mid-0.6 range on GenEval, in the same neighborhood as SD3. One competing 2026 model, HiDream-O1-Image at 8 billion parameters, is reported to beat the 32-billion FLUX.2 [dev] on GenEval, DPG-Bench and several other structured benchmarks while also edging it on arena Elo — a reminder that raw parameter count no longer predicts benchmark rank.

What FLUX.2 is genuinely strong at

Beyond leaderboard position, FLUX.2 has concrete strengths. Text rendering and typography are markedly better than FLUX.1 — the Mistral-3 encoder helps it spell. Multi-reference generation lets you feed several images and hold a character, object, or style consistent across outputs without any fine-tuning. Photorealism at high resolution, up to four megapixels, is a headline capability of the [pro] tier. And instruction-following on long, structured prompts improved substantially over the first generation.

One caveat that applies to every model here: benchmark contamination and prompt-set overlap are real. When a model’s training data may include images similar to a public benchmark’s prompts, scores inflate. Always weight your own eval prompts over any published number.

Access and deployment: tiers, licenses, VRAM and cost

Deployment options and licenses for the FLUX image generation model tiers

Figure 4: FLUX.2 tiers with their licenses and approximate self-host VRAM, plus the quantization paths that fit consumer GPUs.

Figure 4 is the practical decision tree. This section is where most engineering choices actually get made, so it carries the most numbers. The tier you pick determines your license, your hardware bill, and your legal exposure.

The tiers and their exact licenses

FLUX.2 [pro] is the flagship. It is API-only and proprietary — there are no downloadable weights. You call it through the Black Forest Labs API or a reseller.

FLUX.2 [dev] is the 32-billion-parameter open-weight model. Its weights are downloadable from Hugging Face under the FLUX Non-Commercial License. The nuance that trips people up: the model card notes that generated outputs may be used for personal, scientific, and commercial purposes, but running the model itself for commercial deployment requires a separate self-hosted commercial license from Black Forest Labs. In short — you can sell the pictures, but hosting the [dev] weights inside a commercial product needs a paid agreement. Read the license before you build on it.

FLUX.2 [klein] ships in two sizes. The 4B distilled variant is released under Apache 2.0 — a permissive license that allows commercial use, modification, and redistribution with no separate agreement. The 9B variant is larger and higher quality but ships under the FLUX Non-Commercial License. So klein 4B is the only current FLUX.2 checkpoint you can freely embed in a commercial product without talking to BFL’s lawyers.

For historical context, the first generation’s FLUX.1 [schnell] was Apache 2.0, FLUX.1 [dev] was the non-commercial community license, and FLUX.1 [pro] was API-only — the same three-way split that FLUX.2 inherited and extended.

VRAM to self-host each tier

Hardware is where the 32-billion-parameter jump in the FLUX image generation model bites. At full BF16 precision, FLUX.2 [dev] needs roughly 64 GB of VRAM — beyond any single consumer card and into H100 or dual-GPU territory. That is the number to internalize before planning a self-host.

Quantization is the escape hatch. In FP8, [dev] needs around 32 GB, which fits an 80 GB A100 or H100 comfortably but does not fit a 24 GB RTX 4090. For consumer cards, GGUF quantization is the practical route: a Q4 GGUF of [dev] lands near 19 GB and fits a 24 GB 4090, at some quality cost. Lower Q5 and Q4 variants of the smaller models reach into 8 to 10 GB cards.

The klein tier is built for accessibility. FLUX.2 [klein] 4B fits in roughly 13 GB of VRAM and runs on cards like the RTX 3090 or 4070. The 9B klein needs about 19.6 GB and generates in roughly 0.5 seconds on a data-center GB200, or around 2 seconds on a consumer RTX 5090. If your priority is running FLUX locally with commercial rights, klein 4B is almost always the answer. For a broader view of how model size drives infrastructure cost, our breakdown of the DeepSeek V4 architecture walks through the same memory-versus-quality trade-off in the language-model world.

Quantization options in practice

Three quantization families dominate FLUX deployment. FP8 halves memory versus BF16 with minimal quality loss but needs hardware with efficient FP8 kernels. GGUF, via the community ComfyUI-GGUF nodes, offers a granular ladder from Q8 (near-lossless, larger) down to Q4 (visible quality trade-off, smallest). NF4 4-bit quantization, from the bitsandbytes library, is another route — Hugging Face publishes a 4-bit BNB build of FLUX.2 [dev] that pairs a quantized transformer and text encoder with a remote text-encoder option to fit a single RTX 4090.

Inference cost and latency

For the API tier, FLUX.2 [pro] is priced per megapixel. Reported pricing puts a standard one-megapixel output near $0.03, with each additional output megapixel around $0.015 and reference-image inputs around $0.015 per megapixel. A full four-megapixel render therefore costs roughly $0.12. Those are the reported figures; always confirm against the live BFL pricing page, since API prices move.

Self-hosted economics are different in shape. You trade per-image fees for GPU-hour rent or capital. On rented cloud GPUs, a 32-billion [dev] model on an 80 GB card amortizes well only at volume; below a few thousand images a day, the [pro] API is usually cheaper than keeping a big GPU warm. klein changes that math — a 13 GB model on a mid-range card can serve interactive workloads at trivial marginal cost.

Integration

Both [dev] and [klein] are first-class citizens in ComfyUI and in the Hugging Face Diffusers library, with an official Flux2Pipeline. Black Forest Labs also maintains a reference inference repository on GitHub. In practice, ComfyUI is where most self-hosters run FLUX, because its node graph makes multi-reference and editing workflows tractable, and the GGUF nodes handle quantized loading.

Limitations, safety and failure modes

No image model is honest marketing without a limitations section, so here is the unvarnished list.

Fine detail still fails. Hands, complex overlapping fingers, small background faces, and dense text at small sizes remain the classic artifact zones. FLUX.2 improved typography dramatically, but long paragraphs of rendered text still degrade, and precise brand logos are unreliable.

Prompt adherence has limits. On very long compositional prompts with many objects and spatial constraints, FLUX.2 — like all current models — drops or merges elements. The Mistral-3 encoder helps, but structured benchmarks like DPG-Bench exist precisely because dense prompts still break models.

The licensing traps are the most dangerous failure mode for businesses, because they are silent — nothing errors out. Downloading FLUX.2 [dev] and wiring it into a paid SaaS without a self-hosted commercial license is a license violation even though the code runs perfectly. The safe commercial-self-host default in 2026 is klein 4B under Apache 2.0, or the [pro] API under its service terms.

Provenance and safety are built in and worth understanding. FLUX.2 [pro] API outputs carry cryptographically-signed C2PA metadata marking them as AI-generated, and the [dev] inference code includes an example pixel-layer watermark. The open weights ship with NSFW and IP-infringement filters that the license requires deployers to keep in place — Black Forest Labs states it may audit deployers to verify filters or manual review are running. If you strip those filters, you are outside the license.

Finally, the safety filters themselves are a failure mode for some legitimate uses. Medical, forensic, and artistic-nude workflows can hit false positives, and the [pro] API applies input and output filters (including third-party filters from Hive and Microsoft) that you cannot disable. If your use case brushes those boundaries, validate it before committing.

How FLUX compares to its 2026 peers

The right question is never “which model is best” but “best for which job.” Here is a decision matrix across four common use cases, using the reported 2026 landscape.

Use case FLUX.2 GPT Image 2 Google Imagen 4 / Nano Banana Stable Diffusion 3.5
Peak photoreal quality Strong, arena ~1190 Best, arena ~1339 Very strong, top tier Behind the frontier
Typography and text Much improved, reliable-ish Excellent Excellent Weak
Commercial self-hosting klein 4B is Apache 2.0; dev needs a paid license API-only, no weights API-only, no weights Open, community license
Self-host cost / control Full weights, 13–64 GB by tier None, API-only None, API-only Lightest to self-host

Read the matrix by column. If you want the single best per-image result and are happy on an API, GPT Image 2 currently leads the arena. If you want Google’s ecosystem and editing, Imagen 4 and Nano Banana are the play. If you must own the weights, fine-tune, and keep data in-house, FLUX.2 is the strongest downloadable option — with klein 4B the only freely-commercial tier and [dev] the quality-versus-license compromise. Stable Diffusion 3.5 remains the lightest to self-host and the most permissively licensed of the high-quality open models, but it trails the frontier on quality.

For teams standardizing on a single vendor’s stack, it is worth reading how the Gemini 3.5 Pro architecture frames Google’s multimodal roadmap, since image generation is increasingly bundled into the same platforms that serve language and vision.

Frequently Asked Questions

Is the FLUX image generation model free to use commercially?

It depends entirely on the tier. FLUX.2 [klein] 4B is released under Apache 2.0, so you can use it commercially, modify it, and embed it in products with no separate agreement. FLUX.2 [dev] and [klein] 9B ship under the FLUX Non-Commercial License — you can download and experiment, and you may use the generated images commercially, but hosting the weights inside a commercial service needs a separate paid self-hosted license from Black Forest Labs. FLUX.2 [pro] is API-only under BFL’s service terms.

What is the difference between FLUX dev, pro and schnell?

Across generations, the naming is consistent. [pro] is the top-quality, API-only, closed tier. [dev] is the large open-weight model tuned for quality and research, under a non-commercial license. [schnell] (in FLUX.1) and [klein] (in FLUX.2) are the small, distilled, few-step tiers built for speed and consumer hardware, with the most permissive Apache 2.0 licensing on the smallest checkpoint. In FLUX.2, [dev] is 32B and [klein] comes in 4B and 9B sizes.

How much VRAM do I need to self-host FLUX.2?

At full BF16 precision, FLUX.2 [dev] needs roughly 64 GB of VRAM, which means data-center cards. FP8 quantization drops that to around 32 GB, fitting an 80 GB A100 or H100 but not a 24 GB card. A Q4 GGUF of [dev] fits a 24 GB RTX 4090 at about 19 GB. The klein tier is far lighter — klein 4B runs in about 13 GB on an RTX 3090 or 4070, and klein 9B needs about 19.6 GB.

Is FLUX better than Stable Diffusion in 2026?

On raw quality, yes — FLUX.2 clearly outranks Stable Diffusion 3.5 on human-preference arenas and in typical use. But “better” is job-specific. Stable Diffusion 3.5 is lighter to self-host, has a large ecosystem of fine-tunes and LoRAs, and its licensing is straightforward for many commercial cases. FLUX.2 wins on ceiling quality, prompt adherence, and multi-reference editing. Choose SD3.5 for lightweight, permissive self-hosting; choose FLUX.2 when you need the frontier.

What text encoder does FLUX.2 use?

FLUX.2 uses a single vision-language model, Mistral-3 (Mistral Small, 24 billion parameters), as its text encoder. This is a major change from FLUX.1, which used two encoders — the 4.7-billion T5-XXL plus CLIP-L. The FLUX.2 embedder concatenates hidden states from three intermediate Mistral layers (reported as layers 10, 20 and 30) to build a rich prompt representation. The larger language model is a key reason FLUX.2 follows long, compositional prompts and renders text better than its predecessor.

Does FLUX add watermarks or provenance metadata?

Yes, at the flagship tier. FLUX.2 [pro] API outputs carry cryptographically-signed C2PA metadata that marks them as AI-generated. The open [dev] inference code includes an example pixel-layer watermarking implementation and links to the C2PA standard. The open weights also ship with NSFW and IP-infringement filters that the license requires deployers to keep active — Black Forest Labs states it may audit deployers to confirm those filters or a manual review process are in place.

Further Reading

By Riju — about

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *