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="desktop-64k"
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: 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.

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.

Hermes-Update-Korrektur vom 2026-10-21

Der korrigierte hermes-stack-hermes-update ist gezielt auf der Workstation installiert und mit der Repository-Datei bytegleich geprüft. Der echte Dienstlauf mit bereits aktuellem Stable v0.22.3 endete erfolgreich (Result=success, ExecMainStatus=0); der Gateway war danach active/running. Abschlussmeldungen erscheinen jetzt direkt im Dienstjournal.

Vorherige Wrapper-Version: ~/.local/libexec/hermes-stack-hermes-update.before-noop-fix-20261021. Ein vollständiger Installer-Lauf war für diese Korrektur nicht erforderlich. Betrieb und Fehlerdiagnose: HERMES_UPDATE.md.

7.2 KiB Raw Blame History