# 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: 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).