Geteilte Intel UHD 770 unter Volllast: ein 20-minütiger GPU-Stresstest

Bei einem GPU-VPS wird die integrierte Intel UHD 770 von mehreren Servern gemeinsam genutzt. Die entscheidende Frage für Kunden lautet also nicht „Läuft es, wenn ich allein bin?“, sondern „Was passiert, wenn alle Server auf der GPU gleichzeitig Last erzeugen?“. Genau das haben wir am 01.11.2026 getestet: mehrere Server belasten 20 Minuten lang gleichzeitig dieselbe geteilte GPU, bis sie voll ausgelastet ist. Die Kurzfassung:

0 fehlgeschlagene Jobs und 0 GPU-Hänger auf allen Servern, kein GPU-Reset auf dem Host.
Bei voll ausgelasteter GPU lief jeder transkodierende Server immer noch mit etwa 1,3× Echtzeit für 1080p-H.264-Kodierung und für 4K HEVC → 1080p H.264, und mit etwa 0,7× Echtzeit für 4K AV1 → 1080p HEVC.

Testaufbau

Element	Wert
Host-CPU / GPU	Intel Core i5-13500, integrierte Intel UHD 770
Hypervisor	Proxmox VE 9.2, Kernel 7.0.14-pve
GPU-Virtualisierung	Intel-i915-Treiber für GPU-Virtualisierung (Out-of-Tree-Modul), GuC-Submission, CCS aktiviert
Testserver	Debian 13, je 2 vCPU und 4 GB RAM, geklont aus unserem Produktions-Template
Gast-Kernel / Treiber	Linux 7.3, dasselbe i915-Out-of-Tree-Modul, CCS aktiviert (`ccs0` sichtbar)
Vulkan-Einstellung in den Gästen	`ANV_SPARSE=0`
GPU-Priorität	auf allen Servern identisch (unsere Perf-1-Einstellung)
Dauer	20 Minuten, alle Server gleichzeitig gestartet

Jeder Server führte dasselbe Skript mit einem anderen Profil aus: loadtest_gpu.sh <profile> 1200. Das Skript wiederholt einen Job, bis 1.200 Sekunden vergangen sind, und protokolliert für jeden Durchlauf ok oder FAIL.

Die vier Lastprofile

Lastprofil	Was ein Durchlauf macht
H.264-1080p-Kodierung	60 s 1080p30-Video per VAAPI nach H.264 kodieren (klassischer Encoder, nicht `low_power`), 8 Mbit/s
4K HEVC → 1080p Transkodierung	Einen 30-s-Clip in 4K HEVC 10 Bit auf der GPU dekodieren, per `scale_vaapi` auf 1080p skalieren, mit 8 Mbit/s nach H.264 kodieren (eine typische Plex/Jellyfin-Transkodierung)
AV1 4K → HEVC 1080p	30 s 4K-AV1 auf der GPU dekodieren, auf 1080p skalieren, mit 6 Mbit/s nach HEVC kodieren
Vulkan/OpenCL-Schleife	`vulkaninfo` + `clinfo` + `gpu-check` (VAAPI, Vulkan, OpenCL, OpenVINO) in einer Schleife

Die zentralen Befehle, falls Sie den Test auf Ihrem eigenen Server nachstellen möchten:

R=/dev/dri/renderD128

# H.264: synthetische 1080p30-Quelle -> 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-Stil: einmal eine 4K-HEVC-Main10-Quelle erzeugen, dann nach 1080p H.264 transkodieren
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: 10-s-Quelle in 4K AV1 (CPU-Kodierung, SVT-AV1), pro Durchlauf 3-mal abgespielt
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 -

Die UHD 770 kann AV1 dekodieren, aber nicht kodieren. Deshalb wird die AV1-Quelle auf der CPU erzeugt und die Ausgabe ist HEVC.

Ergebnisse

Alle folgenden Werte wurden pro Server gemessen, während die GPU durch alle Testserver gleichzeitig voll ausgelastet war.

Lastprofil	Erfolgreiche Durchläufe pro Server (20 min)	Zeit pro Durchlauf	Geschwindigkeit ggü. Echtzeit
H.264-1080p30-Kodierung	26	~46 s für 60 s Video	~1,3×
4K HEVC 10 Bit → 1080p H.264	49–55	~22–24 s für 30 s Video	~1,3×
AV1 4K → HEVC 1080p	28	~43 s für 30 s Video	~0,7×
Vulkan/OpenCL-Schleife	238	–	–

Durchläufe und Geschwindigkeiten passen zusammen: 26 Durchläufe × 60 s ergeben 1.560 s kodiertes Video in 1.200 s, und 28 AV1-Durchläufe × 30 s ergeben 840 s Video in 1.200 s. Zwei Server mit derselben 4K-Transkodierung schafften 49 bzw. 55 Durchläufe – der Durchsatz ist zwischen Servern mit identischem Job also nicht ganz gleich verteilt.

So wurde „0 Hänger“ nach dem Lauf auf jedem Server geprüft:

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

Die Ausgabe war überall leer. Auf dem Host enthielt das Kernel-Log kein GPU HANG, keinen GT-Reset und keine „wedged“ GPU. Die einzigen „reset“-Zeilen waren die normalen PCI-Geräte-Resets beim Start der einzelnen Testserver.

Was das bedeutet, wenn Sie einen Server auf einer geteilten UHD 770 mieten

Die Isolation hat gehalten. Dauerhafte Transkodierungen auf mehreren Servern plus eine Vulkan/OpenCL-Schleife haben keinen GPU-Kontext zum Absturz gebracht, und nichts davon hat den Host erreicht.
Selbst bei voll ausgelasteter GPU transkodiert ein Server noch schneller als Echtzeit, sowohl 1080p H.264 als auch 4K HEVC → 1080p. Das reicht für einen Live-Stream pro Server, auch wenn alle Nachbarn beschäftigt sind.
AV1-Quellen in 4K sind der schwere Fall: Mit ~0,7× halten sie bei voll ausgelasteter GPU nicht mit der Echtzeit Schritt. Wenn Sie AV1-4K-Dateien an Clients ausliefern, die eine Transkodierung brauchen, müssen Sie bei hoher Last der Nachbarn mit Pufferung rechnen.
Die GPU als Ganzes ist begrenzt. In diesem Test und in einem früheren 20-minütigen Lauf auf einem anderen UHD-770-Host lieferte eine voll ausgelastete GPU insgesamt in der Größenordnung von 2 bis 3 4K-Transkodierungen in Echtzeit pro GPU, über alle Server hinweg. Ist die GPU frei, ist ein einzelner Server deutlich schneller: In unserem Jellyfin-&-Plex-Artikel haben wir mit dem Low-Power-Encoder 12× Echtzeit für 4K HDR → 1080p gemessen.

In der Praxis heißt das: Für einen privaten oder Familien-Medienserver sind einige gleichzeitige 1080p-Transkodierungen realistisch; für einen Dienst, der viele gleichzeitige 4K-Transkodierungen garantieren muss, ist eine einzelne geteilte iGPU das falsche Werkzeug.

Die Lehre hinter „0 Hänger“: die i915-CCS-Einstellung muss übereinstimmen

In früheren Testrunden gab es durchaus GPU-Hänger auf der Render-Engine in den Gästen. Die Ursache war weder die Kernel-Version noch die Last, sondern eine unterschiedliche i915-CCS-Einstellung (Compute Command Streamer) zwischen Host und Gästen. Neuere Versionen des i915-Out-of-Tree-Moduls deaktivieren CCS auf dieser GPU-Generation standardmäßig, während ältere Gast-Treiber davon ausgehen, dass es aktiv ist. Je nach Kombination ließ diese Abweichung entweder 3D/Vulkan oder die VAAPI-Kodierung hängen. Mit CCS sowohl auf dem Host als auch in allen Gästen aktiviert verschwanden die Hänger – dieser 20-minütige Lauf ist die Bestätigung.

Wenn Sie selbst eine Intel-iGPU virtualisieren, prüfen Sie es auf beiden Seiten:

cat /sys/module/i915/parameters/xelp_enable_ccs   # Y auf Host UND Gästen
ls /sys/class/drm/card*/engine/ | grep ccs        # ccs0 sollte aufgelistet sein

Zweite Lehre: Vulkan Sparse Binding im ANV-Treiber von Mesa löste in einem Gast bei jedem vulkaninfo-Aufruf einen GPU-Hänger aus. Deshalb werden unsere Server mit ANV_SPARSE=0 ausgeliefert. Container (Docker, k3s) haben ihre eigene Umgebung, dort muss die Variable separat gesetzt werden.

Grenzen dieses Tests

Synthetische Eingaben. Die Quellen werden mit dem ffmpeg-Testmuster testsrc2 erzeugt, nicht aus echten Filmen. Echte Inhalte, HDR-Tone-Mapping, Audio und Untertitel bedeuten zusätzliche Arbeit.
20 Minuten. Der Test zeigt, dass unter Dauerlast keine Hänger auftreten, nicht aber Monate an Uptime.
Gleiche GPU-Priorität. Alle Testserver nutzten unsere Perf-1-Einstellung. Die Angebote Perf 2 und Perf 3 erhalten einen größeren Anteil der GPU, wenn alle sie belasten; diese Aufteilung hat der Test nicht gemessen.
Kleine Testserver. Sie hatten 2 vCPU und 4 GB RAM; die AV1-Quelle wurde einmalig vor der Schleife auf der CPU kodiert.
Eine GPU-Generation. Die Ergebnisse gelten für die UHD 770 (iGPU von Alder Lake / Raptor Lake) mit den oben genannten Treibern.

Weiterlesen

Ausprobieren

Unsere Server laufen auf genau diesem Stack, gehostet in Deutschland: eine UHD-770-GPU in der VM mit vorinstalliertem VAAPI, Vulkan und OpenCL, Root-SSH, dedizierte IPv6. Angebote ab 14,99 € netto/Monat (Perf 1), 29,99 € (Perf 2) und 44,99 € (Perf 3), zum Festpreis.