FLUX.1-dev · 39 cards measured first-party · Updated July 2026

How Fast Is FLUX.1-dev on Each GPU?

FLUX.1-dev at BF16 is the workload that ends the '24GB is enough' argument. It needs roughly 26GB minimum and 34GB to run properly, which means the most popular high-end consumer card on earth cannot load it, not slowly, not at all. This is the single most consequential VRAM cliff in modern AI image generation.

Benchmarked weights: black-forest-labs/FLUX.1-dev

Fastest we measured

NVIDIA B300

9.71 it/s on FLUX.1-dev. Measured on our bench. 288GB of VRAM, 1400W board rating. AI Score 93.8/100 across our full 12-workload suite.

Pros

• 9.71 it/s on FLUX.1-dev
• 288GB, clears the FLUX.1-dev floor
• Rentable by the hour rather than bought

Cons

• 1400W board rating
• Datacenter or workstation hardware, not a retail purchase

Best for: FLUX.1-dev work where you want the ceiling gone rather than the cheapest entry.

Runner-up

NVIDIA B200

6.13 it/s on FLUX.1-dev. Measured on our bench. 192GB of VRAM, 1000W board rating. AI Score 78.0/100 across our full 12-workload suite.

Pros

• 6.13 it/s on FLUX.1-dev
• 192GB, clears the FLUX.1-dev floor
• Rentable by the hour rather than bought

Cons

• 1000W board rating
• Datacenter or workstation hardware, not a retail purchase

Best for: FLUX.1-dev work where you want the ceiling gone rather than the cheapest entry.

Third

NVIDIA H200

4.44 it/s on FLUX.1-dev. Measured on our bench. 141GB of VRAM, 700W board rating. AI Score 65.0/100 across our full 12-workload suite.

Pros

• 4.44 it/s on FLUX.1-dev
• 141GB, clears the FLUX.1-dev floor
• Rentable by the hour rather than bought

Cons

• 700W board rating
• Datacenter or workstation hardware, not a retail purchase

Best for: FLUX.1-dev work where you want the ceiling gone rather than the cheapest entry.

Tensor-compute bound, so the ranking rewards recent architectures. But the story here isn't the ranking. It's the gate. FLUX.1-dev is where the market splits into cards that do modern image generation and cards that do 2023's image generation, and the dividing line is drawn at about 26GB of VRAM.

Because this workload is tensor-compute bound, the ranking tracks architecture generation and tensor throughput rather than memory bandwidth, the reverse of our LLM charts. The same two cards can swap places entirely depending on which of these pages you're reading. That's the reason we run twelve workloads instead of publishing one score. A GPU isn't fast or slow. It's fast at some things and gated out of others, and which of those matters depends entirely on what you're actually going to run.

Our verdict

NVIDIA B300 tops our FLUX.1-dev leaderboard at 9.71 it/s (measured), 12138% of the way clear of the slowest card that still fits. But the number that decides most purchases isn't on the chart. It's the 32 cards that can't run FLUX.1-dev at all. This is a compute workload: buy architecture generation, not raw VRAM, as long as you clear the floor first.

FAQ

What is the fastest GPU for FLUX.1-dev?

NVIDIA B300, at 9.71 it/s on our bench, a first-party measurement. It carries 288GB of VRAM. Of the 61 cards we have FLUX.1-dev data for, 29 can run it at all.

How much VRAM do I need for FLUX.1-dev?

~26GB minimum at BF16, ~34GB for the full path. A 24GB card misses it by two gigabytes. We publish that as a hard gate rather than quietly dropping to a smaller quant, because silently changing the precision would make the number meaningless.

Why does the FLUX.1-dev ranking look different from your other benchmarks?

Because this workload is tensor-compute bound, the ranking tracks architecture generation and tensor throughput rather than memory bandwidth, the reverse of our LLM charts. The same two cards can swap places entirely depending on which of these pages you're reading. That's why we publish twelve separate workloads rather than one blended score, the ordering genuinely changes depending on the job.

Are these FLUX.1-dev numbers measured or estimated?

Both, and every row says which. 39 of the 61 cards here were rented and run by us on the same harness. The remainder are anchored estimates interpolated per workload against those measurements. We never blend the two silently, if a row says Estimated, we have not run that card.

Can I rent a GPU to run FLUX.1-dev instead of buying one?

Yes, and for the cards at the top of this leaderboard it's the only realistic option, most of them have no retail channel at all. It's also how we got these numbers: we rented the hardware by the hour rather than buying it. That's worth considering before you spend on a card to find out whether it's fast enough.

Why publish cards that can't run FLUX.1-dev?

Because it's the most useful thing we know. A card that can't load a model doesn't run it slowly, it doesn't run it. Most benchmark sites leave that as a blank cell or quietly drop to a smaller quantisation to produce a number. We publish it as a hard gate and score it zero, because 'this card cannot do the thing you want' is the answer to the question you were actually asking.

How we test

Every ranking on this page comes from our own benchmark runs, not vendor claims. Cards marked Measured were rented and run by us; cards marked Estimated are interpolated per workload against those measured anchors and are labelled on every row, we never blend the two silently. LLMs run on llama.cpp (llama-bench) at Q4_K_M with -p 512 -n 128. Diffusion and video run on diffusers/ComfyUI at BF16, with SDXL at FP16. Each workload gets a warmup pass plus multiple timed runs (5 for small LLMs, 3 for large models and images, 2 for video); we publish the mean as the result and the minimum as the 1% low. Run-to-run variance is under 0.5%. Telemetry, power, temperature, utilisation, clocks, peak VRAM, is sampled at 1 Hz for the duration of every run. Where a model exceeds a card's VRAM we publish a hard won't-fit result rather than quietly dropping to a smaller quantisation. A card that can't run a model scores zero on it. Silently swapping precision to make a number appear would make every number on this site meaningless. All figures are single-GPU, single-stream, batch-size-1. That is the honest way to measure what one card does for one user, and it is deliberately not how a datacenter serves a model. Vendor and MLPerf figures use large batches across many GPUs and will be far higher. Neither is wrong, they answer different questions. Ours answers 'what will this card do for me'.