Flux.1: The New King of Open Source Image Generation

Jan 1, 2026 • 22 min read

When SDXL launched, it was impressive but flawed: hands were mangled, text was pixel soup, and prompt adherence required elaborate negative prompts. Flux.1, from Black Forest Labs (the original Stable Diffusion team), changes all of that. It's the first open-weight model that genuinely competes with — and often beats — Midjourney v6 on prompt adherence, text rendering, and photorealism. The catch: it's a 12 billion parameter model with a 4.7B parameter text encoder, which demands careful engineering to run on consumer hardware.

1. Architecture: Why Flux Is Different

The T5-XXL difference: Most image models use CLIP for text encoding, which was designed for image-text matching, not language understanding. T5-XXL is a 4.7 billion parameter language model — Flux essentially has an LLM reading your prompt. This is why it understands complex, multi-clause prompts, relationships between objects, and explicit spatial instructions that CLIP-based models hallucinate over.

2. Model Variants and When to Use Each

3. GGUF Quantization for Consumer GPUs

# The base FP16 model needs 24GB VRAM — more than most consumer cards
# GGUF quantization (originally from llama.cpp) now works for image models

# Quantization levels and VRAM requirements:
# Q8_0: 16GB  — nearly identical to FP16 (recommended for 24GB+ cards)
# Q6_K: 12GB  — minimal quality loss (good for 16GB cards)
# Q5_K_S: 10GB — slight quality reduction, excellent for 12GB cards
# Q4_K_S: 8GB  — noticeable reduction but still impressive (4070/3060)
# Q3_K_S: 6GB  — significant reduction, use only if necessary

# Download pre-quantized GGUF models (from Kijai's HuggingFace repo):
# https://huggingface.co/Kijai/flux-fp8/tree/main

# For ComfyUI: Install ComfyUI-GGUF extension
# git clone https://github.com/city96/ComfyUI-GGUF
# cd ComfyUI/custom_nodes/ComfyUI-GGUF && pip install -r requirements.txt

# Required model files (download separately):
# - flux1-dev-Q4_K_S.gguf (8GB) — Main Flux Dev transformer
# - t5xxl_fp8_e4m3fn.safetensors (4.9GB) — T5 text encoder
# - clip_l.safetensors (246MB) — CLIP text encoder
# - ae.safetensors (335MB) — Flux VAE (for decoding latents to pixels)

# Place files in ComfyUI directories:
# models/unet/   ← Put flux1-dev-Q4_K_S.gguf here
# models/clip/   ← Put t5xxl and clip_l here
# models/vae/    ← Put ae.safetensors here

# Python diffusers generation (for programmatic use):
from diffusers import FluxPipeline
import torch

# Load with auto quantization (requires optimum-quanto or bitsandbytes)
pipe = FluxPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-schnell",  # Use schnell for local (Apache 2.0)
    torch_dtype=torch.bfloat16,
).to("cuda")

# Enable memory optimizations
pipe.enable_model_cpu_offload()  # Offloads model parts to CPU when not needed
pipe.enable_vae_slicing()         # Decode VAE in slices — reduces peak VRAM

image = pipe(
    prompt="A golden retriever puppy playing in autumn leaves, warm afternoon light, professional pet photography, bokeh background, 85mm lens",
    guidance_scale=0.0,    # IMPORTANT: Schnell uses cfg=0 (no guidance needed due to distillation)
    num_inference_steps=4, # Schnell only needs 4 steps
    max_sequence_length=256,
    generator=torch.Generator("cpu").manual_seed(42),
    height=1024,
    width=1024,
).images[0]

image.save("golden_retriever.png")

4. ComfyUI Workflow for Flux with GGUF

// ComfyUI Node Graph for Flux.1 Dev (GGUF quantized)
// Connect nodes in this order:

// ─── Text Encoding Branch ───────────────────────────────────────
// [DualCLIPLoader]
//   clip_name1: "t5xxl_fp8_e4m3fn.safetensors"   // T5-XXL text encoder
//   clip_name2: "clip_l.safetensors"               // CLIP-L text encoder
//   type: "flux"                                   // Must specify Flux mode!
//   └──> [CLIP]
//
// [CLIPTextEncode (Positive)]
//   text: "Your detailed prompt here..."
//   └──> [CONDITIONING]
//
// [CLIPTextEncode (Negative)]  ← Flux mostly ignores negative prompts
//   text: ""                   ← Leave empty or minimal
//   └──> [CONDITIONING]

// ─── Model Loading Branch ───────────────────────────────────────
// [UnetLoaderGGUF] ← From ComfyUI-GGUF extension
//   unet_name: "flux1-dev-Q4_K_S.gguf"
//   └──> [MODEL]

// ─── Latent + Sampling ──────────────────────────────────────────
// [EmptyLatentImage]
//   width: 1024, height: 1024, batch_size: 1
//   └──> [LATENT]
//
// [KSampler]
//   model: [MODEL]                   // From UnetLoaderGGUF
//   positive: [CONDITIONING positive]
//   negative: [CONDITIONING negative]
//   latent_image: [LATENT]
//   seed: 42
//   steps: 20                        // Dev: 20-30, Schnell: 4
//   cfg: 1.0                         // CRITICAL: Flux uses 1.0 not 7.0!
//   sampler_name: "euler"
//   scheduler: "simple"              // "simple" scheduler works best for Flux
//   └──> [LATENT]

// ─── Decoding ────────────────────────────────────────────────────
// [VAELoader]
//   vae_name: "ae.safetensors"       // Flux-specific VAE
//   └──> [VAE]
//
// [VAEDecode]
//   samples: [LATENT from KSampler]
//   vae: [VAE]
//   └──> [IMAGE]
//
// [SaveImage]
//   images: [IMAGE]

Frequently Asked Questions

Why does CFG scale need to be 1.0 for Flux? My outputs look washed out at 7.0.

Flux uses guidance distillation (a technique from consistency models) that bakes classifier-free guidance directly into the model weights during training. When CFG is 1.0, guidance is effectively disabled — but the model was trained to produce well-guided outputs at this setting. Using CFG 7.0 (the typical SDXL value) on Flux causes double-guidance, resulting in oversaturated, overexposed, artifact-heavy images. If you want stronger prompt adherence (higher effective guidance), use Flux Dev's guidance parameter in the FluxPipeline call: guidance_scale=3.5 in diffusers directly controls the internal guidance scale without double-applying it.

Can I train LoRAs on Flux.1?

Yes — Flux LoRA training is well-supported through Kohya's ss trainer and Ostris's ai-toolkit. Use flux1-dev as the base (not schnell — distilled models produce lower quality LoRAs). You need ~15-25 high-quality training images for a style or character LoRA. Key parameters: learning rate 1e-4 to 5e-4, batch size 1-2, 1000-3000 steps. Use T5 + CLIP both for text encoding during training. The resulting LoRA works on both Dev and Schnell at inference time. Resolution: train at 1024×1024 if VRAM permits. Flux LoRAs typically produce stronger concept adherence than equivalent SD 1.5 LoRAs due to the richer T5 text understanding.

Conclusion

Flux.1 represents a genuine generational leap in open-weight image generation. Rectified Flow Transformers enable high-quality results in 20 steps (or 4 with Schnell). T5-XXL text encoding provides LLM-quality prompt understanding. The engineering challenge is managing the 24GB VRAM requirement — GGUF quantization brings this to 8-16GB without meaningful quality loss, making it accessible on RTX 3090, 4090, and high-end laptop GPUs. For commercial applications requiring maximum quality, Flux Pro via API is the obvious choice. For local generation, research, and LoRA training, Flux Dev with Q4_K_S or Q6_K quantization is the current gold standard in open-weight image models.