Files
hermes-arch-stack/docs/WORKSTATION.md
T

150 lines
6.6 KiB
Markdown

# Bestehende Workstation behutsam übernehmen
Nicht blind den Schnellstart für eine neue Maschine ausführen. Vorhandene
Hermes-/Signal-Konfiguration bleibt privat und wird nicht durch das Repo ersetzt.
Das aktuelle Deployment enthält deine gezeigten Anpassungen; weitere lokale,
hier nicht übermittelte Änderungen können nicht automatisch rekonstruiert werden.
## 1. Ausgangszustand sichern
Jobs zu Ende laufen lassen, sicherstellen dass gerade kein Hermes-Update läuft.
Vorhandene Startparameter, Versionen, Units und Drop-ins lokal dokumentieren:
```bash
systemctl --user cat llama-qwen.service
systemctl --user cat hermes-gateway.service
/usr/bin/llama-server --version
systemctl --user list-timers --all --no-pager
```
Bestehende Maintenance-Timer während der Umstellung anhalten; zuvor aktive
Timer notieren und nur diese später wieder aktivieren. Laufende Service-Jobs
werden durch Stoppen ihrer Timer nicht beendet.
```bash
systemctl --user stop hermes-stack-health.timer hermes-stack-hermes-update.timer \
hermes-stack-signal-health.timer hermes-stack-signal-update-check.timer
```
Das folgende `install.sh` sichert ersetzte Dateien unter
`~/.local/state/hermes-stack-deployment.*`, behält vorhandene env-Dateien und
Gateway-Unit bei und startet ohne Optionen keine Timer und keinen Backend-Dienst.
Eigene systemd-Drop-ins bleiben bestehen; sie können den neuen ExecStart übersteuern!
Vergleiche nachher `systemctl --user cat llama-qwen.service`.
```bash
./install.sh
```
Nicht `--install-hermes`, `--install-llama` oder `--install-packages` verwenden,
wenn zunächst nur das bestehende funktionierende Setup übernommen werden soll.
## 2. llama.env bewusst migrieren
Der Installer überschreibt `llama.env` nicht. Vergleiche sie mit
`config/llama.env.example`. Vor manueller Bearbeitung eine datierte Kopie anlegen:
```bash
cp -a ~/.config/hermes-stack-maintenance/llama.env \
~/.config/hermes-stack-maintenance/llama.env.before-rtx-tuning
```
Den Backup-Namen nur einmal verwenden oder ein neues Datum anhängen. Folgende
Werte aus der Vorlage übernehmen, vorhandene individuelle Modellpfade prüfen:
```bash
LLAMA_SERVER_BIN="/usr/bin/llama-server"
LLAMA_MODEL=""
LLAMA_HF_REPO="ggml-org/Qwen3.8-27B-GGUF:Q4_K_M"
LLAMA_ALIAS="qwen38-27b-local"
LLAMA_MMPROJ=""
LLAMA_HOST="127.0.0.1"
LLAMA_PORT="8080"
LLAMA_PROFILE="desktop-64k"
LLAMA_ARGS=()
```
Eine alte Konfiguration mit `LLAMA_MODEL` und vollständigem `LLAMA_ARGS` läuft
weiter, solange `LLAMA_PROFILE` nicht gesetzt ist. Der Profilschalter verweigert
unmigrierte Konfigurationen. Lokale GGUF statt HF: Modellpfad setzen und HF leeren.
```bash
~/.local/libexec/hermes-stack-llama-run --print
~/.local/libexec/hermes-stack-llama-run --check
```
Kein Modellstart, kein Neustart. Erst nach erfolgreicher Prüfung und Jobende:
```bash
~/.local/libexec/hermes-stack-llama-restart --jobs-finished
curl -fsS http://127.0.0.1:8080/health
~/.local/libexec/hermes-stack-llama-report
```
Ein kurzzeitiges 503 während des Ladens ist noch kein Beweis für einen Defekt.
Logs kontrollieren und auf Bereitschaft warten. Danach eine echte Text-/Bild-
und Tool-Aufgabe in Hermes prüfen. Erst dann vorher aktive Timer wieder starten.
`LLAMA_HEALTH_AUTORESTART=0` ist auch bei älterer config.env ohne diesen Schlüssel
der neue Standard: HTTP-Probleme werden gemeldet, nicht durch Neustarts behandelt.
## 3. Optimieren und zurücksetzen
Nun gemäß [RTX3080.md](RTX3080.md) jeweils nur ein Profil vergleichen. Zurück:
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
bei aktivem Profilbetrieb Vorrang; ihre vorherigen Stände liegen daneben.
## Workstation-Abgleich vom 2026-09-09
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
blieben zeitweise nur 678 MiB VRAM frei. Es gab keinen Dienstneustart;
die Bildaufgabe wurde allerdings abgebrochen, nicht fertiggetestet.
Anschließend wurde baseline wieder aktiviert und der Modellendpunkt geprüft.
Die llama-Unit übernimmt die Limits der Workstation mit 64 GiB RAM:
Nice=10, CPUQuota=1600%, MemoryHigh=40G, MemoryMax=48G, OOMPolicy=stop.
Neustartabstand: 30 Sekunden; StartLimitBurst=3 bei StartLimitIntervalSec=300.
Diese Einstellungen begrenzen keinen GPU-Speicher. Auf anderer Hardware
vor dem Start anpassen. Bestehende Drop-ins können die Vorlage übersteuern.
Die Docker-Netzprüfung ist optional: DOCKER_NETWORK in config.env auf den
Namen des verwendeten Netzes setzen. Leer bedeutet keine Netzprüfung.
Die Prüfung erstellt kein Netz. Private Konfigurationen bleiben außerhalb Git.
Der Repository-Updater wurde am 2026-09-09 mit Sicherung auf die Workstation
übernommen und bytegleich geprüft; die Konfigurationsdefaults wurden ergänzt.
Ein echter Update-/Rollback-Lauf der neuen Fassung war damit noch nicht geprüft.
## Wiederherstellung vom 2026-09-10
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).