# Qwen auf RTX 3080 10 GB / Hyprland Aktuelle 9B-Erprobung mit 4B-Rückfallprofil: [QWEN9B_TRIAL.md](QWEN9B_TRIAL.md). Die folgenden Fit-Profile und älteren Messungen betreffen den 27B-Betrieb. 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. ```bash ~/.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: ```bash 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. ## Zur größeren Desktop-Reserve zurückkehren ```bash ~/.local/libexec/hermes-stack-llama-profile desktop-64k ~/.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](https://github.com/ggml-org/llama.cpp/blob/master/common/arg.cpp) 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: ```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 ``` 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: ```bash 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](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md), [ähnlicher NVIDIA-GSP-Bericht](https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1408). Der dort genannte Display-Wakeup-Auslöser ist lokal nicht bewiesen.