借助AMD Vitis AI的GStreamer加速边缘AI流水线
Key takeaway: 本文介绍如何使用 AMD Vitis AI 和 VVAS 工具链加速边缘 AI 视频分析流水线的开发与部署。文章从端到端视角剖析了从训练好的 PyTorch/TensorFlow 模型到在第二代 Versal AI Edge 系列自适应 SoC 上实时运行 NPU 推理的完整流程。核心工具包括：AMD Quark 量化工具支持 BF16、FP16 和 INT8 精度模式，并可通过混合精度解决 YOLO 等模型后处理的精度损失；Vitis AI 编译器自动完成算子融合、内存调度及 CPU/NPU 分区，支持数据并行和张量并行；ONNX Runtime + Vitis AI Execution Provider 和原生 VART-ML 运行时分别适配快速原型与量产级零拷贝执行。在视频流水线集成侧，基于 GStreamer 的 VVAS 通过插件（vvas_xinfer、vvas_xoverlay 等）及 JSON 配置，编排采集、预处理、推理、后处理与渲染，并原生支持空间分区、时间共享和 DMA-BUF 零拷贝等高级部署特性。文中以 YOLOX 检测示例演示了单条 gst-launch 命令即可描述完整流水线。预构建 Docker 镜像和 VEK385 评估板启动镜像使上手时间缩短至数分钟，Python/C++ API 覆盖从原型到量产。这些能力可使团队将更少时间花在底层集成上，更多聚焦于应用开发与性能优化。
- AMD Vitis AI 提供从 ONNX 模型到 NPU 可执行文件的完整工具链，包含 Quark 量化、Vitis AI 编译器和两种运行时（ONNX Runtime Vitis AI Execution Provider 与 VART-ML）。
- 量化支持 BF16（自动校准）、FP16（适用于视觉 Transformer）和 INT8 模式，并可通过混合精度将后处理保留 FP32 自动转 BF16，解决 YOLO 等模型的尺度不匹配精度问题。
- 基于 GStreamer 的 VVAS 通过插件化架构和 JSON 配置编排整个视频分析流水线，无需深入 GStreamer 内部或手写自定义集成代码。
- VVAS 支持高级部署特性，包括空间分区、时间共享和零拷贝推理（DMA-BUF），可显著提升吞吐量并降低时延。
- 预构建 Docker 镜像和面向 VEK385 评估板的启动镜像让环境搭建从“数天”缩短至数分钟，并可通过 Python API 快速原型开发、C++ API 直接投入量产。
边缘AI部署的痛点一直是工程团队的心头大患：从模型量化、精度损失到视频流水线的胶水代码，每一步都可能消耗几周时间。本文以AMD Vitis AI和VVAS为切入点，清晰地拆解了从训练好的PyTorch模型到基于GStreamer的量产级视频分析应用的全流程。它不仅是工具说明，更是一份端到端的实践方法论，对于正在异构计算平台上构建实时AI应用的团队来说，从“找不到北”到“有章可循”，正是这篇文章的核心价值。
AMD Vitis AI 提供从 ONNX 模型到 NPU 可执行文件的完整工具链，包含 Quark 量化、Vitis AI 编译器和两种运行时（ONNX Runtime Vitis AI Execution Provider 与 VART-ML）。
—— 络石智能编辑部 · Editor's Pick借助AMD Vitis AI的GStreamer加速边缘AI流水线
2026-08-19 0
将神经网络部署到边缘硬件上听起来简单，但实际操作起来却并非如此。您在 PyTorch 中训练了一个模型，获得了很好的精度，然后却面临着一系列陌生的问题：如何在不影响精度的前提下降低精度位宽？如何面向特定的自适应 SoC 进行部署？如何以尽可能低的开发工作量，将推理无缝集成到实时视频流水线中？其中每一步，本身都可能需要数周的工程投入。AMD Vitis AI 和 Vitis 视频分析 SDK（ Vitis Video Analytics SDK，VVAS ）正是为弥合这些缺口而设计。
为了理解这些工具的作用，首先需要从端到端的角度，想象一个完整的 AI 视频分析应用是什么样的。视频数据来自一个或多个来源，例如文件、IP 摄像头或 IoT 传感器，并依次经过多个阶段：采集与解码、预处理、推理、后处理与渲染，最终进入存储、显示或流媒体输出端点。每个阶段都需要高效执行，同时各阶段之间需要协同工作，避免引入不必要的数据拷贝或 CPU 瓶颈。图 1 展示了一个典型流水线，其中 Vitis AI 负责加速机器学习推理阶段，而 VVAS（基于 GStreamer ）则负责连接并编排围绕该阶段的各个流水线元素。
图 1：典型视频分析流水线——Vitis AI 为运行在 AMD Versal NPU 上的机器学习推理阶段提供支持；VVAS（基于 GStreamer 构建）连接并编排从源到输出的整体流程。
从训练到部署：复杂性从何而来
图 1 中的流水线看起来非常清晰。但在实际构建中，如果没有合适的工具，项目进度就会放缓。下面具体来看，真正的痛点在哪里。
从训练到推理缺乏清晰路径。
大多数开发者都熟悉 PyTorch 或 TensorFlow，但这些框架并不会直接为 AMD NPU（Neural Processing Unit，神经处理单元；在第二代 AMD Versal AI Edge 系列器件中作为基于 AI 引擎构建的 AI 推理加&速器）提供二进制文件。
量化是一大挑战。
如果只是简单地将 FP32 权重转换为 INT8，而没有进行适当的校准或调优，可能会导致明显的精度损失。找到合适的校准策略、处理混合精度需求（例如，在 YOLO 后处理中保留更高精度，以避免尺度不匹配）以及验证结果，都需要专业知识和工具。
视频流水线集成是一个独立的工程问题。
即使推理已经可以运行，将其与实时视频流集成起来，包括硬件加速预处理、元数据传递、边界框叠加以及多路视频流管理，仍然需要对 GStreamer 和自适应 SoC 或 FPGA 具备深入了解。大多数 AI 开发人员并不具备这样的背景。
性能分析和调试并不容易。
当时延较高时，很难确定瓶颈究竟来自 NPU、CPU 回退、预处理还是后处理。如果缺乏良好的可观测性工具，优化就只能依靠猜测。
上述每一种缺口都与 Vitis AI 或 VVAS 的某项功能直接对应。让我们从模型侧开始，逐步了解工具链是如何解决这些问题的。
Vitis AI：弥合模型到 NPU 的缺口
Vitis AI 提供了一套完整的集成工具链，可将 ONNX 模型转换为经过优化、在第二代 Versal AI Edge 系列器件上运行的 NPU 可执行文件。在深入了解各个阶段之前，有必要先了解软件栈各层之间的关系。在最上层，开发者可以使用熟悉的机器学习框架，例如 PyTorch 和 TensorFlow。标准的开源模型可以从这些框架导出为 ONNX 格式。Vitis AI 工具（ AMD Quark 用于量化，Vitis AI Compiler （ Vitis AI 编译器）用于面向特定硬件的优化）位于中间层，负责将这些模型转换为高效的 NPU 二进制文件。在运行时，两条 API 路径（即带有 Vitis AI Execution Provider 的 ONNX Runtime，以及原生 VART 运行时）会通过灵活运行时（ XRT ）层调用硬件。下图展示了这一完整软件栈：
图 2：Vitis AI 软件栈——AMD Quark Quantizer 和 Vitis AI 编译器位于 ONNX 与 VART 运行时之上，通过 AMD Versal 平台上的灵活运行时（ XRT ）驱动神经处理单元（ NPU ）。
下面来看每个阶段能够带来什么能力。
借助 AMD Quark 进行量化
AMD Quark 是 Vitis AI 中包含的量化工具包。Vitis AI 编译器支持三种精度模式，以适配不同的性能与精度权衡。对于 FP16 和 INT8，Vitis AI 使用 AMD Quark 作为量化工具包。
BF16（自动）：Vitis AI 编译器会在编译过程中自动将 FP32 模型转换为 BF16，无需校准。这是推荐的起步方案。
FP16：通过 Quark 进行显式转换，适用于视觉 Transformer 架构，因为在这类架构中，BF16 可能带来过大的精度损失。
INT8（高性能）：使用小规模校准数据集进行训练后量化。相比 FP16 或 BF16，它能提供更高的吞吐量和更低的时延，但会牺牲一定精度。
对于像 YOLO 这样的模型，INT8 会因后处理中的尺度不匹配而导致精度受影响，Vitis AI 可通过混合精度应对：将计算密集型核心量化为 INT8，同时将精度敏感的后处理保留为 FP32，编译器会自动将这些 FP32 子图转换为 BF16，从而使整个模型仍能在 NPU 上执行。
编译
Vitis AI 编译器接收 ONNX 模型，并生成针对 NPU 优化的二进制文件。它会自动处理算子融合、内存调度以及 CPU/NPU 分区。您只需通过一个 JSON 文件对其进行配置，在文件中指明目标设备和优化偏好。
Vitis AI 编译器支持两种并行化策略，即数据并行和张量并行，以优化模型在 NPU 硬件上的性能。数据并行（批处理）会在多个 NPU 计算块上复制完整模型，使多个独立推理请求可以并发运行。因此，它非常适合多摄像头视频流这类高吞吐量场景。张量并行会将单个推理请求划分到多个 NPU 计算单元上，以并行方式执行，从而降低每个请求的时延，并支持超出单个 NPU 计算块内存容量的模型。选择哪种策略取决于您的应用需求：数据并行更适合面向吞吐量的工作负载，而张量并行更适合对时延敏感或内存受限的用例。Vitis AI 能够将工作负载物理分区到专用 AI 引擎上（后文称为“空间分区”），这是一项重要能力，有助于设计人员降低功耗并提升时延确定性。
编译完成后，AI Analyzer（ AI 分析器）会提供可视化的分析结果，显示哪些算子运行在 NPU 上，哪些算子回退到 CPU 上，从而帮助您确定需要优化的位置。下面的 AI Analyzer 示例图展示了算子如何在 NPU 和 CPU 之间进行分区。
图 3：AI Analyzer 展示 NPU 与 CPU 之间的算子分区情况。
部署运行时
Vitis AI 提供两种运行时，以适配您的部署阶段。具体应选择哪种运行时，取决于您的应用对执行细节控制程度的需求。
ONNX Runtime + Vitis AI Execution Provider 是运行推理的最快路径。如果您的应用已经基于 ONNX Runtime 构建，那么添加 Vitis AI Execution Provider 只需要极少的改动。您只需传入 provider 名称和已编译模型，ONNX Runtime 就会自动对算子进行分区，将受支持的算子发送到 NPU，其余算子则回退到 CPU。对于希望保留现有基于 ONNX Runtime 的技术栈并启用硬件加速的团队来说，这是一个切实可行的选择。
VART-ML 是面向量产环境的高性能 C++ 运行时。对于完全卸载到 NPU 上的模型，它有助于彻底消除 CPU 回退开销，并支持零拷贝执行。因此，当应用需要更严格地控制运行时行为和性能调优时，VART-ML 是更合适的选择。
总结来说：ONNX Runtime 提供了一条熟悉的集成路径，可以快速启动并运行；而当您需要对执行过程进行更直接的控制并追求尽可能低的时延时，VART 是更合适的选择。
易用性与开箱即用体验
上手过程快捷且直接。预构建 Docker 镜像包含了所有量化和编译工具。面向第二代 AMD Versal AI Edge 系列 VEK385 评估板的预构建启动镜像，让您在首次上电后几分钟内即可运行 ResNet50 推理。Python API 可实现快速原型开发；C++ API 可扩展至量产环境。这种开箱即用体验意味着，您可以将时间投入到应用开发，而非环境搭建上。
当模型已经完成量化、编译并可在 NPU 上运行后，您仍需解决另一项挑战：将实际应用中围绕推理的组件集成起来，包括视频解码、预处理、元数据传递以及多接收端输出路由。这正是 VVAS 的用武之地。
VVAS：弥合流水线集成缺口
当 Vitis AI 负责模型量化、编译和 NPU 执行之后，下一个问题是：是什么将图 1 中所示的所有流水线阶段连接起来？解决方案就是 VVAS。如果没有 VVAS，流水线中的每一次交接，包括将帧解码为正确的缓冲区格式、将其送入可编程逻辑（ PL ）预处理内核、将结果传递给 NPU 推理、向叠加阶段传递元数据以及将输出路由到多个接收端，都需要单独的自定义集成项目，并且需要对 GStreamer 以及自适应 SoC 或 FPGA 具备深厚的专业知识。
VVAS 借助开源 GStreamer 技术，通过一个简洁的插件式 SDK 处理所有这些复杂工作。如下架构图所示，您的应用位于最上层，直接使用 VVAS 插件；而 VVAS 则负责管理底层各层，包括 GStreamer、Vitis AI、XRT 和 NPU。
图 4：VVAS 架构——用户应用位于最上层；VVAS 插件层（基础设施、预处理、推理和自定义插件）桥接 GStreamer、Vitis AI 工具、XRT 和底层的 NPU。
流水线中的每个阶段都直接映射到一个专用的 VVAS 插件，通过 JSON 文件进行配置，无需自定义 C++ 或 GStreamer 样板代码：
vvas_xabrscaler：提供硬件加速的尺寸缩放、颜色转换和归一化，预处理不会带来 CPU 开销。
vvas_xinfer：机器学习推理插件，支持 ONNX Runtime 和 VART 后端。负责批处理、元数据生成和 NPU 执行。
vvas_xmetaconvert / vvas_xoverlay：解析推理元数据，并直接在输出帧上绘制边界框、标签和形状。
vvas_xmetaaffixer：支持在不同分辨率的视频流之间传递元数据。
vvas_xmulticrop / vvas_xfunnel / vvas_xdefunnel：支持感兴趣区域裁剪、视频流合并与拆分，用于级联式多模型流水线。
为了更具体地说明，下面示例展示了一个完整的 YOLOX 目标检测流水线在实践中的实现方式，包括从文件读取、解析原始视频、执行推理、转换元数据、叠加结果，并将输出发送至接收端。所有这些步骤都可以用一条 gst-launch 命令来表达。
用于推理和元数据转换的 JSON 文件如下：
(a) 推理 JSON
(b) 元数据转换 JSON
这种流水线方式使您可以继续使用熟悉的媒体框架，同时在分析流程的每个阶段充分利用具备硬件感知能力的插件。它无需自定义缓冲区管理，也不需要深入掌握 GStreamer 内部机制，而是依靠通过 JSON 配置定义的简单、直接的插件组合来完成构建。
VVAS 还支持 Vitis AI 提供的高级部署配置，否则这些配置通常需要大量的自定义工程：空间分区（两个模型在单独的 NPU 列分区上并发运行）、时间共享（多个模型在同一 NPU 资源上进行时分复用），以及零拷贝推理（ DMA-BUF 和 XRT 缓冲区对象直接传递给 NPU，无需中间拷贝）。
在性能分析方面，VVAS 使用标准 GStreamer tracer。您可以使用 fpsdisplaysink 测量每秒帧数，使用 GST_TRACERS="latency" 测量时延，并使用 GST_TRACERS="rusage" 测量 CPU 利用率。GStreamer 流水线常用的可观测性方法同样适用于此。
总体而言，Vitis AI 与 VVAS 覆盖了完整流程：从训练好的浮点模型，一直到经过性能分析、可投入量产并运行在第二代 AMD Versal AI Edge 系列硬件上的视频分析应用。下面可以这样理解二者各自带来的价值。
核心要点
AI 流水线开发并非仅限于模型本身。真正的挑战在于将模型优化、运行时执行、媒体处理、详细的性能分析洞察以及硬件加速整合到一个可维护的应用中。这也正是 Vitis AI 与 VVAS 组合的吸引力所在：一个负责模型准备和 NPU 执行，另一个则对周边流水线进行结构化和编排。
二者结合，可以助力您：
优化吞吐量和时延：面向整个嵌入式 AI 流水线。
降低开发工作量：通过复用经过验证的模型量化、编译和流水线基础设施，而非从零开始构建整条流水线。
最大限度减少集成工作：VVAS 和 Vitis AI 能够处理运行时、缓冲区管理和媒体阶段之间的复杂性。
加速原型开发：借助可复用的插件组件、预构建的启动镜像和 Python API，更快实现可运行的概念验证。
缩短迈向量产的路径：用于快速原型开发的同一套工具链，也可以借助 VART 和零拷贝推理扩展到经过优化的量产级部署。
结语
本文中的示例，从简单的三行 ONNX Runtime 会话，到用单条命令表达的完整 YOLOX GStreamer 流水线，展示了这套工具链在实践中的运行方式。这些示例也说明，边缘 AI 部署中的难点完全可以解决；关键在于在合适的层级使用合适的抽象。
Vitis AI 和 VVAS 正是提供这些抽象的工具。无论您是从 PyTorch 模型起步，需要找到通往 NPU 的路径，还是已经完成推理、需要将其接入实时视频流，这套工具链都能在您当前所处的位置提供支持，并随着需求增长而扩展。对于在第二代 Versal AI Edge 系列上构建实时 AI 应用的团队，Vitis AI、VVAS、Quark 和 AI Analyzer 提供了必要的基础设施与工具，帮助设计人员自信地实现、优化并将其设计部署到量产环境。
准备开始了吗？
欢迎查阅 Vitis AI 6.2 用户指南和 VVAS 6.2 用户指南，获取完整文档、快速入门教程，以及基于第二代 AMDVersal AI Edge 系列 VEK385 评估板的预构建示例。
Tags
Related Topics
Expert Comment
This article is curated by the editorial team from public sources for reference only.