FLUX.3 Image Klein: offene Gewichte und Diffusers-Start mit Layout-Box-Steuerung
Laut einem am 15. Oktober 2026 veröffentlichten Blogbeitrag von Hugging Face erscheint Black Forest Labs' FLUX.3 Image Klein mit zwei offenen Checkpoints und ist am ersten Tag in Diffusers verfügbar. Dasselbe Modell unterstützt Text-zu-Bild, Bild-zu-Bild mit mehreren Referenzbildern und Layout-Steuerung per Bounding-Box; der destillierte Checkpoint erzeugt auf einer H100 in rund 2 Sekunden ein 1024×1024-Bild. Zusätzlich werden NVFP4- und FP8-Einzeldateigewichte sowie LoRA-Trainingsskripte genannt.
Was sich geändert hat
Laut dem offiziellen Blogbeitrag von Hugging Face vom 15. Oktober 2026 hat Black Forest Labs FLUX.3 Image Klein veröffentlicht und gibt an, dass es am ersten Tag in Diffusers lauffähig sei. Der Blogbeitrag nennt zwei offene Checkpoints: black-forest-labs/flux-3-image-klein als zeitdestillierte Variante mit standardmäßig 16 Schritten und ohne Classifier-Free-Guidance; flux-3-image-klein-base als Basismodell mit standardmäßig 50 Schritten und Guidance, das laut Blogbeitrag besser für Feintuning geeignet ist. Funktional deckt dasselbe Modell Text-zu-Bild, Bild-zu-Bild mit einem oder mehreren Referenzbildern sowie Layout-Steuerung ab, bei der eine JSON-Regionsliste in den Prompt geschrieben wird. Regionen nutzen die Felder id, bbox und desc, die Koordinaten werden als [y_min, x_min, y_max, x_max] auf einer normalisierten Skala von 0 bis 1000 angegeben; laut Blogbeitrag gilt dieselbe Box für beliebige Bildgrößen. In Bearbeitungsszenarien beschreiben src_bbox und tgt_bbox, woher der Inhalt im Referenzbild stammt und wohin er im Ausgabebild verschoben wird. Der Blogbeitrag gibt an, dass der distilled-Checkpoint auf einer H100 in rund 1,93 Sekunden ein 1024×1024-Bild erzeugt und ein 1024×1024-Referenzbild die Dauer auf etwa das Doppelte, nämlich 3,87 Sekunden, erhöht, weil jeder Transformer-Aufruf 4096 zusätzliche Referenz-Token erhält. Der Blogbeitrag nennt außerdem NVFP4- und zeilenweise FP8-Einzeldateigewichte, ein DreamBooth-LoRA-Trainingsskript und eine Beschreibung der modularen Modular-Diffusers-Pipeline; der Textencoder ist Qwen3-VL. Diese Leistungs- und Funktionsangaben stammen von den Blogautoren und wurden von dieser Redaktion nicht unabhängig reproduziert.
Auswirkungen für Entwickler
Für Teams mit eigener Inferenz ist das Bemerkenswerteste nicht ein weiteres Modell, sondern dass Layout-Steuerung „Position“ zu einer programmierbaren Eingabe macht. Die Regionskoordinaten sind normalisiert, sodass dieselbe Frontend-Annotation auf unterschiedliche Ausgabauflösungen übertragen werden kann; für Pipelines mit festem Bildaufbau wie E-Commerce-Bilder, Plakatlayouts oder Material-Bearbeitung ist das eine strukturelle Änderung, nicht nur ein Prompt-Trick. Zweitens ist die Speicheraufteilung klar geschichtet: Die im Blogbeitrag genannten Spitzenwerte zeigen bf16 bei etwa 18,8 GiB nach dem Laden und etwa 20,7 GiB nach der Inferenz, während FP8 und NVFP4 auf etwa 14,35 bzw. 13,4 GiB sinken; das bestimmt die Arbeitsteilung zwischen Consumer-Karten und Rechenzentrums-Karten. Drittens verändert das Referenzbild das Kostenmodell: Jedes 1024×1024-Referenzbild fügt pro Transformer-Aufruf 4096 Token hinzu, sodass Latenz und Speicherbedarf bei Mehrfachreferenz-Bearbeitung mit der Anzahl der Referenzen näherungsweise linear steigen; die Kapazitätsplanung darf nicht mit Text-zu-Bild-Zahlen hochgerechnet werden. Viertens auf Ebene der Engineering-Schnittstelle: Das Modell erscheint in Form von Modular Diffusers; der Blogbeitrag zeigt, wie man den Textencoder abtrennt, um „einmal kodieren, mehrfach generieren“ zu ermöglichen, und wie man benutzerdefinierte Schritte in die Denoising-Schleife einfügt. Dadurch können Caching, Telemetrie und Qualitätsüberwachung innerhalb der Pipeline liegen statt in einem Blackbox-Aufruf außerhalb. Zu beachten ist, dass diese Vorteile nur bei selbst gehosteten Gewichten gelten; der Blogbeitrag beschreibt keine Verfügbarkeit, Rate Limits oder Abrechnung einer gehosteten API. Bevor Teams Layout-Steuerung in die Produktion einbinden, müssen sie daher Gewichtsverteilung, Speicher und Nebenläufigkeitssteuerung selbst tragen.
Integration und Bewertung
Das Folgende sind Einschätzungen und Empfehlungen auf Basis der Quelle, keine bestätigten Tatsachen. Die erste Entscheidung betrifft die Checkpoint-Wahl: Laut Blogbeitrag nutzt die distilled-Version standardmäßig 16 Schritte ohne CFG, die Basisversion standardmäßig 50 Schritte mit Guidance und eignet sich für Feintuning. Geht es um Massenbilderzeugung mit durchschnittlichen Anforderungen an Stilkonsistenz, kann man zunächst die distilled-Version zur Latenzsenkung verwenden; wer LoRA-Feintuning braucht oder empfindlich auf die Guidance-Stärke reagiert, sollte mit den Basisgewichten beginnen. Voraussetzung sind Trainingsdaten und Speicherbudget: Das Blogbeispiel trainiert 1500 Schritte bei 1024 Auflösung, Batch Size 1 und Rank 16 und empfiehlt Gradient Checkpointing, das Cachen latenter Variablen und 8-Bit-Adam zur Speicherreduzierung. Ein messbares Bewertungskriterium ist der Unterschied der Nutzbarkeitsrate zwischen distilled mit 16 Schritten und Basis mit 50 Schritten in einer verblindeten menschlichen Bewertung bei festem Prompt-Set sowie die End-to-End-Dauer pro Bild beider Varianten im selben Batch. Die zweite Entscheidung betrifft das Quantisierungsformat: Laut Blogbeitrag kann fp8r auf Compute Capability 8.9 und höher (Ada, Hopper, Blackwell) schnelle Kernel nutzen, während auf anderen GPUs die Gewichte pro Schritt dequantisiert werden, was weniger Speicher, aber keine Beschleunigung bringt; NVFP4 erfordert Blackwell und verlangt übereinstimmende Versionen von flashinfer-python und flashinfer-cubin. Quantisierung ist also keine bedingungslose Beschleunigung, die Wahl hängt vom Kartenmodell ab: Auf Ada/Hopper kann fp8r bevorzugt werden, um Speicher zu sparen, auf Blackwell kommt NVFP4 infrage, während auf älteren Karten Quantisierung vor allem das Passen, nicht das Schnellerlaufen erkauft. Messgrößen sind die Einzelbildlatenz bei gleicher Auflösung und gleichem Prompt sowie mögliche wahrnehmbare Qualitätsverluste durch die Dequantisierung. Die dritte Entscheidung betrifft, ob sich die Einbindung der Layout-Steuerung lohnt: Laut Blogbeitrag teilen Referenzbild und Ausgabe dasselbe (h, w)-Koordinatensystem, dieselbe Position hat für das Modell eine präzise Bedeutung; genau das ist die Grundlage dafür, dass Box-Bearbeitung funktioniert. Derselbe Mechanismus bedeutet aber, dass mit mehr Referenzbildern auch die Token pro Aufruf steigen. Es empfiehlt sich, zuerst mit einem festen Evaluationsset zu messen, wie genau Layout-Anweisungen innerhalb der Box landen und wie stark unveränderte Szenenteile driften, bevor man Skizzenannotationen in den Produktprozess aufnimmt. Entspricht das nicht den Erwartungen, kann man auf reine Text-zu-Bild-Erzeugung mit nachgelagertem Layout zurückfallen, deren Kostenstruktur besser vorhersagbar ist.
Grenzen und offene Fragen
Wesentliche Einschränkung: Zum Stand dieser Katalogprüfung erscheinen FLUX.3 Image Klein und die Version flux-3-image-klein-base nicht im aktuell gelisteten Modellkatalog von KimiSeek, und diese Redaktion kennt auch keine Hosting-Pläne dafür auf dieser Plattform; alle Beschreibungen zu Gewichten, Skripten und Leistung in diesem Artikel stammen aus dem Original-Blogbeitrag von Hugging Face, geben die Darstellung der Quelle wieder und wurden von dieser Redaktion nicht unabhängig reproduziert. Die im Blogbeitrag genannten Latenz- und Speicherwerte stammen aus drei Arbeitsabläufen auf einer einzelnen H100 80GB, ohne Offloading, mit Standard-Attention-Backend, gemittelt über drei Läufe; sie lassen sich nicht ohne Weiteres auf andere GPUs, andere Attention-Backends oder eingeschaltetes CPU-Offload übertragen, und der Blogbeitrag erklärt ausdrücklich, dass Offloading-Szenarien nicht verglichen wurden. Der Einfluss der Referenzbildanzahl auf die Latenz wird nur mit einer einzigen Referenz praktisch belegt; Verhalten bei mehreren Referenzen, sehr hohen Auflösungen oder langen Batches muss selbst getestet werden. Verfügbare Gewichte bedeuten keine großzügige Lizenz: Der Blogbeitrag verwendet durchgängig den Begriff „offene Checkpoints“ und erläutert in diesem Text keine konkreten Lizenzbedingungen oder kommerziellen Konditionen; Teams sollten vor kommerzieller Nutzung der Gewichte die Modellkarte und den Lizenztext prüfen. Das LoRA-Trainingsbeispiel ist nur eine Demonstration mit einem einzigen Datensatz und einem einzigen Stil; ob sich Konvergenzschritte, Rank und Optimierer-Kombination auf eigene Daten übertragen lassen, ist nicht garantiert. Zudem gibt der Blogbeitrag an, dass die Pipeline pro Aufruf nur einen Prompt akzeptiert und Prompts auf ein Vielfaches von 80 Token aufgefüllt und von der Attention berücksichtigt werden; Batch- und Prompt-Verkettungsweisen müssen entsprechend angepasst werden. Preise und Hosting-Verfügbarkeit können sich ändern; wenn später Preise einer API verfolgt werden, gilt die Preisseite des Anbieters.
Abbildungen aus dem Originalbericht
