将神经网络部署到边缘硬件上听起来简单，但实际操作起来却并非如此。您在 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 评估板的预构建示例。
文章来源：AMD Xilinx赛灵思官微
