Flux.1 dev — Setup and Parameters

Flux.1 dev and Krea dev are among the best you can run locally — but that statement carries a silent condition: enough memory. When memory is plentiful, everything is simple: load one file, one loader, done. When it gets tight, a chain of decisions begins, and this page lays that chain out.

And it is about more than image quality. Too little memory costs not just detail — it costs usability. If a model doesn't fit in memory, the system pages to disk, and a one-and-a-half-minute image turns into a ten-minute one. The real problem isn't the softer result, it's the render time that brings work to a halt. So the memory question first decides whether the workflow is usable at all, and only then the last increment of quality.

Two weights dominate the budget; everything else is incidental. The largest is the transformer — the actual image model with roughly twelve billion parameters. In the standard Flux graph it is not loaded via the CheckpointLoaderSimple, but via the Load Diffusion Model node (internally UNETLoader) — the file sits in ComfyUI/models/unet/. The name "UNET" is historical: Flux is technically not a U-Net but a Diffusion Transformer (DiT); the node keeps the old name. In full precision this transformer alone takes about 24 GB.

The second large weight is the text encoder T5XXL, which translates the prompt into the model's language; in full precision about 10 GB. CLIP-L (~250 MB) and the VAE (~335 MB) don't register next to those — they stay as they are.

Everything that follows is measured against that sum — roughly 34 GB in full precision. If you have it, you're done. If you don't, you have to shrink one or both weights, and how you do that depends on the next distinction.

Anyone trying to get Flux running on tight memory quickly runs into a handful of terms — fp16, fp8, scaled, GGUF — and into advice that sounds contradictory. The reason for the confusion is almost always that two different questions get mixed up. Separate them, and the rest sorts itself out.

The first question concerns the file: in what precision are the weights stored? Full precision (fp16/bf16), halved (fp8), or packed into finer steps (GGUF, the Q-variants). That is a property of the downloaded file and decides how much memory it takes and how much quality it carries.

The second question concerns the hardware: can the GPU actually compute a given format directly? This is the point that leads most Mac guides astray — because it turns out opposite depending on the platform. On Nvidia cards fp8 is a real compute format: the Tensor Cores process it natively, so you gain memory and speed. On Apple Silicon, by contrast, there are no compute units for fp8 — the MPS backend simply has no fp8 kernels. An fp8 model can't just be loaded there; usually the run aborts with an error, because MPS can't even convert an fp8 number. Whatever fp8 capabilities ComfyUI prints to the log at startup apply to the Nvidia path and have no effect on the Mac.

On top of that comes a second hardware difference that sharpens the consequences. An Nvidia card has its own, fixed graphics memory (VRAM); if a model doesn't fit, it fails outright. Apple Silicon, by contrast, shares a single memory pool between system and GPU (Unified Memory). That has an advantage and a catch: there is no hard VRAM limit, the GPU can use the whole pool — but when it gets tight, nothing crashes; instead macOS pages parts out to the SSD. The model keeps running, just agonizingly slowly, because computing turns into reading and writing on disk. This silent paging — not a crash — is the real adversary on the Mac, and the reason the memory question decides usability here, not just quality.

Both large weights — transformer and T5 — come in the same three levels. Which one is right is decided by the distinction above, not by taste.

The formats share two loaders, and the boundary doesn't run where you'd expect. Full precision and fp8 both run through Load Diffusion Model. For fp16, weight_dtype stays on default; on Nvidia you produce fp8 by loading the same full file and setting weight_dtype to fp8_e4m3fn — ComfyUI then casts at load time and halves the memory. No separate fp8 transformer download is needed for that. Only GGUF needs the Unet Loader (GGUF), because .gguf is its own file format that the standard node won't open. (The T5 encoder is a different case: there a ready-made _scaled fp8 file exists, see Downloads.) Two formats, one loader; one format, its own.

That gives a short mapping. The memory figures are guide values for the model weights, not measured limits — the operating system and the intermediate data during computation come on top and draw on the same pool.

The middle row is the real work on tight Mac memory: at 24 GB a high quant often fits (Q6/Q8 for the transformer, plus a smaller T5 quant); at 16 GB you have to go lower (Q4 or Q3) until the weights plus intermediate data drop below the threshold at which the system starts paging. If the choice falls on Nvidia with very little VRAM, GGUF is a viable path there too — but fp8 remains the first choice, because it computes there and doesn't just save memory.

One last point against a tempting misconception. The fact that a small GGUF quant runs noticeably faster on the Mac does not come from it computing faster — the weights are unpacked back to bf16 for computation anyway, as with every format. The gain lies elsewhere: once the model fits in memory, the system stops paging to disk, and disk-bound waiting turns back into GPU computation. That alone can make the difference between ten minutes and two or three minutes per image — not the kind of math, but the avoided detour over the SSD.

Whether you're in that state you can read straight off the Activity Monitor: high memory pressure and a rising swap value are the signal that the quant needs to go one step smaller. On the Mac, fitting in memory is the speed.

The specific files and their sources. The transformer is model-specific; the encoders and VAE are identical for Flux.1 dev and Krea dev and are downloaded only once. The "Nvidia only" marker is a reminder that the fp8 rows drop out on Apple Silicon — there it's fp16 or GGUF.

Transformer — Flux.1 dev

Transformer file → ComfyUI/models/unet/. For GGUF, pick the level by the hardware ladder. fp8 on Nvidia needs no separate download — load the full fp16 file and set weight_dtype to fp8_e4m3fn in the Load Diffusion Model node.

Encoders and VAE — identical for dev and Krea

T5XXL and CLIP-L → ComfyUI/models/clip/ (in newer ComfyUI versions also text_encoders/); VAE → ComfyUI/models/vae/.

A licensing note on the distinction: the transformer files, in every format, fall under the FLUX Non-Commercial License from Black Forest Labs, because the quantized variants are derivatives of the original weights too. The encoders, by contrast — CLIP-L and the T5 variants from comfyanonymous and city96 — are under Apache 2.0. More on the license in the section below.

The DualCLIPLoader loads the two encoders — CLIP-L and T5XXL — and, besides the two files, has a third parameter: the type. By default sdxl is preselected. For Flux it must be changed to flux.

It's a small setting with a large effect — the wrong type produces poor results that no amount of prompt tuning will fix. In the JSON from 2.2.2, flux is already set correctly. Anyone adding the node manually has to change it explicitly.

The CLIPTextEncodeFlux node has, besides the two text fields, a third value: guidance. This is not CFG in the classic sense — it's an internal scaling factor that determines how strongly the model follows the combined conditioning of the two encoders. The same value can also be set in ComfyUI through a separate FluxGuidance node instead of in the CLIPTextEncodeFlux field — it's the same guidance, just at a different place in the graph.

This value is independent of the cfg in the sampler. The sampler CFG for Flux.1 dev always stays at 1 — as explained in 2.2.4.

A negative prompt doesn't exist in the standard Flux graph: the BasicGuider takes only the positive conditioning, and the distilled guidance knows no negative conditioning. The negative field familiar from the SDXL KSampler is therefore absent here.

Flux uses the SamplerCustomAdvanced instead of the classic KSampler. The parameters are spread across several nodes:

Flux.1 dev is far more flexible on resolution than SDXL. What matters is not the aspect ratio but the total area: stay near one megapixel — about 1,048,576 pixels — and the model works in the range it was trained on. Go higher and the tendency toward repetition in the image grows: doubled windows, mirrored details.

The second condition: both edge lengths must be divisible by 16. SDXL requires 64 — which is why SDXL and Flux resolutions drift slightly apart at the same aspect ratio.

For portrait, flip the numbers — 832 × 1248, 768 × 1360. Unlike SDXL, Flux hits the ratios cleanly: 1152 × 864 is true 4:3, while the corresponding SDXL bucket 1152 × 896 is strictly 9:7.

Any other ratio you work out yourself:

width  = round( 1024 · √(W/H) / 16 ) · 16
height = round( 1024 · √(H/W) / 16 ) · 16

First the ideal edge length from the area and the square root of the ratio, then round to the nearest multiple of 16. This rounding is also why the pixel sum rarely lands exactly on 1,048,576 — the deviation of a few percent is harmless.

Flux.1 Krea dev is the aesthetic sibling of Flux.1 dev: the same guidance-distilled raw base (flux-dev-raw), only with a pure aesthetic post-training on top. For this setup that means an identical pipeline. Same encoders (CLIP-L + T5XXL, DualCLIPLoader on flux), same guidance range, same sampler parameters (euler + simple, 20–25 steps — for Krea dev rather 28–35, see 2.3.3), same ControlNet Canny, same memory and quantization logic from the sections above. Everything on this page carries over unchanged — you only swap the model file in the Load Diffusion Model or Unet Loader (GGUF) node.

The only difference is the look: Krea dev produces a markedly photographic, "filmic" character instead of the smooth AI middle — for a photographic look currently my first choice. Details in the setup article for 2.3.3 — Flux.1 Krea dev.

Flux.1 dev is under the FLUX Non-Commercial License from Black Forest Labs (version 2.0; until November 2025 the "FLUX [dev] Non-Commercial License", unchanged in substance).

Two things must be kept apart. The generated images belong to the user — Black Forest Labs claims no ownership of the outputs; they may be used and sold for any purpose, with the single exception that they may not serve to train a competing model. Running the model is the separate question: the weights are licensed for non-commercial, non-production use; commercial or production operation requires a separate license from Black Forest Labs. That the images belong to the user does not settle this second question.

Independent of the license, AI-generated images are to be labeled as such where applicable by law.

The license text has changed across versions; what governs is the current version on bfl.ai. More on this in 2.1.4 — Understanding license models. Guidance, not legal advice.