# 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 enthält die aufgerufenen Retry-Pfade und den gemeinsamen Benachrichtigungshelfer. Die zuletzt verglichene installierte Fassung enthält noch ungenutzte Retry-Funktionen. Der Git-Abgleich aktualisiert die Workstation nicht; die Übernahme des Repository-Updaters steht separat aus.