AMD ROCm: GPU-residente YOLO26-Pipeline hält Video-Frames von der Dekodierung bis zur Erkennung im VRAM

AMD beschrieb in seinem ROCm-Blog eine vierstufige GPU-residente Pipeline zur Objekterkennung, die rocDecode, DLPack, PyTorch und MIGraphX kombiniert — und damit demonstriert, wie Video-Frames den gesamten Weg vom komprimierten Bitstream bis zu Bounding Boxes durchlaufen können, ohne eine einzige überflüssige Datenkopie zu erzeugen.

Warum ist „GPU-Residentheit” für Echtzeit-Objekterkennung wichtig?

Der klassische Ansatz zur Video-Objekterkennung basiert auf CPU-Dekodierung, Übertragung der Frames in den RAM und anschließenden Transfer in den GPU-Speicher. Jeder dieser Übergänge kostet: Der PCIe-Bus wird zum Engpass, die Latenz steigt, und die CPU ist mit einfachem Datenkopieren beschäftigt statt mit sinnvoller Arbeit.

AMDs Ansatz eliminiert diese Übergänge. Der komprimierte H.264- oder H.265-Bitstream überquert den PCIe-Bus nur einmal — der Rest findet ausschließlich innerhalb der GPU statt. Frames werden direkt in den VRAM über die rocDecode-Bibliothek dekodiert, verbleiben dort durch Vorverarbeitung und Inferenz, und in den Host-Speicher gelangen nur die endgültigen Erkennungen: Bounding Boxes mit Confidence Scores und Class IDs.

Vier Pipeline-Phasen

Erste Phase ist die Hardware-Videodekodierung. Video Core Next (VCN) — ein dedizierter Block im AMD-GPU — dekodiert H.264 und H.265 nativ, ohne die GFX-Compute-Kerne zu beanspruchen. Messungen auf AMD Radeon AI PRO R9700 mit ROCm 7.2.2 und 1920×1080 H.264-Eingabe zeigen eine VCN-Auslastung von nur ~10%, während die Compute-Kerne parallel mit ~21% Auslastung arbeiten. Beide Engines arbeiten gleichzeitig und unabhängig voneinander.

Zweite Phase ist der Zero-Copy-Transfer zwischen Frames. Die DLPack-Bibliothek definiert ein standardisiertes Tensor-Speicherlayout, das alle gängigen Frameworks verstehen. Die dekodierte Frame-Oberfläche wird nicht in einen neuen Buffer kopiert — ein DLPack-Wrapper referenziert die bestehende VRAM-Position und übergibt sie an PyTorch ohne Allokation. Ausgabe-Tensoren werden einmal alloziert und für jeden Frame wiederverwendet.

Dritte Phase ist die Inferenz. MIGraphX — AMDs Graph-Inferenz-Engine — kompiliert das YOLO26-Modell mit FP16-Quantisierung und führt es nativ auf der AMD-GPU aus, ohne zwischengelagerte Software-Schichten.

Vierte Phase ist die Filterung der Erkennungen. Das YOLO26-Modell von Ultralytics hat NMS (Non-Maximum Suppression) End-to-End eingebettet: Die Ausgabe ist ein Tensor der Dimensionen [1, 300, 6] pro Frame — jede Zeile enthält Bounding-Box-Koordinaten (x1, y1, x2, y2), Confidence Score und Class ID. Ältere Modelle wie YOLO11 benötigten eine separate NMS-Phase nach der Inferenz; YOLO26 eliminiert diese.

Was den PCIe-Bus überquert — und was nicht

Dies ist der entscheidende Unterschied gegenüber CPU-Dekodierung. Den PCIe-Bus überquert ausschließlich der komprimierte Video-Bitstream am Eingang. Rohe dekodierte Frames (1920×1080, je ~6 MB für YUV420) verlassen den VRAM nie. In den Host-Speicher gelangen nur die endgültigen Erkennungen — typischerweise einige Hundert Bytes pro Frame — was vernachlässigbare Bandbreite darstellt.

Referenz-Hardware und Software-Stack

Die Pipeline wurde auf AMD Radeon AI PRO R9700 demonstriert, einem Workstation-GPU mit dediziertem VCN-Engine. Derselbe Stack funktioniert auch auf Rechenzentrum-Karten der AMD Instinct MI300X-, MI325X-, MI350X- und MI355X-Familie. Der Software-Stack basiert auf ROCm 7.2 / ROCm 7.2.2.

Als Testeingang diente ein 15-sekündiges KI-generiertes Fahrrad-Video in 1920×1080 bei 16 fps im H.264-Codec. Der Vergleich mit dem OpenCV-Baseline (CPU-Dekodierung) zeigt bei rocDecode höhere VCN- und GFX-Aktivität — also höhere GPU-Ressourcenauslastung — aber deutlich geringere CPU-Belastung und keinerlei PCIe-Datenverkehr für Frames. Unterstützte Codecs umfassen H.264 und H.265; auf neueren GPU-Generationen unterstützt der VCN-Engine auch AV1 und VP9.

Zum Speichermodell: rocDecode verwendet den „device-copied”-Ausgabemodus, der DLPack-kompatible Oberflächen erzeugt. Das bedeutet, dass Ausgabe-Tensoren pro Frame keine Allokation bei jedem Frame erfordern — einmal allozierte Buffer werden für die gesamte Sitzungsdauer wiederverwendet, was den Druck auf den GPU-Allokator eliminiert.

Implikationen für die Produktions-Objekterkennung

Der von AMD demonstrierte Ansatz ist kein akademisches Experiment — es handelt sich um eine konkrete Integration öffentlich verfügbarer Komponenten (rocDecode, PyTorch, MIGraphX) mit einem in der Produktion eingesetzten Modell (Ultralytics YOLO26). Für jede Anwendung, die Video in Echtzeit verarbeitet — Überwachungskameras, industrielle Inspektion, autonome Fahrzeuge — bedeutet diese Pipeline geringeren CPU-Overhead, niedrigere Latenz und bessere Skalierbarkeit bei Multi-Stream-Szenarien. Die CPU, von Dekodierung und Datenkopieren entlastet, kann parallel Downstream-Aufgaben wie Objektverfolgung oder Ergebnisserialisierung übernehmen.