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,66 @@
|
||||
# Lokale Inferenz begrenzen
|
||||
|
||||
Die Workstation verwendet `hermes-local` als stabilen API-Modellnamen. Das
|
||||
Routineprofil lädt Qwen3.5-4B Q4_K_M (Unsloth-Revision
|
||||
`e87f176479d0855a907a41277aca2f8ee7a09523`), das große Profil weiterhin das
|
||||
vorhandene Qwen3.8-27B. Die tatsächliche Auswahl steht in
|
||||
`~/.config/hermes-stack-maintenance/llama.env`.
|
||||
|
||||
`hermes-stack-model routine` bzw. `hermes-stack-model large` schaltet explizit um
|
||||
und beendet dabei laufende Gateway-Anfragen. Beide Dateien bleiben erhalten.
|
||||
Es wird nur ein Hauptmodell gleichzeitig geladen. Die lokalen profilspezifischen
|
||||
Konfigurationen `llama-routine.env` und `llama-large.env` enthalten absolute
|
||||
Modellpfade. `scripts/prepare-workstation.py` prüft bzw. lädt die fest versionierten
|
||||
Modelldateien und erzeugt fehlende Profile. Die vollständige Neuinstallation ist
|
||||
in [NEW_WORKSTATION.md](NEW_WORKSTATION.md) beschrieben. Der normale Installer
|
||||
allein lädt keine Gewichte und erzeugt diese Profile nicht.
|
||||
|
||||
Die alten Aliasse `qwen38-27b-local` und `qwen36-27b-local` bleiben als
|
||||
Kompatibilitätsnamen für bestehende Sitzungen erreichbar. Sie bezeichnen dann
|
||||
ebenfalls das aktiv ausgewählte Modell; die tatsächliche Modelldatei zeigt
|
||||
`/props.model_path`. Neue Sitzungen und entbundene Cronjobs verwenden `hermes-local`.
|
||||
|
||||
## Drei Schutzebenen
|
||||
|
||||
- Der Runner setzt `--n-predict 2048` als Serverstandard. Das ist kein harter
|
||||
Schutz gegen abweichende Clientparameter.
|
||||
- In Hermes bekommt der lokale Custom-Provider `extra_body.max_tokens: 2048`,
|
||||
`t_max_predict_ms: 540000` und ein Request-Timeout von 600 Sekunden. Der native
|
||||
Generierungszeitgeber von llama.cpp prüft nur bei Zeilenumbrüchen und ersetzt
|
||||
deshalb keine unabhängige Überwachung. `agent.run_budget_seconds: 1800` begrenzt
|
||||
einen ganzen Auftrag einschließlich mehrerer Modellaufrufe und Wiederholungen.
|
||||
- `hermes-stack-llama-watchdog.timer` prüft alle 15 Sekunden `/slots`. Bleibt
|
||||
dieselbe Anfrage 600 Sekunden beobachtet aktiv oder überschreitet sie 2048
|
||||
Tokens, startet die Überwachung den Hauptmodellserver neu. Dieses letzte
|
||||
Auffangnetz hat eine Verzögerung von bis zu einem Prüfintervall nach erstmaliger
|
||||
Beobachtung. Die Tokenzahl kann zwischen zwei Prüfungen überschritten werden.
|
||||
|
||||
Der Watchdog startet keine absichtlich gestoppten Dienste. Einzelne fehlgeschlagene
|
||||
Proben führen nicht zum Neustart; erst 600 Sekunden zusammenhängende Fehler bei
|
||||
demselben aktiven Server. Wartung, Modellwechsel und Updater verwenden dieselbe
|
||||
Sperre. Neustarts haben mindestens 600 Sekunden Abstand. Ein Bootwechsel setzt
|
||||
monotone Zeitstempel zurück. Der Status speichert keine Prompts oder Antworten;
|
||||
Diagnosen stehen ausschließlich im lokalen Journal, ohne Chatbenachrichtigung.
|
||||
|
||||
Die Grenzen stehen in `config.env` (Watchdog), `llama.env` (Serverstandard) und
|
||||
`~/.hermes/config.yaml` (Hermes). Bei Änderungen diese Werte gemeinsam pflegen.
|
||||
Grenzen gelten pro Hauptmodell; das CPU-Kompressionsmodell bleibt getrennt.
|
||||
|
||||
## Prüfung und Rücknahme
|
||||
|
||||
```
|
||||
systemctl --user status hermes-stack-llama-watchdog.timer
|
||||
journalctl --user -u hermes-stack-llama-watchdog.service
|
||||
cat ~/.local/state/hermes-stack-maintenance/llama-watchdog.json
|
||||
```
|
||||
|
||||
Die Bereitstellung sichert vorherige Konfigurationen unter
|
||||
`~/.local/state/hermes-stack-maintenance/inference-limits-*`. Ein Rückwechsel
|
||||
auf `large` behält die Schutzmaßnahmen bei. Zum vollständigen Rückbau Timer
|
||||
deaktivieren, die gesicherten Konfigurationen wiederherstellen und Modellserver
|
||||
sowie Gateway neu starten. Cronjob-Modellbindungen sind über `hermes cron edit
|
||||
JOB_ID --model MODELL --provider custom` wiederherstellbar.
|
||||
|
||||
Quellen: [llama.cpp Serverparameter](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md),
|
||||
[Qwen3.5-4B](https://huggingface.co/Qwen/Qwen3.5-4B),
|
||||
[verwendete GGUF-Dateien](https://huggingface.co/unsloth/Qwen3.5-4B-GGUF/tree/e87f176479d0855a907a41277aca2f8ee7a09523).
|
||||
@@ -1,5 +1,9 @@
|
||||
# Migration auf eine neue Arch-Linux-Maschine
|
||||
|
||||
Für den aktuellen Routine-/Large-Betrieb samt Limits zuerst
|
||||
[NEW_WORKSTATION.md](NEW_WORKSTATION.md) verwenden. Die folgenden Abschnitte
|
||||
ergänzen die Übernahme persönlicher Daten und die ältere manuelle Modellkonfiguration.
|
||||
|
||||
Das Gitea-Repository reproduziert Programme, Units und Wartungslogik. Persönliche
|
||||
Hermes-Daten, Secrets, Signal-Geräteidentität und Modellgewichte werden separat
|
||||
übertragen.
|
||||
|
||||
@@ -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).
|
||||
@@ -1,5 +1,11 @@
|
||||
# Bestehende Workstation behutsam übernehmen
|
||||
|
||||
Aktueller Stand seit 23.10.2026: Qwen3.5-4B als Routineprofil und Qwen3.8-27B
|
||||
als Alternative mit gemeinsamem Alias `hermes-local`, Token-/Zeitlimits und
|
||||
Slot-Watchdog. Einrichtung und Migration: [NEW_WORKSTATION.md](NEW_WORKSTATION.md),
|
||||
[INFERENCE_LIMITS.md](INFERENCE_LIMITS.md). Die nachfolgende Profilumstellung
|
||||
beschreibt den früheren 27B-Betrieb und ersetzt diese aktuelle Auswahl nicht.
|
||||
|
||||
Nicht blind den Schnellstart für eine neue Maschine ausführen. Vorhandene
|
||||
Hermes-/Signal-Konfiguration bleibt privat und wird nicht durch das Repo ersetzt.
|
||||
Das aktuelle Deployment enthält deine gezeigten Anpassungen; weitere lokale,
|
||||
|
||||
Reference in new issue
Block a user