hermes-arch-stack/docs/QWEN9B_TRIAL.md

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

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.