KI · Modellspezifische Setups
Flux.1 dev — Setup und Parameter
Eine andere Architektur, andere Anforderungen — und warum Flux.1 dev für den RAY-L-Workflow die empfohlene Wahl ist.
Flux.1 dev ist kein SDXL-Nachfolger im klassischen Sinne — es ist eine andere Architektur mit anderen Stärken und anderen Anforderungen. Wer den SDXL-Workflow aus 2.2.4 und 2.3.1 kennt, wird die Unterschiede im Flux-Graph aus 2.2.2 wiedererkennen. Dieser Artikel geht auf die Setup-Entscheidungen ein, die dort noch offen geblieben sind.
Encoder-Entscheidung: fp16 oder fp8 für T5XXL
Der DualCLIPLoader lädt zwei Encoder: CLIP-L und T5XXL. CLIP-L ist mit ~250 MB klein, die Entscheidung dort unkritisch. T5XXL ist das Gewicht das zählt.
t5xxl_fp16.safetensors — volle Präzision, ~10 GB. Maximale Qualität, maximaler VRAM-Bedarf. Wer eine Nvidia RTX 4090 oder vergleichbare Hardware mit 24 GB VRAM hat, nimmt fp16.
t5xxl_fp8_e4m3fn.safetensors — halbierte Dateigröße, ~5 GB. Der Qualitätsverlust gegenüber fp16 ist in kontrollierten Tests messbar aber in der Praxis für die meisten Anwendungsfälle kaum wahrnehmbar. Für Karten mit 12–16 GB VRAM ist fp8 der sinnvolle Kompromiss.
Auf Apple Silicon gilt eine Besonderheit: fp8-Inferenz wird vom MPS-Backend nicht nativ unterstützt. Wer fp8 auf Apple Silicon verwenden will, benötigt den Patch patch_mps_fp8_SM.py — ein eigens entwickelter Anpassungsweg der stabil funktioniert, aber ein manueller Schritt ist. Wer den Patch nicht einrichten will, verwendet fp16 — auf einem Mac Studio mit 64 GB Unified Memory ist der Speicherbedarf kein Problem.
DualCLIPLoader — ein Detail das zählt
Der DualCLIPLoader hat neben den zwei Encoder-Dateien einen dritten Parameter: den Typ. Standardmäßig ist sdxl vorausgewählt. Für Flux muss er auf flux geändert werden.
Das ist eine kleine Einstellung mit großem Einfluss — der falsche Typ führt zu schlechten Ergebnissen die sich nicht durch Prompt-Optimierung beheben lassen. In der JSON aus 2.2.2 ist flux bereits korrekt gesetzt. Wer den Node manuell hinzufügt, muss das explizit ändern.
guidance im CLIPTextEncodeFlux
Der CLIPTextEncodeFlux Node hat neben den zwei Textfeldern einen dritten Wert: guidance. Das ist kein CFG im klassischen Sinne — es ist ein interner Skalierungsfaktor der bestimmt wie stark das Modell dem kombinierten Conditioning der beiden Encoder folgt.
3.5–4.0 — für mittellange, präzise Prompts. Das ist der Standardfall.
1.0–2.0 — für sehr lange Prompts oder wenn mehr kreativer Spielraum gewünscht ist.
Dieser Wert ist unabhängig vom cfg im Sampler. Der Sampler-CFG bleibt bei Flux.1 dev immer auf 1 — wie in 2.2.4 erklärt.
Sampler-Parameter für Flux.1 dev
Flux verwendet den SamplerCustomAdvanced statt des klassischen KSampler. Die Parameter verteilen sich auf mehrere Nodes:
KSamplerSelect: euler
BasicScheduler: simple, 20–25 Steps
Warum simple und nicht karras? Bei Flux ist die Rauschkurve bereits durch die guidance-distilled Architektur beeinflusst. simple — eine lineare Abnahme — arbeitet am zuverlässigsten mit dieser Architektur zusammen. karras bringt bei Flux keinen messbaren Vorteil.
20–25 Steps sind für Flux ausreichend — die Architektur ist effizienter als SDXL und konvergiert schneller. Mehr Steps bringen ab einem bestimmten Punkt keine weitere Qualitätssteigerung.
RandomNoise: Seed-Logik wie beim SDXL KSampler — randomize zum Erkunden, fixed wenn ein guter Ausgangspunkt gefunden ist.
Auflösung
Flux.1 dev wurde auf verschiedenen Auflösungen trainiert und ist flexibler als SDXL. 1024×1024 ist ein guter Ausgangspunkt, aber auch 1024×768, 1280×720 oder 768×1024 funktionieren zuverlässig. Die 64er-Schrittgröße gilt auch hier.
Wann Flux, wann SDXL
Flux.1 dev ist die richtige Wahl wenn:
Prompt-Präzision wichtig ist — komplexe räumliche Beschreibungen, mehrere Materialien mit expliziten Zuordnungen, ausformulierte Lichtsituationen. T5XXL versteht Satzstruktur, CLIP nicht.
Die Hardware es erlaubt — 12 GB VRAM aufwärts für fp8, 24 GB für fp16. Auf schwächerer Hardware wird Flux langsam oder instabil.
Der RAY-L-Workflow im Vordergrund steht — beide Modelle unterstützen ControlNet Canny vollständig. Flux.1 dev ist dabei die empfohlene Wahl, weil die Prompt-Präzision von T5XXL die geometrische Kontrolle durch ControlNet besonders gut ergänzt. Auf schwächerer Hardware oder wenn schnelle Iteration wichtig ist, ist SDXL mit ControlNet Canny die sinnvolle Alternative.
SDXL bleibt die richtige Wahl für schnelle Iteration, ressourcenschonende Hardware, und wenn ein spezifisches LoRA-Ökosystem gebraucht wird das für Flux noch nicht existiert.