# Qwen-Image-2.1 auf Athena Stand: 21. September 2026. Qwen-Image-2.1 ist der produktive Bildworker des Routers. FLUX.2 Klein 9B FP8 bleibt als gestoppter Rückfallcontainer erhalten. ## Gepinnter Stand - ComfyUI: Commit `b0f4b7b294ce482a2e071d9d762c133d38c7aa07` - Modell-Repository: `Comfy-Org/Qwen-Image-2.1`, Revision `ace0edeb3791a594ddfa36ed5f41a178a394e921` - Transformer: `qwen_image_2.1_int8_convrot.safetensors` (`cb74113cb03faecd79611b01fd7fd642f0aa60d6f0b95086abee214d75eaa57d`) - Textencoder: `qwen3vl_8b_int8_convrot.safetensors` (`8bfd0f6e12abf2d2d697ecc888e5e90b0d6741d6708f05799f53afa560452e8f`) - VAE: `qwen_image_2.1_vae_bf16.safetensors` (`bb21f7473051e1ac368515dd3f2e15cd44d7a11748ee8823e1ddca3e4876b7c9`) - Pipeline: 25 Schritte, CFG 1, Euler/Simple, `--lowvram` - GPU: ausschließlich Athena-GPU 1, die RTX 5080 mit 16 GB Die Gewichte liegen außerhalb von Git unter `/data/models/Qwen-Image-2.1-ComfyUI`. Der Adapter `platform/docker/qwen-image-worker/qwen_image_worker.py` stellt vor ComfyUI die bestehende private Worker-API auf Port 8086 bereit. Der öffentliche Routervertrag bleibt damit `/v1/images/generations` und `/v1/images/edits`. Der Container läuft wie der Router mit UID/GID `10002:10002`, damit beide das gemeinsame Bild-Volume ohne erweiterte Linux-Capabilities verwenden können. ## Lebenszyklus Ein Bildauftrag läuft transaktional: 1. Der Router merkt sich das aktive Textprofil. 2. Der Profile Controller stoppt LLM, TTS und andere GPU-Spezialworker. 3. `mike-ai-image-worker` startet Qwen Image auf der RTX 5080. 4. Der Adapter erzeugt das Bild oder bearbeitet bis zu vier Referenzbilder. 5. Der Qwen-Worker wird vollständig gestoppt. 6. Das vorherige Textprofil und Qwen3-TTS werden wiederhergestellt. Der Container ist außerhalb eines Auftrags gestoppt. Das ist der Sollzustand. ## Reproduzierbare Vorbereitung ```bash cd /opt/mike-ai/stack sudo ./scripts/prepare-qwen-image-21.sh ``` Das Skript lädt fehlende Dateien mit festen SHA-256-Prüfsummen, baut den produktiven Qwen-Worker und legt Qwen sowie FLUX gestoppt an. Es lädt dabei kein Modell in den VRAM. ## Funktionsprobe über den echten Routerweg ```bash curl -sS http://127.0.0.1:8081/v1/images/generations \ -H 'Content-Type: application/json' \ -d '{ "model":"Qwen-Image-2.1-int8", "prompt":"Fotorealistisches rotes Haus bei Tageslicht", "size":"1024x1024", "steps":25, "guidance":1.0, "response_format":"url" }' ``` Nach dem Lauf müssen `mike-ai-image-worker` und `mike-ai-flux-image-worker` gestoppt sein und das vorherige LLM-Profil wieder gesund laufen. ## OpenClaw 2026.9.5 OpenClaws eingebautes Werkzeug `image_generate` verwendet den separaten Medienmodell-Eintrag. Er muss auf den OpenAI-kompatiblen Athena-Router zeigen: ```bash openclaw config set agents.defaults.mediaModels.image.primary \ openai/Qwen-Image-2.1-int8 openclaw config set agents.defaults.mediaModels.image.fallbacks '[]' \ --strict-json ``` Der Provider `models.providers.openai.baseUrl` bleibt `http://192.168.1.212:8081/v1`. `openclaw models set-image` ist hierfür nicht der richtige Befehl: Er schreibt `agents.defaults.imageModel`, nicht den von `image_generate` verwendeten Medienmodell-Eintrag. Ein alter Wert unter `agents.defaults.imageModel` wird mit folgendem Befehl entfernt: ```bash openclaw config unset agents.defaults.imageModel ``` Die leere Fallbackliste verhindert, dass OpenClaw bei einem lokalen Fehler unbemerkt auf `openai/gpt-image-2` ausweicht. OpenClaw überträgt Referenzbilder an `/v1/images/edits` als OpenAI-kompatibles Multipart-Formular mit dem Feld `image[]`. Der Router akzeptiert dort ein bis vier Referenzbilder und normalisiert numerische Formularwerte wie `n` und `steps`. Der ältere JSON-/Base64-Weg bleibt für bestehende Clients erhalten. Beim ersten Wechsel von FLUX auf Qwen funktionierten Referenzbilder deshalb nicht: Der neue Qwen-Pfad verstand zunächst nur den älteren JSON-/Base64-Weg. Zusätzlich war anfangs `agents.defaults.imageModel` gesetzt, obwohl OpenClaws `image_generate` den Eintrag unter `agents.defaults.mediaModels.image` verwendet. Das waren Lücken der neuen Qwen-Integration. Der zuvor produktive FLUX-Pfad war davon nicht betroffen. ## Produktionsvalidierung vom 21. September 2026 Beide öffentlichen Routerpfade wurden auf Athena mit dem produktiven Stack geprüft: - Text zu Bild: gültiges PNG mit 1024×1024 Pixeln, 25 Schritte, `Qwen-Image-2.1-int8`; 48,9 Sekunden reine Bildpipeline und 71,6 Sekunden für den vollständigen transaktionalen Routerlauf. - Bildbearbeitung: gültiges PNG mit 1024×1024 Pixeln aus einem Referenzbild, 25 Schritte, `Qwen-Image-2.1-int8`; 76,3 Sekunden für den vollständigen Routerlauf. Nach beiden Aufträgen waren Qwen und FLUX gestoppt. `mike-ai-llama-medium`, Qwen3-TTS, Router und Profile Controller liefen anschließend wieder gesund. Damit sind Erzeugung, Referenzbildübergabe und Wiederherstellung des zuvor aktiven Textprofils über den echten Routerweg bestätigt. Zusätzlich wurde `image_generate` am 21. September 2026 über einen isolierten OpenClaw-`agent exec`-Lauf geprüft. OpenClaw rief `openai/Qwen-Image-2.1-int8` einmal auf; Athena erzeugte das PNG und stellte Medium sowie Qwen3-TTS nach 72,5 Sekunden wieder gesund her. Auch die Referenzbildbearbeitung wurde anschließend über das echte OpenClaw-Werkzeug `image_generate` geprüft. OpenClaw übergab ein Referenzbild als `image[]`; der Router erzeugte mit `Qwen-Image-2.1-int8` ein gültiges PNG mit 1024×1024 Pixeln und meldete im Sidecar `mode: image-edit` sowie `reference_images: 1`. Medium und Qwen3-TTS liefen nach dem Auftrag wieder gesund, der Bildworker wurde erwartungsgemäß gestoppt. ## FLUX-Rückfallpfad FLUX verwendet weiterhin das Image `mike-ai/image-worker:local`, die bestehenden Modellverzeichnisse und den Container `mike-ai-flux-image-worker`. Er hat das Controller-Label `flux-standby` und kann deshalb nicht durch einen normalen Router-Bildauftrag gestartet werden. Eine manuelle Diagnose ist nur über den allowlist-beschränkten Controllerpfad `/workers/flux-standby/start` möglich. Für eine dauerhafte Rückschaltung müssen Service-DNS, Modellname und Schrittzahl gemeinsam in Compose auf FLUX gesetzt und anschließend Router und Controller neu ausgerollt werden. Keine dieser Änderungen erfolgt automatisch. Historische FLUX-Messwerte und Grenzen stehen in [FLUX_9B_BETA.md](FLUX_9B_BETA.md) und [FLUX_RESOLUTION_TEST_20260912.md](FLUX_RESOLUTION_TEST_20260912.md). ## Offizieller Prompt Enhancer: Vorabtest vom 21. September 2026 Qwen veröffentlicht für Referenzbild-Aufträge einen separaten, auf Qwen3.5-VL 9B nachtrainierten Prompt Enhancer. Er ist kein Bestandteil der Qwen-Image-Gewichte und wird vom ComfyUI-Workflow nicht automatisch geladen. Der produktive Router verwendet ihn derzeit noch nicht; der folgende Test prüfte zunächst Speicherbedarf, Laufzeit und Wirkung. Geprüft wurde `Qwen/Qwen-Image-2.1-PE-I2I`, Revision `72927bc08afc99b7888ceb7d7d51a12db3700bbd`. Der offizielle Systemprompt verlangt bei mehreren Eingabebildern eine strukturierte Zuordnung und liefert zusätzlich `wh_ratio` beziehungsweise `ratio_follow`. ### FP8 auf der RTX 3060 Der vorquantisierte Testcheckpoint `prithivMLmods/Qwen-Image-2.1-PE-I2I-FP8`, Revision `ac9065ce94fdc39b9aecfff7d11f297b77a5c178`, umfasst 13,54 GB und passt einschließlich Laufzeit- und Aktivierungsspeicher nicht vollständig in die 12-GB-RTX-3060: - mit 11.264 MiB Modellbudget scheiterte das Laden bei nur noch 32 MiB freiem VRAM an einer weiteren 96-MiB-Allokation; - mit 9.216 MiB Modellbudget und CPU-Offload scheiterte die Inferenz bei nur noch 78 MiB freiem VRAM an einer 136-MiB-Allokation; - mit 7.168 MiB Modellbudget, CPU-Offload und auf 262.144 Pixel verkleinerten Referenzen lief die Inferenz, erzeugte wegen der langsamen Transformers- Referenzkerne aber auch nach mehr als drei Minuten noch keinen Rewrite. Der FP8-Testcheckpoint wurde anschließend wieder entfernt. FP8 mit CPU-Offload ist damit kein sinnvoller Produktionspfad auf dieser 3060. ### Q5 vollständig auf der RTX 3060 Als funktionierender Vergleich wurde dieselbe PE-I2I-Feinabstimmung als `Q5_K_M`-GGUF aus `prithivMLmods/Qwen-Image-2.1-PE-I2I-GGUF`, Revision `55b9c1a326599e142d59bcad8715d5601ccf8daa`, mit llama.cpp Build 10930 getestet. Die Dateien liegen vorerst außerhalb von Git unter `/data/models/qwen-image-2.1-pe-i2i-q5-test`: | Datei | SHA-256 | |---|---| | `Qwen-Image-2.1-PE-I2I.Q5_K_M.gguf` | `cb71f71fe5fe5938570d65a7c403fbcb1a9065dff9dd9a021f58aec42785b84e` | | `Qwen-Image-2.1-PE-I2I.mmproj-bf16.gguf` | `8dedb71dbc3092dc47de9108ad373d68a12854e2527d59bd9399601738f3bce1` | Mit vier Peter-Maffay-Referenzbildern belegte der Rewriter 7.167 MiB VRAM. Der erste Prefill umfasste 10.045 Tokens und lief mit 791,3 Token/s; die Ausgabe lief mit 45,9 Token/s. Ohne Denkbudget verbrauchte das Modell mehr als 4.096 Ausgabetokens. Mit `thinking_budget_tokens: 2048` lieferte es nach 52,0 Sekunden gültiges JSON mit 2.384 Ausgabetokens. Der Rewrite erkannte die vier Bilder als dieselbe Person und formulierte ausdrücklich eine einzelne Person, genau eine Gummiente und ein neues 3:4-Motiv. Der anschließende Ende-zu-Ende-Lauf hielt den Rewriter auf der RTX 3060 und Qwen-Image-2.1 auf der RTX 5080. Qwen-Image benötigte 193,18 Sekunden und erzeugte ein neues PNG mit 1.312 × 1.824 Pixeln, genau einer Person und genau einer gelben Gummiente. Das Ergebnis liegt im Router-Bildvolume als `qwen-pe-e2e.png`; SHA-256: `931cd3cf46993aee735e95c7c2447c500a498ffb600a26a96f5faab87a0260e9`. Nach dem Test wurden beide Testworker gestoppt und Medium sowie Qwen3-TTS wieder gesund gestartet. Der Q5-Checkpoint bleibt für die geplante Routerintegration liegen, ist aber noch kein automatisch gestarteter Produktionsdienst.