Recommended Quantized Ultra-Fast Prompt Expander for FLUX 3 / Qwen-Image-2.1 (Overseas Edition)
Don't Blame the Model First for Plain Output: A Killer Prompt Expander Using Only 7GB VRAM In short, whether a good image comes out rarely comes down to the model itself. Feed an AI image generator a one-liner like "a person walking a dog in afternoon sunlight" and the result often looks flat: bare
Kurz gesagt: Ob ein gutes Bild entsteht, hängt selten vom Modell selbst ab.
Füttert man einen KI-Bildgenerator mit einem Einzeiler wie „eine Person, die in Nachmittagssonne mit einem Hund spazieren geht“, wirkt das Ergebnis oft flach: karger oder einfallsloser Hintergrund, mangelnde Details, falsches Licht, mittelmäßige Komposition. Die meisten Nutzer machen dafür das Modell verantwortlich. Doch die offizielle FLUX 3 Dokumentation sagt es unmissverständlich: Klein wurde auf langen Szenenbeschreibungen trainiert; gibt man ihm einen nackten Einzeiler, leidet die Qualität spürbar.
Anders ausgedrückt: Was fehlt, ist kein besseres Bildmodell, sondern die Zwischenschicht, die einen Einzeiler in ein Regiebuch verwandelt. Black Forest Labs hat dafür einen eigenen Prompt Upsampler veröffentlicht, doch das Modell benötigt 18GB VRAM, und allein die Prompt-Erweiterung dauert 4–5 Sekunden, was Consumer-GPUs faktisch ausschließt. Die gute Nachricht: Die Community hat diesen 18GB-Expander auf rund 7GB VRAM komprimiert und dabei eine 3,6-fache Beschleunigung erreicht. Die Prompts, die er schreibt, sind nicht auf FLUX 3 beschränkt; sie funktionieren mit jedem anderen Bildgenerierungsmodell.
FLUX 3 Image Klein ist ein 5,6B großes Open-Source-Bildmodell, das Black Forest Labs im Oktober 2026 veröffentlicht hat. Es unterstützt Text-to-Image, referenzbasierte Bearbeitung, bis zu 10 Referenzbilder und Boxed Layout. Der zugehörige Prompt-Expander (flux-3-image-klein-pup) ist ein Sprachmodell, das vollständig aus Qwen3.5-9B per fine-tuning hervorgegangen ist; er erweitert den Einzeiler zu der vollständigen Beschreibung, die Bildmodelle tatsächlich benötigen: Medium, Stil, Szene, Licht, Kamera sowie Farbe, Material und Position jedes Motivs.
Es ist kein Zeichnungsmodell, das eigentliche Rendering übernimmt weiterhin FLUX 3, und auch kein generisches Werkzeug zum Text-Polieren. Seine Ausgabe ist ein „technisches Skript“, das für das Bildmodell geschrieben wurde. Es sitzt zwischen „deiner Idee“ und „dem Bildmodell“ und senkt die am häufigsten übersehene Hürde: die Prompt-Qualität. Klein wurde genau auf diese Art langer Szenenbeschreibungen trainiert, und die offizielle Dokumentation stellt klar, dass der Verzicht auf den Expander zu deutlich schlechteren Ergebnissen führt.
Der Expander rendert selbst keine Bilder, doch allein seine BF16-Gewichte belegen 18.8GB, mit einem Spitzenwert von nahezu 18GiB VRAM während der Generierung. Nutzer, die FLUX 3 lokal betreiben, haben den Großteil des VRAM bereits für das Bildmodell reserviert; weitere 18GB für diesen Mittelsmann zu reservieren, macht selbst 24GB-Karten unbrauchbar.
Diese quantisierte Version ( https://huggingface.co/tonera/flux-3-image-klein-pup-nunchaku ) verwendet SVDQ: Jede lineare Schicht über die 32 Sprachschichten wird auf INT4-Gewichte komprimiert (W4A16, Gruppengröße 128), einschließlich des lm_head; der Vision Tower, die Token-Embeddings und die RMSNorm-Schichten bleiben in Fließkomma. Die Kalibrierungsdaten bestehen aus Prompts, die vom Originalmodell erzeugt wurden, gemischt mit rund 25% allgemeinem Text.
Ergebnisse: Der Spitzenwert des VRAM-Bedarfs bei der Generierung sinkt von 17.75 GiB auf 7.02 GiB, eine Einsparung von etwa 10.7 GiB (60.5%); die Latenz pro Token sinkt von 15.43 ms auf 4.29 ms, eine 3,6-fache Beschleunigung.
Die Modellkarte enthält zwei Datensätze. Der erste umfasst die Geschwindigkeit pro Token und den Spitzenwert des VRAM (RTX 5090):
Text-to-Image-Erweiterung: 15.43 ms/Token → 4.29 ms/Token, 3,60-fache Beschleunigung; VRAM 17.75 → 7.02 GiB, 60.5% Einsparung.
Erweiterung zur Einzelbild-Bearbeitung: 15.35 → 4.35 ms/Token, 3,53-fache Beschleunigung; VRAM 17.93 → 7.21 GiB, 59.8% Einsparung.
Der zweite Datensatz umfasst End-to-End-Benchmarks auf einem dauerhaft laufenden Server: Die Text-to-Image-Erweiterung dauert insgesamt etwa 1.42 Sekunden (einschließlich 0.086 s bis zum ersten Token) und gibt 297 Token mit rund 221 Token/s aus; die Erweiterung zur Bearbeitung dauert etwa 1.17 Sekunden und gibt 200 Token mit rund 220 Token/s aus.
Methodik: bfloat16, greedy decoding, thinking mode deaktiviert; der Spitzenwert des VRAM skaliert nicht mit der Ausgabelänge. Diese Werte spiegeln nur diese Testumgebung wider und sind auf anderen GPUs als Referenzwerte zu betrachten.
Die empfohlene Bereitstellung für diesen quantisierten Build ist ein dauerhaft laufender Expansionsdienst: Einmal auf die GPU geladen, bleibt das Modell resident, sodass weitere Anfragen direkt ohne erneutes Laden generiert werden. Er stellt einen Endpoint bereit, der mit OpenAI Chat Completions kompatibel ist und sich mit bestehenden OpenAI SDKs direkt aufrufen lässt.
Start des Dienstes (standardmäßig auf 0.0.0.0:8000 lauschend):
python api.py Enter fullscreen mode Exit fullscreen mode Der Dienst unterstützt zwei Modi: reine Text-to-Image-Erweiterung (t2i) und referenzgestützte Erweiterung zur Bearbeitung (i2i). Referenzbilder können als http(s)-URLs, Base64-Strings oder lokale file://-Pfade auf dem Server übergeben werden; bis zu 10 Bilder pro Anfrage, jeweils maximal 20MB. Der komplette Workflow ist unten dargestellt:
Sobald der Dienst läuft, lässt er sich direkt mit curl aufrufen:
curl http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model":"flux-3-image-klein-pup","messages":[{"role":"user","content":"A girl is holding a sign says:CreatePPTX.com"}]}' Enter fullscreen mode Exit fullscreen mode Wer keinen Server betreiben möchte, kann NunchakuQwen3_5ForConditionalGeneration direkt in Python aufrufen und die Erweiterung per Code über eine Transformers-artige API durchführen. Beide Wege erfordern zwei Abhängigkeiten: einen Transformers-Build mit Qwen3.5-Unterstützung und das Nunchaku-Wheel. Zu beachten ist, dass der offizielle Nunchaku-Build derzeit nicht verfügbar ist; man muss die vorgefertigte Community-Version verwenden ( https://huggingface.co/tonera/vitoom-nunchaku ) und das Wheel auswählen, das zur lokalen Python-, CUDA- und PyTorch-Version passt.
Hinweis zur Bereitstellung: Der Dienst ist standardmäßig ohne Authentifizierung, und file://-Pfade können lokale Serverdateien lesen, daher sollte er nur in einem vertrauenswürdigen Netzwerk erreichbar sein oder hinter einem Reverse Proxy mit Authentifizierung stehen.
INT4- und BF16-Ausgaben sind nicht wortidentisch. Formulierung und Länge unterscheiden sich leicht (die INT4-Ausgabe ist etwas kürzer), doch die Qualität, die das Bildmodell erhält, ist vergleichbar; eine exakte wörtliche Reproduktion ist nicht nötig.
Die Leistungsmessungen wurden ausschließlich auf einer RTX 5090 durchgeführt. Geschwindigkeits- und VRAM-Werte auf anderen GPUs sollten als grobe Referenz betrachtet werden.
Der Dienst stellt nur die Modi t2i und i2i bereit. Das zugrunde liegende Modell unterstützt auch Boxed Layout; dafür muss man den Dienst umgehen und das Modell direkt aufrufen.
Expansion ist kein Allheilmittel. Wer bereits selbst detaillierte Beschreibungen verfasst, erhält durch den Expander nur begrenzten Mehrwert; seine Stärke liegt gezielt darin, die Lücke zwischen einem Einzeiler und einer langen Beschreibung zu schließen.
Eine Installation lohnt sich: wenn man den kompletten FLUX 3 Stack oder Qwen-Image-2.1 lokal mit knappem VRAM betreibt (besonders 24GB oder weniger); wenn man einen dauerhaft laufenden Prompt-Expansionsdienst möchte, der sich in bestehende Workflows einbinden lässt; oder wenn man häufig referenzbasierte sekundäre Bearbeitungen durchführt. Trifft auch nur einer dieser Punkte zu, zahlt sich die Investition von 7GB VRAM aus.
Nicht nötig ist es, wenn man nur Cloud-APIs nutzt und keine lokale Generierung betreibt; wenn man reichlich VRAM hat und den 18GB-Bedarf nicht stört; oder wenn man Prompts nur gelegentlich erweitert und keinen dauerhaft laufenden Dienst pflegen möchte.
Fazit: Es verbessert nicht die Modellfähigkeit, sondern senkt die Übersetzungskosten zwischen „einer Idee“ und „einem Prompt“. Der INT4-Build reduziert den VRAM-Aufwand dieser Übersetzung von rund 18GB auf 7GB und erreicht 221 Token/s, sodass ein lokaler FLUX 3 Workflow erstmals „leicht“ anfühlt.
Empfehlung: Zuerst den Expansionsserver lokal starten, in den bestehenden Workflow einbinden, um eine Runde Prompts zu testen, und nach Bestätigung der Ausgabequalität über eine langfristige Bereitstellung entscheiden. Das Modell ist unter Apache 2.0 veröffentlicht und kann frei zur Evaluierung heruntergeladen werden.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
In short, whether a good image comes out rarely comes down to the model itself.
Feed an AI image generator a one-liner like "a person walking a dog in afternoon sunlight" and the result often looks flat: bare or one-note background, poor detail, wrong lighting, mediocre composition. Most users blame the model. But the official FLUX 3 docs put it plainly: Klein was trained on long scene descriptions; feeding it a raw one-liner causes a noticeable drop in quality.
Put another way, what's missing isn't a better image model — it's the middle layer that turns a one-liner into a director's script. Black Forest Labs released a dedicated Prompt Upsampler for this, but the model needs 18GB of VRAM to run, and prompt expansion alone takes 4–5 seconds, effectively ruling out consumer GPUs. The good news: the community has compressed this 18GB expander to roughly 7GB VRAM while delivering a 3.6× speedup. The prompts it writes aren't limited to FLUX 3; they work with any other image generation model.
FLUX 3 Image Klein is a 5.6B open-source image model released by Black Forest Labs in October 2026, supporting text-to-image, reference-based editing, up to 10 reference images, and boxed layout. Its companion prompt expander (flux-3-image-klein-pup) is a language model fully fine-tuned from Qwen3.5-9B; it expands your one-liner into the full description image models actually need: medium, style, scene, lighting, camera, plus the color, material, and position of every subject.
It isn't a drawing model — FLUX 3 still handles the actual rendering; nor is it a generic copy-polishing tool. Its output is a "technical script" written for the image model. It sits between "your idea" and "the image model," lowering the most overlooked barrier: prompt quality. Klein was trained on exactly this kind of long scene caption, and the official docs state clearly that bypassing the expander leads to noticeably worse results.
The expander doesn't render images, yet its BF16 weights alone take 18.8GB, with peak VRAM near 18GiB during generation. Users running FLUX 3 locally already allocate most VRAM to the image model; reserving another 18GB for this middleman makes even 24GB cards unusable.
This quantized version ( https://huggingface\.co/tonera/flux\-3\-image\-klein\-pup\-nunchaku\ ) uses SVDQ: every linear layer across the 32 language layers is compressed to INT4 weights (W4A16, group size 128), including the lm_head; the vision tower, token embeddings, and RMSNorm layers remain in floating point. Calibration data consists of prompts generated by the original model, mixed with roughly 25% general-domain text.
Results: peak generation VRAM drops from 17.75 GiB to 7.02 GiB, saving about 10.7 GiB (60.5%); per-token latency falls from 15.43 ms to 4.29 ms, a 3.6× speedup.
The model card provides two datasets. The first covers per-token speed and peak VRAM (RTX 5090):
Text-to-image expansion: 15.43 ms/token → 4.29 ms/token, 3.60× speedup; VRAM 17.75 → 7.02 GiB, 60.5% savings.
Single-image editing expansion: 15.35 → 4.35 ms/token, 3.53× speedup; VRAM 17.93 → 7.21 GiB, 59.8% savings.
The second set covers end-to-end benchmarks on a resident server: text-to-image expansion takes ~1.42 seconds total (including 0.086 s to first token), outputting 297 tokens at ~221 tokens/s; editing expansion takes ~1.17 seconds, outputting 200 tokens at ~220 tokens/s.
Methodology: bfloat16, greedy decoding, thinking mode disabled; peak VRAM does not scale with output length. These figures reflect only this test environment and are reference values on other GPUs.
The recommended deployment for this quantized build is a resident expansion service: once loaded onto the GPU, the model stays resident, so subsequent requests generate directly without reloading. It exposes an OpenAI Chat Completions-compatible endpoint, callable as-is by existing OpenAI SDKs.
Start the service (listening on 0.0.0.0:8000 by default):
python api.py Enter fullscreen mode Exit fullscreen mode The service supports two modes: plain-text text-to-image expansion (t2i) and reference-guided editing expansion (i2i). Reference images can be passed as http(s) URLs, base64 strings, or local file:// paths on the server; up to 10 images per request, each no larger than 20MB. The full workflow is shown below:
Once the service is running, call it directly with curl:
curl http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model":"flux-3-image-klein-pup","messages":[{"role":"user","content":"A girl is holding a sign says:CreatePPTX.com"}]}' Enter fullscreen mode Exit fullscreen mode If you prefer not to run a server, you can call NunchakuQwen3_5ForConditionalGeneration directly in Python, performing expansion in code via a Transformers-style API. Both approaches require two dependencies: a Transformers build supporting Qwen3.5, and the Nunchaku wheel. Note that the official Nunchaku build is currently unavailable; you must use the community prebuilt version ( https://huggingface\.co/tonera/vitoom\-nunchaku\ ) and select the wheel matching your local Python, CUDA, and PyTorch versions.
Deployment note: the service has no authentication by default, and file:// paths can read local server files, so it should only be exposed on a trusted network or placed behind an authenticated reverse proxy.
INT4 and BF16 outputs are not word-for-word identical. Wording and length differ slightly (INT4 output is a bit shorter), but the quality delivered to the image model is comparable; exact verbatim reproduction is unnecessary.
Performance benchmarks were measured only on an RTX 5090. Speed and VRAM figures on other GPUs should be treated as rough references.
The service only exposes t2i and i2i modes. The upstream model also supports boxed layout; to use it you must bypass the service and call the model directly.
Expansion isn't a silver bullet. If you already write detailed descriptions yourself, the expander adds limited value; its strength lies specifically in bridging the gap from a one-liner to a long description.
Worth installing: you run the full FLUX 3 stack or Qwen-Image-2.1 locally with tight VRAM (especially 24GB or lower); you want a resident prompt expansion service reused across existing workflows; you frequently do reference-based secondary edits. If any one of these applies, the 7GB VRAM investment pays off.
Not necessary: you only use cloud APIs and do no local generation; you have abundant VRAM and don't care about the 18GB footprint; you only expand prompts occasionally and don't want to maintain a resident service.
Bottom line: it doesn't improve model capability; it reduces the translation cost between "an idea" and "a prompt." The INT4 build cuts the VRAM cost of this translation from ~18GB to 7GB and reaches 221 tokens/s, making a local FLUX 3 workflow feel "light" for the first time.
Recommendation: start the expansion server locally first, plug it into your existing workflow to test a round of prompts, and decide on long-term deployment after confirming output quality. The model is released under Apache 2.0 and can be downloaded for evaluation freely.