# 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`.

## Kontextgröße und Kompression

Beide Hauptmodellprofile starten mit `--ctx-size 65536`. Hermes muss dieselbe
Grenze kennen: `model.context_length: 65536` in `~/.hermes/config.yaml`.
Der lokale Alias `hermes-local` wurde bei der Live-Prüfung vom 23.10.2026 nicht
zuverlässig erkannt; Hermes meldete einen Fallback auf 256.000 Tokens.
Die explizite Grenze verhindert eine zu große Annahme bei Kontextverwaltung und
Platzplanung. Sie vergrößert weder das Modellfenster noch die GPU-Belegung.

`scripts/prepare-workstation.py --configure-hermes` setzt die Grenze bei der
Einrichtung für Routine- und großes Profil. Bei einem späteren eigenen Profil
mit anderer `--ctx-size` muss `model.context_length` entsprechend mitgeändert
werden.

Die bestehende CPU-Kompression bleibt bei `threshold: 0.5` und
`threshold_tokens: 24000`: Die absolute Obergrenze zieht die Kompression vor
die rechnerische 50-Prozent-Schwelle von 32.768 Tokens. `target_ratio: 0.2`,
Schutz der ersten drei und letzten zehn Nachrichten sowie die bestehenden
Zeitbudgets bleiben erhalten. Die Schwelle ist ein Auslöser, keine harte
Obergrenze für einzelne Nachrichten oder Werkzeugergebnisse.

Für eine bestehende Installation genügt nach Abschluss laufender Aufträge:

```bash
cp -p ~/.hermes/config.yaml ~/.hermes/config.yaml.before-context-64k
hermes config set model.context_length 65536
hermes config get model.context_length
systemctl --user restart hermes-gateway.service
```

Den Sicherungsnamen bei wiederholter Ausführung ändern, damit die frühere
Sicherung erhalten bleibt. Der Hauptmodell- und CPU-Kompressionsdienst brauchen
für diese Hermes-Einstellung keinen Neustart. Neue Sitzungen verwenden die neue
Grenze; bereits im Agentzustand gehaltene Kontextwerte sind kein verlässlicher
Nachweis. Zur Abnahme eine neue Sitzung öffnen und die Modellantwort sowie das
Gateway-Protokoll auf erneute Kontext-Fallback-Warnungen prüfen.

## 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).