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
baseline	65536	1536 MiB	bisherige Startparameter, Referenz und Rückweg
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

Alle Profile: ein Slot, K/V-Cache q8_0, Flash Attention auto, GPU-Layer auto, Fit an, 6 Generierungs-/16 Batch-Threads, Jinja, Reasoning auto/512/preserve, 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.

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 baseline 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 oder deutlich schlechterer Latenz zurück auf baseline.

~/.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.