115 lines
6.8 KiB
Markdown
115 lines
6.8 KiB
Markdown
# 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.
|