Gedeelde Intel UHD 770 onder volle belasting: een GPU-stresstest van 20 minuten

Op een GPU VPS wordt de geïntegreerde Intel UHD 770 gedeeld door meerdere servers. De vraag die een koper moet stellen is niet “werkt het als ik alleen ben?”, maar “wat gebeurt er als alle servers op de GPU hem tegelijk belasten?”. Op 1 november 2026 hebben we precies dat getest: meerdere servers die 20 minuten lang tegelijk dezelfde gedeelde GPU belastten, tot die verzadigd was. Het korte antwoord:

0 mislukte jobs en 0 GPU-hangs op alle servers, geen GPU-reset op de host.
Met een verzadigde GPU haalde elke transcodeerserver nog ongeveer 1,3× realtime voor 1080p H.264-encoding en voor 4K HEVC → 1080p H.264, en ongeveer 0,7× realtime voor 4K AV1 → 1080p HEVC.

Testopstelling

Onderdeel	Waarde
CPU / GPU van de host	Intel Core i5-13500, geïntegreerde Intel UHD 770
Hypervisor	Proxmox VE 9.2, kernel 7.0.14-pve
GPU-virtualisatie	Intel i915-driver voor GPU-virtualisatie (out-of-tree module), GuC-submission, CCS ingeschakeld
Testservers	Debian 13, elk 2 vCPU en 4 GB RAM, gekloond van ons productietemplate
Kernel / driver in de gast	Linux 7.3, dezelfde out-of-tree i915-module, CCS ingeschakeld (`ccs0` zichtbaar)
Vulkan-instelling in de gasten	`ANV_SPARSE=0`
GPU-prioriteit	identiek op alle servers (onze Perf 1-instelling)
Duur	20 minuten, alle servers tegelijk gestart

Elke server draaide hetzelfde script met een ander profiel: loadtest_gpu.sh <profile> 1200. Het script herhaalt een job tot er 1.200 seconden verstreken zijn en logt voor elke cyclus ok of FAIL.

De vier workloads

Workload	Wat één cyclus doet
H.264 1080p-encoding	60 s 1080p30-video naar H.264 encoderen met VAAPI (klassieke encoder, niet `low_power`), 8 Mbit/s
4K HEVC → 1080p-transcode	Een 4K HEVC 10-bit-clip van 30 s op de GPU decoderen, met `scale_vaapi` naar 1080p schalen, naar H.264 encoderen op 8 Mbit/s (een typische Plex/Jellyfin-transcode)
AV1 4K → HEVC 1080p	30 s 4K AV1 op de GPU decoderen, naar 1080p schalen, naar HEVC encoderen op 6 Mbit/s
Vulkan/OpenCL-lus	`vulkaninfo` + `clinfo` + `gpu-check` (VAAPI, Vulkan, OpenCL, OpenVINO) in een lus

De kerncommando’s, als je ze op je eigen server wilt reproduceren:

R=/dev/dri/renderD128

# H.264: synthetische 1080p30-bron -> 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 -

# Plex-stijl: maak eenmalig een 4K HEVC Main10-bron, transcodeer die dan naar 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: 4K AV1-bron van 10 s (CPU-encoding, SVT-AV1), 3 keer herhaald per cyclus
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 -

De UHD 770 decodeert AV1, maar kan het niet encoderen. Daarom wordt de AV1-bron op de CPU gemaakt en is de uitvoer HEVC.

Resultaten

Alle cijfers hieronder zijn per server gemeten terwijl de GPU verzadigd was door alle testservers tegelijk.

Workload	Geslaagde cycli per server (20 min)	Tijd per cyclus	Snelheid t.o.v. realtime
H.264 1080p30-encoding	26	~46 s voor 60 s video	~1,3×
4K HEVC 10-bit → 1080p H.264	49–55	~22–24 s voor 30 s video	~1,3×
AV1 4K → HEVC 1080p	28	~43 s voor 30 s video	~0,7×
Vulkan/OpenCL-lus	238	n.v.t.	n.v.t.

Het aantal cycli en de snelheden kloppen met elkaar: 26 cycli × 60 s is 1.560 s video, geëncodeerd in 1.200 s, en 28 AV1-cycli × 30 s is 840 s video in 1.200 s. Twee servers die dezelfde 4K-transcode draaiden, haalden 49 en 55 cycli: de doorvoer is dus niet helemaal gelijk tussen servers die hetzelfde werk doen.

Zo hebben we “0 hangs” na de run op elke server gecontroleerd:

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

De uitvoer was overal leeg. Op de host bevatte het kernellog geen GPU HANG, geen GT-reset en geen “wedged” GPU. De enige “reset”-regels waren de normale resets van PCI-apparaten bij het starten van elke testserver.

Wat dit betekent als je een server op een gedeelde UHD 770 huurt

De isolatie hield stand. Doorlopende transcodes op meerdere servers plus een Vulkan/OpenCL-lus lieten bij niemand de GPU-context crashen, en er bereikte niets de host.
Ook met een verzadigde GPU transcodeert één server nog sneller dan realtime voor 1080p H.264 en voor 4K HEVC → 1080p. Dat is genoeg voor één livestream per server, zelfs als alle buren druk bezig zijn.
4K AV1-bronnen zijn het zware geval: met ~0,7× houden ze realtime niet bij als de GPU verzadigd is. Bied je 4K AV1-bestanden aan aan clients die een transcode nodig hebben, reken dan op buffering als de buren zwaar belasten.
De GPU als geheel is eindig. In deze test en in een eerdere run van 20 minuten op een andere UHD 770-host leverde een verzadigde GPU in totaal zo’n 2 à 3 realtime 4K-transcodes per GPU, verdeeld over alle servers. Als de GPU niets te doen heeft, gaat één server veel sneller: in ons artikel over Jellyfin & Plex maten we 12× realtime voor 4K HDR → 1080p met de low-power-encoder.

In de praktijk: voor een persoonlijke mediaserver of een mediaserver voor het gezin zijn een paar gelijktijdige 1080p-transcodes realistisch; voor een dienst die veel gelijktijdige 4K-transcodes moet garanderen, is één gedeelde iGPU niet het juiste gereedschap.

De les achter “0 hangs”: de i915 CCS-instelling moet overeenkomen

In eerdere testrondes zagen we wel GPU-hangs op de render-engine in de gasten. De oorzaak was niet de kernelversie en ook niet de belasting, maar een i915 CCS-instelling (compute command streamer) die verschilde tussen host en gasten. Recente versies van de out-of-tree i915-module schakelen CCS op deze GPU-generatie standaard uit, terwijl oudere gastdrivers ervan uitgaan dat het aan staat. Door die mismatch liep, afhankelijk van de combinatie, ofwel 3D/Vulkan ofwel VAAPI-encoding vast. Met CCS ingeschakeld op zowel de host als alle gasten verdwenen de hangs, en deze run van 20 minuten is de bevestiging.

Virtualiseer je zelf een Intel iGPU, controleer het dan aan beide kanten:

cat /sys/module/i915/parameters/xelp_enable_ccs   # Y op de host EN in de gasten
ls /sys/class/drm/card*/engine/ | grep ccs        # ccs0 moet in de lijst staan

Tweede les: Vulkan sparse binding in de ANV-driver van Mesa veroorzaakte in een gast één GPU-hang per vulkaninfo-run, daarom worden onze servers geleverd met ANV_SPARSE=0. Containers (Docker, k3s) hebben hun eigen omgeving en moeten dat apart ingesteld krijgen.

Beperkingen van deze test

Synthetische invoer. De bronnen zijn gegenereerd met het testsrc2-patroon van ffmpeg, geen echte films. Echte content, HDR-tonemapping, audio en ondertitels voegen werk toe.
20 minuten. Dat toont de afwezigheid van hangs onder aanhoudende belasting, niet maanden uptime.
Gelijke GPU-prioriteit. Alle testservers gebruikten onze Perf 1-instelling. Perf 2- en Perf 3-plannen krijgen een groter deel van de GPU als iedereen hem belast; die verdeling heeft deze test niet gemeten.
Kleine testservers. Ze hadden 2 vCPU en 4 GB RAM; de AV1-bron werd één keer op de CPU geëncodeerd, vóór de lus.
Eén GPU-generatie. De resultaten gelden voor de UHD 770 (iGPU van Alder Lake / Raptor Lake) met de hierboven genoemde drivers.

Gerelateerd

Probeer het

Onze servers draaien op precies deze stack, gehost in Duitsland: een UHD 770-GPU in de VM met VAAPI, Vulkan en OpenCL vooraf geïnstalleerd, root-toegang via SSH en een eigen IPv6-adres. Plannen vanaf €14,99 excl. btw/mnd (Perf 1), €29,99 (Perf 2) en €44,99 (Perf 3), vaste prijs.