Flux.1 Krea dev — Setup und Parameter

Von allen Modellen, die ich lokal getestet habe, ist Krea dev das mit der überzeugendsten fotografischen Anmutung. Das ist kein Zufall, sondern Absicht: Black Forest Labs hat auf die neutrale Flux-Rohbasis ein reines Ästhetik-Post-Training gesetzt, mit dem erklärten Ziel, den übersättigten „AI-Look" zu vermeiden — zurückhaltende Farben, kontrollierte Lichter, natürliche Textur statt glatter Mitte. Für Arbeit, die neben professioneller Werbefotografie bestehen soll, ist das die entscheidende Eigenschaft.

Auf leistungsfähiger Hardware ist Krea unkompliziert. Auf dem MacBook Pro mit 64 GB laufen die vollen Gewichte ohne Umstände — eine Datei, der Standard-Loader, fertig, wie in 2.3.2 beschrieben. Interessant wird es darunter: Die quantisierten GGUF-Varianten bringen Krea auch auf knappe Maschinen, und zwar weit genug herunter, dass auf ausreichend ausgestatteter Hardware neben dem Modell noch Blender und das ControlNet gleichzeitig Platz finden — die drei Teile, aus denen die RAY-L-Kette besteht: Blender liefert die Geometrie, Canny die Kante, Krea das Bild. Dass das RAY-L-Panel die GGUF-Variante direkt ansteuert, kommt mit v0.9.1.

Genau deshalb ist Krea dev — neben Flux.1 dev als neutraler Basis — das fotografische Hauptmodell für RAY-L. Nicht, weil es das schnellste wäre, sondern weil es das einzige mit dieser Anmutung ist, das sich sauber in das ControlNet-Canny-Regime fügt.

Die naheliegende Gegenfrage lautet: Warum dann nicht das deutlich schnellere Flux.2 Klein 4B? Weil Klein für RAY-L nicht in Frage kommt — es gibt für Klein derzeit kein ComfyUI-taugliches ControlNet Canny (die Gründe stehen auf der Klein-Seite). Klein bleibt die erste Wahl für alles ohne Blender und ControlNet — freie Generierung, img2img, schnelle Verfeinerung. Sobald die Kette aber über eine feste Geometrie laufen soll, führt der Weg über das zähere, aber RAY-L-taugliche Krea. Diese Seite handelt davon, wie man dieses zähere Modell praktikabel macht.

Dass der Tausch so bruchlos funktioniert und die Ästhetik trotzdem abweicht, erklärt sich aus der Entstehung. Black Forest Labs hat Krea ein vortrainiertes, guidance-distilliertes 12-Milliarden-Parameter-Modell namens flux-dev-raw bereitgestellt — dieselbe Rohbasis, aus der auch Flux.1 dev hervorgeht. Darauf hat Krea ein reines Ästhetik-Post-Training gefahren, mit dem erklärten Ziel, realistischere und weniger übersättigte Bilder zu erzeugen. Flux.1 dev und Krea dev sind Geschwister aus derselben Rohbasis, die nur im Post-Training auseinandergehen. Das ist der Grund, warum die Pipeline identisch bleibt — gleiche Encoder, gleiche Node-Struktur — und die Bildwirkung dennoch eine andere ist.

Black Forest Labs nennt das Modell selbst „opinionated": ein Text-zu-Bild-Modell mit bewusst eigener ästhetischer Haltung statt neutraler Mitte, mit dem Ziel, den übersättigten „AI look" zu vermeiden. In den Präferenztests des Herstellers liegt Krea dev auf einer Ebene mit der geschlossenen Lösung FLUX1.1 pro. Das ist eine Herstellerangabe, kein unabhängiges Ergebnis, und als solche zu lesen. Die belastbare Aussage über den Unterschied liefert nicht das Datenblatt, sondern der direkte Vergleich am eigenen Motiv — und der beginnt bei der Frage, wie sich diese Ästhetik mit dem verträgt, was man ihr an LoRAs mitgibt.

Der praktische Kern in einem Satz: Krea dev läuft an genau der Stelle, an der vorher Flux.1 dev lief, ohne dass sich sonst irgendetwas ändert. Der DualCLIPLoader bleibt auf flux, dieselben beiden Encoder — CLIP-L und T5XXL — bleiben geladen, die guidance in CLIPTextEncodeFlux bleibt bei 3.5–4.0, der SamplerCustomAdvanced bleibt bei euler / simple, die Sampler-cfg bleibt bei 1, die Ein-Megapixel-Auflösungsregeln bleiben dieselben. Nichts davon fasst man an. Krea dev ist wie Flux.1 dev guidance-distilliert — dasselbe Regime, dieselben Werte.

Was sich ändert, ist eine Datei. Die Krea-Gewichte gehören in denselben ComfyUI-unet-Ordner, in dem schon dein Flux.1-dev-Modell liegt. Danach trägst du ihren Dateinamen — inklusive .safetensors — in das Feld „Diffusion (UNet)" des RAY-L-Panels ein. Das ist der gesamte Eingriff: ein Feld.

Das ControlNet bleibt ebenfalls unberührt. Der InstantX-Flux-Canny (flux-canny-instantx.safetensors) funktioniert mit Krea dev genauso wie mit dev, weil Krea Flux.1-dev-kompatibel ist und dasselbe ControlNet-Regime nutzt. ControlNet-Stärke, Canny-Schwellenwerte, Seed-Logik — alles bleibt, wie es in 2.3.2 steht.

Zwei Modi, und warum der Seed zwischen ihnen nicht trägt. Krea in Zielauflösung mit voller Step-Zahl zu rechnen, kostet auf knapper Hardware Minuten pro Bild — zu viel, um damit eine Komposition zu suchen. Deshalb zwei Modi: ein schneller Iterationsmodus in kleinerer Auflösung mit rund 16 Steps, um Komposition, Licht, Material und Farbe zu prüfen, und ein Finalisierungsmodus in Zielauflösung mit 28–35 Steps für das Abgabebild. 28–35 ist der Bereich, der sich in meinen Tests bewährt hat: Unter etwa 24 Steps bleibt sichtbar Qualität liegen, über 35 bis 40 kommt nichts mehr dazu. Krea ist zwar guidance-distilliert, aber — anders als das step-distillierte Klein — nicht auf wenige Steps trainiert und braucht deshalb diese echten Steps.

Was dabei kontraintuitiv ist und oft falsch verstanden wird: Der Seed, der im Schnellmodus eine schöne Komposition gefunden hat, überträgt sich nicht in den Finallauf. Ein Seed ist nicht das Bild, sondern nur das Startrauschen. Welches Bild daraus wird, hängt vom Weg ab, den der Sampler durch dieses Rauschen nimmt — und diesen Weg verändern beide Modus-Parameter: Eine andere Step-Zahl bedeutet einen anderen Pfad, eine andere Auflösung ein anders geformtes Latent-Gitter. Derselbe Seed liefert in Iterations- und in Finalsettings also zwei verschiedene Bilder, nicht dasselbe Bild in zwei Schärfegraden. Was sich überträgt, ist nicht die konkrete Komposition, sondern die Prompt-Wirkung: Lichtcharakter, Materialanmutung, Farbstimmung, Genre. Die prüft man im Schnellmodus zuverlässig — die genaue Bildanordnung nicht.

Daraus folgt eine praktische Konsequenz: Wer eine bestimmte Komposition tatsächlich halten will, muss entweder von Anfang an in Zielsettings iterieren — langsam — oder sie über die deterministische Seite festnageln, das ControlNet. Hier ist die Grenze aber genau zu ziehen: ControlNet entkoppelt die Bildgeometrie von Seed, Auflösung und Steps — die Kante aus Blender steht fest, egal wie man am Sampler dreht. Was es nicht festlegt, ist alles, was innerhalb dieser Kante liegt: Material, Oberfläche, Lichtzeichnung in den Flächen, Feintextur. Dieser Spielraum variiert auch im RAY-L-Workflow weiter mit Step-Zahl und Auflösung. Der kontrollierte Weg nimmt dem Zufall also die Komposition — nicht die gesamte Bildwirkung. Das ist trotzdem der entscheidende Gewinn, weil die Komposition das ist, was sich über freies Prompting prinzipiell nicht zuverlässig halten lässt.

Und weil ControlNet zwar die Geometrie, aber nicht Material und Textur festhält, gilt dieselbe Disziplin auch im RAY-L-Workflow: Selbst wenn die Kante die Komposition sichert, muss das Abgabebild im Finallauf in Zielauflösung und voller Step-Zahl entstehen — die Materialbeurteilung aus dem Schnellmodus trägt nicht eins zu eins hinüber.

Die Praxisfrage auf knapper Hardware ist nicht „läuft es", sondern „was kostet welcher Kompromiss an Zeit". Anders als die Modellvergleichs-Tabelle auf der Klein-Seite, die bei fixem 1024² misst, welches Modell auf welcher Maschine wie schnell ist, misst diese Matrix das Innere eines einzigen Modells: wie Quantisierung, Auflösung und Step-Zahl die Renderzeit gegeneinander verschieben — jeweils auf dem 16-GB-Air und dem 64-GB-Pro, warm (Modelle im Speicher).

Minuten:Sekunden, 30 Steps, warm (Modell resident). ⚠ Speicherdruck gelb — die Zeit steigt durch beginnendes Auslagern. ✕ nicht praktikabel: Q8 über 60 Minuten (die Gewichte sprengen die 16 GB), fp16 auf 16 GB nicht ladbar. ¹ Transformer + T5 resident, gemessen: Transformer Q3 5.019 MB · Q4 6.647 MB · Q6 9.518 MB · Q8 12.251 MB; T5 Q3 2.676 MB · Q4 3.249 MB · Q6 4.214 MB · Q8 5.314 MB.

Drei Dinge liest man aus der Tabelle, und das erste ist das wichtigste: Auf dem Air trennt der Speicher, nicht die Quant-Stufe. Q3 und Q4 brauchen praktisch gleich lang (gut 16 Minuten bei 768, gut 25 bei 1024) — solange der Speicher grün bleibt, entscheidet nicht die Modellgröße über die Zeit, sondern die Rechenlast pro Step, und die ist zwischen Q3 und Q4 fast gleich. Erst Q6 bricht aus (41 Minuten bei 1024), genau dort, wo der Speicher auf gelb kippt und das System zu swappen beginnt. Q8 sprengt ihn ganz. Nicht die Stufe kostet die Zeit, sondern der Moment, in dem sie den Speicher übersteigt.

Daraus folgt die Empfehlung für 16 GB: Q4, nicht Q3. Beide laufen gleich schnell und beide im grünen Bereich — aber Q4 hält merklich mehr Detail, und bei Q3 zerfallen zuerst die Finger. Q4 ist die höchste Stufe, die auf dem Air noch voll im Grünen rechnet: der Sweet Spot aus Qualität und Lauffähigkeit. Zu Q3 greift man nur, wenn die Downloadgröße zählt. (Dieser Finger-Zerfall ist ein anderer als der aus dem Vorschau-Abschnitt oben — hier wirft die starke Quantisierung Präzision weg, dort fehlten Auflösung und Steps.)

Auf dem Pro gewinnt fp16 — und mehr RAM ersetzt keine Rechenkerne. Wo der Speicher reichlich ist, sinkt die Zeit mit steigender Stufe sogar (Q8 schneller als Q3, weil rechnerisch einfacher zu entpacken), und fp16 ist am schnellsten von allen, weil es gar nicht erst entpackt werden muss — GGUF wird auf Apple Silicon bei jedem Step nach bf16 dequantisiert, fp16 liegt schon im Rechenformat. Der Abstand zwischen Air und Pro beträgt bei grünem Speicher rund das Dreifache — das ist schlicht die GPU-Kerndifferenz (10 gegen 32 Kerne). Bei Q6/1024, wo der Air swappt, reißt er auf etwa das Fünffache auf; dieser Aufschlag ist der Swap. Die Lehre für die Hardware-Wahl: Mehr Arbeitsspeicher verschiebt die Grenze, ab der eine Stufe überhaupt läuft — nie die, ab der sie schnell ist. Ein Air mit mehr RAM brächte die großen Quants zum Laufen, erreichte mit seinen wenigen Kernen aber nie die Pro-Zeiten. Auf Apple Silicon kompensiert Speicher keine fehlenden Rechenkerne.

Die reine Rechenzeit skaliert linear mit den Steps, weil jeder Step gleich teuer ist — bei Q4/1024 rund 50 Sekunden pro Step auf dem Air, rund 15 auf dem Pro. Jede andere Step-Zahl rechnet man sich daraus aus. Und der fp16-Wert auf dem Pro (5:29 bei 1024², 30 Steps) ist zugleich die Brücke zur Klein-Seite: Er liegt in derselben Größenordnung wie die dort genannten rund 6 Minuten für Flux.1 dev — Krea ist schließlich dasselbe Modell in anderer Lackierung.

Weil die Architektur identisch ist, gilt für LoRAs dasselbe wie für das ControlNet: Ein LoRA, das für Flux.1 dev trainiert wurde, lädt und wirkt auch auf Krea dev — und umgekehrt. Technisch sind die beiden Modelle austauschbar. Interessanter als die Frage, ob ein LoRA lädt, ist die Frage, wie gut es sich mit Kreas Ästhetik verträgt.

Kreas Ästhetik ist keine Einstellung, die man wegregelt, sondern in die Gewichte trainiert — eine Kraft, in deren Richtung das Bild gezogen wird. Ein LoRA arbeitet entweder mit dieser Kraft oder gegen sie. Ein Character- oder Identitäts-LoRA lehrt Inhalt — Gesichtsstruktur, wer die Person ist — und liegt damit quer zur Ästhetik der Basis; es reitet auf beiden Modellen mit und bleibt robust, weil es der Krea-Anmutung nichts wegnimmt. Ein Stil-LoRA dagegen lehrt genau das, was Krea schon mitbringt: Anmutung. Hier überlagern sich zwei Ästhetiken, und dasselbe Stil-LoRA kann auf dev und auf Krea unterschiedlich landen — auf der einen Basis malt es in eine leere Fläche, auf der anderen gegen eine bereits vorhandene Handschrift.

Das lässt sich an einem Character-LoRA unmittelbar prüfen. Trainiert man die Identität einer synthetischen Person und rendert sie mit identischem Seed und Prompt einmal auf dev und einmal auf Krea, sollte die Person dieselbe bleiben — die Identität stammt aus dem LoRA — während sich die Anmutung unterscheidet, weil sie aus der Basis stammt: dieselbe Person, zwei Ästhetiken. Zugleich ist das die sauberste Methode, Kreas Ästhetik überhaupt zu isolieren: Wird das Subjekt per LoRA konstant gehalten, ist jeder sichtbare Unterschied zwischen dev und Krea allein der Basis-Ästhetik zuzuschreiben und nichts anderem.

Der Drop-in-Charakter zeigt sich schon beim Download: Neu herunterzuladen ist genau eine Datei — das Krea-Diffusionsmodell. CLIP-L, T5XXL und die VAE (ae.safetensors) sind dieselben wie im Flux.1-dev-Setup aus 2.3.2 und liegen bereits am richtigen Ort. Die neue Datei kommt in denselben Ordner wie dein dev-Modell; ihren Namen trägst du in das Feld „Diffusion (UNet)" des RAY-L-Panels ein.

Welche Variante die richtige ist, entscheidet die Hardware — und zwar nach genau der Staffel aus 2.3.2. Die Kurzfassung, weil sie oft falsch herum erzählt wird: fp8_scaled ist die Wahl auf Nvidia mit wenig VRAM — nicht allgemein „auf schwacher Hardware". Auf Apple Silicon rechnet fp8 nicht; dort gilt fp16, solange der Speicher reicht, und sonst GGUF.

Transformer-Datei → ComfyUI/models/unet/ (in neueren ComfyUI-Versionen auch diffusion_models/). Bei GGUF die Stufe nach Speicher wählen: Ankerpunkte Q3_K_S ~5,23 GB, Q4_K_M ~6,93 GB, Q6_K ~9,85 GB, Q8_0 ~12,7 GB. Für die passenden T5XXL-Varianten (fp16, fp8_scaled, GGUF) gilt die Encoder-Tabelle aus 2.3.2 unverändert.

Für einen direkten Qualitätsvergleich zwischen dev und Krea bei identischer Quant-Stufe die _K_S-Stufen paaren: city96s dev-GGUF führt bei Q3/Q4/Q5 nur _K_S, QuantStacks Krea-GGUF beide. Nur gleiche Stufen sind sauber vergleichbar — sonst mischt sich der Modellunterschied mit einem Kompressionsunterschied.

Krea dev steht unter derselben Lizenzurkunde wie Flux.1 dev — der FLUX Non-Commercial License von Black Forest Labs (Version 2.0). Das ist nicht die Apache-2.0-Lizenz von Flux.2 Klein 4B.

Zwei Dinge sind auseinanderzuhalten. Die erzeugten Bilder gehören dem Anwender — Black Forest Labs beansprucht kein Eigentum an den Outputs; sie dürfen für jeden Zweck genutzt und verkauft werden, mit der einzigen Ausnahme, dass sie nicht zum Training eines konkurrierenden Modells dienen dürfen. Der Betrieb des Modells ist die getrennte Frage: Die Gewichte sind für nicht-kommerzielle, nicht-produktive Nutzung lizenziert; kommerzieller oder produktiver Betrieb braucht eine separate Lizenz von Black Forest Labs. Dass die Bilder dem Anwender gehören, entscheidet diese zweite Frage nicht.

Unabhängig von der Lizenz sind KI-erzeugte Bilder gesetzlich als solche zu kennzeichnen, soweit anwendbar.

Der Lizenztext hat sich über die Versionen geändert; maßgeblich ist die jeweils aktuelle Fassung auf bfl.ai. Mehr dazu in 2.1.4 — Lizenzmodelle verstehen. Orientierung, keine Rechtsberatung.