FLUX.1 [dev] on an RTX 5090: GPU requirements and ComfyUI setup

Yes, FLUX.1 [dev] can run on a single RTX 5090.

The more useful question is how you should run it.

FLUX.1 [dev] has 12 billion parameters, and its main full-precision model file is about 23.8GB. NVIDIA says the ordinary FP16 pipeline requires more than 23GB of VRAM. That already puts a 24GB GPU close to its limit before the rest of the image-generation pipeline gets comfortable.

An RTX 5090 gives you 32GB.

That is enough to make FLUX.1 [dev] a practical single-GPU workload, but I would still avoid the most memory-hungry configuration simply because it technically fits.

For a first ComfyUI deployment on one RTX 5090, there are two sensible paths:

For most people using a 32GB RTX 5090, I would begin with the FP8 checkpoint.

‍

‍

Get the workflow working. Generate representative images. Then move to the full model if you can show that the difference matters.

If you need the general ComfyUI environment first, start with our ComfyUI cloud GPU setup guide. This article assumes ComfyUI itself is already running.

What is FLUX.1 [dev]?

FLUX.1 [dev] is a 12-billion-parameter text-to-image model from Black Forest Labs.

Black Forest Labs describes it as a rectified-flow transformer trained with guidance distillation. In practical terms, it takes natural-language descriptions and generates images while handling relatively detailed prompts, composition, style, objects, and text relationships.

The model is available through the official FLUX.1 [dev] repository on Hugging Face.

Its size is one reason it represented such a jump in hardware requirements compared with older Stable Diffusion models.

A 12B image model is not something you can size by looking only at a familiar “8GB minimum GPU” recommendation from an old Stable Diffusion tutorial.

The model weights themselves are large, and FLUX also relies on separate text encoders and a VAE in its standard ComfyUI pipeline.

FLUX.1 [dev] is open-weight, with an important license restriction

Before downloading anything, understand the license.

FLUX.1 [dev] is distributed under the FLUX.1 [dev] Non-Commercial License.

Under the current license, the model itself is made available for non-commercial and non-production use. Black Forest Labs separately states that outputs generated in accordance with the license may be used for commercial purposes, subject to the license terms.

Those are two different things.

Generating an image during an allowed use and later using that output commercially does not mean the default license lets you operate the FLUX.1 [dev] model as part of a commercial production service.

If you want to use the model itself commercially or in production, check the current Black Forest Labs license and obtain the appropriate rights where required.

This distinction is easy to miss because “open weights” gets flattened into “do whatever you want with it.”

That is not what this license says.

FLUX.1 [dev] or FLUX.1 [schnell]?

Black Forest Labs also publishes FLUX.1 [schnell].

Both are 12B FLUX models, but they serve different purposes.

FLUX.1 [schnell] is not merely a low-quality checkbox for people without enough GPU.

‍

‍

Black Forest Labs distilled it specifically for very low-step generation and released it under Apache 2.0.

If you are building a commercial self-hosted product and do not want to negotiate a FLUX.1 [dev] license, that can matter more than a small quality difference.

The correct model is partly a licensing and deployment decision.

How much VRAM does FLUX.1 [dev] need?

There is no honest single number because the FLUX pipeline contains several large components.

The main flux1-dev.safetensors file alone is about 23.8GB.

The standard ComfyUI full-model workflow also loads:

• FLUX.1 [dev]
• T5-XXL
• CLIP-L
• the FLUX VAE

ComfyUI’s official FLUX documentation makes an unusually useful recommendation here: it recommends the FP16 T5-XXL encoder when you have more than 32GB of VRAM.

An RTX 5090 has exactly 32GB.

That tells us something.

On one 5090, I would not start with the largest precision available for every component simply because each file exists.

ComfyUI provides:

t5xxl_fp8_e4m3fn.safetensors

as the lower-memory alternative to:

t5xxl_fp16.safetensors

and also provides a simplified:

flux1-dev-fp8.safetensors

checkpoint workflow.

That is the sensible 32GB path.

Why the model file size is not the VRAM requirement

A 23.8GB checkpoint does not mean:

FLUX needs 23.8GB VRAM

It means the checkpoint file occupies roughly that much storage.

During inference, GPU memory is also needed for:

• text encoding
• model activations
• latent tensors
• VAE operations
• sampling
• attention
• temporary CUDA allocations
• the ComfyUI runtime
• extra models such as LoRAs or ControlNet

Resolution matters too.

Generating at 1024 × 1024 and generating a much larger image do not have identical working-memory requirements.

This is the same mistake people make with language models: model weights are the beginning of the VRAM budget, not the entire budget.

Our RTX 5090 VRAM guide covers that distinction across AI workloads.

Is 32GB enough for FLUX.1 [dev]?

Yes.

It is enough to run FLUX.1 [dev] comfortably with a sensible precision configuration.

The point of 32GB is not that you should fill 31.9GB before generating the first image.

The spare memory gives you room for the pipeline.

That matters when you start adding:

• larger resolutions
• LoRAs
• ControlNet
• inpainting or fill models
• upscalers
• reference-image tooling
• other ComfyUI nodes

A GPU with some free memory is a more useful creative workstation than a GPU whose memory is consumed almost entirely by the base model.

Can FLUX.1 [dev] run on 24GB VRAM?

Yes, depending on the precision and workflow.

NVIDIA reports that the ordinary FP16 version requires more than 23GB, which makes 24GB a tight target for the full pipeline.

ComfyUI’s FP8 routes exist precisely because reducing memory use makes the model practical on more consumer hardware.

On a 24GB GPU, I would use an FP8 configuration rather than treating the final few hundred megabytes as a challenge.

On a 32GB RTX 5090, you have more choice.

Why FP8 makes sense on one RTX 5090

FP8 represents values using 8-bit floating-point formats instead of 16-bit formats.

That reduces the memory occupied by affected model components and can also accelerate compatible operations on modern NVIDIA hardware.

ComfyUI offers a ready-made:

flux1-dev-fp8.safetensors

checkpoint for its simplified FLUX workflow.

Its documentation is clear about the tradeoff: the FP8 checkpoint needs less VRAM and only requires one model checkpoint, while image quality can be somewhat lower than the full version.

That is exactly the kind of tradeoff you should evaluate rather than argue about abstractly.

Run the same prompts.

Use the same seeds where possible.

Compare:

• composition
• prompt adherence
• fine detail
• text rendering
• faces and hands where relevant
• generation time
• VRAM
• failure rate at higher resolutions

Then decide whether the full model earns its extra memory.

What about FP4 on the RTX 5090?

Blackwell introduces another option.

The RTX 5090 has native FP4 Tensor Core support, and NVIDIA currently supports FLUX.1 [dev] on the RTX 5090 in both FP4 and FP8 through its optimized visual generative AI stack.

NVIDIA has also published substantially higher FLUX.1 [dev] throughput for FP4 on Blackwell compared with higher-precision paths.

That does not mean you should take the official ComfyUI FP8 checkpoint, rename it FP4, and assume the GPU will sort things out.

Precision support depends on:

• checkpoint format
• quantization method
• runtime
• kernels
• framework support

The native ComfyUI workflow we are using here has a well-documented FP8 path.

Use that path for this tutorial.

If you experiment with FP4 later, use a checkpoint and runtime explicitly designed for it.

Hardware capability alone does not create a valid model format.

Step 1: start from a working ComfyUI installation

If you already followed our ComfyUI cloud GPU guide, you should have:

• one RTX 5090 virtual machine
• ComfyUI installed
• a working Python environment
• port 8188 forwarded over SSH
• ComfyUI opening in your local browser

If not, do that first.

For this model there is little value in repeating generic Linux setup while adding another source of errors.

Once ComfyUI opens correctly, move on to FLUX.

Step 2: accept the FLUX.1 [dev] license

Go to the official Black Forest Labs FLUX.1 [dev] model page.

The repository is gated.

You need to sign in and accept the model terms before downloading the full model files.

Do this before launching a long-running GPU session if you do not already have access.

Waiting for repository access while a GPU meter runs is an avoidable way to spend money.

Step 3: choose the FP8 or full workflow

ComfyUI publishes an official FLUX.1 text-to-image workflow covering:

• FLUX.1 [dev]
• FLUX.1 [schnell]
• full model weights
• simplified FP8 checkpoints

For a 32GB RTX 5090, I recommend starting with:

FLUX.1 [dev] FP8 checkpoint

The setup is simpler and leaves more working memory.

If you specifically need the full model, skip ahead to the full-model section.

Step 4: install the FP8 checkpoint

For ComfyUI’s simplified FP8 workflow, download:

flux1-dev-fp8.safetensors

from the model link provided by the official ComfyUI FLUX workflow page.

Save it to:

ComfyUI/
└── models/
   └── checkpoints/
       └── flux1-dev-fp8.safetensors

Restart ComfyUI or refresh the model list if the checkpoint is not visible.

Then load the official FLUX.1 [dev] FP8 workflow.

You can do this using the workflow JSON or the workflow image supplied by ComfyUI.

If you are new to portable ComfyUI workflows, our ComfyUI cloud guide explains how the JSON graph and embedded image metadata work.

Step 5: check the Load Checkpoint node

In the FP8 workflow, find the:

Load Checkpoint

node.

Make sure it contains:

flux1-dev-fp8.safetensors

If the node is red or the model is missing from its dropdown, ComfyUI cannot find the file.

Check the directory before reinstalling anything.

Most “model not found” problems are file-placement problems.

Step 6: run a boring first prompt

For the first generation, resist the temptation to test everything FLUX can do.

Use something simple and diagnostic:

A small wooden cabin beside a mountain lake at sunrise,
soft morning fog over the water, natural light,
pine forest reflected in the lake, realistic photography

Use the resolution and generation settings already included in the official workflow.

Queue the prompt.

Your first objective is to confirm:

• the model loads
• the GPU is used
• no node is missing
• the image decodes correctly
• the workflow completes without running out of VRAM

Once that works, start experimenting.

A spectacular first prompt gives you no diagnostic advantage.

Step 7: monitor the RTX 5090

In another SSH terminal:

watch -n 1 nvidia-smi

Watch:

• GPU utilization
• allocated VRAM
• peak memory behavior during sampling
• whether memory returns after generation

This is useful when deciding whether you can increase:

• resolution
• batch size
• additional models
• workflow complexity

Do not judge GPU use only while ComfyUI is idle.

The interesting memory behavior occurs during the workflow.

What settings should you use for FLUX.1 [dev]?

The official Black Forest Labs examples use a guidance value around:

3.5

and 1024 × 1024 is a common reference resolution.

The exact number of inference steps varies between official examples. Black Forest Labs’ model-card example uses 50, while its own interactive demo has used 28.

That is a good reminder that there is no sacred FLUX step count.

For ComfyUI, start with the values in the official workflow.

Then change one variable at a time.

If 28 steps gives you the image you need, 50 steps are not automatically better because the number is larger.

More steps cost more GPU time.

FLUX prompts do not need to look like old Stable Diffusion prompts

FLUX.1 [dev] has strong natural-language prompt following.

You do not need to write:

masterpiece, best quality, ultra detailed,
8k, perfect, award winning, intricate,
professional, stunning

and hope the adjectives accumulate into quality.

Describe the image.

Useful prompt information includes:

• subject
• action
• environment
• camera position
• composition
• lighting
• materials
• colors
• visual style
• relationships between objects

For example:

Editorial photograph of a ceramic coffee cup on a dark oak desk.
The cup sits to the left of an open notebook with handwritten notes.
Late-afternoon sunlight enters from a window on the right,
casting long soft shadows across the desk.
Shot from slightly above with a 50mm lens,
natural colors and shallow depth of field.

That tells the model something about the scene.

“Beautiful, masterpiece, incredible” mostly tells it that you like beautiful things.

Do you need a negative prompt?

The standard official ComfyUI FLUX workflow does not rely on a negative prompt.

ComfyUI explicitly notes that FLUX’s prompt-following behavior means a negative prompt is not required for the basic workflow.

That changes the prompting habit for people coming from Stable Diffusion 1.5 or SDXL.

Instead of:

Negative:
bad hands, bad anatomy, blurry, ugly,
low quality, malformed, extra fingers

start by describing the desired image more precisely.

Negative-conditioning techniques can still exist in specialized workflows.

They should solve a visible problem rather than survive as ritual from an older model.

Running the full FLUX.1 [dev] model

If you want the full workflow instead of the simplified FP8 checkpoint, ComfyUI requires several files.

The official layout is:

ComfyUI/
└── models/
   ├── diffusion_models/
   │   └── flux1-dev.safetensors
   │
   ├── text_encoders/
   │   ├── clip_l.safetensors
   │   └── t5xxl_fp8_e4m3fn.safetensors
   │
   └── vae/
       └── ae.safetensors

On a GPU with more than 32GB of VRAM, ComfyUI recommends:

t5xxl_fp16.safetensors

for the T5 encoder.

On a 32GB RTX 5090, I would use:

t5xxl_fp8_e4m3fn.safetensors

first.

Again, 32GB of VRAM is useful because you have room to work.

There is no prize for making every component the largest precision that fits individually.

What do the separate FLUX files do?

The full workflow exposes the pipeline more clearly than the simplified checkpoint.

flux1-dev.safetensors

This contains the main FLUX.1 [dev] diffusion/flow transformer.

It does most of the heavy image-generation work and is the largest component.

t5xxl_*.safetensors

T5-XXL is one of the text encoders.

It helps turn the natural-language prompt into conditioning that the image model can use.

Its size is why reducing T5 precision can save a meaningful amount of memory.

clip_l.safetensors

FLUX also uses a CLIP-L text encoder.

The workflow combines information from its text-encoding components.

ae.safetensors

This is the autoencoder, or VAE.

It converts between the latent representation used during generation and the final image pixels you see.

Keeping these components separate makes the workflow more complex.

It also gives you more control.

Why ComfyUI suits FLUX particularly well

The full FLUX pipeline makes several model components explicit.

That maps naturally to ComfyUI.

You can see:

Text encoders
     ↓
Conditioning
     ↓
FLUX model
     ↓
Sampling
     ↓
VAE
     ↓
Image

When memory becomes a problem, you can reason about which component is consuming it.

When a model fails to load, you can see which loader is failing.

When you replace the T5 encoder with an FP8 version, you know exactly what changed.

This is where a node graph becomes more useful than a settings panel.

The workflow is a diagram of the inference pipeline.

Should you use the full model or FP8?

Start with the actual task.

Use the FP8 checkpoint when:

• you want the easiest setup
• one 32GB GPU is your target
• you want more VRAM headroom
• you are exploring prompts and workflows
• you have not demonstrated a quality problem with FP8

Use the full model when:

• image quality differences matter to your application
• you need control over individual pipeline components
• you are benchmarking precision
• you are developing LoRA or other advanced workflows
• you have enough memory for the rest of the pipeline

There is no virtue in higher precision by itself.

The output is the product.

Compare it.

What changes when you add LoRAs?

LoRAs add another model component to the workflow.

They are much smaller than the base FLUX checkpoint, but they still consume memory and can alter generation time.

More importantly, FLUX LoRAs are tied to the model family and workflow they were built for.

Do not assume an SDXL LoRA can be dropped into FLUX because both files end in:

.safetensors

The container format does not make the model architectures compatible.

If you plan to maintain several LoRA-heavy workflows, record:

• base model
• LoRA filename
• LoRA version
• weight/strength
• workflow JSON

That is enough to save you from the familiar problem of finding a good image six weeks later and having no idea how you generated it.

What changes at higher resolutions?

Higher resolution increases the amount of data processed during the workflow.

That can increase:

• VRAM
• sampling time
• VAE workload
• output size

Start at 1024 × 1024.

If the final deliverable needs more resolution, compare two approaches:

1. generate natively at a larger size
2. generate at a known-good size and upscale afterward

The second route can be cheaper and more stable, depending on the image.

Do not assume the largest width and height that fit in the interface produce the best result.

What about batch size?

A batch creates several images within one workflow execution.

That can improve throughput, but it also consumes more GPU memory.

For exploration, use:

batch size = 1

first.

Once the workflow is stable, increase it and watch VRAM.

If your goal is producing many independent images, several sequential jobs can sometimes be easier to manage than one enormous batch.

The right answer depends on the workflow.

FLUX.1 [dev] versus SDXL

SDXL still has advantages.

It has:

• a mature ecosystem
• enormous checkpoint variety
• many established LoRAs
• lower hardware requirements
• familiar tooling
• years of community workflows

FLUX.1 [dev] gives you a stronger base for some kinds of prompt following, scene composition, text handling, and modern high-quality generation.

That does not make every SDXL workflow obsolete.

If you already have an SDXL pipeline that produces exactly what a client or project needs, migrating it because FLUX has a larger parameter count is not progress.

Use the model that produces the result.

Our Stable Diffusion hardware guide covers the broader model and GPU landscape.

FLUX.1 [dev] versus newer FLUX models

The FLUX family has expanded since FLUX.1 [dev] was released.

There are now specialized and newer models for:

• image editing
• structure control
• reference-image workflows
• alternative aesthetics
• later FLUX generations

That does not remove the value of FLUX.1 [dev].

It remains a useful base model because:

• tooling is mature
• ComfyUI has native workflows
• LoRA support is extensive
• quantized checkpoints are widely available
• its hardware behavior is well understood

For infrastructure work, maturity is often useful.

“Newest” and “best deployment choice” are different questions.

How much does FLUX.1 [dev] cost on an RTX 5090?

Hivenet currently lists an RTX 5090 at €0.75 per GPU-hour, with per-second billing.

The basic runtime cost is:

Do not turn that into a cost-per-image number without measuring your workflow.

‍

‍

The cost of one image depends on:

• model precision
• resolution
• sampling steps
• batch size
• LoRAs and other nodes
• upscaling
• how much time the GPU sits idle between generations

A simple way to calculate your own GPU cost per image is:

GPU hourly rate
×
total generation runtime in hours
÷
number of usable images

Use usable images, not total images.

A workflow producing 100 images that you discard is not economically equivalent to one producing 20 images that solve the task.

Current rates are on the Hivenet pricing page.

Does one FLUX workflow need more than one RTX 5090?

For the configurations in this guide, no.

One 32GB RTX 5090 is a sensible FLUX.1 [dev] workstation.

Adding another GPU does not automatically make one normal ComfyUI graph use 64GB of pooled VRAM.

Multi-GPU infrastructure becomes useful when you have a parallel workload, for example several independent workers generating images at the same time.

For an individual interactive ComfyUI session, start with one GPU.

If one card is not enough, identify why before adding hardware.

Save the workflow, not just the output

Once you have a FLUX setup you like, save the ComfyUI workflow JSON.

Keep the workflow with notes about:

FLUX checkpoint
T5 encoder
VAE
LoRAs
resolution
custom nodes
important versions

That gives you something reproducible.

A folder of attractive PNG files is evidence that a workflow once existed.

A workflow JSON plus its model dependencies lets you run it again.

Our ComfyUI cloud guide goes deeper into treating workflows as portable, versioned artifacts.

What comes after FLUX.1 [dev]?

Once this environment works, you have much of the infrastructure needed for more specialized FLUX workflows.

ComfyUI has native examples for FLUX variants involving:

• image editing
• fill and outpainting
• depth guidance
• Canny guidance
• reference-image workflows

The graph gets more complicated.

The GPU problem remains recognizable: every added model or pipeline stage consumes memory and time.

The same habit still works.

Start from a known-good workflow, add one component, and measure.

FLUX.1 [dev] FAQ

What is FLUX.1 [dev]?

FLUX.1 [dev] is a 12-billion-parameter text-to-image rectified-flow transformer from Black Forest Labs. It is an open-weight model distributed under the FLUX.1 [dev] Non-Commercial License.

How much VRAM does FLUX.1 [dev] need?

The full FLUX.1 [dev] model file is about 23.8GB, and NVIDIA reports more than 23GB of VRAM for the ordinary FP16 pipeline. Actual memory use is higher once text encoders, VAE, activations, and the runtime are considered.

Can FLUX.1 [dev] run on an RTX 5090?

Yes. The RTX 5090 has 32GB of VRAM, enough for FLUX.1 [dev] with a suitable full or FP8 ComfyUI configuration.

Can FLUX.1 [dev] run on 24GB VRAM?

Yes with suitable lower-precision workflows, although the full FP16 configuration is tight because the model already needs more than 23GB before much working headroom remains.

Should I use FP8 for FLUX.1 [dev]?

FP8 is a good starting point on a 32GB GPU because it reduces memory use and leaves more space for the rest of the workflow. Compare image quality with the full model before deciding whether the additional precision matters.

Does FLUX.1 [dev] support FP4?

NVIDIA supports optimized FLUX.1 [dev] inference on RTX 5090 hardware using FP4 and FP8. Support depends on the model format and inference runtime. The standard ComfyUI workflow in this guide uses the documented FP8 route.

What resolution should I use with FLUX.1 [dev]?

1024 × 1024 is a sensible starting point and is also the default reference size in common official FLUX pipelines. Higher resolutions require more compute and can increase VRAM use.

How many steps does FLUX.1 [dev] need?

There is no universal number. Official Black Forest Labs examples use different step counts, including 28 in its interactive demo and 50 in the model-card Diffusers example. Start with the settings in your validated workflow and adjust from there.

What guidance should I use for FLUX.1 [dev]?

A guidance value around 3.5 appears in official Black Forest Labs and ComfyUI FLUX examples. Treat it as a starting point rather than a mandatory value.

Does FLUX.1 [dev] need negative prompts?

The standard ComfyUI FLUX text-to-image workflow does not require a negative prompt. Describe the desired image clearly before adding negative-conditioning techniques.

Is FLUX.1 [dev] free for commercial use?

The model itself is distributed under a non-commercial license for the default use granted by Black Forest Labs. The license separately permits commercial use of outputs under its stated conditions. Using the model itself commercially or in production may require separate licensing, so check the current license for your use case.

What is the difference between FLUX.1 [dev] and FLUX.1 [schnell]?

Both are 12B text-to-image models. FLUX.1 [dev] is the higher-quality development model and uses a non-commercial model license by default. FLUX.1 [schnell] is optimized for generation in 1–4 steps and is released under Apache 2.0.

Can ComfyUI run FLUX.1 [dev]?

Yes. ComfyUI has native FLUX.1 [dev] workflows for both the full model and a simplified FP8 checkpoint.

What files does full FLUX.1 [dev] need in ComfyUI?

The standard full workflow uses flux1-dev.safetensors, clip_l.safetensors, a T5-XXL encoder such as t5xxl_fp8_e4m3fn.safetensors, and ae.safetensors.

Should I use t5xxl_fp16 on an RTX 5090?

ComfyUI currently recommends the FP16 T5 encoder when VRAM is greater than 32GB. Since an RTX 5090 has 32GB, the FP8 T5 encoder is the more conservative starting point.

Is FLUX.1 [dev] better than SDXL?

That depends on the workflow. FLUX.1 [dev] can offer stronger prompt following and modern image-generation capability, while SDXL has a mature ecosystem and lighter hardware requirements. Test the models on the images you actually need.

‍