Make local inference limits and workstation setup reproducible
This commit is contained in:
admin committed
1 parent
7006991843
commit
8544abd2d4
28 files changed
+1022
-21
No files matched your search
@@ -0,0 +1,170 @@
|
||||
# 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).
|
||||
Reference in new issue
Block a user