Intel UHD 770 partilhada em carga máxima: teste de stress GPU de 20 minutos

Num VPS com GPU, a Intel UHD 770 integrada é partilhada entre vários servidores. A pergunta que um cliente deve fazer não é “funciona quando estou sozinho?”, mas “o que acontece quando todos os servidores da GPU a usam ao mesmo tempo?”. A 01/11/2026 testámos exatamente isso: vários servidores a carregar a mesma GPU partilhada em simultâneo, durante 20 minutos, até à saturação. Resposta curta:

0 tarefas falhadas e 0 GPU hangs em todos os servidores, nenhum reset de GPU no anfitrião.
Com a GPU saturada, cada servidor de transcodificação manteve cerca de 1,3× o tempo real na codificação H.264 1080p e em HEVC 4K → H.264 1080p, e cerca de 0,7× o tempo real em AV1 4K → HEVC 1080p.

Configuração do teste

Elemento	Valor
CPU / GPU do anfitrião	Intel Core i5-13500, Intel UHD 770 integrada
Hipervisor	Proxmox VE 9.2, kernel 7.0.14-pve
Virtualização da GPU	Controlador de virtualização de GPU Intel i915 (módulo out-of-tree), submissão GuC, CCS ativo
Servidores de teste	Debian 13, 2 vCPU e 4 GB de RAM cada, clonados do nosso template de produção
Kernel / controlador nos convidados	Linux 7.3, o mesmo módulo i915 out-of-tree, CCS ativo (`ccs0` visível)
Definição Vulkan nos convidados	`ANV_SPARSE=0`
Prioridade GPU	idêntica em todos os servidores (a nossa definição Perf 1)
Duração	20 minutos, todos os servidores arrancados em conjunto

Cada servidor executou o mesmo script com um perfil diferente: loadtest_gpu.sh <profile> 1200. O script repete uma tarefa até passarem 1 200 segundos e regista ok ou FAIL em cada ciclo.

As quatro cargas de trabalho

Carga	O que faz um ciclo
Codificação H.264 1080p	Codifica 60 s de vídeo 1080p30 em H.264 com VAAPI (codificador clássico, não `low_power`), 8 Mbit/s
Transcodificação HEVC 4K → 1080p	Descodifica na GPU um clip HEVC 4K 10 bits de 30 s, `scale_vaapi` para 1080p, codifica em H.264 a 8 Mbit/s (uma transcodificação típica de Plex/Jellyfin)
AV1 4K → HEVC 1080p	Descodifica na GPU 30 s de AV1 4K, redimensiona para 1080p, codifica em HEVC a 6 Mbit/s
Ciclo Vulkan/OpenCL	`vulkaninfo` + `clinfo` + `gpu-check` (VAAPI, Vulkan, OpenCL, OpenVINO) em ciclo

Os comandos principais, se quiser reproduzi-los no seu próprio servidor:

R=/dev/dri/renderD128

# H.264: fonte sintética 1080p30 -> H.264 VAAPI
ffmpeg -vaapi_device $R -f lavfi -i testsrc2=size=1920x1080:rate=30 -t 60 \
  -vf format=nv12,hwupload -c:v h264_vaapi -b:v 8M -f null -

# Estilo Plex: criar uma vez uma fonte HEVC Main10 4K e depois transcodificá-la para H.264 1080p
ffmpeg -vaapi_device $R -f lavfi -i testsrc2=size=3840x2160:rate=30 -t 30 \
  -vf format=p010,hwupload -c:v hevc_vaapi -profile:v main10 -b:v 40M -y src.mkv
ffmpeg -vaapi_device $R -hwaccel vaapi -hwaccel_output_format vaapi -i src.mkv \
  -vf scale_vaapi=w=1920:h=1080:format=nv12 -c:v h264_vaapi -b:v 8M -f null -

# AV1: fonte AV1 4K de 10 s (codificada na CPU, SVT-AV1), repetida 3 vezes por ciclo
ffmpeg -f lavfi -i testsrc2=size=3840x2160:rate=30 -t 10 \
  -c:v libsvtav1 -preset 12 -y src.mkv
ffmpeg -vaapi_device $R -hwaccel vaapi -hwaccel_output_format vaapi -stream_loop 2 \
  -i src.mkv -vf scale_vaapi=w=1920:h=1080 -c:v hevc_vaapi -b:v 6M -f null -

A UHD 770 descodifica AV1 mas não o consegue codificar: é por isso que a fonte AV1 é criada na CPU e a saída é HEVC.

Resultados

Todos os números abaixo foram medidos por servidor, com a GPU saturada por todos os servidores de teste ao mesmo tempo.

Carga	Ciclos bem-sucedidos por servidor (20 min)	Tempo por ciclo	Velocidade face ao tempo real
Codificação H.264 1080p30	26	~46 s para 60 s de vídeo	~1,3×
HEVC 4K 10 bits → H.264 1080p	49–55	~22–24 s para 30 s de vídeo	~1,3×
AV1 4K → HEVC 1080p	28	~43 s para 30 s de vídeo	~0,7×
Ciclo Vulkan/OpenCL	238	n/a	n/a

O número de ciclos e as velocidades batem certo: 26 ciclos × 60 s dão 1 560 s de vídeo codificados em 1 200 s, e 28 ciclos AV1 × 30 s dão 840 s de vídeo em 1 200 s. Dois servidores com a mesma transcodificação 4K fizeram 49 e 55 ciclos: o débito não é perfeitamente igual entre servidores com a mesma tarefa.

Como verificámos os “0 hangs”, em cada servidor, depois do teste:

journalctl -k -b | grep -iE "gpu hang|context reset|reset.*engine|guc.*fail"

A saída ficou vazia em todos. No anfitrião, o log do kernel não tinha nenhum GPU HANG, nenhum reset de GT e nenhuma GPU “wedged”. As únicas linhas “reset” eram os resets PCI normais no arranque de cada servidor de teste.

O que isto significa se alugar um servidor numa UHD 770 partilhada

O isolamento aguentou. Transcodificações contínuas em vários servidores e um ciclo Vulkan/OpenCL não fizeram cair o contexto GPU de ninguém, e nada chegou ao anfitrião.
Mesmo com a GPU saturada, cada servidor continua a transcodificar mais depressa do que o tempo real em H.264 1080p e em HEVC 4K → 1080p. Chega para um fluxo em direto por servidor, mesmo com todos os vizinhos ocupados.
As fontes AV1 4K são o caso pesado: a ~0,7×, não acompanham o tempo real quando a GPU está saturada. Se servir ficheiros AV1 4K a clientes que precisam de transcodificação, conte com buffering quando os vizinhos carregam muito.
A GPU inteira é finita. Neste teste e num teste anterior de 20 minutos noutro anfitrião UHD 770, uma GPU saturada forneceu da ordem de 2 a 3 transcodificações 4K em tempo real no total por GPU, somando todos os servidores. Com a GPU livre, um único servidor vai muito mais depressa: o nosso artigo sobre Jellyfin e Plex mediu 12× o tempo real em 4K HDR → 1080p com o codificador low-power.

Na prática: para um servidor multimédia pessoal ou familiar, algumas transcodificações 1080p em simultâneo são realistas; para um serviço que tem de garantir muitas transcodificações 4K em simultâneo, uma iGPU partilhada não é a ferramenta certa.

A lição por trás dos “0 hangs”: a definição CCS do i915 tem de coincidir

Rondas de teste anteriores mostraram GPU hangs no motor de renderização dentro dos convidados. A causa não era a versão do kernel nem a carga: era a definição CCS (compute command streamer) do i915, diferente entre o anfitrião e os convidados. As versões recentes do módulo i915 out-of-tree desativam o CCS por omissão nesta geração de GPU, enquanto os controladores mais antigos dos convidados assumem que está ativo. Esta divergência fazia bloquear ou o 3D/Vulkan ou a codificação VAAPI, consoante a combinação. Com o CCS ativo tanto no anfitrião como em todos os convidados, os hangs desapareceram, e este teste de 20 minutos é a confirmação.

Se virtualizar uma iGPU Intel por conta própria, verifique dos dois lados:

cat /sys/module/i915/parameters/xelp_enable_ccs   # Y no anfitrião E nos convidados
ls /sys/class/drm/card*/engine/ | grep ccs        # ccs0 deve aparecer

Segunda lição: o sparse binding Vulkan do controlador ANV da Mesa provocava um GPU hang por cada execução de vulkaninfo num convidado, por isso os nossos servidores vêm com ANV_SPARSE=0. Os contentores (Docker, k3s) têm o seu próprio ambiente e precisam desta definição à parte.

Limites deste teste

Entrada sintética. As fontes são geradas com o padrão testsrc2 do ffmpeg, não com filmes reais. Conteúdo real, tone mapping HDR, áudio e legendas acrescentam trabalho.
20 minutos. Mostra a ausência de hangs sob carga contínua, não meses de funcionamento.
Prioridade GPU igual. Todos os servidores de teste usaram a nossa definição Perf 1. Os planos Perf 2 e Perf 3 recebem uma parte maior da GPU quando todos a carregam; este teste não mediu essa repartição.
Servidores de teste pequenos. Tinham 2 vCPU e 4 GB de RAM; a fonte AV1 foi codificada uma única vez na CPU, antes do ciclo.
Uma só geração de GPU. Os resultados aplicam-se à UHD 770 (iGPU Alder Lake / Raptor Lake) com os controladores indicados acima.

Experimente

Os nossos servidores correm exatamente nesta stack, alojados na Alemanha: uma GPU UHD 770 dentro da VM com VAAPI, Vulkan e OpenCL pré-instalados, SSH root, IPv6 dedicado. Planos a partir de 14,99 € s/ IVA/mês (Perf 1), 29,99 € (Perf 2) e 44,99 € (Perf 3), preço fixo.