Work- und Gamestation

Ich bin nicht der typische PC-Schrauber. Aber der Bauvorschlag für den „optimalen PC" in der c’t ließ mich eine ganze Weile nicht los. Also befüllte ich meinen Warenkorb bei den einschlägigen Online-Händlern — und wartete. Bis ich dann endlich mit dem Bauen startete, waren die Preise für die Komponenten um einige hundert Franken gefallen. Dafür gönnte ich mir zusätzlich eine gebrauchte NVIDIA-Grafikkarte. So sah die finale Spezifikation aus:

• Board: ASUS PRIME X870-P WiFi
• CPU: AMD Ryzen 9 9950X
• GPU: NVIDIA GeForce RTX 4070 Ti Super (16 GB VRAM)
• RAM: 64 GB DDR5
• Storage: 2 TB NVMe SSD

Das Ganze eingebaut in einem Fractal North — ein wohnzimmertaugliches Gehäuse mit Holzfront, das nicht nach Gaming-Höhle aussieht.

BIOS

Was folgt, ist ein Erfahrungsbericht über die Stolpersteine der Konfiguration. Die war nämlich alles andere als geradlinig. Als Betriebssystem installierte ich Fedora Workstation 43. Zum ersten Mal seit langem begrüßte mich Linux mit einem Kernel Panic. Die Ursache: eine fehlerhafte Implementierung der RDSEED-Instruktion in der CPU-Firmware. Der Kernel nutzt RDSEED als Entropiequelle, und wenn die CPU dabei fehlerhafte Werte liefert, steigt er aus. Erst ein BIOS-Update auf Version 1644 (mit aktualisiertem AGESA-Microcode) behob das Problem.

NVidia Treiber

Der PC muss mehrere Rollen ausfüllen: Gaming-PC für meinen Sohn, Remote-Workstation zum Kompilieren und Number Crunching, sowie lokale LLM-Inferenz mit Ollama. Dafür wuchtete ich die GeForce RTX 4070 Ti Super mit ihren 16 GB VRAM in das Gehäuse. Das ist schon ein ordentlicher Aluminiumklotz — ein massiver Kühlkörper über wenigen Quadratmillimetern Silizium, der drei PCIe-Slots belegt und fast so viel wiegt wie der Rest der Komponenten zusammen.

Wegen der Kernel Panics hatte ich die Treiber zunächst im Verdacht und deaktiviert; also wieder manuell aktivieren:

# Blacklist-Einträge finden und entfernen:
grep -rl nvidia /etc/modprobe.d/
# Betreffende Dateien editieren/löschen (nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm)

# initramfs neu bauen:
sudo dracut -f

# Kernel-Parameter setzen (Pflicht für Wayland):
sudo grubby --update-kernel=ALL --args="nvidia-drm.modeset=1"

sudo reboot

Was zunächst nicht funktionierte, war der Desktop auf der NVIDIA. Gnome unter Wayland lief zwar, aber mit Nebenwirkungen: GhostTy, mein bevorzugter Terminal-Emulator, startete gar nicht erst. Minecraft lieferte nur verwaschene, überbelichtete Farben — egal ob mit oder ohne Shader-Mods. Das Problem stellte sich als Zusammenspiel von NVIDIA und Wayland-Compositor heraus: wenn Gnome die NVIDIA gleichzeitig als Desktop-Renderer und für OpenGL-Anwendungen nutzt, gerät die Farbverarbeitung durcheinander.

Die Lösung war ein Umdenken in der GPU-Architektur. Der Ryzen 9 9950X bringt eine integrierte Radeon-GPU mit, die unter Linux vom ausgereiften amdgpu-Treiber unterstützt wird. Per udev-Regel wies ich Gnome an, die iGPU als primären Renderer zu verwenden. Der Monitor hängt am HDMI-Ausgang des Mainboards, nicht an der NVIDIA-Karte. Ergebnis: der Desktop läuft sauber und stromsparend über die AMD-Grafik. Die NVIDIA bleibt als reine Compute- und Offload-Karte im Hintergrund.

Wenn eine Anwendung die volle GPU-Leistung braucht — Minecraft mit Shadern, Ollama-Inferenz, oder ein grafisch aufwendiges Spiel über Steam — wird sie gezielt auf der NVIDIA gestartet. Linux nennt dieses Verfahren PRIME Render Offload. In der Praxis sieht das so aus:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia <anwendung>

Eine Besonderheit bei Flatpak-Apps: Minecraft läuft über den Prism Launcher, der als Flatpak installiert ist. Flatpak-Anwendungen laufen in einer Sandbox, und Umgebungsvariablen, die man in den Launcher-Settings setzt, werden nicht zuverlässig an den Java-Kindprozess weitergereicht. Die PRIME-Offload-Variablen kommen also nie bei Minecraft an.

Die funktionierende Lösung ist ein Wrapper Command, der den Java-Aufruf direkt umschließt. In Prism Launcher unter Instanz → Settings → Custom Commands → Wrapper Command:

env __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia

Voraussetzung dafür ist, dass die passende NVIDIA Flatpak-Runtime installiert ist. Die Versionsnummer muss exakt zum installierten Treiber passen:

# Installierte Runtime prüfen:
flatpak list | grep nvidia

# Falls fehlend:
flatpak install flathub org.freedesktop.Platform.GL.nvidia-580-142

Damit startet Minecraft tatsächlich auf der NVIDIA — verifizierbar über nvidia-smi, wo der Java-Prozess mit seinem VRAM-Verbrauch auftaucht. Das Tool zeigt in Echtzeit, welche Prozesse auf der GPU laufen, wie viel VRAM sie belegen und wie stark die Karte ausgelastet ist. Ein kurzer Blick genügt, um zu prüfen, ob eine Anwendung tatsächlich auf der NVIDIA rendert — oder doch still und heimlich auf der iGPU landet.

Lokale Intelligenz

Erfreulich unkompliziert ist dagegen die Installation von Ollama. Ein einziger Befehl richtet den Service ein, erkennt automatisch die NVIDIA-GPU und nutzt CUDA ohne weitere Konfiguration. Modelle lassen sich danach einfach per ollama pull herunterladen und sofort nutzen. Mit 16 GB VRAM laufen Modelle bis 14B Parameter komplett auf der GPU, größere Modelle wie ein 70B in 4-Bit-Quantisierung lagern teilweise in den 64 GB Arbeitsspeicher aus — langsamer, aber machbar.

Fedora bringt Podman bereits mit, sodass ich Open WebUI als komfortables Chat-Frontend in einem Container starten kann:

podman run -d --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

Damit habe ich unter http://localhost:8080 ein privates ChatGPT — ohne Cloud, ohne Abo, ohne Datenschutzbedenken. Dank Tailscale auch von unterwegs erreichbar.

Dauerbetrieb und Stromsparen

Der Rechner soll rund um die Uhr per SSH und Tailscale erreichbar bleiben — als Remote-Workstation, für Ollama-Anfragen oder einfach um abends vom Laptop aus eine Kompilierung anzustoßen. Gleichzeitig soll er nicht unnötig Strom verheizen, wenn niemand davor sitzt.

Der erste Schritt: Suspend komplett unterbinden, aber den Monitor nach zehn Minuten Inaktivität abschalten.

# Gnome: Suspend deaktivieren
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

# Bildschirm nach 10 Minuten ausschalten:
gsettings set org.gnome.desktop.session idle-delay 600
gsettings set org.gnome.settings-daemon.plugins.power idle-dim true

# Systemd-Targets maskieren als zusätzliche Absicherung:
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Die doppelte Absicherung über Gnome-Settings und systemd ist bewusst: Gnome hat gelegentlich eigene Ideen, wann der Rechner schlafen sollte. Das Maskieren der systemd-Targets stellt sicher, dass wirklich nichts den Rechner in den Suspend schickt. Rückgängig machen lässt sich das jederzeit mit systemctl unmask.

NVIDIA Runtime Power Management

Die NVIDIA-Karte zieht im Leerlauf 10–15 Watt — unnötig, wenn gerade niemand spielt und Ollama nicht läuft. Per udev-Regel lässt sich das Runtime Power Management aktivieren. Die Karte geht dann automatisch in einen Low-Power-State und wacht bei Bedarf wieder auf:

sudo tee /etc/udev/rules.d/80-nvidia-pm.rules << 'EOF'
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="auto"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger

Ob die Karte tatsächlich schläft, verrät ein Blick in sysfs:

cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
# "suspended" = Karte schläft. "active" = Karte arbeitet.

CPU Power Profiles

Fedora bringt mit power-profiles-daemon drei Leistungsstufen mit, zwischen denen sich im laufenden Betrieb umschalten lässt:

powerprofilesctl set power-saver      # Idle, SSH — CPU taktet minimal
powerprofilesctl set balanced          # Entwicklung, leichte Last
powerprofilesctl set performance       # Vollgas: Ollama-Inferenz, Kompilieren

Im Alltag läuft der Rechner auf balanced. Der Ryzen 9 regelt seine Taktfrequenz dynamisch und braucht im Leerlauf kaum mehr Strom als ein sparsamer Office-PC. Erst wenn ein ollama-Prozess oder eine Kompilierung alle Kerne fordert, dreht er auf.

Monitoring

Wer es genau wissen will:

# CPU-Leistungsaufnahme in Echtzeit:
sudo turbostat --Summary --show PkgWatt --interval 5

# NVIDIA-Leistungsaufnahme:
nvidia-smi -q -d POWER | grep "Power Draw"

Im Leerlauf mit schlafender GPU misst turbostat 22,5 Watt allein für CPU und Board. Mit aktiver, aber unbeschäftigter NVIDIA kommt das System auf rund 35 Watt — immer noch weniger als mancher NAS verbraucht."

Fazit

War das alles komplizierter als eine Windows-Installation? Ohne Frage. Mein Kollege hat den gleichen Bauvorschlag auf Windows aufgesetzt und war in einer Stunde fertig. Bei mir wurden es mehrere Abende. Aber am Ende steht ein System, das mehr kann als eine Gaming-Kiste.

Roblox läuft über Sober , Minecraft mit Complementary-Reimagined-Shadern flüssig auf der RTX 4070 Ti Super. Commandos 2 funktioniert via Proton , 7 Days to Die hat sogar einen nativen Linux-Build. Dank Proton und Steam sind inzwischen rund 90 Prozent der Windows-Spielebibliothek unter Linux spielbar — das hätte ich vor fünf Jahren nicht für möglich gehalten.

Was ich mitgenommen habe: Wer einen Linux-Rechner mit Dual-GPU konfiguriert, versteht am Ende genau, was jede Komponente tut und warum. Kein Treiber-Assistent nimmt einem die Entscheidung ab, aber man steht auch nicht ratlos vor einer Blackbox, wenn etwas nicht funktioniert. Jede Lösung ist nachvollziehbar, dokumentiert und reproduzierbar — von der udev-Regel bis zum Wrapper Command.

Oder, um es in meiner Berufssprache auszudrücken: Das System ist unter Stress besser geworden.