Flux.1 Krea dev — Setup und Parameter

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 / 20–25 Schritten, 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-checkpoints-Ordner, in dem schon dein Flux.1-dev-Modell liegt. Danach trägst du ihren Dateinamen — inklusive .safetensors — in das Checkpoint-Feld 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.

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.

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 für den folgenden Abschnitt: Wird das Subjekt per LoRA konstant gehalten, ist jeder sichtbare Unterschied allein der Basis-Ästhetik zuzuschreiben und nichts anderem.

Der Vergleich ist nur dann ehrlich, wenn ausschließlich das Modell variiert: derselbe Seed, derselbe Prompt, dieselbe guidance, dieselben Sampler-Parameter, dieselbe ControlNet-Kante. Genau deshalb bleibt oben alles unverändert — nur so ist ein sichtbarer Unterschied dem Modell zuzuschreiben und nicht einem verstellten Regler.

Getestet wird entlang von vier Dimensionen, die für die Tauglichkeit neben professioneller Werbefotografie zählen — nicht entlang von „wirkt eindrucksvoller". Die Verdikte unten stehen erst, wenn sie über die Reihe gehalten haben.

Ein Vergleich ist keine Reihe. Was hier als Unterschied behauptet wird, muss über mehrere Seeds und mehrere Motive gehalten haben — ein einzelnes Bildpaar, das in eine Richtung zeigt, ist ein Einzelfall, keine Eigenschaft des Modells.

Krea dev steht unter derselben Lizenz wie Flux.1 dev — der FLUX.1-dev-Non-Commercial-License. Das ist nicht die Apache-2.0-Lizenz von Flux.2 Klein 4B. Für rein lokales Testen und Research ist das ohne Belang; sobald die erzeugten Bilder kommerziell genutzt werden, braucht es die separate kommerzielle Lizenz über das BFL-Lizenzportal.

Die Wahl und die Lizenzierung des Modells liegen beim Anwender. RAY-L liefert kein Modell mit und schreibt keines vor: Wie ComfyUI ist es ein Rahmen, der verschiedene Modelle nutzen kann. Welches davon für den eigenen Einsatz das richtige ist — und unter welcher Lizenz es genutzt wird — entscheidet der Anwender selbst.

Krea dev kostet gegenüber Flux.1 dev nichts extra. Es ist dasselbe 12-Milliarden-Parameter-Modell mit demselben VRAM-Bedarf und derselben Geschwindigkeit — die Encoder- und Sampler-Anforderungen aus 2.3.2 gelten unverändert. Die Entscheidung zwischen dev und Krea ist deshalb keine Hardware-Frage, sondern eine ästhetische.

Der Wechsel selbst kostet nichts und ist reversibel: ein Feld zurückgesetzt, und der nächste Lauf ist wieder dev. Genau diese Reibungslosigkeit ist der Grund, Krea dev an derselben Stelle einzuordnen, an der zuvor dev stand — nicht als neues Modell mit eigenem Setup, sondern als die photographischere Voreinstellung desselben Wegs.