1. 课程导入与部署工程全景

在边缘AI推理场景中，AMD Kria 系列（如 Kria KV260、KR260）是一类定位非常明确的平台：它把 Zynq UltraScale+ MPSoC 的 ARM 处理器、可编程逻辑（PL）与专用 AI 加速单元（DPU）集成在一块核心板上，再通过载板提供摄像头、以太网、USB、MIPI 等外设接口。与“把模型放到服务器 GPU 上跑”不同，Kria 的目标是在功耗受限、空间受限、实时性要求高的现场设备中完成推理，例如智能相机、工业质检、机器人视觉和边缘视频分析。理解这一点，是理解后续所有部署工作的前提：我们不是单纯地“跑一个模型”，而是在一个软硬件协同的异构平台上，把训练好的神经网络映射为可调度、可复用、可量产的推理系统。

围绕 Kria 的模型部署，AMD 提供了 Vitis AI 工具链。它并不是一个单一软件，而是一组围绕“模型编译—硬件加速—运行时调度”构建的工具集合。核心组成包括：用于模型量化与编译的 Vitis AI Quantizer 和 Vitis AI Compiler；用于生成 DPU 硬件配置的 DPU IP 与 Vitis 平台；用于在板端加载模型、管理内存与调度的 Vitis AI Runtime（VART）；以及面向应用开发的 Vitis AI Library，它把常见的分类、检测、分割等任务封装成可调用的 API。对于 Kria 用户，AMD 还提供了 Kria App Store 中的参考应用（如 smartcam、defect detection），这些应用已经完成了 DPU 固件、VART 和 GStreamer 管线的集成，可以直接作为工程起点。

从工程视角看，一个完整的部署流程可以拆成几个关键阶段。第一阶段是模型准备：拿到 PyTorch、TensorFlow 或 ONNX 模型后，先做结构检查，确认算子是否被 DPU 支持；不支持的算子需要替换或回退到 CPU。第二阶段是量化：用 Vitis AI Quantizer 把 FP32 模型转成 INT8，通常需要一小批校准数据（例如 100～500 张真实场景图片），量化后要检查精度损失，若掉点超过阈值（例如分类任务 top-1 下降超过 2%），需要调整量化策略或部分层保留浮点。第三阶段是编译：用 Vitis AI Compiler 把量化模型编译成 DPU 可执行的 xmodel，同时生成指令调度信息。第四阶段是板端集成：在 Kria 上部署 DPU 固件（通过 xmutil 或 Kria 的加速器固件加载机制），用 VART 加载 xmodel，构建输入输出张量，接入摄像头或视频解码管线，最后通过 GStreamer 或自定义 C++/Python 应用完成推理循环。

软硬件协同设计思想贯穿整个流程。硬件侧，DPU 的并行度、寄存器配置和内存带宽决定了推理的峰值算力；软件侧，模型结构、量化策略和运行时调度决定了实际能利用多少算力。一个常见的误区是只关注模型精度，忽略了 DPU 对算子形状、通道数和数据布局的约束。例如，DPU 对卷积层的通道数通常有对齐要求（如 8 的倍数），若模型某层通道数为 3 或 7，编译时可能触发回退或额外填充，导致性能下降。因此，在模型设计阶段就应考虑 DPU 的友好性，而不是等到编译报错才回头修改。

为了把这条链路讲清楚，本课程会以一个具体的实战目标贯穿始终：在 Kria KV260 上部署一个轻量级目标检测模型（例如基于 YOLO 的裁剪版本），输入为 640×480 的 MIPI 摄像头视频流，输出为带检测框的实时画面。我们会从模型导出开始，逐步完成量化校准、编译生成 xmodel、板端固件加载、VART 推理程序编写，最后用 gst-launch-1.0 构建完整管线并测量端到端延迟。过程中会给出具体的校准集数量、量化参数、DPU 配置选择依据，以及如何通过 vaitrace 或时间戳日志判断瓶颈在预处理、推理还是后处理。

需要特别说明的是，Vitis AI 的版本与 Kria 的固件版本存在对应关系。例如 Vitis AI 3.0 通常搭配 Kria 的 2022.2 或 2023.1 固件，DPU 的 IP 配置（如 B4096）也需与 xmodel 编译时选择的架构一致。若版本不匹配，板端加载 xmodel 时会出现“无法识别指令集”或“DPU 配置不匹配”的错误。因此，在工程开始前，先通过 xmutil listapps 查看当前固件支持的加速器，再决定编译时的 --arch 参数，是一个值得养成的习惯。