hermes-arch-stack/docs/INFERENCE_LIMITS.md

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 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:

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, Qwen3.5-4B, verwendete GGUF-Dateien.