michael/AI-Profile-Router
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5106d0d2ed176aaf2e495edb6bdfb61407058688
AI-Profile-Router/docs/QWEN_IMAGE_21.md
T

9.7 KiB
Raw Blame History

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

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

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:

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:

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 und 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.

Reference in New Issue View Git Blame Copy Permalink