KV260实战：从零开始跑通人脸检测与端侧识别

拆开 KV260 包装的那一刻，我的第一反应是：这散热片也太夸张了。但正是这块带着大散热器的板子，让我从完全没碰过 Zynq 的小白，一路跑通了人脸检测和简单的端侧人脸识别。KV260 不是什么传统的 MCU 开发板，它是 AMD Kria 系列里的视觉 AI 入门套件，专门给边缘图像识别、视频分析和智能相机这类场景准备的。这篇文章不打算去抄官方文档，而是把从开箱、烧系统、连接板子到跑起人脸识别流程的整个链路，按我实际动手的顺序写出来，给那些和我一样零基础的朋友一条能被直接复制的路线。你不需要会写 FPGA 代码，甚至不要求熟悉 Linux，只要有一点命令行基础，就能跟着往下走。

1. 开箱先别通电：硬件长什么样、配件怎么配

1.1 为什么 KV260 适合视觉小白而非纯开发板

很多人第一次看到 KV260 时都会问一个问题：它和树莓派、Jetson Nano 到底有什么区别？单看参数表，KV260 用的是一颗 Zynq UltraScale+ 家族的 XCK26 芯片，这颗芯片把四核 ARM Cortex-A53 处理器和可编程逻辑（也就是 FPGA 那部分逻辑）集成在同一个封装里。这意味着它既能完整地跑 Linux 操作系统，又能在可编程逻辑里挂一个专为卷积神经网络优化的 DPU（深度学习处理单元），让视频流和模型推理不再挤在 CPU 上排队。

对小白来说，KV260 最友好的一点是：你不需要自己写 Verilog，也不需要理解芯片内部布线。官方 Ubuntu 镜像里已经把 DPU 驱动、Vitis AI Runtime、各种加速应用都预装好了，你要做的事情更像是“给一个已经建好的实验室接上电”，而不是“从零开始盖实验室”。我之前用过树莓派玩人脸检测，模型稍大一点帧率就掉到惨不忍睹；换到 KV260 之后，合理量化的模型明显轻松很多，这就是硬件加速带来的体感差异。如果你最终的用途是拿边缘设备做实时摄像头分析，KV260 的定位会比通用开发板更准。

1.2 收到货先检查这几样，能少走一半弯路

开箱之后不要急着插电，先把该确认的东西过一遍。KV260 套装一般是开发板主体、散热器、电源适配器，部分批次还会附带 USB-C 转串口线。网线和 microSD 卡经常需要自己准备，而恰恰是这两样最容易出问题。我是吃过亏的：第一次随便找了一张旧 TF 卡，烧录时反复报错，后来换了一张 A1 级别的卡才跑通。

开箱检查清单我整理了一下：

• 板卡本体：确认没有明显磕碰，金手指区域干净，散热器固定螺丝没有被运输震松。
• 电源：务必用官方适配器，或者至少是质量可靠的 12V 直流电源。不要试图用普通手机充电头通过 USB-C 供电，电流不够会导致板子频繁重启。
• microSD 卡：16GB 以上，写入速度按 Class 10/U1 起步，有条件直接上 A2 规格。后续装模型和工具链都需要足够容量。
• 读卡器：烧录镜像的必备工具，电脑如果没有 SD 卡槽，建议用 USB 3.0 读卡器。
• 显示器、键鼠、网线：首次启动最省心的一套外设组合，后面可以慢慢替换成纯远程操作。

另外建议把板子放在防静电袋或绝缘桌面上再检查，不要穿着容易起静电的毛衣在化纤地毯上拿着板子摸来摸去。硬件这东西，怕的不是正常操作，而是莫名其妙的静电击穿。检查完这些，接下来就可以进入烧系统环节了。

2. 第一次点亮：镜像烧录与系统初始化

2.1 镜像别乱下：官方 Ubuntu 镜像省掉了 80% 的编译工作

拿到开发板第一步永远是烧系统镜像。KV260 官方支持 Ubuntu 20.04 LTS for Kria，这个镜像专为 KV260 定制，里面包含了启动引导、内核、DPU 驱动、XRT（Xilinx Runtime）和 Vitis AI Runtime。对小白来说，这个选择几乎没有思考成本：直接下载官方镜像，不要自己折腾 PetaLinux 或从上游编译 Linux，因为那是进阶玩家才该干的事。

我自己刚开始也犯过“总觉得官方镜像不够纯粹”的毛病，想去 GitHub 上找一个精简版 Linux，结果折腾两天一无所获。后来想明白一个问题：KV260 的 DPU 不是插在 PCIe 上的独立显卡，它依赖系统在启动时通过 FPGA Manager 加载 overlay（硬件配置文件）。如果你用的镜像里没有配套驱动和加载脚本，DPU 节点根本不会出现，人脸检测demo自然跑不起来。官方镜像的价值不在于“能用”，而在于“所有东西都对齐了版本”。

2.2 烧录命令与验证

烧录工具我用的是 balenaEtcher，它跨平台、界面直观，适合新手。操作流程很简单：打开 Etcher，选择下载好的镜像文件，选择目标 SD 卡，点击 Flash。这里要特别提醒一句：烧录过程会把 SD 卡完全覆盖，选错盘符会清掉电脑硬盘的数据，一定要在 Etcher 里确认容量大小和盘符再动手。

如果你用的是 Linux 系统，也可以用 dd 命令行烧录：

# 确认 SD 卡设备名，常见是 /dev/sdb 或 /dev/mmcblk0 lsblk # 烧录镜像，注意 if 和 of 不要写反 sudo dd if=ubuntu-kv260-2024.1.img of=/dev/sdX bs=4M status=progress sync

烧录完成后，Windows 有时会弹窗提示“需要格式化磁盘”，一定不要点格式化。直接把 SD 卡弹出，插到 KV260 的 microSD 卡槽里即可。为了确认烧录没有出错，我习惯烧完后再用 Etcher 的校验功能，或者重新把卡插回读卡器看一眼分区是否正常。这一步多花两分钟，能避免上电后陷入“启动日志刷屏但系统起不来”的尴尬。

2.3 上电后那几分钟的初始化流程

KV260 首次上电之前，把 HDMI 显示器、USB 键盘鼠标、网线都接好，再插电源。第一次启动会进入 Ubuntu 的初始化向导，类似给新电脑装系统时的设置页面，需要选择地区和时区，创建用户名密码，确认键盘布局。这个过程大概持续几分钟，中间板子可能会重启一两次，属于正常情况。

进入桌面后，打开终端，我建议立刻确认几个关键信息：

# 查看系统内核版本 uname -a # 查看当前加载的 FPGA 加速应用 xmutil listapps

xmutil是 KV260 镜像里控制 overlay 加载卸载的工具。正常情况下，xmutil listapps会列出几个已经预装的应用程序，比如 SmartCV、SmartCam、DPU 相关应用等。看到这些列表，说明你的环境和驱动基本正常。接下来很多人会犯一个错误：急着把 HDMI 线拔掉只用远程终端。我的建议是首次使用的前半小时先别拔，因为如果网络没配好、SSH 连不上，还有一个显示器能救命。

3. 扔掉屏幕也能干活：SSH 远程开发的三种连接方式

3.1 显示器、SSH、串口，各自什么时候用

在 KV260 上开发，一直挂着 HDMI 显示器并不现实，开发机离板子远、桌面空间有限，更不要说给板子配一套键鼠有多占地方。其实 KV260 的远程并发能力很强，你只需要网络和终端就能完成大部分操作。

我试过三种方式，各有适用场景：

对小白来说，最推荐的组合是：首次启动用显示器配好 SSH，之后就把显示器拔掉，所有开发都在 SSH 里进行。串口可以后面再研究，虽然它看起来很极客，但作为入门阶段的核心工具必要性没那么高。

3.2 SSH 连上之后的第一轮系统配置

KV260 的 Ubuntu 镜像默认开启了 SSH 服务，前提是网络已经通。我是通过路由器后台查看设备列表找到板子 IP 的，比在板子上敲ip addr再回开发机复制地址方便得多。如果你懒得查 IP，也可以试试主机名解析：

ssh yourname@kria.local

其中yourname换成你在初始化向导里创建的用户名。第一次连接会提示确认主机指纹，输入yes继续，然后输入密码。如果连不上，多半是网络隔离或者防火墙问题，先用显示器确认板子有没有拿到 IP。

SSH 连接成功后，我建议先做三件事：改密码、更新软件包索引、安装常用工具。

# 修改当前用户密码 passwd # 更新软件包索引 sudo apt update sudo apt upgrade -y # 安装 htop 和 vim，后面排查问题都能用上 sudo apt install -y htop vim

htop特别重要。后面跑人脸检测时，你要通过它判断 CPU 占用是不是真的降下来了、DPU 是不是在干活。另外我建议顺手把build-essential和git装上，即使暂时不用，后面拉代码、编译工具链时会省一步。

3.3 文件传输与远程编码

SSH 只能解决敲命令的问题，模型文件、脚本、图片这些数据怎么传到板子上？两个最常用的办法是scp和 VS Code Remote-SSH。

scp在开发机终端里执行，基本用法如下：

# 从开发机复制文件到 KV260 scp model.xmodel yourname@192.168.1.100:/home/yourname/

如果你在用 Windows，还推荐用 WinSCP，它可以像拖文件一样把程序传到板子上。更进阶的方案是 VS Code 的 Remote-SSH 插件，安装之后可以直接在本地编辑器里打开板子上的目录，写代码、跑终端、看日志都在一起，体验非常接近本地开发。

这里想多说一句：KV260 的存储空间和内存都有限，不要无限往板子上堆文件和工具链。系统盘满了之后，最典型的症状是编译到一半报No space left on device，或者桌面环境变得异常卡顿。养成习惯，大文件优先放在开发机或者 NAS 上，KV260 里只留代码和必要的模型文件。

4. 官方人脸检测 Demo 实测：从摄像头到检测框

4.1 SmartCam 应用跑起来有多简单

系统环境整理干净之后，就可以体验 KV260 上最直观的视觉应用了。官方镜像预装了 SmartCam 之类的应用，它的定位就是让人快速验证板载 DPU 和摄像头链路。操作方式是：在桌面终端里启动应用菜单里的 SmartCam，或者直接敲kv260-smartcam，启动后能看到一个配置界面，里面会有模型选择项，选择人脸检测（face detect）模式，然后指向摄像头设备。

我用的是一个普通的 USB 摄像头，系统会自动识别成 UVC 设备，不用装额外驱动。MIPI CSI 摄像头接口也可以接，但不同型号兼容性差别很大，入门阶段不建议拿 CSI 摄像头作为唯一方案，否则容易卡在驱动上。应用启动后，画面会以视频流形式输出，如果接了显示器可以直接看到检测框，如果纯远程操作，可以通过网络地址访问板子推出来的 HTTP 视频流。

人脸检测框出现的那一瞬间，是入门阶段最有成就感的时刻。一个站在摄像头前的人，脸部会被一个矩形框精确框住，稍微转头、走动，检测框会跟着人脸移动。整个体验下来，帧率大概在二三十帧的水平，这对人脸检测来说已经足够流畅。要注意的是，官方 demo 输出的仅仅是人脸位置信息，它不会告诉你这个人是谁，这是“检测”和“识别”最本质的区别，后面我会专门展开。

4.2 DPU 到底加速在哪一步

跑起来之后，很多人会好奇：DPU 到底干了什么？为了说清楚，我用一个抓扒手的类比：摄像头是眼睛，CPU 是现场指挥，DPU 是一群只看钱包动作的专业保安。原始视频流一帧一帧进来，CPU 先把图像缩放到模型输入尺寸，然后交给 DPU，DPU 在硬件电路里并行执行卷积、激活、池化这些高重复性计算，再把结果交回给 CPU 做后处理，比如筛选出置信度高的目标框，去掉重叠多余的候选框。

人脸检测模型本质上是一个足够深的卷积神经网络，包含几十层卷积层和大量乘加运算。在纯 CPU 上跑这类模型，每帧图像都要做海量浮点计算，即使 CPU 有四个核，也架不住逐帧处理。而 DPU 是硬件逻辑设计的计算单元，能在一个时钟周期内完成大量并行的乘加运算，模型如果提前量化为 INT8 精度，DPU 的利用率会非常高。这就是为什么看起来同样是跑模型，KV260 比没有专用加速器的板子流畅那么多。

4.3 怎么确认硬件加速真的在工作

跑 demo 的时候，我需要确认结果不是 CPU 硬扛出来的，而是 DPU 在参与。最直接的方法是开一个终端运行htop，观察四个 CPU 核的占用率。如果帧率挺高，但 CPU 占用率并不是长时间满载，多半是 DPU 在分担推理任务。反过来，如果 CPU 全部跑满、画面还是卡顿，那就要怀疑模型是不是没有成功加载到 DPU 上。

还可以在系统日志里搜索 DPU 相关信息：

dmesg | grep -i dpu

正常运行时能看到 DPU 驱动和硬件节点注册的记录。如果你之前乱执行过xmutil unloadapp，或者手动改了 overlay，dmesg里很可能会出现 DPU 节点不存在的异常提示。另外还有一个体感判断法：把手轻轻放在散热器上，板子运行人脸检测时发热很明显，这是加速器在高速工作。发热虽然听起来不好，但对 KV260 来说是正常的，只要没到烫伤程度就不用太担心。

5. 从“检测”到“识别”：搞懂原理就能自己改流程

5.1 检测是“找脸”，识别是“认脸”

官方 demo 跑通之后，大多数人的下一步需求自然是：能不能判断镜头前的人是谁？先说结论：能，但你需要给 KV260 加一个识别模型，或者自己写一套比对流程。因为“人脸检测”和“人脸识别”是两个完全不同的任务，混在一起只会让你调试时一头雾水。

用门禁机来举例就很好理解：

• 人脸检测：解决“画面里有没有脸，有的话在哪里”，输出是矩形坐标，比如(x, y, w, h)。
• 人脸识别：解决“这张脸是哪一位”，输出是一个身份标签，比如“张三”或“访客”。

检测模型相对轻量，它不关心脸是谁，只关心脸的几何特征，所以只要找脸即可。识别模型则会把一张裁剪好的人脸转换成一串数字特征，再用这串数字和数据库里的特征做比对。官方 SmartCam 默认只有检测能力，你要做的不是修改检测模型，而是把识别环节像积木一样接在检测后面。

5.2 那张人脸上的 512 维数字

人脸识别模型的核心思路是把人脸图像映射到一个高维特征空间。常见做法是通过 FaceNet、ArcFace 这类模型，把一张 112x112 或 160x160 的人脸图压缩成一个 128 维、256 维或 512 维的特征向量。训练阶段模型会学习一个度量空间：同一个人的不同照片，对应向量之间的距离尽量近；不同人之间的距离尽量远。

实际部署时，注册过程完成下面几件事：

1. 采集人脸区域并进行对齐和裁剪，比如双眼位置矫正，让输入图片尽可能标准。
2. 把处理后的人脸图输入识别模型，得到特征向量，存进特征库。
3. 识别时，对当前镜头中检测到的人脸同样做对齐和特征提取。
4. 将当前向量与特征库中所有向量计算相似度，常用余弦相似度或欧式距离。
5. 超过阈值则判定为同一个人，低于阈值则判为未知。

这里有一个小白容易忽略的点：人脸对齐非常关键。同样一个人，歪着头、低着头提取出的特征向量和正着脸提取的差异可能比不同人的差异还大，所以识别前通常会用关键点检测模型找出双眼、鼻尖、嘴角位置，再做仿射变换把人脸扶正。这也是为什么完整的人脸识别系统通常包含“人脸检测-关键点检测-对齐-特征提取-比对”多个模块。

5.3 KV260 落地识别方案的最低成本路径

想在 KV260 上跑通完整识别，最省力的路线不是自己写模型，而是先把系统分成几个里程碑逐步推进。

第一个里程碑：继续使用官方 SmartCam 的人脸检测能力，把检测框截图存下来。这样你就有了一个可以直接接触摄像头的人脸采集工具。

第二个里程碑：在开发机上用 Python 的 ONNX Runtime 或者 OpenCV DNN 跑一个预训练识别模型，比如 ArcFace。确认你的底库注册流程、相似度阈值都能正常工作，再把识别脚本通过 SSH 放到 KV260 上，用 CPU 方式跑通。虽然 CPU 帧率不好看，但它能帮你把流程走通。

第三个里程碑：把 CV 流程中耗时最大的模型量化成 INT8，转成 DPU 可以加载的 xmodel。可以用 Vitis AI 官方量化器和编译器来处理 PyTorch 或 TensorFlow 模型，量化完成后通过 Vitis AI Runtime API 调用。

伪代码的思路大致如下：

# 伪代码：完整人脸识别流程 for frame in video_stream: boxes = face_detect(frame) for (x, y, w, h) in boxes: face = frame[y:y+h, x:x+w] face = align_face(face) # 关键点对齐 vec = embed_model(face) # 提取特征向量 name = match_feature(vec, db) # 相似度比对 draw_frame(frame, (x, y, w, h), name)

要注意的是，DPU 不一定支持模型里的所有算子，某些层的兼容性问题会迫使它卸载到 CPU 上执行。所以“转 xmodel 成功”不等于“性能起飞”，还得看实际端侧耗时。如果识别精度因为 INT8 量化明显下降，需要通过校验集合对比量化前后的特征向量分布，顺带调整相似度阈值。整体来说，这条路径比很多人想象中要长，但它每一步都是可验证的，卡在哪一步就排查哪一步，不玄学。

6. 启动失败的坑、性能瓶颈与小白的调优顺序

6.1 我踩过的三个典型坑

先说供电问题。KV260 对供电要求比常规开发板苛刻，我一开始用了一个看起来功率够大的“通用 12V 电源”，结果运行 Demo 时 USB 摄像头反复掉线，甚至板子偶尔重启。换成官方电源后问题彻底消失。以后只要遇到莫名其妙的 USB 设备掉线，优先怀疑供电，而不是怀疑摄像头驱动。

第二是 SD 卡坑。烧录成功后第一次启动卡在启动界面，日志停在文件系统挂载阶段，最后发现是 SD 卡写入速度太慢。换了 A2 规格的卡以后一路顺畅。还有一个隐蔽问题：如果 SD 卡在 Etcher 烧录后又被 Windows 格式化过一次，也会出现“系统起不来”的情况，所以烧录后看到弹窗一律点取消。

第三是 overlay 操作坑。我为了调试曾经执行过xmutil unloadapp，再重启之后发现 DPU 节点不见了，SmartCam 起不来。后来才理解，KV260 的硬件加速应用依赖 overlay 在启动时加载到可编程逻辑里，卸载后不会自动恢复，必须重新执行xmutil loadapp加载对应应用，或者直接重启。建议小白前期除了xmutil listapps之外，其他xmutil命令不要乱碰。

6.2 从 20 到 30 帧：调优要先找瓶颈

当你把人脸检测或识别流程跑顺之后，很多人会开始关注帧率和延迟。优化之前最重要的是先判断瓶颈在哪：是摄像头采集太慢，是网络推流占用了太多 CPU，还是 DPU 推理本身耗时高，又或是后处理 NMS 写得太随意？

一个比较实用的做法是分阶段计时。在代码里分别记录抓帧耗时、DPU 推理耗时、后处理耗时，逐个打印出来。我自己优化时基本是按照下面的顺序：

1. 降低输入分辨率，比如从 1080p 降到 720p，人脸检测对分辨率没那么敏感，但推理耗时能显著下降。
2. 检查摄像头输出格式，尽量用 MJPEG 或者 YUYV 里更适合板载视频管线的格式。
3. 避免每帧都用 Python 做过重的图像循环，能用 OpenCV 内建函数处理的尽量向量化。
4. 正式部署时考虑把推理和视频采集拆到两个线程里，避免抓帧等待拖慢整个循环。
5. 模型层面做量化校准，精度允许的情况下选择更小的检测骨干网络。

我个人不太建议一上来就追求极限帧率。KV260 这类边缘设备的优势在于稳定运行、可离线部署，不是为了在打分榜上超过台式机。把功耗、发热、识别准确率和延迟放在一起评估，才是做边缘视觉项目该有的心态。

最后再分享一个感想：入门阶段的成功标准不是把代码跑通一次，而是你能解释清楚每一步到底发生了什么。从烧录镜像、SSH 连接，到看着摄像头前的人脸被框出来，再亲手把识别算法加进去，这个过程本身就是对边缘计算和视觉 AI 最好的入门训练。遇到问题时，一次只改动一个变量，不要同时换模型、换系统、换摄像头。先把 KV260 这套板子驯服，后面接别的传感器或应用场景时，你会发现自己已经有了排查问题的肌肉记忆。