Intel UHD 770 compartida a plena carga: prueba de estrés GPU de 20 minutos

En un VPS GPU, la Intel UHD 770 integrada se comparte entre varios servidores. La pregunta que debería hacerse quien contrata no es «¿funciona cuando estoy solo?», sino «¿qué pasa cuando todos los servidores de la GPU la usan a la vez?». El 1 de noviembre de 2026 hicimos justo eso: varios servidores cargando la misma GPU compartida al mismo tiempo, durante 20 minutos, hasta saturarla. Respuesta corta:

0 trabajos fallidos y 0 GPU hangs en todos los servidores, ningún reset de la GPU en el host.
Con la GPU saturada, cada servidor de transcodificación seguía yendo a unas 1,3× tiempo real en codificación H.264 1080p y en HEVC 4K → H.264 1080p, y a unas 0,7× tiempo real en AV1 4K → HEVC 1080p.

Configuración de la prueba

Elemento	Valor
CPU / GPU del host	Intel Core i5-13500, Intel UHD 770 integrada
Hipervisor	Proxmox VE 9.2, kernel 7.0.14-pve
Virtualización de la GPU	Driver de virtualización de GPU Intel i915 (módulo out-of-tree), envío GuC, CCS activado
Servidores de prueba	Debian 13, 2 vCPU y 4 GB de RAM cada uno, clonados de nuestra plantilla de producción
Kernel / driver de los invitados	Linux 7.3, mismo módulo i915 out-of-tree, CCS activado (`ccs0` visible)
Ajuste Vulkan en los invitados	`ANV_SPARSE=0`
Prioridad GPU	idéntica en todos los servidores (nuestro ajuste Perf 1)
Duración	20 minutos, todos los servidores arrancados a la vez

Cada servidor ejecutaba el mismo script con un perfil distinto: loadtest_gpu.sh <profile> 1200. El script repite un trabajo hasta que pasan 1200 segundos y registra ok o FAIL en cada ciclo.

Las cuatro cargas de trabajo

Carga	Qué hace un ciclo
Codificación H.264 1080p	Codifica 60 s de vídeo 1080p30 a H.264 con VAAPI (codificador clásico, no `low_power`), 8 Mbit/s
Transcodificación HEVC 4K → 1080p	Decodifica en la GPU un clip HEVC 4K de 10 bits de 30 s, `scale_vaapi` a 1080p, codifica a H.264 a 8 Mbit/s (una transcodificación típica de Plex/Jellyfin)
AV1 4K → HEVC 1080p	Decodifica en la GPU 30 s de AV1 4K, escala a 1080p, codifica a HEVC a 6 Mbit/s
Bucle Vulkan/OpenCL	`vulkaninfo` + `clinfo` + `gpu-check` (VAAPI, Vulkan, OpenCL, OpenVINO) en bucle

Los comandos principales, por si quieres reproducirlos en tu propio servidor:

R=/dev/dri/renderD128

# H.264: fuente 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: crear una vez una fuente HEVC Main10 4K y transcodificarla a 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: fuente AV1 4K de 10 s (codificada en CPU, SVT-AV1), repetida 3 veces 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 -

La UHD 770 decodifica AV1 pero no puede codificarlo: por eso la fuente AV1 se crea en la CPU y la salida es HEVC.

Resultados

Todas las cifras siguientes se midieron por servidor mientras la GPU estaba saturada por todos los servidores de prueba a la vez.

Carga	Ciclos correctos por servidor (20 min)	Tiempo por ciclo	Velocidad frente a tiempo real
Codificación 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×
Bucle Vulkan/OpenCL	238	n/a	n/a

Los ciclos y las velocidades cuadran: 26 ciclos × 60 s son 1560 s de vídeo codificados en 1200 s, y 28 ciclos AV1 × 30 s son 840 s de vídeo en 1200 s. Dos servidores con la misma transcodificación 4K hicieron 49 y 55 ciclos: el rendimiento no es exactamente igual entre servidores que hacen el mismo trabajo.

Cómo se comprobó el «0 hangs», en cada servidor después de la prueba:

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

La salida estaba vacía en todos. En el host, el log del kernel no mostraba ningún GPU HANG, ningún reset del GT ni ninguna GPU «wedged». Las únicas líneas con «reset» eran los resets PCI normales al arrancar cada servidor de prueba.

Qué significa si alquilas un servidor en una UHD 770 compartida

El aislamiento aguantó. Transcodificaciones continuas en varios servidores más un bucle Vulkan/OpenCL no tumbaron el contexto GPU de nadie, y nada llegó al host.
Incluso con la GPU saturada, un servidor sigue transcodificando más rápido que el tiempo real en H.264 1080p y en HEVC 4K → 1080p. Basta para un flujo en directo por servidor aunque todos los vecinos estén ocupados.
Las fuentes AV1 4K son el caso pesado: a ~0,7× no siguen el tiempo real cuando la GPU está saturada. Si sirves archivos AV1 4K a clientes que necesitan transcodificación, cuenta con cortes de buffering cuando los vecinos cargan mucho.
La GPU entera es finita. En esta prueba y en otra anterior de 20 minutos en otro host UHD 770, una GPU saturada dio del orden de 2 a 3 transcodificaciones 4K en tiempo real en total por GPU, sumando todos los servidores. Con la GPU libre, un solo servidor va mucho más rápido: nuestro artículo sobre Jellyfin y Plex midió 12× tiempo real en 4K HDR → 1080p con el codificador low-power.

En la práctica: para un servidor multimedia personal o familiar, unas pocas transcodificaciones 1080p simultáneas son realistas; para un servicio que deba garantizar muchas transcodificaciones 4K a la vez, una iGPU compartida no es la herramienta adecuada.

La lección detrás del «0 hangs»: el ajuste CCS de i915 debe coincidir

En rondas de prueba anteriores sí aparecieron GPU hangs en el motor de render dentro de los invitados. La causa no era la versión del kernel ni la carga: era que el ajuste CCS (compute command streamer) de i915 era distinto entre el host y los invitados. Las versiones recientes del módulo i915 out-of-tree desactivan CCS por defecto en esta generación de GPU, mientras que los drivers de invitado más antiguos dan por hecho que está activado. Según la combinación, el desajuste hacía colgarse o el 3D/Vulkan o la codificación VAAPI. Con CCS activado a la vez en el host y en todos los invitados, los hangs desaparecieron, y esta prueba de 20 minutos lo confirma.

Si virtualizas tú mismo una iGPU Intel, compruébalo en ambos lados:

cat /sys/module/i915/parameters/xelp_enable_ccs   # Y en el host Y en los invitados
ls /sys/class/drm/card*/engine/ | grep ccs        # debe aparecer ccs0

Segunda lección: el sparse binding de Vulkan en el driver ANV de Mesa provocaba un GPU hang en cada ejecución de vulkaninfo dentro de un invitado, así que nuestros servidores vienen con ANV_SPARSE=0. Los contenedores (Docker, k3s) tienen su propio entorno y hay que definirlo aparte.

Límites de esta prueba

Entrada sintética. Las fuentes se generan con el patrón testsrc2 de ffmpeg, no son películas reales. El contenido real, el tone mapping HDR, el audio y los subtítulos añaden trabajo.
20 minutos. Demuestra la ausencia de hangs con carga sostenida, no meses de funcionamiento continuo.
Misma prioridad GPU. Todos los servidores de prueba usaban nuestro ajuste Perf 1. Las ofertas Perf 2 y Perf 3 reciben una parte mayor de la GPU cuando todos la cargan; esta prueba no midió ese reparto.
Servidores de prueba pequeños. Tenían 2 vCPU y 4 GB de RAM; la fuente AV1 se codificó una sola vez en la CPU, antes del bucle.
Una sola generación de GPU. Los resultados se aplican a la UHD 770 (iGPU Alder Lake / Raptor Lake) con los drivers indicados arriba.

Probar

Nuestros servidores funcionan exactamente con esta pila, alojados en Alemania: una GPU UHD 770 dentro de la VM con VAAPI, Vulkan y OpenCL preinstalados, SSH root e IPv6 dedicada. Ofertas desde 14,99 €/mes sin IVA (Perf 1), 29,99 € (Perf 2) y 44,99 € (Perf 3), precio fijo.