8.5 KiB
Aktuelles Workstation-Setup neu installieren
Stand: 23.10.2026. Diese Anleitung stellt den aktuellen lokalen Modellbetrieb wieder her: Qwen3.5-4B für den Alltag, Qwen3.8-27B als explizite Alternative, Qwen3-1.7B für Kompression auf der CPU, 64K Kontext 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 \
--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 fünf Modelldateien zusammen benötigen rund 22,6 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-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: 65536
passend zu beiden Hauptmodellprofilen. Bei CPU-Kompression bleibt die
Kompressionsschwelle auf 24.000 Tokens begrenzt. 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. Der bisherige Live-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 # schnelles Alltagsmodell
hermes-stack-model large # größeres Modell für bewusste Einzelnutzung
Ein Wechsel stoppt laufende Gateway-Anfragen, prüft die Kandidatenkonfiguration,
sichert llama.env, 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.
Beide Modelle 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.