3.8 KiB
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.