AI · Model-Specific Setups
Flux.1 dev — Setup and Parameters
A different architecture, different requirements — and why Flux.1 dev is the recommended choice for the RAY-L workflow.
Flux.1 dev isn't an SDXL successor in the classical sense — it's a different architecture with different strengths and different requirements. Anyone who knows the SDXL workflow from 2.2.4 and 2.3.1 will recognize the differences in the Flux graph from 2.2.2. This article covers the setup decisions that were left open there.
Encoder decision: fp16 or fp8 for T5XXL
The DualCLIPLoader loads two encoders: CLIP-L and T5XXL. CLIP-L is small at ~250 MB — the decision there is uncritical. T5XXL is the weight that matters.
t5xxl_fp16.safetensors — full precision, ~10 GB. Maximum quality, maximum VRAM demand. Anyone with a Nvidia RTX 4090 or comparable hardware with 24 GB VRAM uses fp16.
t5xxl_fp8_e4m3fn.safetensors — half the file size, ~5 GB. The quality loss compared to fp16 is measurable in controlled tests but barely noticeable in practice for most use cases. For cards with 12–16 GB VRAM, fp8 is the sensible compromise.
On Apple Silicon there's a particular consideration: fp8 inference isn't natively supported by the MPS backend. Anyone wanting to use fp8 on Apple Silicon needs the patch patch_mps_fp8_SM.py — a custom solution that works stably, but is a manual step. Anyone who doesn't want to set up the patch uses fp16 — on a Mac Studio with 64 GB Unified Memory, the memory demand is no issue.
DualCLIPLoader — a detail that matters
The DualCLIPLoader has a third parameter besides the two encoder files: the type. By default sdxl is preselected. For Flux it must be changed to flux.
This is a small setting with significant impact — the wrong type produces poor results that can't be fixed by optimizing the prompt. In the JSON from 2.2.2, flux is already set correctly. Anyone adding the node manually must change this explicitly.
guidance in CLIPTextEncodeFlux
The CLIPTextEncodeFlux node has a third value besides the two text fields: guidance. This isn't CFG in the classical sense — it's an internal scaling factor that determines how strongly the model follows the combined conditioning from both encoders.
3.5–4.0 — for medium-length, precise prompts. This is the standard case.
1.0–2.0 — for very long prompts or when more creative latitude is desired.
This value is independent of cfg in the sampler. The sampler CFG stays at 1 for Flux.1 dev always — as explained in 2.2.4.
Sampler parameters for Flux.1 dev
Flux uses SamplerCustomAdvanced instead of the classic KSampler. The parameters are distributed across several nodes:
KSamplerSelect: euler
BasicScheduler: simple, 20–25 steps
Why simple and not karras? With Flux, the noise curve is already influenced by the guidance-distilled architecture. simple — a linear decrease — works most reliably with this architecture. karras brings no measurable advantage with Flux.
20–25 steps are sufficient for Flux — the architecture is more efficient than SDXL and converges faster. More steps don't bring further quality improvement beyond a certain point.
RandomNoise: Same seed logic as the SDXL KSampler — randomize for exploring, fixed when a good starting point has been found.
Resolution
Flux.1 dev was trained on various resolutions and is more flexible than SDXL. 1024×1024 is a good starting point, but 1024×768, 1280×720, or 768×1024 also work reliably. The 64-pixel increment rule applies here too.
When Flux, when SDXL
Flux.1 dev is the right choice when:
Prompt precision matters — complex spatial descriptions, multiple materials with explicit assignments, detailed lighting situations. T5XXL understands sentence structure; CLIP doesn't.
The hardware allows it — 12 GB VRAM or more for fp8, 24 GB for fp16. On weaker hardware, Flux becomes slow or unstable.
The RAY-L workflow is in focus — both models fully support ControlNet Canny. Flux.1 dev is the recommended choice because T5XXL's prompt precision complements ControlNet's geometric control particularly well. On weaker hardware or when fast iteration matters, SDXL with ControlNet Canny is the sensible alternative.
SDXL remains the right choice for fast iteration, resource-conscious hardware, and when a specific LoRA ecosystem is needed that doesn't yet exist for Flux.