AMD ROCm：GPU驻留YOLO26流水线将视频帧从解码到检测全程保留在VRAM中

AMD在其ROCm博客中详细介绍了一种四阶段GPU驻留目标检测流水线，结合了rocDecode、DLPack、PyTorch和MIGraphX——展示了视频帧如何在从压缩比特流到边界框的整个过程中不产生任何多余的数据拷贝。

为什么「GPU驻留性」对实时检测至关重要？

传统的视频目标检测方法依赖CPU解码，将帧移至RAM，然后传输到GPU内存。每次转换都有代价：PCIe总线成为瓶颈，延迟增加，CPU被简单的数据复制占用而无法处理更有价值的工作。

AMD的方法消除了这些转换。压缩的H.264或H.265比特流只穿越一次PCIe总线——其余操作完全在GPU内部进行。帧通过rocDecode库直接解码到VRAM，在预处理和推理过程中保持在那里，只有最终检测结果（带有置信度分数和类别ID的边界框）才进入主机内存。

流水线的四个阶段

第一阶段是视频硬件解码。视频核心下一代（VCN）——AMD GPU内部的专用模块——无需调用GFX计算核心即可原生解码H.264和H.265。在AMD Radeon AI PRO R9700（ROCm 7.2.2，1920×1080 H.264输入）上的测量显示VCN利用率仅约10%，而计算核心并行以约**21%**的利用率运行。两个引擎同时独立工作。

第二阶段是帧之间的零拷贝传输。DLPack库定义了所有主流框架都能理解的标准张量内存布局。解码后的帧表面不会复制到新缓冲区——DLPack包装器引用现有VRAM位置并将其传递给PyTorch，无需分配。输出张量一次分配后对每帧重复使用。

第三阶段是推理。MIGraphX——AMD的图推理引擎——使用FP16量化编译YOLO26模型，并在AMD GPU上原生运行，无需中间软件层。

第四阶段是检测过滤。Ultralytics的YOLO26模型内置了端到端NMS（非极大值抑制）：输出是每帧形状为**[1, 300, 6]**的张量——每行包含边界框坐标（x1、y1、x2、y2）、置信度分数和类别ID。旧版模型如YOLO11在推理后需要单独的NMS阶段；YOLO26消除了这一需求。

什么穿越PCIe总线——什么不穿越

这是与CPU解码的关键区别。只有压缩视频比特流在输入时穿越PCIe总线。原始解码帧（1920×1080，YUV420格式每帧约6 MB）永远不离开VRAM。只有最终检测结果——通常每帧几百字节——进入主机内存，带宽占用可忽略不计。

参考硬件和软件栈

该流水线在AMD Radeon AI PRO R9700（配备专用VCN引擎的工作站GPU）上进行了演示。同样的栈也适用于AMD Instinct MI300X、MI325X、MI350X和MI355X系列的数据中心显卡。软件层基于ROCm 7.2 / ROCm 7.2.2。

测试输入是一段15秒的AI生成骑行视频，分辨率1920×1080，16 fps，H.264编码。与OpenCV基线（CPU解码）的比较显示，rocDecode路径的VCN和GFX活动率更高——意味着GPU资源利用率更高——但CPU占用显著降低，帧的PCIe流量为零。支持的编解码器包括H.264和H.265，在较新一代GPU上VCN引擎还支持AV1和VP9。

在内存模型方面，rocDecode使用「设备拷贝」输出模式，生成DLPack兼容的表面。这意味着每帧的输出张量不需要在每帧时进行分配——一次分配的缓冲区在整个会话中重复使用，消除了GPU分配器的压力。

对生产目标检测的影响

AMD展示的方法不是学术实验——而是使用公开可用组件（rocDecode、PyTorch、MIGraphX）与生产中使用的模型（Ultralytics YOLO26）的具体集成。对于任何实时处理视频的应用——监控摄像头、工业检测、自动驾驶车辆——这种流水线意味着更低的CPU开销、更低的延迟和在多路流场景中更好的可扩展性。从解码和复制中解放出来的CPU可以并行处理下游任务，如目标跟踪或结果序列化。