Un escritorio Linux en la nube con GPU: lo que la GPU cambia de verdad

Cada vez más gente quiere un escritorio Linux que viva en un servidor: un entorno de trabajo idéntico desde cualquier ordenador, un navegador que funciona lejos de tu portátil, un sitio para las aplicaciones de escritorio de IA y los agentes que siguen funcionando cuando cierras la tapa. Herramientas como Kasm Workspaces, webtop, Apache Guacamole o RustDesk responden a esa necesidad. La mayoría dibujan el escritorio por software, en la CPU.

Así que nos hicimos una pregunta sencilla: en un servidor en la nube con una GPU Intel compartida, ¿qué aporta la GPU a un escritorio remoto? Ejecutamos el mismo escritorio en el mismo servidor, transmitido a un cliente en 1080p y 60 fps, primero con la GPU dibujando las aplicaciones y codificando el flujo, y luego con todo hecho por la CPU.

El mismo escritorio en la nube tal como lo recibe un cliente Moonlight (5 segundos cada uno). Arriba: GPU, WebGL Aquarium a 62 fps. Abajo: solo CPU, 9 fps, y el propio flujo baja a unos 45 fps. Las estadísticas de Moonlight están arriba a la izquierda.

Resultados de un vistazo

La GPU deja libre el servidor. Con la GPU, todo el escritorio y su flujo usaron 0,14 vCPU en reposo, 0,31 con un vídeo 1080p, 0,44 al desplazar una página web pesada y 0,56 con una escena WebGL, de 4. Por software las mismas tareas necesitaron 0,96, 2,71, 3,21 y 3,88 vCPU: a partir de la reproducción de vídeo, el servidor estaba casi lleno.
El 3D en el navegador necesita la GPU. WebGL Aquarium funcionó a 62 fps en la GPU y 7 fps por software, usando las 4 vCPU. Sin un flag de renderizado por software, Chromium simplemente desactiva WebGL.
Un flujo más fluido y más rápido. Con la GPU, Moonlight recibió 60 fps en todas las pruebas y Sunshine necesitó de 8 a 11 ms por fotograma en el servidor. Por software el flujo bajó a 52 a 59 fps y tardó de 25 a 32 ms por fotograma en cuanto algo se movía.
Solo la codificación: 0,1 núcleo en lugar de 1. El codificador H.264 de Sunshine en la GPU (VA-API) usó de 0,10 a 0,15 de un núcleo; el codificador por software x264 usó de 0,81 a 1,19 núcleos para el mismo flujo 1080p60.
0 cuelgues de la GPU en el host durante toda la prueba.

Configuración de la prueba

Elemento	Valor
Servidor	Debian 13, Linux 7.3, Intel UHD 770 (GPU compartida), 4 vCPU, 8 GB de RAM
Escritorio	sway (Wayland, paquete de Debian) en modo headless, 1920×1080, waybar, terminal foot; Xwayland para las aplicaciones X11
Navegador	Chromium 156 (paquete de Debian), Wayland nativo
Streaming	Sunshine 2026.914 (`capture = wlr`), H.264 1080p 60 fps a 15 Mbit/s
Cliente	Moonlight (AppImage Qt) en un segundo servidor del mismo centro de datos (red de 1 ms), decodificación por hardware
Modo GPU	Chromium en la GPU (OpenGL ES a través de Mesa, decodificación de vídeo con VA-API), Sunshine `encoder = vaapi`
Modo software	Chromium con SwiftShader (el renderizador por CPU de Chrome) y sin decodificación de vídeo por hardware, Sunshine `encoder = software` (x264 superfast)
Pruebas	escritorio en reposo; Big Buck Bunny 1080p30 H.264 en un `<video>` a pantalla completa; WebGL Aquarium (500 peces); en.wikipedia.org/wiki/Linux desplazado 12 px por fotograma
Mediciones	12 s de calentamiento y luego 30 s por prueba mientras Moonlight transmite; CPU de todo el servidor desde `/proc/stat`; fotogramas por segundo medidos en la página (`requestAnimationFrame`, `getVideoPlaybackQuality`); estadísticas de fin de sesión de Moonlight. 3 ejecuciones en la GPU, 2 por software, promediadas

Las cifras de CPU están en vCPU (1,00 = un núcleo completo de los 4). En ambos modos el propio gestor de ventanas dibuja en la GPU: Sunshine no puede capturar una sesión de sway dibujada por la CPU. Un servidor sin ninguna GPU lo haría, por tanto, un poco peor que nuestro modo software.

1. CPU del servidor: la diferencia principal

Gráfico de barras: CPU del servidor usada por el escritorio transmitido en cuatro pruebas, GPU frente a software — CPU de todo el servidor, en vCPU de 4, mientras Moonlight transmite el escritorio. GPU en verde, solo CPU en naranja.

Prueba	GPU: servidor	de ello Chromium	de ello Sunshine	Software: servidor	de ello Chromium	de ello Sunshine
Escritorio en reposo	0,14 vCPU	—	0,10	0,96 vCPU	—	0,92
Vídeo 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
Desplazamiento en Wikipedia	0,44 vCPU	0,25	0,15	3,21 vCPU	1,91	1,23

Por software, dos cosas llenan la CPU. Primero las aplicaciones: Chromium necesitó 1,2 núcleos para decodificar y mostrar un vídeo 1080p, y 2,8 núcleos para dibujar mal el acuario. Después el flujo: el codificador por software cuesta alrededor de un núcleo todo el tiempo, incluso cuando nada se mueve en la pantalla, porque sigue enviando 60 fotogramas por segundo. En la GPU, ambos trabajos pasan a motores dedicados: en nuestras mediciones el motor de vídeo de la GPU estuvo ocupado entre el 15 y el 43 % y su motor 3D entre el 5 y el 30 %.

Sin ningún flujo (el escritorio solo, sin nadie conectado), el escritorio en GPU usó 0,00 vCPU en reposo, 0,10 con el vídeo y 0,26 con el acuario.

2. Fotogramas por segundo: la página y el flujo

Gráfico de barras: fotogramas por segundo de WebGL Aquarium y fotogramas por segundo recibidos por Moonlight, GPU frente a software — Primera barra: fotogramas dibujados por WebGL Aquarium en la página. Otras barras: fotogramas por segundo recibidos por el cliente Moonlight durante cada prueba.

Con la GPU, todas las páginas funcionaron a los 60 fps completos de la pantalla (de 61,5 a 61,8 medidos por la página) y el vídeo reprodujo sus 30 fotogramas por segundo sin perder ninguno. Por software el vídeo también se reprodujo sin pérdidas y el desplazamiento se mantuvo a 60 fps dentro de la página, pero el servidor estaba tan ocupado que el flujo perdió fotogramas: Moonlight recibió 58,5 fps durante el vídeo, 55,8 durante el desplazamiento y 52,0 con el acuario. En la pantalla, eso es un escritorio que va a tirones.

Cliente Moonlight mostrando el escritorio en la nube: un terminal y Chromium con WebGL Aquarium a 62 fps, estadísticas de Moonlight a 59,8 fps y 10,1 ms de procesamiento en el host — GPU: WebGL Aquarium a 62 fps; Moonlight recibe 59,8 fps, con 10,1 ms de procesamiento en el servidor. La barra superior muestra la CPU del servidor al 13 %.

El mismo escritorio por software: WebGL Aquarium a 7 fps, estadísticas de Moonlight a 50,5 fps y 32,6 ms de procesamiento en el host, CPU del servidor al 97 % — Software: el acuario cae a 7 fps, el flujo a 50,5 fps con 32,6 ms en el servidor, y la CPU está al 97 %.

3. Latencia del flujo en el servidor

Gráfico de barras: tiempo de procesamiento de Sunshine en el host por fotograma en cuatro pruebas, GPU frente a software — Tiempo medio que necesita Sunshine en el servidor para capturar y codificar un fotograma, según Moonlight. Menos significa un escritorio más reactivo.

Moonlight indica el tiempo que pasa cada fotograma en el servidor («host processing latency»). Con la GPU fue de 8,1 a 10,8 ms de media, con picos de unos 20 a 32 ms. Por software fue de 14 ms en reposo y de 25 a 32 ms en cuanto la pantalla se movía, con picos de 51 a 67 ms. A eso se suma la latencia de tu conexión a Internet: nuestro cliente estaba a 1 ms, en el mismo centro de datos.

4. El codificador solo: VA-API frente a x264

Gráfico de barras: CPU usada por Sunshine con el codificador VA-API y con el codificador x264 en cuatro pruebas — CPU usada solo por Sunshine, con Chromium en la GPU en ambos casos, para que solo cambie el codificador.

Para aislar el codificador, dejamos las aplicaciones en la GPU y solo cambiamos Sunshine de VA-API a x264. Sunshine pasó de 0,10-0,15 núcleos a 0,81-1,19 núcleos, y el tiempo por fotograma en el servidor de 8-11 ms a 12-17 ms. También cronometramos los codificadores con ffmpeg sobre 60 segundos de vídeo 1080p sin comprimir:

Codificador (H.264, 15 Mbit/s)	Velocidad máxima	CPU para un flujo 1080p60
`h264_vaapi` (GPU)	194 fps	0,18 núcleos
`h264_vaapi`, modo de bajo consumo (GPU)	254 fps	0,19 núcleos
`libx264` superfast, latencia cero (CPU)	126 fps	1,35 núcleos
`libx264` veryfast (CPU)	78 fps	2,31 núcleos

Con 2 vCPU, un codificador por software ocuparía por sí solo más de la mitad del servidor. El codificador de la GPU podría con tres flujos 1080p60 a la vez.

5. Qué aspecto tiene y qué puedes ejecutar

El escritorio en la nube: un terminal que muestra Debian 13, Linux 7.3, el renderizador OpenGL Intel UHD 770 y sus perfiles VA-API, junto a Chromium reproduciendo Big Buck Bunny — El escritorio en el servidor: el terminal muestra OpenGL en la Intel UHD 770 y los codificadores VA-API; Chromium reproduce un vídeo 1080p decodificado por la GPU. CPU al 4 %, 1,3 GB de RAM usados.

Es un escritorio Linux normal: un navegador con WebGL y vídeo por hardware, un terminal, ofimática, un IDE, edición de imágenes y aplicaciones de escritorio de IA. Existen, por ejemplo, compilaciones comunitarias de Claude Desktop para Linux; son paquetes no oficiales, sin soporte de Anthropic, y no instalamos ninguno aquí porque necesita una cuenta. Lo mismo ocurre con las aplicaciones que controlan un navegador para un agente de IA: consulta OpenClaw en un servidor GPU: por qué la GPU importa para tu agente de IA y Ejecutar Chrome con GPU en un servidor Linux (headless, Playwright, Puppeteer).

El escritorio usó entre 1,3 y 1,7 GB de RAM con Chromium abierto.

6. ¿Una aplicación o un navegador?

Probamos Sunshine y Moonlight porque usan la GPU en ambos extremos: codificación VA-API en el servidor, decodificación por hardware en tu dispositivo, y clientes para Windows, macOS, Linux, Android, iOS y Apple TV. Moonlight se hizo para juegos, así que es muy reactivo, pero no tiene transferencia de archivos: usa scp, SFTP o una herramienta de sincronización para los archivos.

Si prefieres un navegador y nada que instalar, proyectos como Selkies (WebRTC), Kasm Workspaces o webtop transmiten un escritorio a una página web, y Apache Guacamole retransmite RDP o VNC. No los medimos aquí. Comprueba si el escritorio que hay detrás se dibuja en la GPU y si el flujo se codifica con VA-API: un escritorio dibujado por Xvfb o xrdp es solo software, como nuestro modo software.

7. Conectarse de forma segura

Sunshine abre varios puertos (de 47984 a 48010) y una página web de administración en el puerto 47990. Nunca los expongas a Internet. Pon el servidor y tus dispositivos en una red privada con Tailscale (o WireGuard) y conecta Moonlight a la dirección Tailscale del servidor:

# en el servidor y en cada dispositivo
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# el cortafuegos del servidor puede entonces bloquear todos los puertos de Sunshine excepto en tailscale0

Empareja cada dispositivo una vez con el PIN de Sunshine y deja la página de administración accesible solo a través de la tailnet o de un túnel SSH (ssh -L 47990:localhost:47990 <server>). Explicamos toda la configuración paso a paso en Juega en tu servidor en la nube desde cualquier lugar con Moonlight y Tailscale.

8. Ponerlo en marcha tú mismo

¿Lo quieres listo para usar? Pídelo por correo al hacer el pedido (contact@linuxgpu.eu): podemos entregarte el servidor con el escritorio, Sunshine en la GPU y Tailscale ya instalados.

En Debian 13, como root:

apt install sway waybar foot xwayland seatd chromium intel-media-va-driver-non-free vainfo
# Sunshine: el .deb para 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

Después, como usuario desk, inicia sway sin pantalla y Sunshine en la 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 = sin pantalla; libinput = teclado y ratón enviados por Moonlight (a través de 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 &

El log de Sunshine debería decir Creating encoder [h264_vaapi]. Inicia Chromium con --ozone-platform=wayland; entonces chrome://gpu debería mostrar la Intel UHD 770 y el acuario debería funcionar a la frecuencia de la pantalla. Sin libinput en WLR_BACKENDS, el escritorio se ve bien pero ignora el teclado y el ratón.

Límites de esta prueba

Un usuario, 4 vCPU, un cliente a 1 ms. A través de Internet, añade la latencia de tu conexión. No probamos el audio ni varios usuarios a la vez.
sway es un gestor de ventanas en mosaico (tiling). Funciona muy bien sin pantalla. GNOME y KDE Plasma necesitan otra configuración headless que no medimos aquí.
La GPU es compartida. Otros servidores también la usan, así que los tiempos por fotograma pueden variar un poco cuando están ocupados. Cada plan tiene su propia parte de la GPU (Perf 1, 2 o 3).
Nuestro modo software seguía usando la GPU para el gestor de ventanas. Un servidor sin ninguna GPU sería más lento que lo que medimos por software.

¿Qué plan elegir?

Con la GPU, el escritorio transmitido usó de 0,1 a 0,6 vCPU y unos 1,5 GB de RAM en nuestras pruebas.

iGPU Start (2 vCPU, 8 GB de RAM, Perf 1, 14,99 € al mes sin IVA): el escritorio de una persona para navegar, ofimática, desarrollo y aplicaciones de escritorio de IA. Con la GPU, un vídeo 1080p o una página WebGL dejan más de una vCPU libre; por software, 2 vCPU ya estarían llenas.
iGPU Power (4 vCPU, 14 GB, Perf 2 = el doble de GPU que Start, 29,99 €): navegación intensa con muchas pestañas, 3D en el navegador, trabajo de diseño, o un escritorio más servicios Docker y agentes de IA en el mismo servidor. Es el tamaño que probamos.
iGPU Pro (6 vCPU, 14 GB, Perf 3, 44,99 €): un escritorio junto a trabajos de GPU más pesados, como transcodificación o modelos de IA locales.

Pruébalo

Ver los planes: iGPU Start cuesta 14,99 € e iGPU Power 29,99 € al mes sin IVA.