hermes-arch-stack/README.md

Hermes Arch Stack

Reproduzierbares Benutzer-Deployment für Hermes Agent auf Arch Linux mit:

• offizieller Hermes-Git-Installation unter ~/.hermes/hermes-agent
• von Hermes erzeugtem systemd-User-Service für den Messaging Gateway
• optionalem lokalen llama.cpp/OpenAI-kompatiblen Modellendpunkt
• optionalem CPU-Kompressionsserver für Hermes
• optionalem signal-cli HTTP-Daemon
• robustem Hermes-Update mit Vorprüfung, Retry, Backup und Rollback
• regelmäßigen Healthchecks und Selbstheilungsversuchen
• Statusmeldungen an Telegram und Signal
• systemd-Timern für Updates und Zustandsprüfungen
• optionalem CUDA-Build von llama-server, llama-cli und llama-bench
• Qwen-/RTX-3080-Profilen mit prüfbarem Wechsel und Rückweg

Stand: 2026-10-27. Die Anleitung für das aktuelle Setup auf einem neuen Rechner steht in NEW_WORKSTATION.md: feste Modellrevisionen und Prüfsummen, Vorbereitung der Profile und Hermes-Limits, Aktivierung und Rückweg. Für deine bestehende Workstation zuerst docs/WORKSTATION.md lesen. Der Schnellstart unten ist für eine neue Maschine. Das Routineprofil erprobt Qwen3.5-9B IQ4_XS mit 64K Kontext. Das bisherige 4B-Modell mit 64K bleibt als fallback verfügbar. Details und Rückweg: QWEN9B_TRIAL.md. Das 27B-Modell bleibt optional. Frühere VRAM-Messungen stehen in RTX3080.md. Der Installer richtet keinen Gitea-Server ein und pusht keine Änderungen.

Das Repository enthält keine Zugangsdaten, Signal-Sitzung oder Modellgewichte. Diese Daten werden lokal angelegt und sind durch .gitignore ausgeschlossen.

Schnellstart auf einer neuen Arch-Maschine

git clone ssh://git@GITEA/OWNER/hermes-arch-stack.git
cd hermes-arch-stack

./install.sh --install-packages --install-hermes

Für den lokalen GPU-Endpunkt anschließend den CUDA-Installer ausführen. Ein vorhandener Server kann stattdessen über LLAMA_SERVER_BIN verwendet werden. Der Installer benötigt funktionierende NVIDIA-Treiber; diese werden nicht von diesem Repo eingerichtet. --install-packages führt ein vollständiges pacman -Syu aus: bei Kernel-/ Treiberänderungen einen Neustart einplanen.

Danach die beim ersten Lauf erzeugten lokalen Konfigurationen bearbeiten:

$EDITOR ~/.config/hermes-stack-maintenance/config.env
$EDITOR ~/.config/hermes-stack-maintenance/llama.env
# Bei Nutzung der lokalen Kompression:
$EDITOR ~/.config/hermes-stack-maintenance/compression.env
$EDITOR ~/.config/hermes-stack-maintenance/signal-cli.env
$EDITOR ~/.hermes/.env

Hermes und die Messaging-Plattformen konfigurieren:

hermes setup
hermes gateway setup
hermes gateway install --force

In Hermes als lokalen OpenAI-kompatiblen Endpunkt http://127.0.0.1:8080/v1 und als Modell-ID hermes-local wählen, wenn die aktuellen Routine-/Large-Profile nach NEW_WORKSTATION.md vorbereitet wurden. Der ältere HF-Schnellstart verwendet weiterhin qwen38-27b-local. Bestehende Hermes-Konfigurationen, Profile, Skills und Memories werden nicht durch generische Vorgaben ersetzt. Für Neuinstallationen diese Einstellungen interaktiv vornehmen oder die eigenen Daten gemäß Migration sicher übernehmen. Der Alias allein setzt kein Kontextlimit.

Signal benötigt zusätzlich eine installierte/verknüpfte signal-cli-Instanz. Nach Konfiguration kann ./scripts/install-signal-cli.sh den vorhandenen Signal-Updater aufrufen; siehe dessen Konfiguration und docs/MIGRATION.md.

Optionale Dienste erst nach ihrer Konfiguration aktivieren:

systemctl --user enable --now signal-cli.service
systemctl --user enable --now llama-qwen.service

Maintenance aktivieren:

systemctl --user enable --now \
  hermes-stack-hermes-update.timer \
  hermes-stack-health.timer \
  hermes-stack-llama-watchdog.timer \
  hermes-stack-signal-health.timer \
  hermes-stack-signal-update-check.timer

Für Start ohne interaktive Anmeldung:

sudo loginctl enable-linger "$USER"

Abschließend:

~/.local/libexec/hermes-stack-doctor

Installationsoptionen

./install.sh [Optionen]

  --install-packages  Arch-Pakete mit pacman installieren
  --install-hermes    offiziellen Hermes-Installer ausführen
  --install-llama     CUDA-Build installieren (benötigt funktionierenden Treiber)
  --llama-ref REF     expliziter llama.cpp-Tag/Commit oder bewusst master
  --enable-timers     Maintenance-Timer sofort aktivieren
  --skip-browser      Hermes ohne Browser-Automation installieren (Standard)
  --with-browser      Browser-Automation nicht überspringen

Ohne Optionen installiert das Skript nur die versionierten Dateien und legt fehlende Beispielkonfigurationen an. Bestehende lokale Konfigurationen werden nicht überschrieben. hermes-stack-model wird über ~/.local/bin ohne Pfadangabe aufrufbar. Der separate Helfer scripts/prepare-workstation.py stellt auf Wunsch die fixierten Modelldateien bereit und übernimmt gezielt die aktuellen Hermes-Einstellungen. Ersetzte Wrapper und Units werden vorher gesichert. Eine vorhandene hermes-gateway.service wird nicht neu erzeugt. Ein Modell wird erst beim echten Start des llama-Dienstes geladen, nicht bei der Konfigurationsprüfung.

RTX 3080 und Qwen

Die aktuellen Schutzmaßnahmen gegen endlose Modellantworten und die explizite Umschaltung zwischen Routine- und großem Modell stehen in INFERENCE_LIMITS.md. Hermes verwendet zum aktiven Modell passend 64K Kontext für routine (9B), fallback (4B) und large (27B). Der Modellschalter passt auch die Kompressionsschwelle an: 24.000 Tokens.

hermes-stack-model status
hermes-stack-model routine
hermes-stack-model fallback  # bisheriges 4B-/64K-Setup
hermes-stack-model large

~/.local/libexec/hermes-stack-llama-run --check
~/.local/libexec/hermes-stack-llama-profile list
~/.local/libexec/hermes-stack-llama-report

Für neue Konfigurationen ist desktop-64k der Standard: 64K Kontext, 4096 MiB Fit-Zielmarge, Reasoning-Budget 128 ohne Reasoning-Preserve. Das priorisiert Spielraum für Browser und Desktop auf einer gemeinsam genutzten GPU. Die früheren Profile bleiben für bewusste Vergleiche verfügbar. Bestehende Konfigurationen werden nicht umgestellt. Bei expliziten LLAMA_ARGS und leerem LLAMA_PROFILE wirken die Profile nicht.

Der optionale Dienst llama-compression.service verwendet eine eigene compression.env, Port 8081 und CPU-Ausführung einschließlich KV-/Op-Offload. Für beide Server werden Modellgewichte separat bereitgestellt. Einrichtung, Messgrenzen und Migration: docs/RTX3080.md.

Profilwechsel ändern zunächst nur eine separate Auswahl-Datei. Ein Neustart benötigt hermes-stack-llama-restart --jobs-finished. Der Healthcheck teilt das Update-Lock und löst bei Backend-HTTP-Timeouts keine Inferenz-Neustarts mehr aus.

Update-Verhalten

hermes-stack-hermes-update führt folgende Schritte aus:

1. exklusives Lock und Prüfung auf lokale Änderungen
2. origin/main-Fetch mit begrenzten Retries und letztem HTTP/1.1-Fallback
3. schneller Abschluss ohne Backup, wenn Checkout und gefetchter Branch identisch sind
4. komprimiertes Backup vor jeder Änderung
5. Stoppen des Gateways und Aufruf von hermes update
6. einmaliger Retry bei eindeutig transientem Fetch-Fehler
7. Konfigurationsmigration und frischer Gateway-Neustart
8. Gateway-Healthcheck; bei Fehler Wiederherstellung des gesicherten Checkouts und der erfassten Konfigurationsdateien
9. separater llama.cpp-Healthcheck ohne unsinnigen Hermes-Rollback
10. Aufbewahrung der drei neuesten Hermes-Backups

Den Zielstand wählt hermes update anhand des konfigurierten Update-Kanals. Bei Stable kann der Checkout bereits aktuell sein, obwohl origin/main weiter ist. Ein unveränderter Commit bei Updater-Exitcode 0 und gesundem Gateway gilt deshalb als Erfolg. Dabei können Backup und Gateway-Neustart trotzdem stattfinden. Ein fehlgeschlagener Updater bei unverändertem Commit bleibt ein Fehler.

Ein Fehler von Telegram oder Signal kann den Updateprozess niemals fehlschlagen lassen. Detaillierte Zwischenstände landen im Journal; nur zusammengefasste Ergebnisse werden versendet. Abschlussmeldungen stehen auch direkt im Journal von hermes-stack-hermes-update.service. Diagnose, gezielte Installation und Prüfung sind in HERMES_UPDATE.md beschrieben.

Bedienung

# Update manuell
systemctl --user start hermes-stack-hermes-update.service

# Status und Logs
systemctl --user status hermes-stack-hermes-update.service
journalctl --user -u hermes-stack-hermes-update.service -n 200
journalctl --user -t hermes-stack-maintenance -n 100

# Benachrichtigung testen
~/.local/libexec/hermes-stack-notify \
  "Hermes-Stack: Benachrichtigungstest"

# signal-cli nach einer Update-Meldung aktualisieren
~/.local/libexec/hermes-stack-signal-update

# Gesamtprüfung
~/.local/libexec/hermes-stack-doctor

Migration

Deployment-Code und Benutzerdaten werden bewusst getrennt behandelt. Siehe docs/MIGRATION.md für die Übernahme von Hermes-Daten, Signal-Sitzung und Modellgewichten.

Gitea

Nach dem Entpacken oder Erzeugen des Repositories:

git init
git add .
git commit -m "Initial Hermes Arch deployment"
git branch -M main
git remote add origin ssh://git@GITEA/OWNER/hermes-arch-stack.git
git push -u origin main

Die mitgelieferte Gitea-Actions-Workflowdatei führt Syntax- und Smoke-Tests aus. make test führt zusätzlich isolierte Funktionstests mit simulierten Programmen aus. Ein echter NVIDIA-/Arch-/Signal-/Hermes-End-to-End-Test bleibt auf der Zielmaschine erforderlich. make archive verwendet den letzten Commit (also zuerst eigene Änderungen prüfen und committen).

Grenzen der Reproduktion

Das Repo reproduziert die Deployment-Logik, nicht deine privaten Daten oder ein eingefrorenes Arch-Abbild. Für denselben Modell-/Backendstand Quell-SHA sowie Modell-/Projektor-Prüfsummen notieren. Der offizielle Hermes-Installer und Arch liefern beim Neuaufsetzen sonst den dann verfügbaren Stand. Technische Quellen stehen in docs/LLAMA_INSTALL.md und docs/RTX3080.md.

Cleanup und dauerhafte Modellablage

Siehe Cleanup und Wiederherstellung und Vorlage für lokale Modelle. Die optionalen Skripte in maintenance/ werden nicht automatisch installiert.