129 lines
5.4 KiB
Markdown
129 lines
5.4 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="baseline"
|
|
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:
|
|
Profil `baseline` wählen und kontrolliert neustarten. 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
|
|
|
|
Alltagsprofil bleibt 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).
|