FLUX 3 GPU Requirements: Video, Audio & Image Setup (2026)

Black Forest Labs shipped FLUX 3 on July 23, 2026, its first model trained on image, video, audio, and robot action inside one architecture (MarkTechPost). If you're searching for FLUX 3 GPU requirements to plan a deployment, the honest answer is that BFL hasn't published one: no parameter count, no VRAM number, for any variant. What follows is what's actually known, how to size GPU capacity using FLUX.2 as a proxy, and what to run today while FLUX 3 stays behind an early-access gate.

What FLUX 3 Can Do That FLUX 2 Couldn't

FLUX.2, which we covered in our FLUX.2 production deployment guide, is a 32B image-only rectified flow transformer. FLUX 3 is a different kind of model entirely: one set of weights that handles four modalities instead of one.

One Set of Weights: Image, Video, Audio, and Action Prediction

FLUX 3 is trained jointly on images, video, and audio, with a robot action-prediction extension built on the same backbone (MarkTechPost). BFL CEO Robin Rombach put the reasoning plainly: "a model that only learns images can only generate images" (RITS Shanghai NYU). The bet is that a model forced to reconcile how pixels, sound, and motion relate to each other ends up understanding all three better than a model trained on any one in isolation.

FLUX 3 Video is the flagship result. It generates clips up to 20 seconds in a single generation with native audio built in rather than added as a separate pass (MarkTechPost). It supports text-to-video, image-to-video, video-to-video from a reference clip, keyframe-to-video for controlled transitions, and generative video-audio continuation from existing footage (MarkTechPost). It accepts up to 10 image references plus audio and video inputs for editing existing footage, and supports aspect ratios from 9:16 to 21:9 (MindStudio).

The action-prediction side is where it gets interesting for reasons that have nothing to do with content generation. FLUX-mimic, co-developed with Zurich robotics startup Mimic Robotics, reuses FLUX 3's video-prediction backbone with a lightweight decoder to output robot motion commands instead of pixels. It targets tasks conventional automation has struggled with: kitting parts into trays, inserting components into tight-fitting fixtures, and manipulating soft, flexible materials like seals and cables. Audi is one of the production partners running it, on a car door assembly task, and an Audi engineer credited it with solving "complex soft body manipulation work that would have been simply impossible with conventional robotics" (Mimic Robotics). The policy runs inference in under 80ms on a single RTX 5090, fully on the edge (MarkTechPost).

Self-Flow: The Training Method Behind the Jump

The technique behind all of this is called Self-Flow: flow matching combined with self-supervised feature reconstruction. BFL built it on a SiT-XL/2-style backbone with per-token timestep conditioning, and distills from an EMA teacher at layer 20 down to a student at layer 8 (MarkTechPost). BFL's research team frames the multimodal training itself as the mechanism: "No single modality gives a complete description of the world... training on all of them at once means the modalities constrain each other" (BFL research team, via MarkTechPost).

That constraint shows up unevenly. Over 95% of FLUX 3's training compute went to video prediction, with audio consuming less than 0.5% of tokens. Audio quality rides along as a secondary channel rather than being trained as a first-class objective, which tracks with what early testers report: the video is the headline, audio is solid but clearly not where the compute went.

In blind preference testing on 10-second text-to-video clips, FLUX 3 beat Luma Ray 3.2 93% of the time, Runway Gen-4.5 77% of the time, Grok Imagine Video 69% of the time, and Kling v3 Pro 60% of the time. Those are BFL's own numbers, not third-party benchmarks, so treat them as a starting point for your own evaluation rather than a settled result.

What's Live Today vs What's Still Gated

Only FLUX 3 Video and FLUX 3 Action are available, and both require gated early access to selected partners. FLUX 3 Image is expected in the following weeks. FLUX 3 Dev, the open-weight release of the multimodal backbone, is planned for later in 2026 with no announced date, license terms, or parameter count as of this writing (BFL). BFL's own launch post confirms the phased rollout without committing to dates: "Over the next few weeks and months, we will make the following capabilities available, each after an early access phase" (BFL).

So if you came here looking for a FLUX 3 self-host guide: there isn't one yet. There's an API you can apply to use, and a promise of open weights sometime later this year.

FLUX 3 GPU Requirements: Video vs Image Mode VRAM Planning

Here's the direct answer: nobody outside Black Forest Labs currently knows FLUX 3's GPU requirements, for Video, Image, or Action. No parameter count, no VRAM figure, no minimum GPU tier has been published for any variant (BFL). That's unusual for BFL, which has published detailed specs for every prior FLUX release. It's also not an accident: the early-access API model means BFL runs the inference infrastructure themselves, so there's no immediate pressure to document a spec sheet nobody outside their cluster needs yet.

Why Parameter Count and VRAM Aren't Published Yet, and How to Plan Anyway

The practical problem is that GPU capacity planning has to happen before weights exist. Teams evaluating whether to budget for FLUX 3 Dev later this year need a number now, not in Q4. The answer is to size against the closest available sibling architecture and adjust once real numbers land.

Sizing Against FLUX.2's Known 32B Footprint as a Proxy

FLUX.2-dev is a 32B parameter rectified flow transformer, and it's the best available proxy for FLUX 3 Dev sizing because it's the most recent BFL model built on a comparable transformer-based architecture with published numbers. FLUX.2-dev needs roughly 64GB VRAM at BF16, drops to about 32GB at FP8, an ~50% reduction, and goes as low as ~19GB at GGUF Q4_K_S on an RTX 4090 (see our FLUX.2 GPU cloud deployment guide for the full quantization ladder).

If FLUX 3 Dev's backbone lands in a similar parameter range, a similar quantization path is a reasonable planning assumption: BF16 needing an 80GB card, FP8 fitting comfortably on an H100 or A100 80G, and a GGUF path opening up consumer GPUs. That's a proxy, not a confirmed spec. Treat every number in this section as a planning estimate, and re-check once BFL actually publishes FLUX 3 Dev's card.

FLUX-mimic and the RTX 5090 Inference Number BFL Did Publish

The one concrete hardware number reported for any FLUX 3 variant is for FLUX-mimic, the robot-action model: it runs inference in under 80ms on a single RTX 5090, fully on the edge (MarkTechPost). That's a very different workload from video generation, small-decoder robot-action inference rather than 20-second video synthesis, so it doesn't translate directly into a VRAM estimate for FLUX 3 Video. But it's a signal that BFL is optimizing the action variant hard for consumer-tier hardware, which is worth watching if you're planning edge deployment rather than cloud inference.

What GPU Tier to Provision Now vs When FLUX 3 Dev Ships

Given the uncertainty, here's a practical split: provision for what you can actually run today, and hold a GPU tier in reserve for FLUX 3 Dev once it lands.

For a broader comparison of H100, H200, and B200 across inference workloads generally, see Best GPU for AI Inference in 2026.

Deploying FLUX 3 Early Access on Rented GPUs: Step by Step

Since FLUX 3 Video and Action are API-only, "deploying FLUX 3" today means deploying a client that calls BFL's API, not standing up inference infrastructure yourself. Here's what that actually looks like.

Applying for Early Access and What You Get (API, Not Weights)

Request access at bfl.ai/models/flux-3, which links to an application form. It's an application process, not a purchase: you describe your use case and wait for BFL to approve or hold the request, with no published wait times or acceptance criteria. Pricing hasn't been published either, so any per-generation cost you see quoted before BFL ships an official pricing page is a guess, not a fact.

If approved, you get API credentials, not model weights. There's nothing to download, no checkpoint to load onto a GPU. FLUX 3 Video and FLUX 3 Action are not yet available through third-party inference platforms either; access runs through BFL directly at this stage.

Setting Up a GPU Cloud Client Instance to Call the FLUX 3 API

You still need somewhere to run the application code that calls FLUX 3's API, handles the async video generation job, and serves results to your own users. A small always-on instance works fine here since the heavy lifting happens on BFL's infrastructure, not yours.

1. Spin up a lightweight instance. This doesn't need a GPU for the API-calling layer itself; a CPU instance is enough unless you're also doing local video post-processing (transcoding, watermarking, thumbnail extraction). For those steps, an RTX 4090 is a cost-effective choice.
2. Install your HTTP client and async job queue (FastAPI + Celery, or similar) to submit generation requests and poll for completion, since video generation from FLUX 3 is not instant.
3. Store generated clips in object storage rather than passing large video payloads through your own database.
4. If you're also running local models alongside the FLUX 3 API calls (upscaling, format conversion, a fallback model for when early access rate limits hit), size that GPU separately using the guidance above.

For account setup and instance provisioning basics on Spheron, see the getting started guide.

Bridging Today: Running FLUX.2 and Wan 2.5 in Production While You Wait for FLUX 3 Dev

If your actual need is "generate video with audio in production right now," not "wait for FLUX 3 Dev," there are self-hostable options that cover real ground today. Wan 2.5 is the closest self-hostable match to FLUX 3 Video's feature set: text-to-video generation with audio, deployable on your own GPU today rather than gated behind an application. Our Wan 2.5 GPU cloud deployment guide covers VRAM sizing and production setup.

For image-to-video specifically, LTX-Video, Wan 2.2, and Hunyuan Video Avatar are all self-hostable now and covered in our image-to-video GPU cloud guide. And if you need image generation rather than video, FLUX.2 is the open-weight option that actually ships today, not sometime later in 2026.

Deploy FLUX2 GPU Cloud Production Guide: The Established Pattern FLUX 3 Will Follow

FLUX.2 matters here for a reason beyond "it's from the same lab." It's the closest thing to a working preview of how FLUX 3 Dev will likely be packaged for self-hosting once it ships: same license-gated HuggingFace distribution model, same quantization ladder from BF16 down to consumer-GPU GGUF variants, same ComfyUI-and-diffusers dual deployment path. Our full FLUX.2 GPU cloud production guide walks through all of it; this section pulls out the parts most likely to carry over.

FLUX.2's FP8/GGUF Quantization Ladder as a Preview of FLUX 3 Dev Sizing

Pricing below is from Spheron's live marketplace as of 03 Aug 2026, split by instanceType (dedicated on-demand vs spot) before computing any per-GPU rate.

Pricing fluctuates based on GPU availability. The prices above are based on 03 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

If FLUX 3 Dev follows a similar quantization curve, an H100 covers FP8 inference comfortably, and A100 SXM4 80G spot is the value play for batch or checkpointable workloads. Neither is a guarantee, since FLUX 3's actual parameter count is still unknown, but it's the same reasoning that has worked for every prior FLUX release.

ComfyUI and Diffusers Setup That Will Carry Over to FLUX 3 Dev

FLUX.2 ships two practical deployment paths: ComfyUI for interactive, workflow-driven use, and the diffusers Python library for production APIs behind FastAPI. Both patterns are architecture-agnostic enough that they'll likely apply directly to FLUX 3 Dev once weights exist, swap the checkpoint loader node or the from_pretrained call, and the rest of the pipeline (FP8 quantization via optimum-quanto, torch.compile for sustained throughput, sequential CPU offload for low-VRAM experimentation) carries over unchanged. If you're setting up either stack now for FLUX.2, you're not wasting the setup work: it's the same infrastructure FLUX 3 Dev will need later.

FLUX 3 vs Competing Video Models: Where It Stands Today

On BFL's own preference testing, FLUX 3 leads the field it was tested against: 93% preferred over Luma Ray 3.2, 77% over Runway Gen-4.5, 69% over Grok Imagine Video, and 60% over Kling v3 Pro. Those numbers come from BFL, so independent verification is worth waiting for once FLUX 3 sees broader use, but the gap over Luma in particular is large enough to be notable even accounting for house-benchmark bias.

The catch is access, not quality. Runway, Luma, and Kling are all available today through paid APIs or consumer apps. FLUX 3 Video is gated to approved early access partners with no public pricing. For teams that need synchronized-audio video generation in production this quarter, Wan 2.5 is the realistic self-hostable alternative; FLUX 3 is the one to benchmark against once it opens up further.

If you're self-hosting FLUX.2 or Wan 2.5 while FLUX 3 stays gated, an H100 gives you FP8 headroom for either model today.

Spheron H100 instances →