199 lines
10 KiB
Markdown
199 lines
10 KiB
Markdown
# 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.
|