Preserve desktop VRAM reserve and portable CPU compression setup

2026-10-12 12:36:11 +02:00
1 parent e8512b56f5
commit eb456b37ea
@@ -56,7 +56,16 @@ betreiben. Für Parallelbetrieb die neue Maschine als separates Gerät verknüpf
 inklusive CLI und Benchmark) oder vorhandene Binary verwenden. Die GGUF-Datei
 und einen ggf. benötigten Vision-Projektor übertragen oder beim ersten Start
 über HF beziehen. Danach
-`~/.config/hermes-stack-maintenance/llama.env` anpassen. Modellgewichte gehören
+`~/.config/hermes-stack-maintenance/llama.env` anpassen.
+
+Für eine Workstation mit Desktop auf derselben GPU `desktop-64k` (64K,
+4096 MiB Fit-Zielmarge) als Ausgangspunkt verwenden. Den optionalen lokalen
+Kompressionsserver über `compression.env` auf CPU konfigurieren und seine
+GGUF-Datei separat übertragen. Die vollständige Einrichtung und Abnahme steht
+unter [Desktop-Reserve und CPU-Kompression](RTX3080.md#desktop-reserve-und-cpu-kompression-seit-12102026).
+Auch die eigenen `~/.config/hermes-stack-maintenance/`-Dateien sichern und
+gezielt übertragen; lokale Pfade, Binary-Auswahl und Profil-Override auf der
+neuen Maschine prüfen. Keine vollständige systemd-Konfiguration blind kopieren. Modellgewichte gehören
 wegen Größe und Lizenz nicht in dieses Repository.

 Die RTX-3080-Profile sind für 10 GB VRAM und die bisherige CPU ausgelegt; auf
@@ -70,6 +79,8 @@ NVIDIA-/Kernelpakete. Keine Binärkopie des alten CUDA-Builds erzwingen.
 hermes gateway install --force
 systemctl --user daemon-reload
 systemctl --user enable --now signal-cli.service llama-qwen.service
+# Nur nach Einrichtung der optionalen Kompression:
+systemctl --user enable --now llama-compression.service
 systemctl --user enable --now \
  hermes-stack-hermes-update.timer \
  hermes-stack-health.timer \
@@ -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.
@@ -1,3 +1,16 @@
+# Validierung vom 2026-10-12
+
+- `make test`: Shell-Syntaxprüfung, Secret-Mustercheck und **26 isolierte
+  Funktionstests bestanden**, einschließlich separater CPU-Kompressionskonfiguration.
+- `git diff --check`: erfolgreich.
+- Neue Profil- und Kompressionsvorlagen mit der installierten llama.cpp-Binary
+  auf unterstützte Optionsnamen geprüft, ohne Modellstart.
+- ShellCheck ist lokal nicht installiert; weiterhin über Gitea-CI vorgesehen.
+- Die aktive Workstation-Konfiguration wurde vor der Repo-Änderung mit echten
+  Text-/Bildanfragen und mindestens 4096 MiB freiem VRAM geprüft. Die portablen
+  Installer-/Wrapperdateien wurden nicht erneut auf den laufenden Rechner
+  installiert. Keine neue Workstation eingerichtet und kein Langzeitnachweis.
+
 # Validierung vom 2026-09-05

 Ausgeführt in einer isolierten Arbeitsumgebung, nicht auf der Workstation:
@@ -90,7 +90,8 @@ der neue Standard: HTTP-Probleme werden gemeldet, nicht durch Neustarts behandel
 ## 3. Optimieren und zurücksetzen

 Nun gemäß [RTX3080.md](RTX3080.md) jeweils nur ein Profil vergleichen. Zurück:
-Profil `baseline` wählen und kontrolliert neustarten. Für vollständige Rückkehr
+Bei Speicherdruck die größere Reserve von `desktop-64k` verwenden. Die
+früheren Vergleichsprofile bieten keine Stabilitätsgarantie. Für vollständige Rückkehr
 alte llama.env und ggf. alte Unit/Wrapper aus der Deployment-Sicherung einzeln
 wiederherstellen, `daemon-reload` und Neustart nach Jobende. Nicht pauschal ein
 Archiv über dein gesamtes Home extrahieren. Die Datei `llama-profile.env` hat nur
@@ -98,7 +99,7 @@ bei aktivem Profilbetrieb Vorrang; ihre vorherigen Stände liegen daneben.

 ## Workstation-Abgleich vom 2026-09-09

-Alltagsprofil bleibt baseline: 65536 Kontext, Fit-Zielmarge 1536 MiB.
+Historischer Stand (durch den Abgleich vom 12.10.2026 abgelöst): baseline, 65536 Kontext, Fit-Zielmarge 1536 MiB.
 Die zwei kurzen Texttests vom 5. September ergaben im Mittel rund 2,58 tok/s
 für baseline und 2,62 tok/s für vram-64k. Das belegt keinen belastbaren
 Geschwindigkeitsvorteil. Im fünfminütigen Desktop-/Bildtest mit vram-64k
@@ -126,3 +127,23 @@ Ein echter Update-/Rollback-Lauf der neuen Fassung war damit noch nicht geprüft
 Modell und Projektor liegen jetzt außerhalb von ~/.cache. Die korrigierten
 Cleanup-Skripte sind unter ~/Scripts installiert. Details und Prüfgrenzen:
 [CLEANUP_RECOVERY.md](CLEANUP_RECOVERY.md).
+
+
+## Workstation-Abgleich vom 2026-10-12
+
+Nach NVIDIA-Speicherallokationsfehlern und GUI-Abstürzen wurde der aktive
+Hauptserver auf 4096 MiB Fit-Zielmarge bei unverändert 65536 Kontext umgestellt.
+Die aktive `llama.env` enthält dafür explizite `LLAMA_ARGS` bei leerem
+`LLAMA_PROFILE`; Profilwechsel wirken dort erst nach bewusster Umstellung auf
+Profilbetrieb. Reasoning: auto, Budget 128, kein Preserve.
+
+Die bestehende Kompressions-Unit wurde um `--device none --no-op-offload
+--no-kv-offload` ergänzt. Der vorher mit null GPU-Layern weiterhin belegte
+VRAM wurde freigegeben. Kurze Text-/Bildtests bestanden mit mindestens 4096 MiB
+freiem VRAM und ohne neue NVIDIA-/CUDA-OOM-Fehler. Langzeitstabilität bleibt offen.
+
+Diese aktiven Änderungen wurden separat installiert. Die neuen portablen
+Repo-Dateien wurden danach aufgenommen und getestet, aber nicht erneut über
+`install.sh` auf die Workstation ausgerollt. Der aktuelle Betrieb bleibt bei den
+bereits geprüften Einstellungen. Details zur Übertragung und zu bestehenden
+Units/Drop-ins stehen in [RTX3080.md](RTX3080.md).