Um ambiente de trabalho Linux na nuvem com GPU: o que a GPU muda realmente

Cada vez mais pessoas querem um ambiente de trabalho Linux que vive num servidor: um ambiente igual a partir de qualquer computador, um navegador que corre longe do seu portátil, um lugar para as aplicações de ambiente de trabalho de IA e para os agentes que continuam a trabalhar quando fecha a tampa. Ferramentas como Kasm Workspaces, webtop, Apache Guacamole ou RustDesk respondem a essa necessidade. A maioria desenha o ambiente de trabalho por software, no CPU.

Por isso fizemos uma pergunta simples: num servidor na nuvem com uma GPU Intel partilhada, o que traz a GPU a um ambiente de trabalho remoto? Corremos o mesmo ambiente de trabalho no mesmo servidor, transmitido para um cliente em 1080p e 60 fps, primeiro com a GPU a desenhar as aplicações e a codificar o fluxo, depois com tudo feito pelo CPU.

O mesmo ambiente de trabalho na nuvem tal como é recebido por um cliente Moonlight (5 segundos cada). Em cima: GPU, WebGL Aquarium a 62 fps. Em baixo: só CPU, 9 fps, e o próprio fluxo desce para cerca de 45 fps. As estatísticas do Moonlight estão no canto superior esquerdo.

Resultados em resumo

A GPU deixa o servidor livre. Com a GPU, todo o ambiente de trabalho e o respetivo fluxo usaram 0,14 vCPU em repouso, 0,31 com um vídeo 1080p, 0,44 ao percorrer uma página web pesada e 0,56 com uma cena WebGL, de 4. Por software, as mesmas tarefas precisaram de 0,96, 2,71, 3,21 e 3,88 vCPU: a partir da reprodução de vídeo, o servidor estava quase cheio.
O 3D no navegador precisa da GPU. O WebGL Aquarium correu a 62 fps na GPU e a 7 fps por software, usando as 4 vCPU. Sem uma flag de renderização por software, o Chromium simplesmente desativa o WebGL.
Um fluxo mais fluido e mais rápido. Com a GPU, o Moonlight recebeu 60 fps em todos os testes e o Sunshine precisou de 8 a 11 ms por imagem no servidor. Por software, o fluxo desceu para 52 a 59 fps e demorou 25 a 32 ms por imagem assim que algo se mexia.
Só a codificação: 0,1 núcleo em vez de 1. O codificador H.264 do Sunshine na GPU (VA-API) usou 0,10 a 0,15 de um núcleo; o codificador por software x264 usou 0,81 a 1,19 núcleos para o mesmo fluxo 1080p60.
0 bloqueios da GPU no anfitrião durante todo o teste.

Configuração do teste

Elemento	Valor
Servidor	Debian 13, Linux 7.3, Intel UHD 770 (GPU partilhada), 4 vCPU, 8 GB de RAM
Ambiente de trabalho	sway (Wayland, pacote Debian) em modo headless, 1920×1080, waybar, terminal foot; Xwayland para as aplicações X11
Navegador	Chromium 156 (pacote Debian), Wayland nativo
Streaming	Sunshine 2026.914 (`capture = wlr`), H.264 1080p 60 fps a 15 Mbit/s
Cliente	Moonlight (AppImage Qt) num segundo servidor no mesmo centro de dados (rede de 1 ms), descodificação por hardware
Modo GPU	Chromium na GPU (OpenGL ES através do Mesa, descodificação de vídeo com VA-API), Sunshine `encoder = vaapi`
Modo software	Chromium com SwiftShader (o renderizador por CPU do Chrome) e sem descodificação de vídeo por hardware, Sunshine `encoder = software` (x264 superfast)
Testes	ambiente de trabalho em repouso; Big Buck Bunny 1080p30 H.264 num `<video>` em ecrã inteiro; WebGL Aquarium (500 peixes); en.wikipedia.org/wiki/Linux percorrida 12 px por imagem
Medições	12 s de aquecimento e depois 30 s por teste enquanto o Moonlight transmite; CPU de todo o servidor a partir de `/proc/stat`; imagens por segundo medidas na página (`requestAnimationFrame`, `getVideoPlaybackQuality`); estatísticas de fim de sessão do Moonlight. 3 execuções na GPU, 2 por software, em média

Os valores de CPU estão em vCPU (1,00 = um núcleo inteiro dos 4). Nos dois modos, o próprio gestor de janelas desenha na GPU: o Sunshine não consegue capturar uma sessão sway desenhada pelo CPU. Um servidor sem qualquer GPU ficaria, portanto, um pouco abaixo do nosso modo software.

1. CPU do servidor: a principal diferença

Gráfico de barras: CPU do servidor usado pelo ambiente de trabalho transmitido em quatro testes, GPU contra software — CPU de todo o servidor, em vCPU de 4, enquanto o Moonlight transmite o ambiente de trabalho. GPU a verde, só CPU a laranja.

Teste	GPU: servidor	dos quais Chromium	dos quais Sunshine	Software: servidor	dos quais Chromium	dos quais Sunshine
Ambiente de trabalho em repouso	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
Percorrer a Wikipédia	0,44 vCPU	0,25	0,15	3,21 vCPU	1,91	1,23

Por software, duas coisas enchem o CPU. Primeiro as aplicações: o Chromium precisou de 1,2 núcleos para descodificar e mostrar um vídeo 1080p, e de 2,8 núcleos para desenhar mal o aquário. Depois o fluxo: o codificador por software custa cerca de um núcleo o tempo todo, mesmo quando nada se mexe no ecrã, porque continua a enviar 60 imagens por segundo. Na GPU, os dois trabalhos passam para motores dedicados: nas nossas medições, o motor de vídeo da GPU esteve ocupado entre 15 e 43% e o motor 3D entre 5 e 30%.

Sem qualquer fluxo (o ambiente de trabalho sozinho, sem ninguém ligado), o ambiente de trabalho na GPU usou 0,00 vCPU em repouso, 0,10 com o vídeo e 0,26 com o aquário.

2. Imagens por segundo: a página e o fluxo

Gráfico de barras: imagens por segundo do WebGL Aquarium e imagens por segundo recebidas pelo Moonlight, GPU contra software — Primeira barra: imagens desenhadas pelo WebGL Aquarium na página. Restantes barras: imagens por segundo recebidas pelo cliente Moonlight durante cada teste.

Com a GPU, todas as páginas correram aos 60 fps completos do ecrã (61,5 a 61,8 medidos pela página) e o vídeo reproduziu as suas 30 imagens por segundo sem perder nenhuma. Por software, o vídeo também foi reproduzido sem perdas e o deslocamento manteve-se a 60 fps dentro da página, mas o servidor estava tão ocupado que o fluxo perdeu imagens: o Moonlight recebeu 58,5 fps durante o vídeo, 55,8 durante o deslocamento e 52,0 com o aquário. No ecrã, isso é um ambiente de trabalho que engasga.

Cliente Moonlight a mostrar o ambiente de trabalho na nuvem: um terminal e o Chromium com o WebGL Aquarium a 62 fps, estatísticas do Moonlight a 59,8 fps e 10,1 ms de processamento no anfitrião — GPU: WebGL Aquarium a 62 fps; o Moonlight recebe 59,8 fps, com 10,1 ms de processamento no servidor. A barra no topo mostra o CPU do servidor a 13%.

O mesmo ambiente de trabalho por software: WebGL Aquarium a 7 fps, estatísticas do Moonlight a 50,5 fps e 32,6 ms de processamento no anfitrião, CPU do servidor a 97% — Software: o aquário cai para 7 fps, o fluxo para 50,5 fps com 32,6 ms no servidor, e o CPU está a 97%.

3. Latência do fluxo no servidor

Gráfico de barras: tempo de processamento do Sunshine no anfitrião por imagem em quatro testes, GPU contra software — Tempo médio de que o Sunshine precisa no servidor para capturar e codificar uma imagem, segundo o Moonlight. Menos significa um ambiente de trabalho mais reativo.

O Moonlight indica o tempo que cada imagem passa no servidor (“host processing latency”). Com a GPU foi de 8,1 a 10,8 ms em média, com picos de cerca de 20 a 32 ms. Por software foi de 14 ms em repouso e de 25 a 32 ms assim que o ecrã se mexia, com picos de 51 a 67 ms. A isto soma-se a latência da sua ligação à Internet: o nosso cliente estava a 1 ms, no mesmo centro de dados.

4. Só o codificador: VA-API contra x264

Gráfico de barras: CPU usado pelo Sunshine com o codificador VA-API e com o codificador x264 em quatro testes — CPU usado apenas pelo Sunshine, com o Chromium na GPU nos dois casos, para que só o codificador mude.

Para isolar o codificador, mantivemos as aplicações na GPU e mudámos apenas o Sunshine de VA-API para x264. O Sunshine passou de 0,10-0,15 núcleos para 0,81-1,19 núcleos, e o tempo por imagem no servidor de 8-11 ms para 12-17 ms. Também cronometrámos os codificadores com o ffmpeg em 60 segundos de vídeo 1080p não comprimido:

Codificador (H.264, 15 Mbit/s)	Velocidade máxima	CPU para um fluxo 1080p60
`h264_vaapi` (GPU)	194 fps	0,18 núcleos
`h264_vaapi`, modo de baixo consumo (GPU)	254 fps	0,19 núcleos
`libx264` superfast, latência zero (CPU)	126 fps	1,35 núcleos
`libx264` veryfast (CPU)	78 fps	2,31 núcleos

Com 2 vCPU, só um codificador por software ocuparia mais de metade do servidor. O codificador da GPU aguentaria três fluxos 1080p60 ao mesmo tempo.

5. Como é, e o que pode correr

O ambiente de trabalho na nuvem: um terminal que mostra Debian 13, Linux 7.3, o renderizador OpenGL Intel UHD 770 e os seus perfis VA-API, ao lado do Chromium a reproduzir Big Buck Bunny — O ambiente de trabalho no servidor: o terminal mostra o OpenGL na Intel UHD 770 e os codificadores VA-API; o Chromium reproduz um vídeo 1080p descodificado pela GPU. CPU a 4%, 1,3 GB de RAM usados.

É um ambiente de trabalho Linux normal: um navegador com WebGL e vídeo por hardware, um terminal, aplicações de escritório, um IDE, edição de imagem e aplicações de ambiente de trabalho de IA. Existem, por exemplo, builds comunitárias do Claude Desktop para Linux; são pacotes não oficiais, sem suporte da Anthropic, e não instalámos nenhum aqui porque precisa de uma conta. O mesmo se aplica às aplicações que controlam um navegador para um agente de IA: veja OpenClaw num servidor GPU: porque a GPU conta para o seu agente de IA e Chrome com GPU num servidor Linux (headless, Playwright).

O ambiente de trabalho usou entre 1,3 e 1,7 GB de RAM com o Chromium aberto.

6. Uma aplicação ou um navegador?

Testámos o Sunshine e o Moonlight porque usam a GPU nas duas pontas: codificação VA-API no servidor, descodificação por hardware no seu dispositivo, e clientes para Windows, macOS, Linux, Android, iOS e Apple TV. O Moonlight foi feito para jogos, por isso é muito reativo, mas não tem transferência de ficheiros: use scp, SFTP ou uma ferramenta de sincronização para os ficheiros.

Se preferir um navegador e nada para instalar, projetos como o Selkies (WebRTC), o Kasm Workspaces ou o webtop transmitem um ambiente de trabalho para uma página web, e o Apache Guacamole retransmite RDP ou VNC. Não os medimos aqui. Verifique se o ambiente de trabalho por trás deles é desenhado na GPU e se o fluxo é codificado com VA-API: um ambiente de trabalho desenhado pelo Xvfb ou pelo xrdp é só software, como o nosso modo software.

7. Ligar-se em segurança

O Sunshine abre várias portas (47984 a 48010) e uma página web de administração na porta 47990. Nunca as exponha à Internet. Coloque o servidor e os seus dispositivos numa rede privada com o Tailscale (ou WireGuard) e ligue o Moonlight ao endereço Tailscale do servidor:

# no servidor e em cada dispositivo
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# a firewall do servidor pode então bloquear todas as portas do Sunshine exceto em tailscale0

Emparelhe cada dispositivo uma vez com o PIN do Sunshine e mantenha a página de administração acessível apenas através da tailnet ou de um túnel SSH (ssh -L 47990:localhost:47990 <server>). Explicamos toda a configuração passo a passo em Jogue no seu servidor na nuvem a partir de qualquer lugar com Moonlight e Tailscale.

8. Configurar por si mesmo

Quer o servidor pronto a usar? Peça-o por e-mail ao encomendar (contact@linuxgpu.eu): podemos entregar-lhe o servidor com o ambiente de trabalho, o Sunshine na GPU e o Tailscale já instalados.

No Debian 13, como root:

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

Depois, como utilizador desk, inicie o sway sem ecrã e o Sunshine na 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 = sem ecrã; libinput = teclado e rato enviados pelo Moonlight (através do 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 &

O registo do Sunshine deve indicar Creating encoder [h264_vaapi]. Inicie o Chromium com --ozone-platform=wayland; o chrome://gpu deve então listar a Intel UHD 770 e o aquário deve correr à frequência do ecrã. Sem libinput em WLR_BACKENDS, o ambiente de trabalho aparece bem mas ignora o teclado e o rato.

Limites deste teste

Um utilizador, 4 vCPU, um cliente a 1 ms. Através da Internet, acrescente a latência da sua ligação. Não testámos o áudio nem vários utilizadores ao mesmo tempo.
O sway é um gestor de janelas em mosaico (tiling). Corre muito bem sem ecrã. O GNOME e o KDE Plasma precisam de outra configuração headless que não medimos aqui.
A GPU é partilhada. Outros servidores também a usam, por isso os tempos por imagem podem variar um pouco quando estão ocupados. Cada plano tem a sua própria parte da GPU (Perf 1, 2 ou 3).
O nosso modo software continuava a usar a GPU para o gestor de janelas. Um servidor sem qualquer GPU seria mais lento do que o que medimos por software.

Que plano escolher?

Com a GPU, o ambiente de trabalho transmitido usou 0,1 a 0,6 vCPU e cerca de 1,5 GB de RAM nos nossos testes.

iGPU Start (2 vCPU, 8 GB de RAM, Perf 1, 14,99 € s/ IVA por mês): o ambiente de trabalho de uma pessoa para navegar, trabalho de escritório, desenvolvimento e aplicações de ambiente de trabalho de IA. Com a GPU, um vídeo 1080p ou uma página WebGL deixam mais de uma vCPU livre; por software, 2 vCPU já estariam cheias.
iGPU Power (4 vCPU, 14 GB, Perf 2 = o dobro da parte de GPU do Start, 29,99 €): navegação intensa com muitos separadores, 3D no navegador, trabalho de design, ou um ambiente de trabalho mais serviços Docker e agentes de IA no mesmo servidor. É o tamanho que testámos.
iGPU Pro (6 vCPU, 14 GB, Perf 3, 44,99 €): um ambiente de trabalho ao lado de trabalho de GPU mais pesado, como transcodificação ou modelos de IA locais.

Experimentar

Ver os planos: o iGPU Start custa 14,99 € e o iGPU Power 29,99 € s/ IVA por mês.