Local Image Generation (SDXL, Flux): Common Pitfalls and Fixes

The #1 mistake in 2026 for people moving from SD to Flux in local image generation is treating Flux like SDXL. If your output is blown-out (oversaturated), blurry, and has weird hands, it's almost never the model - it's the settings: Flux is a distilled model with guidance baked in, so you must set CFG to 1.0 and it ignores negative prompts. High CFG and negative prompts - SDXL habits - wreck the result. Another common misconception: SDXL doesn't need quantization - it already fits on consumer GPUs at FP16 (only Flux benefits). This guide walks the image-gen-specific traps as symptom -> cause -> fix, with numbers.

In plain terms: SDXL and Flux are two cars you drive differently. SDXL wants you to floor the accelerator (CFG) and spell out "don't do this" (negatives), but Flux already has self-driving on (built-in guidance), so flooring the accelerator (raising CFG) just spins the tires (oversaturation). Bring SDXL driving habits to Flux and you crash.

Why is your Flux output blown-out and blurry?#

Because you kept SDXL's defaults - Flux is a different model. Fix three things. (1) Set CFG (guidance) to 1.0-1.5 - Flux dev/schnell are distilled with guidance baked in, so high CFG only produces oversaturated, blown-out images. (2) Leave the negative prompt empty - Flux ignores it. (3) 1024x1024 is the sweet-spot resolution - generate below the trained resolution and it turns mushy (up to 4MP supported). For the sampler, euler + simple is the safe baseline, and steps are 20-30 for dev, 4 for schnell/Klein 4B. Note that hands are a Flux strength, not a weakness - bad hands are a symptom of over-quantization, wrong CFG, or too-low resolution, not a model flaw.

How do you match quantization and the text encoder?#

Quantize only Flux, and avoid double-quantization and the wrong encoder. SDXL/SD1.5 already fit at FP16, so don't quantize them (no benefit). Flux is different: FP16 ~33GB (exceeds every consumer GPU) -> FP8 ~13GB (4070 Ti Super/4080) -> GGUF Q4 ~7GB (4060 8GB). GGUF's granularity (Q4/Q5/Q6/Q8) beats FP8 on 8GB cards, with Q8 near full precision and Q5 the balance. Absolute no: don't load the FP8 checkpoint (flux1-dev-fp8) with the NF4 option - you waste 30s de-quantizing plus 60s re-quantizing and lose quality by quantizing twice. The text encoder (T5-XXL) is a trap too: a full-precision T5 on 8GB crashes or outputs garbage, so you need t5xxl_fp8 (t5xxl_fp16 is higher quality if you have room). And GGUF must go in models/unet/ and load via the 'Unet Loader (GGUF)' node - pointing the standard Load Diffusion Model node at it is a common failure. After installing the extension, don't forget to restart ComfyUI (skipping it is the cause of most "it doesn't work").

What if VRAM overflows or a generation takes 10 minutes?#

Usually parallel loading, the VAE decode, or accidental CPU offload. Total VRAM is not the checkpoint size but the sum of weights + VAE + text encoder + working memory. (1) Load models sequentially - SDXL+ControlNet+IP-Adapter loaded together is ~14GB, but load/unload as needed and peak drops to ~8GB. (2) The VAE decode is the peak-memory moment - enable tiled VAE decoding or offload VAE to CPU (--cpu-vae, +1-2GB), and decode the final image singly. A two-pass approach (low-res then upscale) is the difference between creating and crashing on 12GB. (3) 10+ minutes per image means suspect CPU offload - watch GPU utilization in nvidia-smi/Task Manager; near zero means it's on the CPU. Use --lowvram (20-30% slower) instead of --novram, and enable attention optimization (+1-2GB). On Windows, avoid PyTorch 2.4 - use 2.3.1/nightly.

So what's a safe local image-gen setup?#

The key is accept "Flux is not SDXL" first, then match the format to your hardware.

• Flux settings: CFG 1.0, empty negative, 1024 resolution, euler/simple, 20-30 steps for dev. Blown-out output and bad hands are settings issues, not model issues.
• Quantization: leave SDXL as FP16, quantize only Flux to FP8 (13GB) / GGUF Q5-Q8 (8GB). No double-quantization, use t5xxl fp8 (fp16 if room), and load GGUF via its dedicated node.
• OOM/speed: sequential loading + tiled VAE + CPU-offload flags. 10+ minutes signals a CPU fallback. A/B every setting on your own GPU and prompt, then lock it in.

Related reading: ComfyUI로 이미지·영상 만들기: 우리가 직접 굴리며 잰 운영 회고, ComfyUI란? 노드로 조립하는 이미지·영상 생성 파이프라인

Related reading: 로컬 이미지 생성(SDXL·Flux), 5분 시작 가이드, 로컬 이미지 생성 SDXL vs Flux, 직접 돌려본 속도·품질

Reference links

• Flux (Black Forest Labs)
• ComfyUI (local image-gen UI)
• ComfyUI-GGUF (city96, Flux GGUF loader)
• Stable Diffusion (Stability AI, SDXL)
• ComfyUI Flux official tutorial

Note: figures like VRAM (Flux 33/13/7GB, SDXL 8GB), steps (dev 20-30, schnell 4), CFG (1.0), sequential-load savings (14->8GB), and speed penalty (20-30%) are 2026 public and community-measured numbers that vary by GPU, resolution, workflow, and extensions (not permanent; many blog benchmarks). Nodes, flags, and optimal samplers change across model and ComfyUI versions (e.g., new models need new sampler nodes), and NF4 can be more precise than FP8, so verify on your own GPU. Image-gen practice moves fast, so this is reviewed quarterly.