Preserve desktop VRAM reserve and portable CPU compression setup

docs/RTX3080.md

@@ -9,17 +9,22 @@ helfen; weder Voll-Offload noch eine bestimmte Beschleunigung werden versprochen
 
 | Profil | Kontextlimit | Fit-Zielmarge | Einsatz |
 | --- | ---: | ---: | --- |
-| `baseline` | 65536 | 1536 MiB | bisherige Startparameter, Referenz und Rückweg |
+| `desktop-64k` | 65536 | 4096 MiB | Standard für Neuinstallationen mit Desktop auf derselben GPU |
+| `baseline` | 65536 | 1536 MiB | historische Vergleichsparameter |
 | `vram-64k` | 65536 | 1280 MiB | optionaler Vergleich, kein Standard |
 | `balanced` | 49152 | 1536 MiB | erster Vergleich, nur Kontext reduzieren |
 | `vram-plus` | 49152 | 1280 MiB | zweiter Vergleich, kleinere Zielmarge |
 | `compact` | 32768 | 1536 MiB | Alternative für kürzere Sitzungen |
 
-Alle Profile: ein Slot, K/V-Cache q8_0, Flash Attention auto, GPU-Layer auto,
-Fit an, 6 Generierungs-/16 Batch-Threads, Jinja, Reasoning auto/512/preserve,
+Gemeinsam: ein Slot, K/V-Cache q8_0, Flash Attention auto, GPU-Layer auto,
+Fit an, 6 Generierungs-/16 Batch-Threads, Jinja, Reasoning auto,
 Image-Minimum 1024 Tokens und Idle-Sleep nach 300 Sekunden. Modellalias bleibt
 `qwen38-27b-local`. Es werden keine Sampling-Werte oder Hermes-Memories geändert.
 
+`desktop-64k` verwendet Reasoning-Budget 128 ohne Preserve wie die am
+12.10.2026 geprüfte Workstation. Die älteren Vergleichsprofile behalten 512 mit
+Preserve; sie ändern neben der Speicherplanung auch diesen Parameter.
+
 Die Definitionen stehen zentral in `libexec/hermes-stack-llama-run`.
 Die Konfiguration und Optionsnamen werden anhand der installierten Binary
 geprüft. Nicht unterstützte Optionen führen zum Abbruch, nicht zum stillen
@@ -35,14 +40,15 @@ hier bewusst nicht als fertiges Profil vorgesehen.
 
 ## Messung statt Auslastungsziel
 
-1. Zuerst `baseline` mit deiner normalen Browser-/Hyprland-Nutzung messen.
+1. Zuerst `desktop-64k` mit deiner normalen Browser-/Hyprland-Nutzung messen.
 2. Nur bei erneutem Tuning: Jobs beenden, ein Vergleichsprofil wählen
    und kontrolliert neu starten. Für 64K Kontext ist dies `vram-64k`.
 3. Dieselben Aufgaben erneut ausführen: kurze Textantwort, längerer Agent-Task
    mit Tools und eine repräsentative Bildaufgabe. Qualität mitbewerten.
 4. Kalten Start nach Idle-Sleep getrennt von warmem Prompt-Cache messen.
 5. Erst bei genügend Spielraum `vram-plus` probieren. Bei Rucklern, OOM,
-   Grafikfehlern oder deutlich schlechterer Latenz zurück auf `baseline`.
+   Grafikfehlern wieder die größere Reserve von `desktop-64k` verwenden.
+   Latenz und Qualität gegen die eigenen Anforderungen prüfen.
 
 ```bash
 ~/.local/libexec/hermes-stack-llama-profile list
@@ -98,3 +104,92 @@ für Fit-Marge, Kontext, Cache und Idle-Sleep; geprüft am 2026-09-05. Maßgebli
 für deinen Rechner bleibt `llama-server --help` seiner tatsächlich installierten
 Version. Die Profile übernehmen die von dir gezeigten Modellparameter; sie
 sind noch kein auf deiner GPU gemessener Optimalwert.
+
+## Desktop-Reserve und CPU-Kompression seit 12.10.2026
+
+Auf der RTX 3080 mit NVIDIA Open 615.78.08 standen vor den GUI-Abstürzen
+NVKMS-Allokationsfehler und `NV_ERR_NO_MEMORY` im Kerneljournal; danach folgten
+anhaltende GSP-Zustandsfehler und Abstürze neuer GPU-Anwendungen. VRAM-Druck ist
+belegt, die vollständige Kausalkette zum Treiberfehler nicht. Eine spätere
+Momentaufnahme mit freiem Speicher schließt frühere Lastspitzen nicht aus.
+
+Die aktive Workstation-Konfiguration wurde auf 4096 MiB Fit-Zielmarge geändert.
+Das Kompressionsmodell bekam zusätzlich zu `--n-gpu-layers 0` die Optionen
+`--device none --no-op-offload --no-kv-offload`. Nur null GPU-Layer hatte zuvor
+noch etwa 700 MiB VRAM belegt. `MemoryHigh`/`MemoryMax` begrenzen RAM, nicht VRAM.
+
+Kurze produktive Abnahme am 12.10.2026: CPU-Kompression antwortet, Hauptmodell
+verarbeitet einen Text mit 984 Eingabetokens und erkennt ein synthetisches
+96×96-Bild. Mindestens 4096 MiB VRAM frei während dieser Tests; keine neuen
+NVIDIA-/CUDA-OOM-Fehler im Prüfzeitraum. Kein Nachweis langfristiger
+Treiberstabilität, maximaler Kontext-/Bildlast oder einer bestimmten Leistung.
+Das Hauptmodell behält 64K Kontext und GPU-Visionprojektor. Bei weiterem
+Speicherdruck zuerst Reserve messen; optional `--no-mmproj-offload` prüfen,
+Kontextkürzungen mit Hermes abstimmen. Mehr CPU-Offload kann langsamer sein.
+
+### Auf einer neuen Workstation einrichten
+
+Nach `./install.sh` und Bereitstellung der Modellgewichte:
+
+1. In `llama.env` Binary/Modell/Projektor setzen; `LLAMA_PROFILE="desktop-64k"`
+   und `LLAMA_ARGS=()` verwenden. Ein eventuell aus dem alten Rechner kopiertes
+   `llama-profile.env` kann die Profilwahl überschreiben. Über den Profilhelfer
+   bewusst `desktop-64k` wählen. Die lokale Modellvorlage verwendet `$HOME`.
+2. In `compression.env` CPU-Binary bzw. die gemeinsame CUDA-Binary, Modellpfad
+   und Port prüfen. Die CUDA-Binary kann mit `--device none` auf CPU rechnen.
+3. Beide Konfigurationen ohne Modellstart prüfen:
+
+   ```bash
+   ~/.local/libexec/hermes-stack-llama-run --check
+   HERMES_LLAMA_CONFIG="$HOME/.config/hermes-stack-maintenance/compression.env" \
+     ~/.local/libexec/hermes-stack-llama-run --check
+   ```
+
+4. Hermes' Hauptmodell auf `http://127.0.0.1:8080/v1`, Alias
+   `qwen38-27b-local`, und den separaten Kompressionsanbieter auf
+   `http://127.0.0.1:8081/v1`, Alias `qwen3-1.7b-compression`, konfigurieren.
+   Bestehende `config.yaml` übernehmen und mit der installierten Hermes-Version
+   abgleichen; keine Zugangsdaten oder allgemeine Modellantworten überschreiben.
+5. Erst ohne laufende Backend-Aufträge aktivieren:
+
+   ```bash
+   systemctl --user daemon-reload
+   systemctl --user enable --now llama-compression.service llama-qwen.service
+   ```
+
+   Bei bereits laufenden Diensten aktiviert `enable --now` keine neuen
+   Einstellungen: nach Abschluss aller Anfragen gezielt neu starten.
+
+6. Mit normalem Browser-/Desktopbetrieb Text- und Bildanfragen prüfen und
+   `nvidia-smi` im Sekundentakt beobachten. Für diese 10-GB-Klasse mindestens
+   etwa 3 GiB tatsächlich freie Reserve unter den eigenen Aufgaben anstreben;
+   4096 MiB Fit-Zielmarge ist nur der Ausgangspunkt. CPU-Kompression sollte
+   nicht als NVIDIA-Verbraucher erscheinen. Journal auf neue CUDA-OOM-, NVKMS-
+   und GSP-Fehler prüfen. Aufwachen nach Idle-Sleep separat testen.
+
+Die Unit-Vorlage verwendet den üblichen Konfigurationspfad unter `~/.config`.
+Bei abweichendem `XDG_CONFIG_HOME` den Environment-Pfad in der Unit ebenfalls
+anpassen. Auch vorhandene `ExecStart`-Drop-ins vor der Übernahme prüfen.
+
+Der Installer installiert den Kompressionsdienst, aktiviert ihn aber nicht und
+lädt keine Kompressionsgewichte herunter. Fehlende `compression.env` wird
+angelegt, eine bestehende Datei bleibt erhalten. Die alte Workstation nutzt
+aktuell explizite Argumente im Hauptmodell und eine direkte Kompressions-Unit;
+diese portable Repo-Variante bildet die wirksamen Optionen ab. Ein erneuter
+Installerlauf ersetzt Units/Wrapper nach Sicherung, startet aber keine laufenden
+Modellserver neu. Für bestehende Setups deshalb zuerst sichern und den geplanten
+Dienstwechsel ohne laufende Anfragen durchführen.
+
+### Rücknahme auf einer Zielmaschine
+
+Vor Änderungen `llama.env`, `llama-profile.env` (falls vorhanden),
+`compression.env` und bestehende Units/Drop-ins sichern. Die Installer-Sicherung
+enthält ersetzte Units/Wrapper; unveränderte Konfigurationen separat sichern.
+Bei Rücknahme die betroffenen Dateien gezielt wiederherstellen, `daemon-reload`
+ausführen und die beiden Server nach Abschluss der Anfragen neu starten.
+Die früheren Profile sind Vergleichsmöglichkeiten, kein bewiesener stabiler
+Rückfallweg bei Speicherdruck.
+
+Quellen: [llama.cpp: Serveroptionen](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md),
+[ähnlicher NVIDIA-GSP-Bericht](https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1408).
+Der dort genannte Display-Wakeup-Auslöser ist lokal nicht bewiesen.