AI · Model-Specific Setups
SDXL — Setup and Parameters
Juggernaut XL, external VAE, reliable parameters — and when SDXL is the better choice.
Why Juggernaut XL
SDXL isn't a single model file — it's an architecture on which hundreds of fine-tunes and checkpoints are built. Juggernaut XL is one of them, and the question of why this one in particular deserves a brief answer.
Juggernaut XL specializes in photorealistic output. The Stability AI base model produces good general results but tends toward an aesthetic that sits between photography and illustration — too indecisive for professional image production. Juggernaut XL was specifically trained for photographic quality: realistic skin tones, convincing material surfaces, natural lighting situations. For the use cases at the center of this site — interior, architecture, product, fashion — it's the right starting point.
Other SDXL checkpoints have other strengths: Realistic Vision for portrait photography, RealVisXL for exterior shots, DreamShaper XL for illustrative styles. The architecture is the same, the training is different. Anyone who understands Juggernaut XL can use any other SDXL checkpoint — the workflow structure stays identical, only the checkpoint file in CheckpointLoaderSimple changes.
The external VAE
In 2.2.1 — Stability Matrix we already noted: Juggernaut XL recommends an external VAE. Here's the reason.
The VAE embedded in Juggernaut XL was trained with fp16 weights — a precision format that produces a known artifact in certain color values: slight desaturation in dark tones, a subtle green cast in shadows. This isn't a flaw in the checkpoint itself, but a characteristic of the original SDXL VAE.
The sdxl-vae-fp16-fix addresses this. It's a separate VAE specifically calibrated for fp16 inference — colors stay neutral, shadows stay clean. The difference is barely visible in low-resolution previews but measurable on close inspection in final output.
In the workflow: add a VAELoader node, load sdxl-vae-fp16-fix.safetensors, replace the VAE output of the CheckpointLoaderSimple with the output of the VAELoader. The CheckpointLoaderSimple then only loads MODEL and CLIP — ignore its VAE output.
Parameters for Juggernaut XL
The values from 2.2.4 — Building a Workflow as a starting point, now with explanation:
cfg: 4–5
Juggernaut XL is heavily trained for photorealism — the model already knows what "realistic" means without needing strong guidance. CFG 4–5 gives the model enough room to produce natural results. Higher values — from 7 upward — start exaggerating contrast and hardening textures.
steps: 30–35 · sampler: dpmpp_2m · scheduler: karras
As explained in 2.2.4: at 30+ steps karras delivers its advantage, dpmpp_2m uses available compute efficiently. For quick tests or weaker hardware: 20–25 steps with euler + exponential — less detail, but a working result.
Resolution: 1024×1024
SDXL was trained at 1024×1024 pixels — equivalent to a total area of roughly 1,048,576 pixels. Other aspect ratios work well as long as the total pixel count stays approximately the same. Reliable values: 1365×768 for landscape (approx. 16:9) and 832×1216 for portrait (approx. 2:3). Always choose resolutions in steps of 64 — the internal latent structure requires it.
When SDXL, when Flux
A question that comes up at this point: if Flux.1 dev delivers better results in many areas — why still use SDXL?
Three reasons that count in practice:
Speed
Flux.1 dev is significantly larger than Juggernaut XL at ~23 GB vs ~7 GB. On a Nvidia RTX 3080 with 10 GB VRAM, Flux only runs with compromises — quantization, slower inference, higher RAM demand. SDXL runs smoothly on the same hardware. Anyone testing many variants is faster with SDXL.
LoRA ecosystem
SDXL has a significantly larger and more mature LoRA offering than Flux — for specific styles, products, people, materials. Anyone dependent on existing LoRAs finds more options for SDXL.
Negative prompts
With SDXL, the negative prompt works as an active steering instrument. With Flux it doesn't. For some workflows — especially when certain artifacts or styles need to be reliably excluded — that's a practical advantage.
Flux.1 dev is superior in prompt precision and image quality, especially for complex spatial descriptions. SDXL is faster, less resource-intensive, and has the deeper LoRA ecosystem. Both have their place.