Blog

Ein Linux-Desktop in der Cloud mit GPU: was die GPU wirklich ändert

Wir haben einen vollständigen Linux-Desktop auf einem Cloud-Server mit einer geteilten Intel UHD 770 betrieben und mit Sunshine und Moonlight gestreamt, einmal mit der GPU und einmal in Software. Mit der GPU brauchten ein 1080p-Video, eine WebGL-Szene oder eine schwere Webseite 0,3 bis 0,6 vCPU und blieben bei 60 fps; in Software brauchte derselbe Desktop 2,7 bis 3,9 vCPU, WebGL fiel auf 7 fps und die Stream-Latenz auf dem Server verdreifachte sich.

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.

Derselbe Cloud-Desktop, wie ihn ein Moonlight-Client empfängt (je 5 Sekunden). Oben: GPU, WebGL Aquarium mit 62 fps. Unten: nur CPU, 9 fps, und der Stream selbst fällt auf etwa 45 fps. Die Statistiken von Moonlight stehen oben links.

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

ElementWert
ServerDebian 13, Linux 7.3, Intel UHD 770 (geteilte GPU), 4 vCPU, 8 GB RAM
Desktopsway (Wayland, Debian-Paket) im Headless-Modus, 1920×1080, waybar, Terminal foot; Xwayland für X11-Apps
BrowserChromium 156 (Debian-Paket), nativ unter Wayland
StreamingSunshine 2026.914 (capture = wlr), H.264 1080p 60 fps mit 15 Mbit/s
ClientMoonlight (Qt-AppImage) auf einem zweiten Server im selben Rechenzentrum (1 ms Netzwerk), Hardware-Dekodierung
GPU-ModusChromium auf der GPU (OpenGL ES über Mesa, Videodekodierung mit VA-API), Sunshine encoder = vaapi
Software-ModusChromium mit SwiftShader (dem CPU-Renderer von Chrome) und ohne Hardware-Videodekodierung, Sunshine encoder = software (x264 superfast)
TestsDesktop 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
Messungen12 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

Balkendiagramm: Server-CPU, die der gestreamte Desktop in vier Tests braucht, GPU gegen Software
CPU des ganzen Servers, in vCPU von 4, während Moonlight den Desktop streamt. GPU in Grün, nur CPU in Orange.
TestGPU: Serverdavon Chromiumdavon SunshineSoftware: Serverdavon Chromiumdavon Sunshine
Desktop im Leerlauf0,14 vCPU—0,100,96 vCPU—0,92
1080p-Video0,31 vCPU0,120,142,71 vCPU1,231,45
WebGL Aquarium0,56 vCPU0,370,153,88 vCPU2,841,00
Wikipedia scrollen0,44 vCPU0,250,153,21 vCPU1,911,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

Balkendiagramm: Bildrate von WebGL Aquarium und von Moonlight empfangene Bilder pro Sekunde, GPU gegen Software
Erster Balken: von WebGL Aquarium in der Seite gezeichnete Bilder. Weitere Balken: vom Moonlight-Client in jedem Test empfangene Bilder pro Sekunde.

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.

Moonlight-Client mit dem Cloud-Desktop: ein Terminal und Chromium mit WebGL Aquarium bei 62 fps, Moonlight-Statistiken bei 59,8 fps und 10,1 ms Verarbeitung auf dem Host
GPU: WebGL Aquarium mit 62 fps; Moonlight empfängt 59,8 fps, mit 10,1 ms Verarbeitung auf dem Server. Die Leiste oben zeigt die CPU des Servers bei 13 %.
Derselbe Desktop in Software: WebGL Aquarium bei 7 fps, Moonlight-Statistiken bei 50,5 fps und 32,6 ms Verarbeitung auf dem Host, Server-CPU bei 97 %
Software: Das Aquarium fällt auf 7 fps, der Stream auf 50,5 fps mit 32,6 ms auf dem Server, und die CPU steht bei 97 %.

3. Stream-Latenz auf dem Server

Balkendiagramm: Verarbeitungszeit von Sunshine auf dem Host pro Bild in vier Tests, GPU gegen Software
Durchschnittliche Zeit, die Sunshine auf dem Server braucht, um ein Bild aufzunehmen und zu kodieren, wie von Moonlight gemeldet. Weniger bedeutet einen reaktionsschnelleren Desktop.

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

Balkendiagramm: von Sunshine genutzte CPU mit dem VA-API-Encoder und mit dem x264-Encoder in vier Tests
Nur von Sunshine genutzte CPU, in beiden Fällen mit Chromium auf der GPU, sodass sich nur der Encoder ändert.

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öchstgeschwindigkeitCPU für einen 1080p60-Stream
h264_vaapi (GPU)194 fps0,18 Kern
h264_vaapi, Low-Power-Modus (GPU)254 fps0,19 Kern
libx264 superfast, Zero Latency (CPU)126 fps1,35 Kerne
libx264 veryfast (CPU)78 fps2,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

Der Cloud-Desktop: ein Terminal mit Debian 13, Linux 7.3, dem OpenGL-Renderer Intel UHD 770 und seinen VA-API-Profilen, daneben Chromium, das Big Buck Bunny abspielt
Der Desktop auf dem Server: Das Terminal zeigt OpenGL auf der Intel UHD 770 und die VA-API-Encoder; Chromium spielt ein von der GPU dekodiertes 1080p-Video ab. CPU bei 4 %, 1,3 GB RAM belegt.

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.