hermes-arch-stack/docs/RTX3080.md

Qwen auf RTX 3080 10 GB / Hyprland

Zielhardware: RTX 3080 mit 10 GiB, i9-13900KF, 64 GB RAM. Der Desktop und llama.cpp nutzen dieselbe GPU. Das 27B-Modell in Q4_K_M passt nicht vollständig in 10 GiB: CPU/RAM-Offload bleibt erforderlich. Mehr VRAM für Gewichte kann helfen; weder Voll-Offload noch eine bestimmte Beschleunigung werden versprochen.

Profile

Profil	Kontextlimit	Fit-Zielmarge	Einsatz
desktop-64k	65536	4096 MiB	Standard für Neuinstallationen mit Desktop auf derselben GPU
baseline	65536	1536 MiB	historische Vergleichsparameter
vram-64k	65536	1280 MiB	optionaler Vergleich, kein Standard
balanced	49152	1536 MiB	erster Vergleich, nur Kontext reduzieren
vram-plus	49152	1280 MiB	zweiter Vergleich, kleinere Zielmarge
compact	32768	1536 MiB	Alternative für kürzere Sitzungen

Gemeinsam: ein Slot, K/V-Cache q8_0, Flash Attention auto, GPU-Layer auto, Fit an, 6 Generierungs-/16 Batch-Threads, Jinja, Reasoning auto, Image-Minimum 1024 Tokens und Idle-Sleep nach 300 Sekunden. Modellalias bleibt qwen38-27b-local. Es werden keine Sampling-Werte oder Hermes-Memories geändert.

desktop-64k verwendet Reasoning-Budget 128 ohne Preserve wie die am 12.10.2026 geprüfte Workstation. Die älteren Vergleichsprofile behalten 512 mit Preserve; sie ändern neben der Speicherplanung auch diesen Parameter.

Die Definitionen stehen zentral in libexec/hermes-stack-llama-run. Die Konfiguration und Optionsnamen werden anhand der installierten Binary geprüft. Nicht unterstützte Optionen führen zum Abbruch, nicht zum stillen Weglassen. Diese Prüfung kann GPU-Laufzeitfehler oder ungültige Optionswerte nicht ausschließen. Auf anderer Hardware die Profile nicht ungeprüft übernehmen.

Fit-Zielmarge ist keine geschützte VRAM-Reservierung. Sie beeinflusst die Speicheranpassung beim Laden; später wachsende Browser-/Desktop-/Bildlast kann trotzdem zu Speicherdruck führen. Verfügbare Layer und Puffer hängen auch von Modellarchitektur, Kontext, Projektor und llama.cpp-Version ab. Weniger Kontext bedeutet nicht proportional weniger Gesamtspeicher. 1024 MiB und weniger sind hier bewusst nicht als fertiges Profil vorgesehen.

Messung statt Auslastungsziel

1. Zuerst desktop-64k mit deiner normalen Browser-/Hyprland-Nutzung messen.
2. Nur bei erneutem Tuning: Jobs beenden, ein Vergleichsprofil wählen und kontrolliert neu starten. Für 64K Kontext ist dies vram-64k.
3. Dieselben Aufgaben erneut ausführen: kurze Textantwort, längerer Agent-Task mit Tools und eine repräsentative Bildaufgabe. Qualität mitbewerten.
4. Kalten Start nach Idle-Sleep getrennt von warmem Prompt-Cache messen.
5. Erst bei genügend Spielraum vram-plus probieren. Bei Rucklern, OOM, Grafikfehlern wieder die größere Reserve von desktop-64k verwenden. Latenz und Qualität gegen die eigenen Anforderungen prüfen.

~/.local/libexec/hermes-stack-llama-profile list
~/.local/libexec/hermes-stack-llama-report

# Nur speichern, unterbricht nichts:
~/.local/libexec/hermes-stack-llama-profile balanced

# Ausschließlich nach Abschluss aller Backend-Jobs:
~/.local/libexec/hermes-stack-llama-restart --jobs-finished
journalctl --user -u llama-qwen.service -f

Laufende Inferenz überlebt diesen llama.cpp-Neustart nicht. Ein Hermes-Update ist davon getrennt. Die neue Healthcheck-Version startet einen laufenden llama-server nicht allein wegen eines HTTP-Timeouts neu. Ein inaktiver Dienst wird nur mit LLAMA_HEALTH_AUTORESTART=1 automatisch wieder gestartet.

GPU während aller Vergleichsläufe beobachten, nicht nur nach Modellstart:

nvidia-smi --query-gpu=timestamp,memory.used,memory.free,utilization.gpu \
  --format=csv --loop=1

Pro Profil notieren: freie VRAM-Minima, tatsächlich ausgelagerte GPU-Layer, Prompt-tok/s, Generierungs-tok/s, Zeit bis erster Antwort, Job-Gesamtdauer, Desktop-Verhalten und Ergebnisqualität. Nicht die höchste VRAM-Anzeige gewinnt, sondern die beste zuverlässig nutzbare Leistung.

Bei kleinerem Kontext auch Hermes' Kontextbudget passend konfigurieren: erst die in deiner Hermes-Version verfügbaren Modell-/Konfigurationsoptionen ansehen. Der Alias bleibt gleich, daher erkennt Hermes eine geänderte Grenze nicht zwingend automatisch. Lange alte Sitzungen nicht ungeprüft fortsetzen; eine frische Sitzung für den Vergleich verwenden. Das Deployment überschreibt deine config.yaml bewusst nicht.

Rückkehr

~/.local/libexec/hermes-stack-llama-profile baseline
~/.local/libexec/hermes-stack-llama-restart --jobs-finished

Eine Profiländerung stellt keine anderen Konfigurationen zurück. Für alte vollständige Startparameter siehe WORKSTATION.md. Browserbeschleunigung, NVIDIA-Treiber, Hyprland und Kernelparameter werden nicht verändert.

Quellen

Offizielle llama.cpp-Argumentdefinitionen für Fit-Marge, Kontext, Cache und Idle-Sleep; geprüft am 2026-09-05. Maßgeblich für deinen Rechner bleibt llama-server --help seiner tatsächlich installierten Version. Die Profile übernehmen die von dir gezeigten Modellparameter; sie sind noch kein auf deiner GPU gemessener Optimalwert.

Desktop-Reserve und CPU-Kompression seit 12.10.2026

Auf der RTX 3080 mit NVIDIA Open 615.78.08 standen vor den GUI-Abstürzen NVKMS-Allokationsfehler und NV_ERR_NO_MEMORY im Kerneljournal; danach folgten anhaltende GSP-Zustandsfehler und Abstürze neuer GPU-Anwendungen. VRAM-Druck ist belegt, die vollständige Kausalkette zum Treiberfehler nicht. Eine spätere Momentaufnahme mit freiem Speicher schließt frühere Lastspitzen nicht aus.

Die aktive Workstation-Konfiguration wurde auf 4096 MiB Fit-Zielmarge geändert. Das Kompressionsmodell bekam zusätzlich zu --n-gpu-layers 0 die Optionen --device none --no-op-offload --no-kv-offload. Nur null GPU-Layer hatte zuvor noch etwa 700 MiB VRAM belegt. MemoryHigh/MemoryMax begrenzen RAM, nicht VRAM.

Kurze produktive Abnahme am 12.10.2026: CPU-Kompression antwortet, Hauptmodell verarbeitet einen Text mit 984 Eingabetokens und erkennt ein synthetisches 96×96-Bild. Mindestens 4096 MiB VRAM frei während dieser Tests; keine neuen NVIDIA-/CUDA-OOM-Fehler im Prüfzeitraum. Kein Nachweis langfristiger Treiberstabilität, maximaler Kontext-/Bildlast oder einer bestimmten Leistung. Das Hauptmodell behält 64K Kontext und GPU-Visionprojektor. Bei weiterem Speicherdruck zuerst Reserve messen; optional --no-mmproj-offload prüfen, Kontextkürzungen mit Hermes abstimmen. Mehr CPU-Offload kann langsamer sein.

Auf einer neuen Workstation einrichten

Nach ./install.sh und Bereitstellung der Modellgewichte:

1. In llama.env Binary/Modell/Projektor setzen; LLAMA_PROFILE="desktop-64k" und LLAMA_ARGS=() verwenden. Ein eventuell aus dem alten Rechner kopiertes llama-profile.env kann die Profilwahl überschreiben. Über den Profilhelfer bewusst desktop-64k wählen. Die lokale Modellvorlage verwendet $HOME.

2. In compression.env CPU-Binary bzw. die gemeinsame CUDA-Binary, Modellpfad und Port prüfen. Die CUDA-Binary kann mit --device none auf CPU rechnen.

3. Beide Konfigurationen ohne Modellstart prüfen:

   ~/.local/libexec/hermes-stack-llama-run --check
   HERMES_LLAMA_CONFIG="$HOME/.config/hermes-stack-maintenance/compression.env" \
     ~/.local/libexec/hermes-stack-llama-run --check
   

4. Hermes' Hauptmodell auf http://127.0.0.1:8080/v1, Alias qwen38-27b-local, und den separaten Kompressionsanbieter auf http://127.0.0.1:8081/v1, Alias qwen3-1.7b-compression, konfigurieren. Bestehende config.yaml übernehmen und mit der installierten Hermes-Version abgleichen; keine Zugangsdaten oder allgemeine Modellantworten überschreiben.

5. Erst ohne laufende Backend-Aufträge aktivieren:

   systemctl --user daemon-reload
   systemctl --user enable --now llama-compression.service llama-qwen.service
   

   Bei bereits laufenden Diensten aktiviert enable --now keine neuen Einstellungen: nach Abschluss aller Anfragen gezielt neu starten.

6. Mit normalem Browser-/Desktopbetrieb Text- und Bildanfragen prüfen und nvidia-smi im Sekundentakt beobachten. Für diese 10-GB-Klasse mindestens etwa 3 GiB tatsächlich freie Reserve unter den eigenen Aufgaben anstreben; 4096 MiB Fit-Zielmarge ist nur der Ausgangspunkt. CPU-Kompression sollte nicht als NVIDIA-Verbraucher erscheinen. Journal auf neue CUDA-OOM-, NVKMS- und GSP-Fehler prüfen. Aufwachen nach Idle-Sleep separat testen.

Die Unit-Vorlage verwendet den üblichen Konfigurationspfad unter ~/.config. Bei abweichendem XDG_CONFIG_HOME den Environment-Pfad in der Unit ebenfalls anpassen. Auch vorhandene ExecStart-Drop-ins vor der Übernahme prüfen.

Der Installer installiert den Kompressionsdienst, aktiviert ihn aber nicht und lädt keine Kompressionsgewichte herunter. Fehlende compression.env wird angelegt, eine bestehende Datei bleibt erhalten. Die alte Workstation nutzt aktuell explizite Argumente im Hauptmodell und eine direkte Kompressions-Unit; diese portable Repo-Variante bildet die wirksamen Optionen ab. Ein erneuter Installerlauf ersetzt Units/Wrapper nach Sicherung, startet aber keine laufenden Modellserver neu. Für bestehende Setups deshalb zuerst sichern und den geplanten Dienstwechsel ohne laufende Anfragen durchführen.

Rücknahme auf einer Zielmaschine

Vor Änderungen llama.env, llama-profile.env (falls vorhanden), compression.env und bestehende Units/Drop-ins sichern. Die Installer-Sicherung enthält ersetzte Units/Wrapper; unveränderte Konfigurationen separat sichern. Bei Rücknahme die betroffenen Dateien gezielt wiederherstellen, daemon-reload ausführen und die beiden Server nach Abschluss der Anfragen neu starten. Die früheren Profile sind Vergleichsmöglichkeiten, kein bewiesener stabiler Rückfallweg bei Speicherdruck.

Quellen: llama.cpp: Serveroptionen, ähnlicher NVIDIA-GSP-Bericht. Der dort genannte Display-Wakeup-Auslöser ist lokal nicht bewiesen.