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