Ein Linux-Desktop in der Cloud mit GPU: was die GPU wirklich ändert
Immer mehr Menschen wünschen sich einen Linux-Desktop, der auf einem Server läuft: eine Arbeitsumgebung, die von jedem Computer aus gleich ist, einen Browser, der nicht auf Ihrem Laptop läuft, einen Ort für KI-Desktop-Apps und Agenten, die weiterlaufen, wenn Sie den Deckel schließen. Werkzeuge wie Kasm Workspaces, webtop, Apache Guacamole oder RustDesk erfüllen alle diesen Bedarf. Die meisten zeichnen den Desktop in Software, auf der CPU.
Also haben wir eine einfache Frage gestellt: Was bringt die GPU einem Remote-Desktop auf einem Cloud-Server mit einer geteilten Intel-GPU? Wir haben denselben Desktop auf demselben Server betrieben und mit 1080p und 60 fps zu einem Client gestreamt, zuerst mit der GPU, die die Apps zeichnet und den Stream kodiert, dann mit allem auf der CPU.
Die Ergebnisse auf einen Blick
- Die GPU hält den Server frei. Mit der GPU brauchten der ganze Desktop und sein Stream 0,14 vCPU im Ruhezustand, 0,31 für ein 1080p-Video, 0,44 für das Scrollen einer schweren Webseite und 0,56 für eine WebGL-Szene, von 4. In Software brauchten dieselben Aufgaben 0,96, 2,71, 3,21 und 3,88 vCPU: Ab der Videowiedergabe war der Server fast voll.
- 3D im Browser braucht die GPU. WebGL Aquarium lief mit 62 fps auf der GPU und 7 fps in Software und belegte dabei alle 4 vCPU. Ohne ein Flag für den Software-Fallback schaltet Chromium WebGL einfach ab.
- Ein flüssigerer, schnellerer Stream. Mit der GPU empfing Moonlight in jedem Test 60 fps, und Sunshine brauchte 8 bis 11 ms pro Bild auf dem Server. In Software fiel der Stream auf 52 bis 59 fps und brauchte 25 bis 32 ms pro Bild, sobald sich etwas bewegte.
- Nur die Kodierung: 0,1 Kern statt 1. Der H.264-Encoder von Sunshine auf der GPU (VA-API) brauchte 0,10 bis 0,15 eines Kerns; der x264-Software-Encoder brauchte 0,81 bis 1,19 Kerne für denselben 1080p60-Stream.
- 0 GPU-Hänger auf dem Host während des gesamten Tests.
Testaufbau
| Element | Wert |
|---|---|
| Server | Debian 13, Linux 7.3, Intel UHD 770 (geteilte GPU), 4 vCPU, 8 GB RAM |
| Desktop | sway (Wayland, Debian-Paket) im Headless-Modus, 1920×1080, waybar, Terminal foot; Xwayland für X11-Apps |
| Browser | Chromium 156 (Debian-Paket), nativ unter Wayland |
| Streaming | Sunshine 2026.914 (capture = wlr), H.264 1080p 60 fps mit 15 Mbit/s |
| Client | Moonlight (Qt-AppImage) auf einem zweiten Server im selben Rechenzentrum (1 ms Netzwerk), Hardware-Dekodierung |
| GPU-Modus | Chromium auf der GPU (OpenGL ES über Mesa, Videodekodierung mit VA-API), Sunshine encoder = vaapi |
| Software-Modus | Chromium mit SwiftShader (dem CPU-Renderer von Chrome) und ohne Hardware-Videodekodierung, Sunshine encoder = software (x264 superfast) |
| Tests | Desktop im Leerlauf; Big Buck Bunny 1080p30 H.264 in einem <video> im Vollbild; WebGL Aquarium (500 Fische); en.wikipedia.org/wiki/Linux, um 12 px pro Bild gescrollt |
| Messungen | 12 s Aufwärmen, dann 30 s pro Test, während Moonlight streamt; CPU des ganzen Servers aus /proc/stat; Bildraten aus der Seite (requestAnimationFrame, getVideoPlaybackQuality); Statistiken von Moonlight am Ende des Streams. 3 Durchläufe auf der GPU, 2 in Software, gemittelt |
CPU-Werte sind in vCPU angegeben (1,00 = ein ganzer Kern von 4). In beiden Modi zeichnet der Fenstermanager selbst auf der GPU: Sunshine kann keine sway-Sitzung aufnehmen, die von der CPU gezeichnet wird. Ein Server ganz ohne GPU würde daher etwas schlechter abschneiden als unser Software-Modus.
1. Server-CPU: der Hauptunterschied
| Test | GPU: Server | davon Chromium | davon Sunshine | Software: Server | davon Chromium | davon Sunshine |
|---|---|---|---|---|---|---|
| Desktop im Leerlauf | 0,14 vCPU | — | 0,10 | 0,96 vCPU | — | 0,92 |
| 1080p-Video | 0,31 vCPU | 0,12 | 0,14 | 2,71 vCPU | 1,23 | 1,45 |
| WebGL Aquarium | 0,56 vCPU | 0,37 | 0,15 | 3,88 vCPU | 2,84 | 1,00 |
| Wikipedia scrollen | 0,44 vCPU | 0,25 | 0,15 | 3,21 vCPU | 1,91 | 1,23 |
Zwei Dinge füllen die CPU in Software. Zuerst die Apps: Chromium brauchte 1,2 Kerne, um ein 1080p-Video zu dekodieren und anzuzeigen, und 2,8 Kerne, um das Aquarium schlecht zu zeichnen. Dann der Stream: Der Software-Encoder kostet ständig etwa einen Kern, selbst wenn sich auf dem Bildschirm nichts bewegt, denn er sendet weiterhin 60 Bilder pro Sekunde. Auf der GPU wandern beide Aufgaben auf dafür vorgesehene Einheiten: In unseren Messungen war die Video-Engine der GPU zu 15 bis 43 % ausgelastet und ihre 3D-Engine zu 5 bis 30 %.
Ohne Stream (nur der Desktop, ohne verbundenen Nutzer) brauchte der GPU-Desktop 0,00 vCPU im Ruhezustand, 0,10 für das Video und 0,26 für das Aquarium.
2. Bildraten: die Seite und der Stream
Mit der GPU lief jede Seite mit den vollen 60 fps des Bildschirms (61,5 bis 61,8 von der Seite gemessen), und das Video spielte seine 30 Bilder pro Sekunde ab, ohne eines zu verlieren. In Software lief das Video ebenfalls ohne Verlust, und das Scrollen blieb in der Seite bei 60 fps, aber der Server war so ausgelastet, dass der Stream Bilder verlor: Moonlight empfing 58,5 fps während des Videos, 55,8 beim Scrollen und 52,0 mit dem Aquarium. Auf dem Bildschirm ist das ein Desktop, der ruckelt.
3. Stream-Latenz auf dem Server
Moonlight meldet die Zeit, die jedes Bild auf dem Server verbringt („host processing latency“). Mit der GPU waren es im Durchschnitt 8,1 bis 10,8 ms, mit Spitzen um 20 bis 32 ms. In Software waren es 14 ms im Ruhezustand und 25 bis 32 ms, sobald sich der Bildschirm bewegte, mit Spitzen von 51 bis 67 ms. Die Latenz Ihrer Internetverbindung kommt noch hinzu: Unser Client war 1 ms entfernt, im selben Rechenzentrum.
4. Nur der Encoder: VA-API gegen x264
Um den Encoder zu isolieren, haben wir die Apps auf der GPU gelassen und Sunshine nur von VA-API auf x264 umgestellt. Sunshine ging von 0,10-0,15 Kern auf 0,81-1,19 Kerne, und die Zeit pro Bild auf dem Server von 8-11 ms auf 12-17 ms. Außerdem haben wir die Encoder mit ffmpeg auf 60 Sekunden unkomprimiertem 1080p-Video gemessen:
| Encoder (H.264, 15 Mbit/s) | Höchstgeschwindigkeit | CPU für einen 1080p60-Stream |
|---|---|---|
h264_vaapi (GPU) | 194 fps | 0,18 Kern |
h264_vaapi, Low-Power-Modus (GPU) | 254 fps | 0,19 Kern |
libx264 superfast, Zero Latency (CPU) | 126 fps | 1,35 Kerne |
libx264 veryfast (CPU) | 78 fps | 2,31 Kerne |
Auf 2 vCPU würde ein Software-Encoder allein mehr als die Hälfte des Servers belegen. Der Encoder der GPU könnte drei 1080p60-Streams gleichzeitig bewältigen.
5. Wie es aussieht und was Sie darauf betreiben können
Es ist ein normaler Linux-Desktop: ein Browser mit WebGL und Hardware-Video, ein Terminal, Office-Apps, eine IDE, Bildbearbeitung und Desktop-Apps für KI. Es gibt zum Beispiel Community-Builds von Claude Desktop für Linux; das sind inoffizielle Pakete, die nicht von Anthropic unterstützt werden, und wir haben hier keines installiert, weil es ein Konto erfordert. Dasselbe gilt für Apps, die einen Browser für einen KI-Agenten steuern: siehe OpenClaw auf einem GPU-Server und Chrome mit GPU auf Linux-Server starten (headless).
Der Desktop belegte mit geöffnetem Chromium zwischen 1,3 und 1,7 GB RAM.
6. Eine App oder ein Browser?
Wir haben Sunshine und Moonlight getestet, weil sie die GPU an beiden Enden nutzen: VA-API-Kodierung auf dem
Server, Hardware-Dekodierung auf Ihrem Gerät, und Clients für Windows, macOS, Linux, Android, iOS und Apple TV.
Moonlight wurde für Spiele entwickelt und reagiert daher sehr schnell, bietet aber keine Dateiübertragung: Nutzen
Sie für Dateien scp, SFTP oder ein Synchronisierungswerkzeug.
Wenn Sie einen Browser und nichts zu installieren bevorzugen, streamen Projekte wie Selkies (WebRTC), Kasm Workspaces oder webtop einen Desktop in eine Webseite, und Apache Guacamole leitet RDP oder VNC weiter. Diese haben wir hier nicht gemessen. Prüfen Sie, ob der Desktop dahinter auf der GPU gezeichnet wird und ob der Stream mit VA-API kodiert wird: Ein von Xvfb oder xrdp gezeichneter Desktop ist reine Software, wie unser Software-Modus.
7. Sicher verbinden
Sunshine öffnet mehrere Ports (47984 bis 48010) und eine Web-Verwaltungsseite auf Port 47990. Machen Sie sie niemals im Internet erreichbar. Bringen Sie den Server und Ihre Geräte mit Tailscale (oder WireGuard) in ein privates Netzwerk und verbinden Sie Moonlight mit der Tailscale-Adresse des Servers:
# auf dem Server und auf jedem Gerät
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# die Firewall des Servers kann dann jeden Sunshine-Port verwerfen, außer auf tailscale0
Koppeln Sie jedes Gerät einmal mit der PIN von Sunshine und halten Sie die Verwaltungsseite nur über das Tailnet
oder einen SSH-Tunnel erreichbar (ssh -L 47990:localhost:47990 <server>). Die ganze Einrichtung erklären wir
Schritt für Schritt in
Mit Moonlight und Tailscale überall auf Ihrem Cloud-Server spielen.
8. Selbst einrichten
Lieber sofort einsatzbereit? Fragen Sie bei der Bestellung per E-Mail danach (contact@linuxgpu.eu): Wir können Ihnen den Server mit vorinstalliertem Desktop, Sunshine auf der GPU und Tailscale liefern.
Unter Debian 13, als root:
apt install sway waybar foot xwayland seatd chromium intel-media-va-driver-non-free vainfo
# Sunshine: das .deb für Debian 13 („trixie“) von github.com/LizardByte/Sunshine/releases
apt install ./sunshine-*trixie*amd64.deb
useradd -m -G video,render,input desk && systemctl enable --now seatd
Starten Sie dann als Benutzer desk sway ohne Bildschirm und Sunshine auf der GPU:
mkdir -p ~/.config/sway ~/.config/sunshine
printf 'output HEADLESS-1 resolution 1920x1080\nbar swaybar_command waybar\n' > ~/.config/sway/config
printf 'capture = wlr\nencoder = vaapi\nadapter_name = /dev/dri/renderD128\n' > ~/.config/sunshine/sunshine.conf
export XDG_RUNTIME_DIR=/run/user/$(id -u)
# headless = kein Bildschirm; libinput = Tastatur und Maus, von Moonlight gesendet (über uinput)
LIBSEAT_BACKEND=seatd WLR_BACKENDS=headless,libinput WLR_RENDER_DRM_DEVICE=/dev/dri/renderD128 \
dbus-run-session sway &
sleep 3; WAYLAND_DISPLAY=wayland-1 sunshine ~/.config/sunshine/sunshine.conf &
Im Log von Sunshine sollte Creating encoder [h264_vaapi] stehen. Starten Sie Chromium mit
--ozone-platform=wayland; dann sollte chrome://gpu die Intel UHD 770 aufführen, und das Aquarium sollte mit der
Bildrate des Bildschirms laufen. Ohne libinput in WLR_BACKENDS wird der Desktop zwar korrekt angezeigt, ignoriert
aber Tastatur und Maus.
Grenzen dieses Tests
- Ein Nutzer, 4 vCPU, ein Client in 1 ms Entfernung. Über das Internet kommt die Latenz Ihrer Verbindung hinzu. Wir haben weder Audio noch mehrere Nutzer gleichzeitig getestet.
- sway ist ein Tiling-Fenstermanager. Er läuft sehr gut ohne Bildschirm. GNOME und KDE Plasma brauchen eine andere Headless-Einrichtung, die wir hier nicht gemessen haben.
- Die GPU ist geteilt. Andere Server nutzen sie ebenfalls, daher können die Bildzeiten leicht schwanken, wenn diese ausgelastet sind. Jedes Angebot hat seinen eigenen Anteil an der GPU (Perf 1, 2 oder 3).
- Unser Software-Modus nutzte die GPU weiterhin für den Fenstermanager. Ein Server ganz ohne GPU wäre langsamer als das, was wir in Software gemessen haben.
Welches Angebot?
Mit der GPU brauchte der gestreamte Desktop in unseren Tests 0,1 bis 0,6 vCPU und etwa 1,5 GB RAM.
- iGPU Start (2 vCPU, 8 GB RAM, Perf 1, 14,99 € netto pro Monat): der Desktop einer Person zum Surfen, für Büroarbeit, Entwicklung und KI-Desktop-Apps. Mit der GPU lassen ein 1080p-Video oder eine WebGL-Seite mehr als eine vCPU frei; in Software wären 2 vCPU bereits voll.
- iGPU Power (4 vCPU, 14 GB, Perf 2 = doppelter GPU-Anteil von Start, 29,99 €): intensives Surfen mit vielen Tabs, 3D im Browser, Designarbeit oder ein Desktop plus Docker-Dienste und KI-Agenten auf demselben Server. Das ist die Größe, die wir getestet haben.
- iGPU Pro (6 vCPU, 14 GB, Perf 3, 44,99 €): ein Desktop neben schwererer GPU-Arbeit wie Transkodierung oder lokalen KI-Modellen.
Ausprobieren
Zu den Angeboten: iGPU Start kostet 14,99 € und iGPU Power 29,99 € netto pro Monat.