171 lines
8.4 KiB
Markdown
171 lines
8.4 KiB
Markdown
# 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.
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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](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:
|
||
|
||
```bash
|
||
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. 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](INFERENCE_LIMITS.md).
|
||
|
||
## 4. Prüfen und aktivieren
|
||
|
||
```bash
|
||
~/.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.
|
||
|
||
```bash
|
||
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
|
||
|
||
```bash
|
||
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](INFERENCE_LIMITS.md).
|