Flux.1 dev — Setup und Parameter

Flux.1 dev und Krea dev gehören zum Besten, was lokal zu haben ist — aber dieser Satz hat eine stillschweigende Bedingung: genug Speicher. Ist er reichlich vorhanden, ist alles einfach: eine Datei laden, ein Loader, fertig. Wird er knapp, beginnt eine Kette von Entscheidungen, die diese Seite ausbreitet.

Dabei geht es um mehr als Bildqualität. Zu wenig Speicher kostet nicht nur Detail — er kostet Nutzbarkeit. Passt ein Modell nicht in den Speicher, lagert das System auf die Festplatte aus, und aus einem Bild in anderthalb Minuten wird eines in zehn. Nicht das unscharfe Ergebnis ist das eigentliche Problem, sondern die Renderzeit, die das Arbeiten praktisch anhält. Die Speicherfrage entscheidet also zuerst darüber, ob der Workflow überhaupt benutzbar ist, und erst danach über die letzte Stufe Qualität.

Zwei Gewichte dominieren das Budget, alles andere ist Beiwerk. Das größte ist der Transformer — das eigentliche Bildmodell mit rund zwölf Milliarden Parametern. Im Standard-Flux-Graph wird er nicht über den CheckpointLoaderSimple geladen, sondern über den Node Load Diffusion Model (intern UNETLoader) — die Datei liegt in ComfyUI/models/unet/. Der Name „UNET" ist historisch: Flux ist technisch kein U-Net, sondern ein Diffusion Transformer (DiT); der Node heißt aus Alt-Gründen weiter so. In voller Präzision belegt dieser Transformer allein etwa 24 GB.

Das zweite große Gewicht ist der Text-Encoder T5XXL, der den Prompt in die Sprache des Modells übersetzt; in voller Präzision rund 10 GB. CLIP-L (~250 MB) und die VAE (~335 MB) fallen daneben nicht ins Gewicht — sie bleiben, wie sie sind.

Gegen diese Summe — grob 34 GB in voller Präzision — wird im Folgenden alles gerechnet. Wer sie hat, ist fertig. Wer sie nicht hat, muss eines oder beide Gewichte verkleinern, und wie er das tut, hängt an der nächsten Unterscheidung.

Wer Flux auf knappem Speicher zum Laufen bringen will, stößt schnell auf eine Handvoll Begriffe — fp16, fp8, scaled, GGUF — und auf widersprüchlich klingende Ratschläge. Der Grund für die Verwirrung ist fast immer, dass zwei verschiedene Fragen durcheinandergeraten. Trennt man sie, sortiert sich der Rest von selbst.

Die erste Frage betrifft die Datei: In welcher Präzision liegen die Gewichte vor? Volle Präzision (fp16/bf16), halbiert (fp8), oder in feineren Stufen gepackt (GGUF, die Q-Varianten). Das ist eine Eigenschaft der heruntergeladenen Datei und entscheidet, wie viel Speicher sie belegt und wie viel Qualität sie mitbringt.

Die zweite Frage betrifft die Hardware: Kann die GPU ein Format überhaupt direkt rechnen? Und hier liegt der Punkt, der die meisten Mac-Anleitungen in die Irre führt — denn er fällt je nach Plattform entgegengesetzt aus. Auf Nvidia-Karten ist fp8 ein echtes Rechenformat: Die Tensor-Cores verarbeiten es nativ, man gewinnt Speicher und Geschwindigkeit. Auf Apple Silicon gibt es für fp8 dagegen keine Recheneinheiten — das MPS-Backend hat schlicht keine fp8-Kernels. Ein fp8-Modell lässt sich dort nicht einfach laden; im Normalfall bricht der Lauf mit einer Fehlermeldung ab, weil MPS nicht einmal die Umwandlung einer fp8-Zahl beherrscht. Was ComfyUI beim Start an fp8-Fähigkeiten in die Protokolle schreibt, gilt dem Nvidia-Pfad und ist auf dem Mac ohne Wirkung.

Dazu kommt ein zweiter Hardware-Unterschied, der die Folgen verschärft. Eine Nvidia-Karte hat ihren eigenen, fest zugeteilten Grafikspeicher (VRAM); passt ein Modell nicht hinein, bricht es hörbar ab. Apple Silicon teilt sich dagegen einen gemeinsamen Speicherpool zwischen System und GPU (Unified Memory). Das hat einen Vorteil und eine Tücke: Es gibt keine harte VRAM-Grenze, die GPU kann den ganzen Pool nutzen — aber wird es eng, stürzt nichts ab, sondern macOS lagert Teile auf die SSD aus. Das Modell läuft dann weiter, nur quälend langsam, weil aus Rechnen plötzlich Lesen und Schreiben auf der Festplatte wird. Dieses stille Auslagern — nicht ein Absturz — ist auf dem Mac der eigentliche Gegner, und der Grund, warum die Speicherfrage hier über Nutzbarkeit entscheidet, nicht nur über Qualität.

Beide großen Gewichte — Transformer und T5 — gibt es in denselben drei Stufen. Welche die richtige ist, entscheidet die vorige Unterscheidung, nicht der Geschmack.

Die Formate teilen sich zwei Loader, und die Grenze verläuft nicht dort, wo man sie vermutet. Volle Präzision und fp8 laufen beide über Load Diffusion Model. Für fp16 steht weight_dtype auf default; fp8 erzeugt man auf Nvidia, indem man dieselbe volle Datei lädt und weight_dtype auf fp8_e4m3fn stellt — ComfyUI castet dann beim Laden und halbiert den Speicher. Ein eigener fp8-Transformer-Download ist dafür nicht nötig. Nur GGUF braucht den Unet Loader (GGUF), weil .gguf ein eigenes Dateiformat ist, das der Standard-Node nicht öffnet. (Beim T5-Encoder liegt der Fall anders: Dort gibt es eine fertig vorbereitete _scaled-fp8-Datei, siehe Bezugsquellen.) Zwei Formate, ein Loader; ein Format, ein eigener.

Daraus ergibt sich eine knappe Zuordnung. Die Speicherangaben sind Richtwerte für die Modellgewichte, nicht gemessene Grenzen — Betriebssystem und die Zwischendaten während der Berechnung kommen obendrauf und zehren am selben Pool.

Die mittlere Zeile ist die eigentliche Arbeit auf knappem Mac-Speicher: Bei 24 GB reicht oft ein hoher Quant (Q6/Q8 für den Transformer, dazu ein kleinerer T5-Quant); bei 16 GB muss man weiter heruntergehen (Q4 oder Q3), bis die Gewichte samt Zwischendaten unter die Schwelle fallen, an der das System auszulagern beginnt. Fällt die Wahl auf Nvidia mit sehr wenig VRAM, ist GGUF auch dort ein gangbarer Weg — fp8_scaled bleibt aber die erste Wahl, weil es dort rechnet und nicht nur Speicher spart.

Ein letzter Punkt gegen ein naheliegendes Missverständnis. Dass ein kleiner GGUF-Quant auf dem Mac spürbar schneller läuft, kommt nicht daher, dass er schneller rechnet — die Gewichte werden zum Rechnen ohnehin wieder nach bf16 entpackt, wie bei jedem Format. Der Gewinn liegt woanders: Passt das Modell in den Speicher, hört das System auf, auf die Festplatte auszulagern, und aus festplattengebundenem Warten wird wieder GPU-Rechnen. Genau das kann den Unterschied zwischen zehn Minuten und zwei, drei Minuten pro Bild ausmachen — nicht die Rechenart, sondern der vermiedene Umweg über die SSD.

Ob man in diesem Zustand steckt, liest man im Aktivitätsmonitor direkt ab: hoher Speicherdruck und ein wachsender Swap-Wert sind das Signal, dass der Quant eine Stufe kleiner werden muss. Auf dem Mac ist Passen-in-den-Speicher die Geschwindigkeit.

Die konkreten Dateien und ihre Quellen. Der Transformer ist modellspezifisch; Encoder und VAE sind für Flux.1 dev und Krea dev identisch und werden nur einmal geladen. Die „nur Nvidia"-Markierung erinnert daran, dass die fp8-Zeilen auf Apple Silicon ausfallen — dort gilt fp16 oder GGUF.

Transformer — Flux.1 dev

Transformer-Datei → ComfyUI/models/unet/. Bei GGUF die Stufe nach der Hardware-Staffel wählen. fp8 auf Nvidia braucht keinen eigenen Download — die volle fp16-Datei laden und im Load Diffusion Model-Node weight_dtype auf fp8_e4m3fn stellen.

Encoder und VAE — für dev und Krea identisch

T5XXL und CLIP-L → ComfyUI/models/clip/ (in neueren ComfyUI-Versionen auch text_encoders/); VAE → ComfyUI/models/vae/.

Ein Lizenz-Hinweis zur Trennung: Die Transformer-Dateien stehen in allen Formaten unter der FLUX Non-Commercial License von Black Forest Labs, weil auch die quantisierten Varianten Ableitungen der Originalgewichte sind. Die Encoder dagegen — CLIP-L und die T5-Varianten von comfyanonymous und city96 — stehen unter Apache-2.0. Mehr zur Lizenz im Abschnitt weiter unten.

Der DualCLIPLoader lädt die beiden Encoder — CLIP-L und T5XXL — und hat neben den zwei 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.

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. Derselbe Wert lässt sich in ComfyUI auch über einen separaten FluxGuidance-Node setzen statt im Feld des CLIPTextEncodeFlux — es ist dieselbe Guidance, nur an anderer Stelle im Graph.

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.

Ein Negativ-Prompt existiert im Standard-Flux-Graph nicht: Der BasicGuider nimmt nur das positive Conditioning, und die distillierte Guidance kennt kein Negativ-Conditioning. Das Negativ-Feld, das man vom SDXL-KSampler kennt, gibt es hier also nicht.

Flux verwendet den SamplerCustomAdvanced statt des klassischen KSampler. Die Parameter verteilen sich auf mehrere Nodes:

Flux.1 dev ist bei der Auflösung deutlich flexibler als SDXL. Entscheidend ist nicht das Seitenverhältnis, sondern die Gesamtfläche: Bleibst du in der Nähe von einem Megapixel — also rund 1.048.576 Pixel —, arbeitet das Modell in dem Bereich, auf den es trainiert wurde. Weiter oben wächst die Neigung zu Wiederholungen im Bild: doppelte Fenster, gespiegelte Details.

Die zweite Bedingung: Beide Kantenlängen müssen durch 16 teilbar sein. SDXL verlangt 64 — das ist der Grund, warum SDXL-Auflösungen und Flux-Auflösungen bei gleichem Seitenverhältnis leicht auseinanderlaufen.

Für Hochformat drehst du die Zahlen um — 832 × 1248, 768 × 1360. Anders als bei SDXL trifft Flux die Verhältnisse dabei sauber: 1152 × 864 ist echtes 4:3, während der entsprechende SDXL-Bucket 1152 × 896 streng genommen 9:7 ist.

Jedes andere Verhältnis rechnest du dir selbst aus:

Breite = round( 1024 · √(B/H) / 16 ) · 16
Höhe   = round( 1024 · √(H/B) / 16 ) · 16

Erst die ideale Kantenlänge aus Fläche und Wurzel des Verhältnisses, dann auf das nächste Vielfache von 16 runden. Diese Rundung ist auch der Grund, warum die Pixelsumme selten exakt bei 1.048.576 landet — die Abweichung von ein paar Prozent ist unkritisch.

Flux.1 Krea dev ist das ästhetische Geschwister von Flux.1 dev: dieselbe guidance-distillierte Rohbasis (flux-dev-raw), nur mit einem reinen Ästhetik-Post-Training darauf. Für dieses Setup heißt das: identische Pipeline. Gleiche Encoder (CLIP-L + T5XXL, DualCLIPLoader auf flux), gleicher guidance-Bereich, gleiche Sampler-Parameter (euler + simple, 20–25 Steps — für Krea dev eher 28–35, siehe 2.3.3), gleiches ControlNet Canny, dieselbe Speicher- und Quantisierungslogik aus den Abschnitten oben. Alles auf dieser Seite überträgt sich unverändert — du tauschst nur die Modelldatei im Load Diffusion Model- bzw. Unet Loader (GGUF)-Node.

Der einzige Unterschied liegt im Look: Krea dev erzeugt einen betont fotografischen, „filmischen" Charakter statt der glatten AI-Mitte — für einen fotografischen Look aktuell meine erste Wahl. Details im Setup-Artikel zu 2.3.3 — Flux.1 Krea dev.

Flux.1 dev steht unter der FLUX Non-Commercial License von Black Forest Labs (Version 2.0; bis November 2025 „FLUX [dev] Non-Commercial License“, inhaltlich unverändert).

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.