FLUX 3 Image Klein: What 5.6B Parameters Actually Weighs on Your Disk

FLUX 3 Image Klein is the open-weights member of Black Forest Labs' FLUX 3 Image family, published on 15 October 2026 at 5.6B parameters, with downloadable weights and a metered endpoint on the same day. The number in the headline counts the image transformer and nothing else. The text encoder — Qwen3-VL-4B-Instruct — is a separate download, the image autoencoder is a third, and the smallest combination of the three that actually runs comes to about 10.5 GB. Take the BF16 versions of the same three files and you are at roughly 20 GB. Follow the reference implementation's own default pipeline, which runs a prompt upsampler before every generation, and the total passes 39 GB on disk.

None of that contradicts the vendor's claim that FLUX 3 Image Klein runs on a single consumer GPU, because the claim was never about file size. It is about VRAM at inference time, in a quantised build, with the weights loaded one tensor at a time. But "5.6B parameters and runs on a single consumer GPU" compresses three separate numbers — the parameter count, the download, and the resident memory — into one phrase, and anyone planning a deployment needs all three. This is what each of them actually is, from BFL's own documentation and the Hugging Face API, when the model is a day old and nobody independent has measured it yet.

What shipped on 15 October

Klein is the second open-weights release from the FLUX 3 family, after FLUX 3 Action in September. The launch post is titled FLUX 3 Image Klein: open weights, 5.6B parameters, and what it enumerates is a fairly complete release rather than a checkpoint dump:

• Two checkpoints, both 5.6B. Klein Base is undistilled, runs 50 steps at guidance 3.5, and exists for fine-tuning, LoRA training and research. Klein is step-distilled to 16 steps with no guidance and is the checkpoint behind the BFL API.

• Three quantisation formats. FP8 and NVFP4 variants sit alongside the BF16 transformer in the main repository, with an INT8 build developed with NVIDIA support. The ComfyUI repackaging adds INT8 versions of both the transformer and the text encoder, which the main repository does not carry.

• Day-one runtime support in ComfyUI, Hugging Face Diffusers, TensorRT-LLM, SGLang Diffusion and vLLM-Omni, plus LoRA training through Ostris's AI Toolkit and recipes in NVIDIA NeMo AutoModel. Trained on NVIDIA GB200 NVL72; the GB300 NVFP4 timing is the one behind the sub-second claim.

• The feature set is inherited, not reduced. Native 4K, instruction-based editing that preserves unedited regions, up to ten reference images, and bounding boxes on a 0–1000 grid that can place elements or confine an edit to a region. BFL is explicit in the model card that boxes guide placement and scale rather than constraining pixels to a hard mask — which matters if you were expecting mask-level control.

The repositories went up before the announcement. The base and distilled repositories were created on 13 October and the ComfyUI and prompt-upsampler repositories on 14 October, with the launch post and the API endpoint following on the 15th.

The three files behind the 5.6B number

Read the file listing rather than the parameter count and the shape of the download changes. The Hugging Face API reports the distilled repository's own files at these sizes:

• Image transformer, BF16 — model.safetensors, 11.10 GB. BFL's launch post rounds this to 11.2 GB in BF16 and 5.6 GB in FP8.

• Text encoder, BF16 — Qwen3-VL-4B-Instruct, split across two safetensors shards, 8.88 GB together. An INT8 build of the same encoder exists in the ComfyUI repository at 4.86 GB.

• Image autoencoder — 0.34 GB, and it is the one file no quantisation path removes.

So the practical floor is not 5.6 GB and it is not 11.2 GB. It is the NVFP4 transformer at 5.28 GB plus the INT8 text encoder at 4.86 GB plus the 0.34 GB VAE — about 10.5 GB of files for a pipeline that generates and edits. The all-BF16 version of the same three is about 20.3 GB. And the prompt upsampler, which the reference CLI downloads and runs on every request unless you pass --no-pup, is its own repository: 18.82 GB in bfloat16, or 9.75 GB in the INT8 build the ComfyUI packaging ships. Add the BF16 upsampler to the BF16 pipeline and you are looking at roughly 39 GB on disk before you generate an image.

BFL's own model card carries the caveat that belongs next to these numbers: "Quantized packages need a loader that supports their format; their file size is not a measure of total GPU memory use."

That cuts both ways. A quantised file being small does not mean the run fits in that much memory, and a large download does not mean the working set is large. It does mean the download is the part you can plan before you have hardware, and it is the part the headline parameter count hides.

Where the 8 GB VRAM figure comes from

The memory claim is specific. With the INT8 build, BFL states that FLUX 3 Image Klein runs on NVIDIA GeForce RTX GPUs with as little as 8 GB of VRAM, through ComfyUI or Diffusers, and the documentation puts the supported floor at an RTX 3090.

The speed figures come with a provenance worth naming precisely: they were measured by NVIDIA, in ComfyUI for the RTX results. With the step-distilled model and the INT8 build, a 1 MP image takes about 4 seconds on an RTX 5090 and under 9 seconds on an RTX 4070. On a GB300 in NVFP4 the distilled model produces a 1 MP image in under 0.6 seconds. Serving a LoRA adds roughly 5% to generation time.

These are vendor-reported and they are not the same measurement as the API latency numbers in the launch post. BFL timed Klein on its own servers while timing Qwen-Image 2.1, FLUX.2 [pro], Ideogram V4.5 and Krea 2 from the client, which folds polling and network time into the competitors' figures but not into its own — and the post says so. The honest reading is that the 4-second and 9-second numbers are credible as local inference timings on the named cards, and that the speed-versus-quality frontier chart is a vendor's own comparison drawn with asymmetric stopwatches. No one outside BFL or NVIDIA has reproduced either.

What it costs through the API, and where the curve bends

The distilled checkpoint is served as flux-3-image-klein, with prompt upsampling and pixel restoration included. BFL publishes these rates per image, identical for text-to-image and for editing:

• 768 × 768 — $0.008

• 1K — $0.009

• 1.5K — $0.011

• 2K — $0.014

• 4K — $0.036

Set against FLUX 3 Image, the larger API-only sibling on the same feature list, the ratio is what should drive the decision rather than the absolute price. FLUX 3 Image is $0.048 for a 1K image against Klein's $0.009 — a factor of about 5.3. At 4K the same comparison is $0.607 against $0.036, a factor of nearly seventeen. Anyone generating 4K at volume is not choosing between a cheap model and an expensive one; they are choosing between a per-image rate that survives contact with a product and one that does not.

The other half of the arithmetic is on your own side: a self-hosted Klein on a card you already own has no per-image cost, and a self-hosted Klein on a rented card has an hourly one. The break-even point moves with utilisation, and it moves a lot — an idle GPU is the expensive configuration, not the cheap one. If your image traffic is spiky, the flat rate is usually the better trade; if it is steady and high, the download starts paying for itself and the licence becomes the variable that matters.

The licence is the part that decides whether you can ship it

Both checkpoints are under the FLUX Kommunity License, and it is worth reading the two descriptions of it side by side because they are not worded the same way. The launch post says the licence "allows free commercial use for individuals and companies with annual revenue under $5M, alongside research and non-commercial use," with larger organisations deploying commercially through BFL's paid self-hosted licensing options or the API. The model card says the licence "permits non-commercial use and provides a commercial-output exception for Qualifying Users, subject to its terms," where Qualifying User is defined in the licence text itself.

The revenue threshold is the operative fact for most teams: under $5M in annual revenue, free commercial use; above it, one of BFL's paid tiers. Those tiers are listed publicly — Builder at 10K images per month and 1 domain, Platform and Professional at 100K images per month, Enterprise custom — and all of them bundle FLUX 3 Image Klein alongside FLUX.2 family models, with fine-tuning and LoRA rights included. Note what the tiers mean: a company past the threshold is not buying the model again, it is buying the right to use weights it has already downloaded, which is a different kind of line item from an API bill and one that is easier to forget when a prototype becomes a product.

If your organisation's revenue is anywhere near the line, read LICENSE.md rather than either summary. Two vendor documents describing the same instrument in two different registers is exactly the situation where the primary text is the one that binds you.

The quality claim is BFL's own, and it does not include FLUX 3 Image

Klein's headline quality result, from internal evaluations, is first place in text-to-image, multi-reference generation and image editing — ahead of larger open-weights models, and above the closed models in the comparison, Ideogram V4.5 and FLUX.2 [pro]. The open-weights comparison set is named elsewhere in the post: Qwen-Image 2.1 at 7B and Krea 2 at 12.9B, both larger than Klein's 5.6B, with Krea 2 excluded from the editing column because it does not support editing. Against FLUX.2 [klein] 9B, the previous generation's open model, Klein gains 91 Elo in text-to-image and 70 in image editing while carrying 38% fewer parameters.

FLUX 3 Image — the vendor's own larger model, sold through the same API on the same feature surface — appears nowhere in that comparison. That is not damning on its own; benchmarking a small open model against the models a downloader would otherwise run is a defensible choice. But it means the sentence a buyer most wants, "Klein is within X of the bigger model," is still unwritten.

The independent picture is thinner still. The one public text-to-image leaderboard that tracks this family lists FLUX 3 Image, and as of writing it has no FLUX 3 Image Klein entry at all. So every quality number available on day one traces back to BFL, and the reproducible ones — the ones you can check yourself in twenty minutes — are the file sizes and the per-image rates above, not the Elo deltas.

Calling it, or running it

The decision splits cleanly along three questions. If you need fine-tunes or LoRAs on your own data, or the images cannot leave your infrastructure, or your volume is high and steady, the download is the answer and the licence is the thing to settle first. If your volume is spiky, your images are hero assets rather than bulk output, or you want to evaluate the model before committing hardware, the endpoint at $0.009 a 1K image is cheaper than a weekend of setup.

There is a third case worth naming, because it is the common one: teams that end up calling several image models rather than one, using a small open model for volume work and a frontier model for the shots that matter. That is the case OrcaRouter exists for — one API key across 200+ models, provider list price passed through at 0% markup so a vendor rate change lands the same day, and automatic failover so an unproven model can sit in a production path without being a single point of failure. FLUX 3 Image Klein is not on our catalogue today, so the BFL endpoint is a direct vendor call either way; what we can do is keep everything around it — the other image models, the routing rules, the fallback — behind the same endpoint and the same billing line.

What would change this

Three things, in order of how much they would move a decision. An independent head-to-head between Klein and FLUX 3 Image, because the price gap between them is seventeen-fold at 4K and the quality gap is unmeasured. INT8 timings on an actual 8 GB card from someone who is not NVIDIA, because that is the number the entire local-deployment pitch rests on and it has been measured by one interested party. And a licence clarification from BFL that reconciles the revenue-threshold framing in the launch post with the Qualifying User framing in the model card.

Until then, the defensible position is the narrow one: FLUX 3 Image Klein is real, it is downloadable today, it does the things the FLUX 3 Image API does on the same feature list, and it costs roughly a fifth as much per image at 1K and a seventeenth as much at 4K. Plan for about 10.5 GB of files at the smallest and 39 GB with the upsampler and everything in BF16, decide the licence question before you decide the hardware question, and treat every quality number you have read so far as the vendor's.