KI · Prompt-Architektur
Prompts für Flux
Zwei Encoder, zwei Felder — und warum die T5-Logik das Fundament für alle kommenden Modelle ist.
Zwei Encoder, zwei Felder
Flux.1 dev arbeitet anders als SDXL — nicht mit einem, sondern mit zwei Text-Encodern gleichzeitig: CLIP-L und T5XXL. Beide verarbeiten deinen Text parallel, auf völlig unterschiedliche Weise. Deshalb gibt es im ComfyUI-Node CLIPTextEncodeFlux zwei getrennte Eingabefelder — und deshalb macht es einen messbaren Unterschied, was du in welches Feld schreibst.
Die Grundregel:
Das ist kein stilistisches Detail. Wer beiden Feldern denselben Text gibt — egal in welchem Format — verliert substanziell an Bildqualität und Prompt-Präzision. CLIP-L erwartet Listen, T5XXL erwartet Sprache. Beide mit Sätzen zu füttern, oder beide mit Stichwörtern, kostet in beiden Fällen.
clip_l — die Stichwortliste
Das clip_l-Feld funktioniert nach derselben Logik wie ein SDXL-Prompt — mit einer Einschränkung: Gewichtungssyntax ((wort:1.3)) wirkt hier deutlich schwächer als bei reinem SDXL, weil T5XXL den Großteil der semantischen Steuerung übernimmt. Reihenfolge zählt trotzdem — frühe Tokens werden stärker gewichtet.
Inhalt: die wichtigsten Konzepte deiner Bildidee, kompakt und priorisiert.
Scandinavian kitchen interior, minimalist Nordic design, white upper cabinets, light oak wood lower cabinets and island, gray stone countertops, floor-to-ceiling windows, soft natural daylight, photorealistic, editorial photography
Das 77-Token-Limit von CLIP-L gilt auch hier — kompakt halten.
t5xxl — die ausformulierte Szene
Das t5xxl-Feld versteht echte Sprache. Hier schreibst du keine Liste — hier beschreibst du ein Bild so, wie du es einem Assistenten erklären würdest, der es fotografieren soll.
Zwei Dinge, die T5 wirklich anders verarbeitet als CLIP:
Beziehungen zwischen Elementen
"The streetlight casts a rim light through the fog" ist für T5 eine Aussage über eine Beziehung — Lichtquelle, Wirkung, Medium, alles in einem Satz. CLIP würde daraus "streetlight", "rim light", "fog" als drei unverbundene Konzepte lesen.
Syntaktische Prominenz
Was Subjekt eines Satzes ist, bekommt mehr Gewicht als was im Nebensatz steht. Wenn ein Element im Ergebnis fehlt oder schwach auftaucht — prüfe, ob es in deinem Text syntaktisch prominent steht oder nur beiläufig erwähnt wird.
Beispiel: "natural daylight that pours in through floor-to-ceiling windows" — die Fenster sind hier Nebensache hinter dem Licht. Ergebnis: Licht wurde umgesetzt, Fenster nicht. Korrektur: eigener Satz.
A bright, spacious Scandinavian kitchen is photographed from eye level with a 35mm lens. Floor-to-ceiling windows span the back wall, flooding the room with natural daylight. The cabinetry combines matte white upper cabinets with light oak wood lower cabinets and a matching island, while the gray stone countertops reflect the soft light realistically. A single ceramic vase sits on an otherwise uncluttered counter. The composition has strong depth and realistic proportions, shot in the style of an Architectural Digest editorial feature.
Faustregel: Was du wirklich sehen willst, steht als eigener Satz — nicht als Relativsatz, nicht als Präpositionalphrase.
Zwei Materialien brauchen eine Beziehung
Diese Regel gilt bei Flux genauso wie bei SDXL — aber bei Flux hast du ein besseres Werkzeug, um sie umzusetzen: den T5-Satz.
Statt
matte white cabinetry, light oak wood fronts
Mit expliziter räumlicher Zuordnung im t5xxl-Feld
The cabinetry combines matte white upper cabinets with light oak wood lower cabinets and a matching island.
CLIP kann Beziehungen nur über Token-Reihenfolge und Gewichtung annähern. T5 versteht "combines... with..." als echte strukturelle Aussage. Das ist einer der Fälle, wo Flux gegenüber SDXL einen klaren Vorteil hat — nicht in der Qualität des Ergebnisses generell, sondern in der Präzision komplexer räumlicher Beschreibungen.
Kein negativer Prompt
Bei Flux.1 dev gibt es keinen funktionierenden negativen Prompt — das ist keine Einschränkung des Interfaces, sondern eine Folge der Modellarchitektur. Flux ist ein "guidance-distilled" Modell: der klassische Mechanismus, auf dem negative Prompts basieren (Classifier-Free Guidance), wurde beim Training bereits eingearbeitet und ist nicht mehr als separater Steuerungskanal verfügbar.
Was stattdessen funktioniert: Unerwünschtes positiv umformulieren.
| Negativer Reflex (funktioniert nicht) | Positive Umformulierung (funktioniert) |
|---|---|
| no clutter | uncluttered surfaces, minimal decoration |
| not blurry | sharp focus, crisp detail |
| no people | empty room, no figures |
| avoid harsh shadows | soft, diffused lighting |
Diese Umformulierung ist oft präziser als ein negativer Prompt es je war — weil du das Bild beschreibst, das du willst, statt das, was du nicht willst.
guidance — der dritte Wert im CLIPTextEncodeFlux
Der CLIPTextEncodeFlux-Node hat neben den zwei Textfeldern einen dritten Wert: guidance. Das ist kein CFG im klassischen Sinne — sondern ein interner Skalierungsfaktor, der bestimmt, wie stark das Modell dem kombinierten Conditioning folgt.
Dieser Wert ist nicht dasselbe wie cfg im KSampler. Der KSampler-cfg-Wert muss bei Flux.1 dev auf 1 stehen — jeder höhere Wert verschlechtert das Ergebnis, weil er gegen die eingebaute Guidance-Distillation arbeitet. Das ist einer der häufigsten Fehler beim Einstieg in Flux.
Der vollständige Flux.1 dev Workflow auf einen Blick
clip_l (Stichwortliste, max. 77 Tokens): [Subjekt, Komposition, Umgebung, Licht, Material, Atmosphäre, Stil] — kommasepariert, Priorität bestimmt Reihenfolge t5xxl (ausformulierte Sätze, bis ~512 Tokens): Vollständige Szenen-Beschreibung mit expliziten Beziehungen zwischen Elementen. Wichtige Elemente als eigene Sätze. Räumliche Zuordnungen ausformulieren. guidance (im CLIPTextEncodeFlux): 3.5–4.0 (Standard) KSampler-Werte für Flux.1 dev: cfg: 1 · steps: 20–25 · sampler: euler · scheduler: simple
Flux.2 — wohin die Entwicklung geht
Flux.2 dev macht einen weiteren Schritt: Die bisherige Zwei-Encoder-Architektur (CLIP-L + T5XXL) wurde durch ein einzelnes, großes multimodales Sprachmodell ersetzt, das Text-Embedding, Prompt-Upsampling und Safety-Filterung gleichzeitig übernimmt. Kein separates CLIP-L mehr, kein getrenntes Zwei-Felder-Interface.
Das bestätigt die Tendenz, die sich bereits im Grundlagen-Artikel abgezeichnet hat: Modelle entwickeln sich weg von CLIP-Logik, hin zu echtem Sprachverständnis. Die T5-Faustregel — ausformulierte Sätze, explizite Beziehungen, syntaktische Prominenz — bleibt auch für Flux.2 die richtige Grundlage. Nur dass du sie dort nicht mehr in einem separaten Feld, sondern in einem einzigen Eingabefeld anwendest.
Die Prompt-Logik, die du für t5xxl gelernt hast, ist damit direkt auf Flux.2 übertragbar.
Die Portabilität nochmal zusammengefasst
| Zielmodell | Quelle |
|---|---|
| SDXL (Juggernaut XL) | clip_l-Feld, ggf. Gewichtung ergänzen |
| Flux.1 dev | beide Felder gemeinsam |
| Flux.2 / SD 3.5 / Ideogram 4 | t5xxl-Feld, direkt übertragbar |
Das ist mehr als eine praktische Abkürzung. Wer lernt, im t5xxl-Feld präzise, beziehungsreiche Sätze zu formulieren — explizite räumliche Zuordnungen, syntaktisch prominente Hauptelemente, ausformulierte Lichtsituationen — erwirbt eine Kompetenz, die unabhängig vom jeweiligen Modell gilt.
Alle modernen Modelle mit Sprachverständnis — Flux.2, SD 3.5, Ideogram 4, und was danach kommt — erwarten genau diese Art von Formulierung. Sie unterscheiden sich in Architektur, Trainingsgewichten und Stärken, aber nicht in der Grundlogik: Sie lesen Sprache, keine Listen.
Das clip_l-Feld dagegen ist spezifischer: Es bedient CLIP-basierte Encoder, deren Bedeutung mit jeder Modellgeneration kleiner wird. Es bleibt relevant, solange SDXL und Flux.1 im Einsatz sind — aber es ist kein Fundament für die Zukunft, sondern ein Werkzeug für die Gegenwart.
Die Konsequenz für die eigene Praxis: Investiere mehr Sorgfalt ins t5xxl-Feld. Nicht weil clip_l unwichtig ist — sondern weil die Qualität deiner t5xxl-Formulierung bestimmt, wie gut du mit jedem Modell arbeitest, das nach Flux.1 kommt.