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:

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.

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.

./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:

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:

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.

~/.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:

~/.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 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.

5.4 KiB Raw Blame History