KI · Setup & Infrastruktur
ComfyUI — Philosophie und Oberfläche
Eine leere Arbeitsfläche, kein Textfeld, keine Schaltfläche "Generieren" — und warum das die richtige Entscheidung ist.
Stability Matrix ist installiert, ComfyUI gestartet, der Browser öffnet sich. Was du siehst: eine dunkle Arbeitsfläche, vielleicht ein paar Default-Nodes, kein Textfeld, keine Schaltfläche "Generieren". Wer von Adobe Firefly oder Midjourney kommt, sucht instinktiv nach einem Interface — und findet keines.
Das ist kein unfertiges Produkt. Es ist eine Designentscheidung.
ComfyUI zeigt dir nicht ein Interface für Bildgenerierung. Es zeigt dir den Prozess selbst — als Graph, in dem jeder Schritt ein Node ist und jede Verbindung zwischen Nodes ein Datenfluss. Prompt-Text rein, Conditioning raus. Conditioning rein, Sampler verarbeitet, Latent raus. Latent rein, VAE dekodiert, Bild raus. Dieser Prozess läuft in jedem KI-Bildgenerierungs-Tool — ComfyUI macht ihn sichtbar, statt ihn zu verbergen.
Das hat einen Preis: der Einstieg kostet mehr Zeit als ein Textfeld. Und einen Vorteil: wer den Graph versteht, versteht was das Modell tut — nicht nur wie man es bedient.
Den ersten Workflow laden
Bevor der Graph Sinn macht, braucht es etwas zum Lesen. Zwei fertige Minimal-Workflows stehen zum Download bereit — einen für SDXL, einen für Flux.1 dev. Beide sind auf das Wesentliche reduziert: kein ControlNet, keine LoRAs, keine zusätzlichen Nodes. Nur der Kern.
Laden über Load in der ComfyUI-Menüleiste, oder per Drag-and-Drop der JSON-Datei direkt auf die Arbeitsfläche. Der Workflow erscheint als Node-Graph.
Fang mit dem SDXL-Workflow an.
Der SDXL-Workflow — Node für Node
Der Graph besteht aus sieben Nodes. Von links nach rechts gelesen ergibt sich ein klarer Datenfluss — jeder Node nimmt etwas entgegen, verarbeitet es, gibt etwas weiter.
Node 1
CheckpointLoaderSimple
Der Startpunkt. Dieser Node lädt den SDXL-Checkpoint — in diesem Fall Juggernaut XL — und gibt drei Dinge aus: das Modell (MODEL), den CLIP-Encoder (CLIP) und den VAE. Ein einzelner Node, drei Ausgänge. Das ist möglich weil SDXL-Checkpoints alle drei Komponenten in einer Datei bündeln.
Ausgänge: MODEL → KSampler · CLIP → beide Textfelder · VAE → VAEDecode
Node 2 + 3
CLIPTextEncode (positiv) / CLIPTextEncode (negativ)
Zwei Nodes, dieselbe Struktur. Beide nehmen den CLIP-Encoder entgegen und wandeln einen Text-Prompt in CONDITIONING um — ein Format das das Modell versteht. Der positive Node beschreibt was im Bild sein soll, der negative was nicht. Beide landen im KSampler.
Node 4
EmptyLatentImage
Dieser Node erzeugt den leeren Arbeitsbereich für die Diffusion — eine Fläche aus zufälligem Rauschen in der eingestellten Auflösung. 1024×1024 ist der SDXL-Standard. Das Ergebnis ist noch kein Bild, sondern ein Latent: eine komprimierte Repräsentation im internen Raum des Modells, die erst am Ende in sichtbare Pixel übersetzt wird.
Node 5
KSampler
Das Herzstück. Hier laufen alle Fäden zusammen: MODEL, positives und negatives CONDITIONING, und das leere Latent. Der KSampler führt den eigentlichen Diffusionsprozess durch — er iteriert über eine einstellbare Anzahl von Steps und formt das Rauschen schrittweise in ein Latent, das dem Prompt entspricht. CFG, Steps, Sampler-Algorithmus und Scheduler sind hier einstellbar.
Ausgabe: ein verarbeitetes Latent — immer noch kein sichtbares Bild.
Node 6
VAEDecode
Der VAE übersetzt das Latent in sichtbare Pixel. Erst hier entsteht ein tatsächliches Bild. Der VAE ist dafür zuständig, dass die Pixelwerte korrekt und ohne Artefakte rekonstruiert werden — deshalb macht ein externer, gut kalibrierter VAE bei SDXL einen sichtbaren Unterschied.
Node 7
SaveImage
Speichert das fertige Bild im Output-Verzeichnis von ComfyUI und zeigt es in der Arbeitsfläche an.
Der Datenfluss in einer Zeile:
CheckpointLoader → [CLIP → Textfelder → Conditioning]
→ [EmptyLatent]
→ KSampler → VAEDecode → SaveImage
Sieben Nodes, ein Bild. Was dieser Graph zeigt: Bildgenerierung ist keine schwarze Box — es ist eine Abfolge von Transformationen, bei der jeder Schritt einen definierten Input hat und einen definierten Output liefert.
Der Flux-Workflow — was sich ändert und warum
Jetzt die zweite JSON laden. Derselbe Ablauf — Load oder Drag-and-Drop. Der Graph sieht auf den ersten Blick komplexer aus. Er ist es auch. Aber die Komplexität ist nicht willkürlich.
Flux.1 dev hat eine andere Architektur als SDXL — und diese Architektur schlägt sich direkt im Graph nieder. Drei Unterschiede fallen sofort auf.
Drei Loader statt einem
Bei SDXL liefert ein einzelner CheckpointLoaderSimple alles: Modell, CLIP, VAE. Bei Flux sind das drei separate Nodes:
UNETLoader— lädt das Diffusion Model (flux1-dev.safetensors). Nicht "Checkpoint", sondern "Diffusion Model" — Flux verwendet eine Transformer-Architektur (DiT) statt des U-Net aus der SDXL-Generation. Stability Matrix legt diese Dateien deshalb in einen eigenen OrdnerDiffusion Models, getrennt vonCheckpoints. Dieselbe konzeptionelle Rolle, andere Architektur, andere Benennung.DualCLIPLoader— lädt zwei Encoder gleichzeitig: T5XXL und CLIP-L. Bei SDXL war der Encoder im Checkpoint eingebettet. Bei Flux sind es zwei separate Dateien, zwei verschiedene Encoder-Typen, die unterschiedliche Aspekte des Prompts verarbeiten.VAELoader— lädt den Flux-VAE (ae.safetensors) separat.
Diese Trennung ist kein Nachteil. Sie ist der Grund warum Flux-Komponenten flexibel kombinierbar sind — T5XXL lässt sich zwischen Flux.1 und Flux.2 teilen, der VAE kann ausgetauscht werden ohne das Modell neu laden zu müssen.
CLIPTextEncodeFlux statt zwei CLIPTextEncode
Statt zwei getrennter Textfelder für positiv und negativ gibt es einen einzigen Node: CLIPTextEncodeFlux. Und dieser Node hat zwei Textfelder — aber nicht für positiv/negativ, sondern für zwei verschiedene Encoder:
clip_l— nimmt eine Stichwortliste entgegen, verarbeitet sie über CLIP-Lt5xxl— nimmt ausformulierte Sätze entgegen, verarbeitet sie über T5XXL
Kein negativer Prompt. Das ist keine Einschränkung des Interfaces — Flux ist ein guidance-distilled Modell, der Mechanismus hinter negativen Prompts ist in der Architektur nicht mehr als separater Kanal verfügbar. Was stattdessen funktioniert, steht in 2.4.3 — Prompts für Flux.
Der dritte Wert im Node ist guidance — ein interner Skalierungsfaktor, kein CFG im klassischen Sinne. Standard: 3.5.
SamplerCustomAdvanced statt KSampler
Der KSampler bei SDXL bündelt alles in einem Node. Bei Flux ist der Sampling-Prozess in mehrere separate Nodes aufgeteilt:
KSamplerSelect— wählt den Algorithmus (euler)BasicScheduler— definiert die Sigma-Kurve (simple, 25 Steps)RandomNoise— erzeugt den initialen Rausch-SeedBasicGuider— verbindet Modell und ConditioningSamplerCustomAdvanced— führt den eigentlichen Sampling-Prozess durch
Das sieht nach mehr Komplexität aus — ist es auch. Aber es ist kontrollierbare Komplexität: jede dieser Komponenten lässt sich einzeln austauschen. Ein anderer Scheduler, eine andere Noise-Strategie, ein anderer Guider — ohne den gesamten Sampler neu konfigurieren zu müssen. Das ist derselbe Gedanke wie bei den getrennten Loadern: Modularität statt Bündelung.
Was dieser Vergleich zeigt
SDXL und Flux lösen dasselbe Problem — Text in Bild — aber mit unterschiedlichen Architekturen. Der Graph macht diese Unterschiede sichtbar, statt sie zu verbergen.
Das ist das eigentliche Argument für ComfyUI. Nicht dass es mächtiger ist als andere Tools — das ist es auch, aber das ist nicht der Punkt. Sondern dass es ehrlich ist: was im Graph steht, passiert wirklich. Wer den SDXL-Graph versteht, versteht was ein Checkpoint ist, was ein VAE tut, warum es positiven und negativen Prompt gibt. Wer den Flux-Graph danebenlegt, versteht warum Flux anders promptet werden muss, warum es keinen negativen Prompt gibt, warum die Encoder-Dateien separat sind.
Kein anderes Interface gibt diesen Einblick. Der Preis ist die leere Arbeitsfläche beim ersten Start. Der Gewinn ist, dass man danach weiß was man tut.
Bevor du den ersten Run startest
Die Workflows sind mit Beispiel-Prompts vorbelegt — derselbe Küchen-Prompt aus 2.4.2 — Prompts für SDXL und 2.4.3 — Prompts für Flux, absichtlich. So lässt sich das Ergebnis direkt mit den dort beschriebenen Prinzipien vergleichen.
Zwei Dinge vor dem ersten Run prüfen:
Modellpfade: Der CheckpointLoaderSimple im SDXL-Workflow sucht nach dem genauen Dateinamen, der mit dem übereinstimmen muss, was du in Stability Matrix heruntergeladen hast. Gleiches gilt für flux1-dev.safetensors, t5xxl_fp16.safetensors, clip_l.safetensors und ae.safetensors im Flux-Workflow. ComfyUI zeigt einen roten Node wenn eine Datei nicht gefunden wird.
Auflösung: Beide Workflows sind auf 1024×1024 eingestellt — das ist für einen ersten Test in Ordnung, aber langsam auf schwächerer Hardware. Wer schnell testen will: 512×512 für SDXL, 768×768 für Flux.
Run starten über die Queue-Schaltfläche oben rechts. ComfyUI arbeitet die Nodes in der richtigen Reihenfolge ab — der Fortschritt ist in der Statusleiste sichtbar.