Un bureau Linux dans le cloud avec un GPU : ce que le GPU change vraiment

De plus en plus de gens veulent un bureau Linux qui vit sur un serveur : un environnement de travail identique depuis chaque ordinateur, un navigateur qui tourne loin de votre portable, un endroit pour les applications de bureau d’IA et les agents qui continuent de tourner quand vous fermez l’écran. Des outils comme Kasm Workspaces, webtop, Apache Guacamole ou RustDesk répondent tous à ce besoin. La plupart dessinent le bureau en logiciel, sur le CPU.

Nous nous sommes donc posé une question simple : sur un serveur cloud avec un GPU Intel partagé, qu’apporte le GPU à un bureau à distance ? Nous avons fait tourner le même bureau sur le même serveur, diffusé vers un client en 1080p à 60 i/s, d’abord avec le GPU pour dessiner les applications et encoder le flux, puis avec tout le travail fait par le CPU.

Le même bureau cloud tel que le reçoit un client Moonlight (5 secondes chacun). En haut : GPU, WebGL Aquarium à 62 i/s. En bas : CPU seul, 9 i/s, et le flux lui-même descend à environ 45 i/s. Les statistiques de Moonlight sont en haut à gauche.

Les résultats en bref

Le GPU laisse le serveur libre. Avec le GPU, le bureau entier et son flux ont utilisé 0,14 vCPU au repos, 0,31 pour une vidéo 1080p, 0,44 pour faire défiler une page web lourde et 0,56 pour une scène WebGL, sur 4. En logiciel, les mêmes tâches ont pris 0,96, 2,71, 3,21 et 3,88 vCPU : dès la lecture vidéo, le serveur était presque plein.
La 3D dans le navigateur a besoin du GPU. WebGL Aquarium a tourné à 62 i/s sur le GPU et 7 i/s en logiciel, en utilisant les 4 vCPU. Sans option de repli logiciel, Chromium désactive tout simplement le WebGL.
Un flux plus fluide et plus rapide. Avec le GPU, Moonlight a reçu 60 i/s dans chaque test et Sunshine a mis 8 à 11 ms par image sur le serveur. En logiciel, le flux est tombé à 52 à 59 i/s et a pris 25 à 32 ms par image dès que quelque chose bougeait.
L’encodage seul : 0,1 cœur au lieu de 1. L’encodeur H.264 de Sunshine sur le GPU (VA-API) a utilisé 0,10 à 0,15 cœur ; l’encodeur logiciel x264 a utilisé 0,81 à 1,19 cœur pour le même flux 1080p60.
0 blocage du GPU (GPU hang) sur l’hôte pendant tout le test.

Configuration du test

Élément	Valeur
Serveur	Debian 13, Linux 7.3, Intel UHD 770 (GPU partagé), 4 vCPU, 8 Go de RAM
Bureau	sway (Wayland, paquet Debian) en mode headless, 1920×1080, waybar, terminal foot ; Xwayland pour les applications X11
Navigateur	Chromium 156 (paquet Debian), Wayland natif
Diffusion	Sunshine 2026.914 (`capture = wlr`), H.264 1080p 60 i/s à 15 Mbit/s
Client	Moonlight (AppImage Qt) sur un second serveur dans le même centre de données (réseau à 1 ms), décodage matériel
Mode GPU	Chromium sur le GPU (OpenGL ES via Mesa, décodage vidéo avec VA-API), Sunshine `encoder = vaapi`
Mode logiciel	Chromium avec SwiftShader (le moteur de rendu CPU de Chrome) et sans décodage vidéo matériel, Sunshine `encoder = software` (x264 superfast)
Tests	bureau au repos ; Big Buck Bunny 1080p30 H.264 dans une `<video>` plein écran ; WebGL Aquarium (500 poissons) ; en.wikipedia.org/wiki/Linux défilée de 12 px par image
Mesures	12 s de mise en route puis 30 s par test pendant que Moonlight diffuse ; CPU de tout le serveur via `/proc/stat` ; fréquences d’images mesurées dans la page (`requestAnimationFrame`, `getVideoPlaybackQuality`) ; statistiques de fin de flux de Moonlight. 3 passes sur le GPU, 2 en logiciel, moyennées

Les chiffres CPU sont en vCPU (1,00 = un cœur entier sur les 4). Dans les deux modes, le gestionnaire de fenêtres lui-même dessine sur le GPU : Sunshine ne peut pas capturer une session sway dessinée par le CPU. Un serveur sans aucun GPU ferait donc un peu moins bien que notre mode logiciel.

1. Le CPU du serveur : la principale différence

Graphique en barres : CPU du serveur utilisé par le bureau diffusé dans quatre tests, GPU contre logiciel — CPU de tout le serveur, en vCPU sur 4, pendant que Moonlight diffuse le bureau. GPU en vert, CPU seul en orange.

Test	GPU : serveur	dont Chromium	dont Sunshine	Logiciel : serveur	dont Chromium	dont Sunshine
Bureau au repos	0,14 vCPU	—	0,10	0,96 vCPU	—	0,92
Vidéo 1080p	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
Défilement de Wikipédia	0,44 vCPU	0,25	0,15	3,21 vCPU	1,91	1,23

Deux choses remplissent le CPU en logiciel. D’abord les applications : Chromium a eu besoin de 1,2 cœur pour décoder et afficher une vidéo 1080p, et de 2,8 cœurs pour dessiner mal l’aquarium. Ensuite le flux : l’encodeur logiciel coûte environ un cœur en permanence, même quand rien ne bouge à l’écran, parce qu’il envoie quand même 60 images par seconde. Sur le GPU, ces deux tâches passent sur des moteurs dédiés : dans nos mesures, le moteur vidéo du GPU était occupé à 15 à 43 % et son moteur 3D à 5 à 30 %.

Sans aucun flux (le bureau seul, sans personne de connecté), le bureau sur GPU a utilisé 0,00 vCPU au repos, 0,10 pour la vidéo et 0,26 pour l’aquarium.

2. Fréquence d’images : la page et le flux

Graphique en barres : fréquence d'images de WebGL Aquarium et images par seconde reçues par Moonlight, GPU contre logiciel — Première barre : images dessinées par WebGL Aquarium dans la page. Autres barres : images par seconde reçues par le client Moonlight pendant chaque test.

Avec le GPU, chaque page a tourné aux 60 i/s complets de l’écran (61,5 à 61,8 mesurés par la page) et la vidéo a lu ses 30 images par seconde sans en perdre une. En logiciel, la vidéo a aussi été lue sans perte et le défilement est resté à 60 i/s dans la page, mais le serveur était si occupé que le flux a perdu des images : Moonlight a reçu 58,5 i/s pendant la vidéo, 55,8 pendant le défilement et 52,0 avec l’aquarium. À l’écran, cela donne un bureau qui saccade.

Client Moonlight affichant le bureau cloud : un terminal et Chromium avec WebGL Aquarium à 62 i/s, statistiques Moonlight à 59,8 i/s et 10,1 ms de traitement sur l'hôte — GPU : WebGL Aquarium à 62 i/s ; Moonlight reçoit 59,8 i/s, avec 10,1 ms de traitement sur le serveur. La barre du haut montre le CPU du serveur à 13 %.

Le même bureau en logiciel : WebGL Aquarium à 7 i/s, statistiques Moonlight à 50,5 i/s et 32,6 ms de traitement sur l'hôte, CPU du serveur à 97 % — Logiciel : l'aquarium tombe à 7 i/s, le flux à 50,5 i/s avec 32,6 ms sur le serveur, et le CPU est à 97 %.

3. La latence du flux sur le serveur

Graphique en barres : temps de traitement par image de Sunshine sur l'hôte dans quatre tests, GPU contre logiciel — Temps moyen dont Sunshine a besoin sur le serveur pour capturer et encoder une image, tel que l'indique Moonlight. Plus c'est bas, plus le bureau est réactif.

Moonlight indique le temps que chaque image passe sur le serveur (« host processing latency »). Avec le GPU, il était de 8,1 à 10,8 ms en moyenne, avec des pics autour de 20 à 32 ms. En logiciel, il était de 14 ms au repos et de 25 à 32 ms dès que l’écran bougeait, avec des pics de 51 à 67 ms. La latence de votre connexion Internet s’ajoute à cela : notre client était à 1 ms, dans le même centre de données.

4. L’encodeur seul : VA-API contre x264

Graphique en barres : CPU utilisé par Sunshine avec l'encodeur VA-API et avec l'encodeur x264 dans quatre tests — CPU utilisé par Sunshine seul, avec Chromium sur le GPU dans les deux cas, pour que seul l'encodeur change.

Pour isoler l’encodeur, nous avons gardé les applications sur le GPU et seulement fait passer Sunshine de VA-API à x264. Sunshine est passé de 0,10-0,15 cœur à 0,81-1,19 cœur, et le temps par image sur le serveur de 8-11 ms à 12-17 ms. Nous avons aussi chronométré les encodeurs avec ffmpeg sur 60 secondes de vidéo 1080p brute :

Encodeur (H.264, 15 Mbit/s)	Vitesse maximale	CPU pour un flux 1080p60
`h264_vaapi` (GPU)	194 i/s	0,18 cœur
`h264_vaapi`, mode basse consommation (GPU)	254 i/s	0,19 cœur
`libx264` superfast, latence nulle (CPU)	126 i/s	1,35 cœur
`libx264` veryfast (CPU)	78 i/s	2,31 cœurs

Sur 2 vCPU, un encodeur logiciel prendrait à lui seul plus de la moitié du serveur. L’encodeur du GPU pourrait gérer trois flux 1080p60 en même temps.

5. À quoi ça ressemble, et ce que vous pouvez y faire tourner

Le bureau cloud : un terminal affichant Debian 13, Linux 7.3, le moteur de rendu OpenGL Intel UHD 770 et ses profils VA-API, à côté de Chromium qui lit Big Buck Bunny — Le bureau sur le serveur : le terminal montre OpenGL sur l'Intel UHD 770 et les encodeurs VA-API ; Chromium lit une vidéo 1080p décodée par le GPU. CPU à 4 %, 1,3 Go de RAM utilisé.

C’est un bureau Linux normal : un navigateur avec WebGL et vidéo matérielle, un terminal, des applications de bureautique, un IDE, de la retouche d’image, et des applications de bureau pour l’IA. Il existe par exemple des versions communautaires de Claude Desktop pour Linux ; ce sont des paquets non officiels, non pris en charge par Anthropic, et nous n’en avons pas installé ici car il faut un compte. Il en va de même pour les applications qui pilotent un navigateur pour un agent IA : voir OpenClaw sur un serveur GPU : pourquoi le GPU compte pour votre agent IA et Lancer Chrome avec le GPU sur un serveur Linux.

Le bureau a utilisé entre 1,3 et 1,7 Go de RAM avec Chromium ouvert.

6. Une application ou un navigateur ?

Nous avons testé Sunshine et Moonlight parce qu’ils utilisent le GPU aux deux bouts : encodage VA-API sur le serveur, décodage matériel sur votre appareil, et des clients pour Windows, macOS, Linux, Android, iOS et Apple TV. Moonlight a été conçu pour les jeux, il est donc très réactif, mais il n’a pas de transfert de fichiers : utilisez scp, SFTP ou un outil de synchronisation pour les fichiers.

Si vous préférez un navigateur et rien à installer, des projets comme Selkies (WebRTC), Kasm Workspaces ou webtop diffusent un bureau dans une page web, et Apache Guacamole relaie le RDP ou le VNC. Nous ne les avons pas mesurés ici. Vérifiez si le bureau derrière eux est dessiné sur le GPU et si le flux est encodé avec VA-API : un bureau dessiné par Xvfb ou xrdp est uniquement logiciel, comme notre mode logiciel.

7. Se connecter en toute sécurité

Sunshine ouvre plusieurs ports (47984 à 48010) et une page web d’administration sur le port 47990. Ne les exposez jamais à Internet. Mettez le serveur et vos appareils sur un réseau privé avec Tailscale (ou WireGuard) et connectez Moonlight à l’adresse Tailscale du serveur :

# sur le serveur et sur chaque appareil
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# le pare-feu du serveur peut alors bloquer tous les ports de Sunshine sauf sur tailscale0

Appairez chaque appareil une fois avec le code PIN de Sunshine, puis ne laissez la page d’administration joignable que via le tailnet ou un tunnel SSH (ssh -L 47990:localhost:47990 <server>). Nous expliquons toute la mise en place pas à pas dans Jouer sur votre serveur cloud de n’importe où avec Moonlight et Tailscale.

8. Le mettre en place vous-même

Envie d’un serveur prêt à l’emploi ? Demandez-le par e-mail à la commande (contact@linuxgpu.eu) : nous pouvons vous livrer le serveur avec le bureau, Sunshine sur le GPU et Tailscale déjà installés.

Sur Debian 13, en root :

apt install sway waybar foot xwayland seatd chromium intel-media-va-driver-non-free vainfo
# Sunshine : le .deb Debian 13 (« trixie ») de github.com/LizardByte/Sunshine/releases
apt install ./sunshine-*trixie*amd64.deb
useradd -m -G video,render,input desk && systemctl enable --now seatd

Ensuite, avec l’utilisateur desk, lancez sway sans écran et Sunshine sur le 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 = pas d'écran ; libinput = clavier et souris envoyés par Moonlight (via 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 &

Le journal de Sunshine doit indiquer Creating encoder [h264_vaapi]. Lancez Chromium avec --ozone-platform=wayland ; chrome://gpu doit alors lister l’Intel UHD 770 et l’aquarium doit tourner à la fréquence d’images de l’écran. Sans libinput dans WLR_BACKENDS, le bureau s’affiche bien mais ignore le clavier et la souris.

Les limites de ce test

Un utilisateur, 4 vCPU, un client à 1 ms. Sur Internet, ajoutez la latence de votre connexion. Nous n’avons testé ni le son ni plusieurs utilisateurs à la fois.
sway est un gestionnaire de fenêtres en mosaïque (tiling). Il fonctionne très bien sans écran. GNOME et KDE Plasma demandent une autre configuration headless que nous n’avons pas mesurée ici.
Le GPU est partagé. D’autres serveurs l’utilisent aussi, donc les temps par image peuvent varier un peu quand ils sont occupés. Chaque offre a sa propre part du GPU (Perf 1, 2 ou 3).
Notre mode logiciel utilisait quand même le GPU pour le gestionnaire de fenêtres. Un serveur sans aucun GPU serait plus lent que ce que nous avons mesuré en logiciel.

Quelle offre ?

Avec le GPU, le bureau diffusé a utilisé 0,1 à 0,6 vCPU et environ 1,5 Go de RAM dans nos tests.

iGPU Start (2 vCPU, 8 Go de RAM, Perf 1, 14,99 € HT par mois) : le bureau d’une personne pour la navigation, la bureautique, le développement et les applications de bureau d’IA. Avec le GPU, une vidéo 1080p ou une page WebGL laisse plus d’un vCPU libre ; en logiciel, 2 vCPU seraient déjà pleins.
iGPU Power (4 vCPU, 14 Go, Perf 2 = deux fois la part GPU de Start, 29,99 €) : une navigation lourde avec beaucoup d’onglets, de la 3D dans le navigateur, du travail de design, ou un bureau plus des services Docker et des agents IA sur le même serveur. C’est la taille que nous avons testée.
iGPU Pro (6 vCPU, 14 Go, Perf 3, 44,99 €) : un bureau à côté de travaux GPU plus lourds comme le transcodage ou des modèles d’IA locaux.

Essayer

Voir les offres : iGPU Start coûte 14,99 € et iGPU Power 29,99 € HT par mois.