Intel UHD 770 partagé à pleine charge : test GPU de 20 minutes

Sur un VPS GPU, l’Intel UHD 770 intégré est partagé entre plusieurs serveurs. La vraie question pour un acheteur n’est pas « est-ce que ça marche quand je suis seul ? », mais « que se passe-t-il quand tous les serveurs du GPU le sollicitent en même temps ? ». Le 1er novembre 2026, nous avons fait exactement ce test : plusieurs serveurs chargeant le même GPU partagé en même temps, pendant 20 minutes, jusqu’à le saturer. En bref :

0 tâche en échec et 0 plantage GPU sur tous les serveurs, aucun reset du GPU côté hôte.
GPU saturé, chaque serveur de transcodage tournait encore à environ 1,3× le temps réel en encodage H.264 1080p comme en HEVC 4K → H.264 1080p, et à environ 0,7× le temps réel en AV1 4K → HEVC 1080p.

Le banc de test

Élément	Valeur
CPU / GPU de l’hôte	Intel Core i5-13500, Intel UHD 770 intégré
Hyperviseur	Proxmox VE 9.2, noyau 7.0.14-pve
Virtualisation du GPU	pilote de virtualisation GPU Intel i915 (module hors arbre), soumission GuC, CCS activé
Serveurs de test	Debian 13, 2 vCPU et 4 Go de RAM chacun, clonés depuis notre modèle de production
Noyau / pilote des serveurs	Linux 7.3, même module i915 hors arbre, CCS activé (`ccs0` visible)
Réglage Vulkan dans les serveurs	`ANV_SPARSE=0`
Priorité GPU	identique sur tous les serveurs (notre réglage Perf 1)
Durée	20 minutes, tous les serveurs lancés ensemble

Chaque serveur exécutait le même script avec un profil différent : loadtest_gpu.sh <profil> 1200. Le script répète une tâche jusqu’à ce que 1 200 secondes soient écoulées et note ok ou FAIL à chaque cycle.

Les quatre charges

Charge	Ce que fait un cycle
Encodage H.264 1080p	Encode 60 s de vidéo 1080p30 en H.264 via VAAPI (encodeur classique, pas `low_power`), 8 Mbit/s
Transcodage HEVC 4K → 1080p	Décode sur le GPU un extrait HEVC 10 bits 4K de 30 s, `scale_vaapi` en 1080p, encode en H.264 à 8 Mbit/s (un transcodage typique de Plex ou Jellyfin)
AV1 4K → HEVC 1080p	Décode sur le GPU 30 s d’AV1 4K, redimensionne en 1080p, encode en HEVC à 6 Mbit/s
Boucle Vulkan/OpenCL	`vulkaninfo` + `clinfo` + `gpu-check` (VAAPI, Vulkan, OpenCL, OpenVINO) en boucle

Les commandes principales, pour reproduire le test sur votre serveur :

R=/dev/dri/renderD128

# H.264 : source synthétique 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 -

# Type Plex : créer une fois une source HEVC Main10 4K, puis la transcoder en 1080p H.264
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 : source AV1 4K de 10 s (encodée sur le CPU avec SVT-AV1), lue 3 fois par cycle
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 -

L’UHD 770 sait décoder l’AV1 mais pas l’encoder : la source AV1 est donc créée sur le CPU, et la sortie est en HEVC.

Résultats

Tous les chiffres ci-dessous ont été mesurés par serveur, pendant que le GPU était saturé par l’ensemble des serveurs de test.

Charge	Cycles réussis par serveur (20 min)	Durée d’un cycle	Vitesse / temps réel
Encodage H.264 1080p30	26	~46 s pour 60 s de vidéo	~1,3×
HEVC 10 bits 4K → H.264 1080p	49 à 55	~22 à 24 s pour 30 s de vidéo	~1,3×
AV1 4K → HEVC 1080p	28	~43 s pour 30 s de vidéo	~0,7×
Boucle Vulkan/OpenCL	238	sans objet	sans objet

Cycles et vitesses concordent : 26 cycles × 60 s, soit 1 560 s de vidéo encodées en 1 200 s ; 28 cycles AV1 × 30 s, soit 840 s de vidéo en 1 200 s. Deux serveurs faisant le même transcodage 4K ont réalisé 49 et 55 cycles : le débit n’est pas parfaitement identique entre serveurs qui font le même travail.

Comment le « 0 plantage » a été vérifié, sur chaque serveur après le test :

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

Résultat vide partout. Côté hôte, le journal du noyau ne contenait ni GPU HANG, ni reset du GT, ni GPU « wedged ». Les seules lignes « reset » étaient les réinitialisations PCI normales au démarrage de chaque serveur de test.

Ce que ça change si vous louez un serveur sur un UHD 770 partagé

L’isolation tient. Des transcodages continus sur plusieurs serveurs et une boucle Vulkan/OpenCL n’ont fait planter le contexte GPU de personne, et rien n’a remonté jusqu’à l’hôte.
Même GPU saturé, un serveur transcode plus vite que le temps réel en H.264 1080p et en HEVC 4K → 1080p. De quoi tenir un flux en direct par serveur, même quand tous les voisins travaillent.
L’AV1 4K est le cas lourd : à ~0,7×, il ne suit pas le temps réel quand le GPU est saturé. Si vous servez des fichiers AV1 4K à des lecteurs qui ont besoin d’un transcodage, attendez-vous à de la mise en mémoire tampon quand les voisins chargent fort.
Le GPU entier a une capacité finie. Dans ce test comme lors d’un premier essai de 20 minutes sur un autre hôte UHD 770, un GPU saturé fournit de l’ordre de 2 à 3 transcodages 4K en temps réel au total par GPU, tous serveurs confondus. GPU libre, un seul serveur va bien plus vite : notre article Jellyfin et Plex mesure 12× le temps réel en 4K HDR → 1080p avec l’encodeur basse consommation.

Concrètement : pour un serveur multimédia personnel ou familial, quelques transcodages 1080p simultanés sont réalistes. Pour un service qui doit garantir de nombreux transcodages 4K en parallèle, un iGPU partagé n’est pas le bon outil.

La leçon derrière le « 0 plantage » : le réglage CCS d’i915 doit être identique

Nos premières séries de tests montraient bien des plantages GPU sur le moteur de rendu dans les serveurs invités. La cause n’était ni la version du noyau ni la charge : c’était le réglage CCS (compute command streamer) d’i915 différent entre l’hôte et les invités. Les versions récentes du module i915 hors arbre désactivent le CCS par défaut sur cette génération de GPU, alors que les pilotes invités plus anciens le supposent actif. Selon la combinaison, ce décalage faisait planter soit la 3D/Vulkan, soit l’encodage VAAPI. Avec le CCS activé à la fois sur l’hôte et dans chaque invité, les plantages ont disparu ; ce test de 20 minutes en est la confirmation.

Si vous virtualisez vous-même un iGPU Intel, vérifiez des deux côtés :

cat /sys/module/i915/parameters/xelp_enable_ccs   # Y sur l'hôte ET dans les invités
ls /sys/class/drm/card*/engine/ | grep ccs        # ccs0 doit apparaître

Deuxième leçon : le sparse binding Vulkan du pilote Mesa ANV provoquait un plantage GPU à chaque vulkaninfo dans un invité. Nos serveurs sont donc livrés avec ANV_SPARSE=0. Les conteneurs (Docker, k3s) ont leur propre environnement : il faut y définir la variable séparément.

Les limites de ce test

Vidéo synthétique. Les sources sont générées par la mire testsrc2 de ffmpeg, pas par de vrais films. Un contenu réel, le tone mapping HDR, l’audio et les sous-titres ajoutent du travail.
20 minutes. Le test montre l’absence de plantage sous charge soutenue, pas des mois de disponibilité.
Priorité GPU identique. Tous les serveurs de test avaient notre réglage Perf 1. Les offres Perf 2 et Perf 3 obtiennent une plus grande part du GPU quand tout le monde le charge ; ce test n’a pas mesuré cette répartition.
Petits serveurs de test. Ils avaient 2 vCPU et 4 Go de RAM ; la source AV1 a été encodée une seule fois sur le CPU, avant la boucle.
Une seule génération de GPU. Les résultats valent pour l’UHD 770 (iGPU Alder Lake / Raptor Lake) avec les pilotes indiqués plus haut.

Essayer

Nos serveurs tournent sur exactement cette pile, hébergée en Allemagne : un GPU UHD 770 dans la VM avec VAAPI, Vulkan et OpenCL préinstallés, accès SSH root, IPv6 dédiée. Offres à partir de 14,99 € HT/mois (Perf 1), 29,99 € (Perf 2) et 44,99 € (Perf 3), prix fixe.