Trial GPU-resident Qwen3.5-9B with verified 4B rollback

docs/QWEN9B_TRIAL.md

@@ -0,0 +1,114 @@
+# Qwen3.5-9B auf der RTX 3080 erproben
+
+Stand: 27.10.2026. Ziel ist bessere Alltagsqualität bei vollständigem GPU-Offload
+des Sprachmodells und weiter nutzbarem Hyprland-/Browser-Desktop. Die Freigabe
+ist eine Erprobung, keine Langzeit-Stabilitätszusage oder Qualitätsbewertung.
+
+## Profile und Schutzgrenzen
+
+- `routine`: Qwen3.5-9B IQ4_XS, 65536 Kontexttokens, Q4_0-K/V-Cache,
+  vollständiger GPU-Offload (`--n-gpu-layers 99 --fit off`), Batch 512,
+  Microbatch 128. Der Bildprojektor läuft mit `--no-mmproj-offload` auf der CPU.
+- `fallback`: das bisherige Qwen3.5-4B Q4_K_M mit 65536 Kontexttokens und
+  Q8_0-K/V-Cache. Auf Archwork wurde die aktive Ausgangskonfiguration unverändert
+  als `llama-fallback.env` übernommen. Eine Neuinstallation erzeugt sie aus dem Manifest.
+- `large`: bisheriges Qwen3.8-27B-Profil für bewusste Einzelnutzung.
+
+Die Gewichte und der Bildprojektor sind in `config/models.lock.json` mit fester
+Hugging-Face-Revision, Dateigröße und SHA-256 fixiert. Der Projektor bleibt erhalten;
+die Bildverarbeitung benötigt CPU-Zeit. IQ4_XS und der Q4_0-Kontextcache sparen
+Speicher gegenüber Q4_K_M/Q8_0 und können die Antwortqualität beeinflussen.
+
+Hermes und Server bleiben bei 65536 Kontexttokens; die CPU-Kompression beginnt
+spätestens bei 24000 Tokens. Antwortlimit 2048 Tokens, Request-Watchdog und
+bestehende Zeitbudgets bleiben bestehen. Die jetzige Hermes-Version verlangt
+mindestens 64000 Kontexttokens: Eine 16K-Konfiguration wird beim Agentstart
+abgelehnt, auch wenn der Modellserver selbst antwortet. Das wurde lokal geprüft.
+Der Modellschalter lehnt bei vorhandener Hermes-Konfiguration Metadaten unter
+dieser Grenze ab und stellt bei Fehlern die vorherige Modell- und Hermes-Konfiguration
+wieder her.
+
+## Messungen und verworfene Konfigurationen
+
+Alle Speicherangaben sind MiB laut `nvidia-smi`; die freie Menge hängt von den
+gleichzeitig laufenden Desktop-Anwendungen ab und ist nicht reserviert.
+
+| Konfiguration | Beobachtung |
+|---|---|
+| 4B Q4_K_M, 64K, GPU-Projektor | Vergleichstest: mindestens 2288 MiB frei; kurze Textgenerierung ca. 136 Tokens/s |
+| 9B Q4_K_M, 16K, GPU-Projektor, Standardpuffer | Nur ca. 900 MiB frei nach Start; verworfen |
+| 9B Q4_K_M, 16K, CPU-Projektor, kleinere Puffer | Mindestens 1760 MiB frei; ca. 94 Tokens/s, Screenshot ca. 39 s; direktes API funktioniert, Hermes lehnt 16K ab |
+| 9B Q4_K_M, 64K, CPU-Projektor, Q4_0-Cache | Nur ca. 1439 MiB frei nach Start; zugunsten kleinerer Gewichtsdatei verworfen |
+| 9B IQ4_XS, 64K, CPU-Projektor, Q4_0-Cache, Batch 512/Microbatch 128 | Nach Start 1988 MiB frei; im Text-/Bild-/Werkzeug-/58315-Token-Test mindestens **1627 MiB frei**; ca. 73–101 Tokens/s |
+
+Die ersten API-Tests prüfen deutsche Textantwort, Screenshot-Erkennung,
+strukturierten Werkzeugaufruf (`add`, Argumente 17/25) und knapp 11000 Tokens
+Eingabekontext. Der Werkzeugaufruf wird nur als JSON geprüft und nicht ausgeführt.
+Die kurzen Beispiele belegen Funktionsfähigkeit, keinen Qualitätsgewinn gegenüber
+4B. Die ursprüngliche Modellbewertung beruhte auf Hersteller-Benchmarks und muss
+sich in Johannes' tatsächlichen Aufgaben bewähren.
+
+Das endgültige IQ4_XS-Profil beantwortete die 58315-Token-Anfrage ohne
+Abschneiden in ca. 22,4 Sekunden. Der strukturierte Werkzeugaufruf enthielt
+korrekt `{"a":17,"b":25}`. Ein echter lokaler Hermes-Lauf mit 65536 Kontext,
+20243 Zeichen Systemprompt und 19 Signal-Werkzeugbeschreibungen antwortete
+in ca. 5,2 Sekunden mit „Modelltest erfolgreich“. Werkzeugausführung war für
+diesen Lauf deaktiviert; es wurden keine Nachrichten an Kontakte versendet.
+
+**Bildgrenze:** Der Screenshot brauchte mit dem CPU-Projektor ca. 38,9 Sekunden.
+CPU-Modell und die Angabe 6.0G/10G wurden erkannt, im freien Text wurde aber die
+Leistungsangabe 106 W fälschlich als „106 GB“ wiedergegeben. Die Bildverarbeitung
+funktioniert technisch; fehlerfreie OCR oder ein Qualitätsgewinn gegenüber 4B
+sind damit nicht belegt. Eine gezielte JSON-Nachfrage nach belegtem und gesamtem
+VRAM lieferte anschließend korrekt `6.0`/`10.0` in ca. 38,9 Sekunden.
+Die freien 1627 MiB sind ein gemessenes Minimum während
+dieses kurzen Tests, keine dauerhafte Zusicherung bei zusätzlichen Anwendungen.
+
+Repository-Prüfungen: 55 Python-Tests und Bash-Syntaxprüfungen bestanden;
+Shellcheck ist auf der Workstation nicht installiert. Hauptmodell, Gateway und
+CPU-Kompression waren abschließend `active/running`, jeweils ohne automatische
+Neustarts. Im zugänglichen Kerneljournal seit Versuchsbeginn keine Treffer für
+NVIDIA-/Xid-/Speicherfehler. Kein absichtlich erzeugter
+UI-Absturz, keine Neustart- oder Langzeitabnahme.
+
+## Bestehende 4B-Installation übernehmen
+
+Die Vorbereitungshilfe überschreibt vorhandene Profil-Dateien absichtlich nicht.
+Vor einer manuellen Migration deshalb die aktive `llama.env`, das bisherige
+`llama-routine.env` und die Hermes-YAML separat sichern, die bisherige aktive
+4B-Konfiguration als `llama-fallback.env` erhalten und das alte Routineprofil
+in die Sicherung verschieben. Erst dann `prepare-workstation.py --download
+--models routine` ausführen (gegebenenfalls `--server-bin /usr/bin/llama-server`).
+Das erzeugt die neue Routinekonfiguration, ohne bereits umzuschalten.
+Nach Installation des aktuellen Umschalters erfolgt die Aktivierung ausdrücklich
+mit `hermes-stack-model routine`. Kein Modellwechsel durch `install.sh` allein.
+
+## Umschalten und zurückrollen
+
+```bash
+hermes-stack-model status
+hermes-stack-model fallback  # ursprüngliches 4B-/64K-Setup wieder aktivieren
+hermes-stack-model routine   # 9B-Erprobung wieder aktivieren
+```
+
+Ein Wechsel beendet laufende Gateway-Anfragen. Der Umschalter sichert beide
+Konfigurationen, übernimmt das Profil samt Kontext-/Kompressionsgrenze, wartet
+auf den Modell-Healthcheck und startet den Gateway. Bei Startfehlern versucht er
+die Rückkehr zum vorherigen Profil; danach Dienststatus prüfen.
+
+Der Rückweg auf Archwork wurde während der Erprobung tatsächlich ausgeführt:
+`llama.env` war danach bytegleich zum Ausgangsstand, die gesamte Hermes-YAML
+semantisch identisch; ein lokaler Hermes-Lauf mit 19 Signal-Werkzeugbeschreibungen
+antwortete mit „Modelltest erfolgreich.“. Es wurde keine Nachricht an einen
+Kontakt gesendet.
+
+Die vollständige lokale Ausgangssicherung liegt auf Archwork unter
+`~/.local/state/hermes-stack-maintenance/qwen9b-20261027/` (private Hermes-YAML,
+aktives Profil, altes Routineprofil, vorheriger Umschalter und Messberichte).
+Diese privaten Dateien werden nicht eingecheckt. Der normale Rückweg braucht
+keine Wiederherstellung der gesamten Sicherung, sondern nur den Fallback-Befehl.
+
+Bei erneutem UI-Stottern, Grafikfehlern oder zu geringer Reserve zuerst
+`hermes-stack-model fallback` verwenden. Bei einem dauerhaft unbedienbaren
+Desktop lässt sich derselbe Befehl aus einer Textkonsole ausführen. Ein
+automatischer Wechsel wegen neuer UI-Probleme ist nicht eingerichtet.