FLUX.2 Architecture Guide: Dev Components and Model Sizes

FLUX.2 dev combines a 32-billion-parameter image transformer with a Mistral text encoder and a separate autoencoder. Black Forest Labs publishes its weights and reference code for image generation and editing. 2, 5

What are the key facts about FLUX.2 architecture?

What components make up the FLUX.2 dev pipeline?

FLUX.2 supports both creating images from descriptions and editing with image references. The dev model card describes generating, editing, and combining images through text instructions in one checkpoint. 2

Start a component inventory with the exact checkpoint. Record the image transformer, text encoder, and autoencoder separately so that a model-size label does not stand in for the whole deployment.

BFL's reference implementation uses Mistral-Small-3.2-24B-Instruct-2506 for text encoding. It documents the FLUX.2 autoencoder separately from the image transformer. 5

The text encoder supplies prompt embeddings to the image pipeline. The published 32B count describes the image transformer; the autoencoder has its own model file and Apache 2.0 release. 2, 5

The CLI documents FLUX2_MODEL_PATH for dev weights and AE_MODEL_PATH for autoencoder weights. If these paths are unset, the repository says it downloads the weights automatically. 5

The hosted lineup exposes different priorities. BFL positions pro for production generation, flex for controllable sampling and typography, and Max for demanding output and grounding search. 3

Use those descriptions to build a shortlist, then test representative work. For a catalog scene, judge the product; for a poster, inspect the words; for a reference edit, check what was preserved as well as what changed.

What do FLUX.2 parameter counts and licenses cover?

Do not apply the dev parameter count to every hosted model. BFL publishes the dev and Klein checkpoint sizes but does not give equivalent counts for all endpoints in its overview. 2, 3, 4

The family's licenses also differ. A downloadable checkpoint is not automatically an unrestricted commercial model, and an Apache-licensed inference repository does not make all model weights Apache-licensed. 2, 4, 5

BFL describes the dev reference script as requiring H100-equivalent GPU capacity. Its consumer-GPU example uses quantization and a remote text encoder. 2, 5

A remote text encoder makes a workflow partly hosted even if image sampling occurs on your GPU. Read that example's data path before choosing it for a project that requires all prompt processing to stay local. 2

Model performance should be evaluated at the level you intend to use. A successful text-to-image sample does not establish that your product-reference edits or text-heavy layouts will meet the same acceptance criteria.

Record the model name in every evaluation. “FLUX.2” alone is too broad to explain a result when the family includes different weights, hosted endpoints, and sampling options.

How do you load a complete FLUX.2 dev pipeline?

1. Review the gated FLUX.2 dev model card and its weight-license conditions. For hosted access, use BFL's separate account and API-key setup guide. 2, 9

2. If running locally, begin with the official inference repository. Its instructions describe the tested Python and CUDA environment, model-path variables, and automatic weight downloads. 5

3. After installing that repository's dependencies and arranging access to the required weights, launch the documented interactive CLI from its root directory. 5
   

PYTHONPATH=src python scripts/cli.py

This is the repository's CLI entry point, not a standalone installation command. Follow its current setup instructions before running it; dev's reference example is intended for substantial GPU capacity. 5

1. For a consumer GPU, use the quantized implementation guidance linked in the model card. Check whether its text encoder is remote, what precision it uses, and which components are offloaded. 2

2. For an API workflow, select a named endpoint rather than trying to upload local weights to the service. BFL documents an asynchronous request: submit, poll the returned URL, and download the result once ready. 6

3. Create one text-only test and one reference-image test. Save the request details and inspect the downloaded images against a short list of requirements before building a larger workflow.

For local workflow concepts, see the ComfyUI guide. Model compatibility should still be checked against the implementation you actually install.

The Klein variant guide covers the compact branch. The online access guide covers hosted setup and pricing.

As a suggested evaluation method, keep the creative brief fixed while comparing routes. Note any changes needed to make a request work, because those changes are part of the integration effort you are deciding whether to accept.

For a repeatable internal record, include the source images, exact prompt, endpoint or checkpoint, dimensions, and the reason the output passed or failed. That is more useful than saving only a favorite image.

How does FLUX.2 dev compare with FLUX.1 architectures?

This comparison describes the published model tasks and sizes. It does not establish a speed ratio or predict which model will produce your preferred image on a particular GPU.

For an existing workflow, first identify the capability you need to add. If the current pipeline already meets the job, evaluate migration effort against a specific benefit such as combining multiple references.

How many parameters does FLUX.2 dev have?

FLUX.2 dev is published as a 32B image transformer. The original Klein releases use 4B and 9B image transformers; hosted models should be described using their own published specifications. 2, 3, 4

Is the whole FLUX.2 family open source?

FLUX.2 access varies by model: Klein 4B uses Apache 2.0; dev and Klein 9B weights use non-commercial licenses. Pro, flex, and Max are hosted offerings without published open weights. 1, 3, 4

Does a local FLUX.2 example always stay entirely local?

The FLUX.2 dev model card includes a consumer-GPU example with a remote text encoder. That workflow processes prompts through a hosted component while sampling images on your GPU. 2

Which specification should I record when sharing results?

Record the exact FLUX.2 checkpoint or endpoint, dimensions, and available sampling settings. For dev, also identify the text encoder, autoencoder, precision, and any remote components. 2, 3, 5

Sources

• FLUX.2 launch announcement
• FLUX.2 dev model card
• BFL family and access overview
• Klein release and licenses
• Official FLUX.2 inference repository
• BFL generation API guide
• FLUX.1 dev model card
• FLUX.1 Kontext dev model card
• BFL account and API-key setup

Related guides on PromptZone

• Realistic Photos with FLUX
• Best SDXL Models in 2026