hermes-arch-stack/docs/NEW_WORKSTATION.md

Aktuelles Workstation-Setup neu installieren

Stand: 27.10.2026. Diese Anleitung stellt den aktuellen lokalen Modellbetrieb wieder her: Qwen3.5-9B mit 64K für den Alltag als Erprobung, Qwen3.5-4B mit 64K als Rückfallprofil, Qwen3.8-27B als explizite Alternative und Qwen3-1.7B für Kompression auf der CPU sowie Antwort- und Zeitlimits. Die Modelle werden nacheinander betrieben; der Kompressionsserver läuft separat.

1. Voraussetzungen und Deployment

Ziel ist Arch Linux mit systemd-User-Sitzung, einer funktionierenden NVIDIA-/CUDA- Installation und ausreichend RAM und VRAM. Die kurze Abnahme erfolgte auf einer RTX 3080 mit 10 GB VRAM und 64 GB RAM. Der Installer richtet keine Grafiktreiber ein. Für andere GPUs muss der CUDA-Build angepasst und die Speicherbelegung neu geprüft werden. Das Routineprofil erzwingt vollständigen GPU-Offload.

git clone https://gitea.jr-it-services.de/johannes/hermes-arch-stack.git
cd hermes-arch-stack
./install.sh --install-packages --install-hermes

Für einen CUDA-Quellbuild des hier geprüften llama.cpp-Standes:

sudo pacman -Syu --needed base-devel cmake ninja cuda openssl
./scripts/install-llama-cpp.sh \
  --ref d81235049384534c167caea52b85a694f6103d14 --cuda-arch 86

86 ist für die RTX 3080, auf anderer Hardware die passende Architektur setzen. Alternativ eine vorhandene kompatible llama-server-Binary verwenden; später beim Vorbereiten --server-bin /usr/bin/llama-server ergänzen. Der Quellbuild setzt einen neuen Compiler/CUDA-Stand voraus und wurde hier nicht erneut gebaut.

Das Deployment installiert hermes-stack-model nach ~/.local/bin. Falls dieses Verzeichnis in einer neuen Shell noch nicht im PATH steht, einmal in die eigene Shell-Konfiguration aufnehmen und eine neue Shell starten:

export PATH="$HOME/.local/bin:$PATH"

2. Eigene Hermes-Daten und Plattformen

Bei einer neuen Hermes-Installation zuerst hermes setup ausführen. Für die Übernahme der vorhandenen Chats, Skills, Plugins, Cronjobs und Zugangsdaten stattdessen die privaten Daten gemäß MIGRATION.md wiederherstellen. Das Repository enthält diese Daten nicht. Die gesamte persönliche Konfiguration kann aus dem Quellcode allein nicht wiederhergestellt werden.

Vorbereitung auf der alten Maschine: Gateway und Maintenance-Timer kontrolliert anhalten und die privaten Hermes-Daten, ~/.config/hermes-stack-maintenance/, gegebenenfalls ~/HermesWorkspace/ und die Signal-Geräteidentität verschlüsselt sichern. Auch private lokale Plugins und eigene Skills berücksichtigen. Signal auf dem neuen Rechner separat verknüpfen oder die Geräteidentität nur auf einem Rechner gleichzeitig betreiben. Secrets gehören nicht nach Gitea.

Nach dem Import absolute Pfade auf alten Benutzernamen prüfen. Besonders terminal.docker_volumes und HERMES_REPO/HERMES_ENV können noch auf das alte Home zeigen. Private Konfigurationsdateien gezielt bearbeiten und nicht blind alte systemd-Units samt Drop-ins über die neue Installation kopieren.

Wenn das bisherige Docker-Terminal übernommen wird, Docker installieren und starten, dem Benutzer die erforderlichen Docker-Rechte geben und neu anmelden. Das eigene Arbeitsverzeichnis anlegen, das Netzwerk hermes-net bereitstellen und das in der persönlichen Hermes-Konfiguration angegebene Container-Image laden. Die alten DNS-Adressen sind nur im ursprünglichen Netzwerk gültig. Der Modellhelfer verändert Terminal-, Netzwerk-, Plugin- und Auth-Einstellungen nicht.

3. Modelle und Schutzmechanismen vorbereiten

Während dieser Konfigurationsänderung muss der Gateway gestoppt sein:

systemctl --user stop hermes-gateway.service
python3 scripts/prepare-workstation.py \
  --download --models routine,large,compression,fallback \
  --select routine --configure-hermes --unpin-local-cron

Bei noch nicht installierter Gateway-Unit ist deren Stop-Fehler unkritisch. Die Vorbereitung startet selbst keine Dienste. Sie prüft vor Änderungen, dass kein Gateway läuft, und teilt das Maintenance-Lock mit Updater und Watchdog.

Alle sieben Modelldateien zusammen benötigen rund 28,3 GiB. Wer zunächst nur das Alltagsmodell möchte, verwendet --models routine. Für Routine plus CPU- Kompression --models routine,compression. Ohne --download müssen die Dateien bereits im erwarteten Modellverzeichnis liegen; das ermöglicht eine Offline- Übernahme. --model-dir /anderer/absoluter/pfad unterstützt eine andere Ablage.

config/models.lock.json hält für jede Datei Repository, vollständige Revision, Dateigröße und SHA-256 fest. Downloads erfolgen ausschließlich von der fixierten Revision, werden zunächst als .part gespeichert und erst nach erfolgreicher Prüfung umbenannt. Beschädigte vorhandene Dateien werden gemeldet und behalten. Fehlgeschlagene Downloads können erneut gestartet werden; bei einem falschen Partial-Download muss die betroffene .part vor erneutem Download entfernt werden.

Der Helfer erzeugt fehlende Dateien llama-routine.env, llama-fallback.env, llama-large.env und compression.env für den jeweiligen Benutzernamen. Bereits vorhandene Profile und deren Tuning bleiben erhalten. --select routine übernimmt das vorbereitete Routineprofil ausdrücklich als aktive llama.env und sichert deren alten Stand. Soll nach einer Migration ein Modellpfad geändert werden, vorhandene Profile vorher gezielt sichern und anpassen oder zur Neuerzeugung aus dem Konfigurations- verzeichnis verschieben. Das gilt auch für LLAMA_SERVER_BIN.

--configure-hermes aktualisiert mit Backup die lokalen Provider-, Vision- und optional Kompressionseinstellungen, das 30-Minuten-Auftragsbudget und die 600-Sekunden-/2048-Token-Limits. Dabei setzt er model.context_length passend zur Auswahl: 65536 für alle drei Profile. Die Kompressionsschwelle beträgt 24.000 Tokens. Fremde Provider, Terminal, Plugins und andere Einstellungen bleiben bestehen. --unpin-local-cron löst nur bekannte lokale Modellbindungen über die Hermes-CLI; eigene Cloud-Provider bleiben gebunden. Die Option legt keine Cronjobs an. Vorhandene Cronjobs kommen aus dem privaten Hermes-Backup. Details und Grenzen des Watchdogs: INFERENCE_LIMITS.md.

4. Prüfen und aktivieren

~/.local/libexec/hermes-stack-llama-run --check
HERMES_LLAMA_CONFIG="$HOME/.config/hermes-stack-maintenance/compression.env" \
  ~/.local/libexec/hermes-stack-llama-run --check
hermes config check
hermes gateway install --force
systemctl --user daemon-reload
systemctl --user enable --now llama-qwen.service
systemctl --user enable --now llama-compression.service
# Nach Einrichtung von signal-cli und dessen Konfiguration:
# systemctl --user enable --now signal-cli.service
systemctl --user enable --now hermes-gateway.service
systemctl --user enable --now \
  hermes-stack-llama-watchdog.timer \
  hermes-stack-health.timer \
  hermes-stack-hermes-update.timer

Bei einer Vorbereitung ohne Kompressionsmodell dessen Prüfung und Dienst weglassen. Signal-Wartungstimer erst nach der Signal-Einrichtung aktivieren. Ein lokaler Modellserver kann beim Laden kurz HTTP 503 liefern.

curl -fsS http://127.0.0.1:8080/health
hermes-stack-model status
systemctl --user status hermes-stack-llama-watchdog.timer
~/.local/libexec/hermes-stack-doctor

Danach eine deutsche Textantwort, ein Bild und einen Werkzeugaufruf in Hermes prüfen. Messungen zur aktuellen 9B-Erprobung stehen in QWEN9B_TRIAL.md. Der historische 4B-Test erreichte bei kurzen Textanfragen etwa 130–136 Tokens/s; das ist kein Benchmark für lange Kontexte oder Bildaufgaben. Eine erzwungene lange Antwort endete bei genau 2048 Tokens, und ein reiner Tool-Call wurde korrekt als JSON erzeugt. Ein zehnminütiger echter Hänger wurde nicht absichtlich erzeugt; dessen Watchdog-Recovery ist automatisiert simuliert.

Alltag und Rückweg

hermes-stack-model          # aktives Modell anzeigen
hermes-stack-model routine  # 9B/64K-Erprobung
hermes-stack-model fallback # bisheriges 4B/64K-Profil
hermes-stack-model large    # größeres Modell für bewusste Einzelnutzung

Ein Wechsel stoppt laufende Gateway-Anfragen, prüft die Kandidatenkonfiguration, sichert llama.env und die Hermes-Konfiguration, setzt Kontext und Kompressionsschwelle passend, wartet nach dem Modellstart auf /health und startet den Gateway wieder. Bei Fehlern wird die vorherige Konfiguration zurückkopiert und die Wiederaufnahme der Dienste versucht; Journal und Dienststatus kontrollieren. Alle Hauptmodelle verwenden den stabilen API-Alias hermes-local und dieselben Limits.

Automatischer Wechsel zwischen den Modellen findet nicht statt. Das große Modell bleibt auf der 10-GB-Karte langsam. Für Betrieb ohne Anmeldung optional sudo loginctl enable-linger "$USER" setzen. Vollständige Rücknahme und Sicherungs- orte stehen in INFERENCE_LIMITS.md.