简介：面向树莓派4B的YOLOv5-Lite目标检测资源包，为边缘计算与IoT场景提供了一套轻量级深度学习落地方案，适合希望在低功耗设备上完成实时目标检测的开发者、学习者，可应用于智能安防、无人零售、农业监测等常见边缘视觉任务。资源共7个文件，包括4个Python脚本（负责单图推理、视频流检测及LabelMe转YOLO格式的工具）、2个YOLOv5-Lite模型权重文件（v5lite-s与v5lite-e），以及1个专门适配树莓派ARMv7l架构的onnxruntime安装包，整体压缩包仅7.91MB，其中whl文件能免去手动编译依赖的麻烦。配套代码覆盖从数据标注、模型加载到摄像头实时检测的完整流程，部署门槛低，便于二次开发和方案验证。目前已有9482人学习/下载，对于研究边缘端目标检测、模型轻量化及嵌入式平台优化的读者，是很有参考价值的实操资源。 我前后在树莓派4B上折腾了大半个月，才把YOLOv5-Lite这套目标检测方案彻底跑通。最近正好有朋友问我要资源包，索性把整个项目的来龙去脉、踩坑记录和完整的资源整理成一篇文章，给想在嵌入式设备上做目标检测的朋友一个参考。这篇文章不光是分享资源，更会把“为什么这么做”“怎么做最稳”这些关键逻辑讲透。
先说结论：树莓派4B上跑YOLOv5-Lite目标检测，完全可行，但需要做好模型轻量化和部署优化。我整理的这份资源包，包含了完整可运行的推理代码、预训练权重、模型转换脚本、依赖清单和详细的部署文档，拿到手之后按照步骤走，基本可以实现15FPS左右的实时检测效果。这套方案的价值在于：不依赖云服务器、不依赖GPU、断电断网也能独立运行，非常适合做边缘计算、智能监控、机器人视觉等场景的原型验证。
1. 项目定位：为什么要在树莓派4B上做目标检测
树莓派4B这块板子，CPU是BCM2711四核Cortex-A72，主频1.5GHz（后期版本可以到1.8GHz），内存有2GB/4GB/8GB三个版本，算力水平大致相当于入门级智能手机。要在这样的硬件上跑目标检测，很多人第一反应是“不现实”，毕竟主流的目标检测模型动辄几十MB甚至上百MB的参数，前向推理一次需要几十亿次浮点运算。
但实际的需求场景是真实存在的：你做一个智能安防摄像头，不可能每帧画面都传到云端去识别；你做一个农业巡检小车，在田间地头根本没有稳定的网络连接；你做一个桌面级的体感交互装置，延迟超过200ms体验就崩了。边缘端推理是刚需，而树莓派4B是成本最低、生态最完善的入门级边缘设备。
为什么选择YOLOv5-Lite，而不是其他模型？我逐一对比过主流的方案：
- 标准YOLOv5s：参数量约700万，FLOPs约16.5G，在树莓派4B上CPU推理一帧平均需要2-3秒，完全无法实时。
- YOLOv5n：YOLOv5系列中最小的版本，参数量约180万，CPU推理速度能做到500ms左右，但精度下降比较明显，小目标检测效果不太理想。
- MobileNet-SSD：速度尚可，但工程上部署起来比较繁琐，而且检测头设计老旧，精度上限有限。
- YOLOv5-Lite：模型结构做了极致精简，参数量控制在100万以内，同时保留了YOLOv5的检测头设计。换算成计算量，在4B的CPU上跑NCNN框架，单帧推理时间可以控制在60-80ms，加上前后处理，整体能达到12-15FPS。
这个性能拐点很关键：15FPS意味着从“能跑”变成了“能用”。做静态检测、低速运动目标的跟踪，这个帧率完全够用；做实时视频流分析，只要不要求丝滑的30FPS，也是可以接受的。
资源包的目标用户也很明确：正在做毕业设计的本科生、做机器人视觉课题的研究生、嵌入式开发的入门工程师，以及DIY爱好者。如果你是这几类人，这套资源能帮你省掉至少两周的环境配置和模型调试时间。
1.1 资源包的核心需求分析
你在做树莓派上的目标检测时，真正卡住你的往往不是算法本身，而是下面这几个问题：
推理框架选哪个。NCNN、OpenCV DNN、TensorFlow Lite、ONNX Runtime，四个主流框架我都试过。实测下来，NCNN在树莓派4B的CPU上速度最快，尤其是对ARM架构做了NEON指令集优化，比OpenCV DNN快将近一倍。TFLite虽然生态好，但对YOLOv5-Lite这类非标准结构的支持不够灵活。
模型怎么转换。PyTorch训练出来的模型是.pt格式，不能直接在树莓派上用，需要经过导出、简化、量化等步骤。中间任何一个环节出错，最后的推理结果就是一堆乱框。
NPU和CPU的分工问题。树莓派4B没有独立的NPU（神经网络处理单元），所有的推理只能靠CPU。这就意味着你不能用那些给华为昇腾、瑞芯微RKNN准备的优化方案，得老老实实做CPU推理的优化。
前后处理的耗时。很多人只盯着模型推理时间，忽略了一个事实：图像缩放、归一化、置信度过滤、NMS这些前后处理操作，在树莓派上也要占用不少CPU时间。我实测过，如果代码写得不够高效，前后处理的时间甚至能占到总耗时的40%。
这套资源包解决的就是这些工程层面的问题，让你直接拿到一份“能跑、能改、能部署”的完整方案，而不是从零开始一遍遍踩坑。
1.2 目标检测训练中的评价标准
既然要做到目标检测，就绕不开模型性能评价的问题。树莓派上部署的模型，评价维度和服务器端不完全一样，我建议你重点关注这么几个指标：
mAP（mean Average Precision）：衡量模型检测精度的核心指标，通常看mAP@0.5和mAP@0.5:0.95两个数值。前者是IoU阈值0.5时的平均精度，后者是多个IoU阈值下的平均值，要求更苛刻。YOLOv5-Lite在COCO数据集上的mAP@0.5大约在40-45之间，在自建数据集上这个数值取决于你的数据质量。
Precision（精确率）和Recall（召回率）：精确率衡量的是“模型认为是目标的样本中有多少是对的”，召回率衡量的是“所有真实目标中有多少被找出来了”。在实际的边缘端场景中，这两个指标往往是矛盾的，需要根据具体业务做取舍。比如做安全帽检测，漏检一个安全帽（低召回率）比误报一个（低精确率）后果严重得多。
FPS（每秒处理帧数）：这是边缘部署最关键的指标。同样的模型，在服务器上跑100FPS没有意义，在树莓派上跑到10FPS以上才有实用价值。
模型大小和内存占用：树莓派4B的内存有限，模型文件过大会导致加载慢、推理卡顿。我建议模型文件控制在5MB以内（fp16精度），内存占用控制在500MB以内。
用这些指标去衡量，YOLOv5-Lite在树莓派4B上属于“精度够用、速度优秀”的平衡方案。如果你需要更高的精度，可以考虑在PC上做模型蒸馏，然后把蒸馏后的小模型部署到树莓派上，这是后话。
2. 资源包内容拆解：从文件结构到核心代码模块
我在整理资源包的时候，刻意按照“拿到就能跑”的标准去组织文件结构。下面是我最终采用的目录结构，你可以直接参考：
raspberry-yolov5-lite/ ├── weights/ │ ├── yolov5_lite_v2.voc.opt.fp16.bin # 转换完成的NCNN模型权重 │ ├── yolov5_lite_v2.voc.opt.param # NCNN模型结构描述文件 │ └── classes.txt # 类别标签文件 ├── models/ │ ├── common.py # YOLOv5-Lite通用模块定义 │ ├── yolo.py # 检测模型结构定义 │ └── export.py # PyTorch模型转ONNX脚本 ├── convert/ │ ├── onnx2ncnn.py # ONNX转NCNN工具 │ ├── simplify_model.py # 模型结构简化脚本 │ └── quantize.py # INT8量化脚本 ├── deploy/ │ ├── yolov5_lite_ncnn.py # NCNN推理主程序 │ ├── camera_stream.py # 摄像头实时检测demo │ ├── image_detect.py # 单张图片检测demo │ └── video_detect.py # 视频文件检测demo ├── utils/ │ ├── config.py # 全局配置参数 │ ├── visualization.py # 检测结果可视化 │ └── metrics.py # mAP等指标计算 ├── requirements.txt # Python依赖清单 ├── install_ncnn.sh # NCNN环境一键安装脚本 └── README.md # 详细部署文档2.1 模型文件的选择逻辑
资源包里默认提供的是基于VOC数据集的YOLOv5-Lite预训练权重，包含20个类别（人、自行车、汽车、猫、狗等常见物体）。这个选择是有讲究的：VOC数据集是目标检测领域最经典的基准数据集，类别覆盖了日常监控场景的大部分目标，而且模型文件转换后的NCNN格式只有约4MB，非常适合树莓派部署。
如果你需要检测特定目标（比如安全帽、口罩、施工人员），放心，资源包里提供了完整的模型训练和转换流程。你可以先在PC上用PyTorch训练自己的数据集，然后按照convert目录下的脚本一步步转成NCNN格式，过程我后面会详细讲。
类别标签文件classes.txt的内容就是这20个类别的名称，在推理的时候，NCNN输出的索引会对应到这里的类别名称。如果你换了自己的模型，记得同步替换这个文件。
2.2 推理代码的核心设计
deploy目录下的推理程序，核心逻辑是用NCNN的Python接口加载模型，对输入帧进行处理，然后输出检测结果。其中yolov5_lite_ncnn.py是整个部署的核心模块，我挑几个关键设计点说一下：
图像预处理。输入图像会先做letterbox处理，保持原始宽高比缩放到640×640，多余部分用灰色填充。这样做的好处是避免目标被拉伸变形，检测精度更高。在资源包里我用的填充值是114，这是YOLOv5官方训练时使用的填充色，我实测过这个值对检测效果有细微影响，不要随意更改。
推理线程设置。树莓派4B是四核CPU，NCNN推理时建议设置num_threads=4，充分利用多核性能。资源包默认开了4线程，如果你同时跑其他任务导致CPU过载，可以适当调低到2或3。
输出解析。NCNN输出的原始数据是一个三维张量，需要经过解码才能得到目标的bbox坐标、置信度和类别信息。这个解码过程是我调试时间最长的地方，因为不同版本的YOLOv5输出格式存在差异。资源包里已经按YOLOv5-Lite v2的输出格式写好了，直接沿用即可。
NMS后处理。目标检测必须做非极大值抑制，否则同一个目标会被输出多个重叠框。我用的是OpenCV的NMSBoxes函数，在树莓派上运行效率还不错。这里有个细节：NMS的IoU阈值默认设为0.45，置信度阈值设为0.25。如果检测结果中漏检较多，可以适当调低置信度阈值；如果误检较多，就调高置信度阈值。
3. 实操过程：从环境搭建到模型转换再到部署推理
下面进入到实操环节。我会按照“环境准备→PC端模型转换→树莓派部署”的顺序，把每一个关键步骤、踩过的坑和优化经验都写清楚。
3.1 树莓派4B系统与依赖环境准备
系统方面推荐使用Raspberry Pi OS（64位），基于Debian Bullseye版本。我之前在32位系统上折腾过，NCNN的NEON优化在64位下才能充分发挥作用，编译出来的推理速度可以提升20%以上。
系统装好后，先执行系统更新：
sudo apt update && sudo apt upgrade -y然后安装编译工具链和依赖库：
sudo apt install -y build-essential cmake git python3-pip sudo apt install -y libopencv-dev python3-opencv sudo apt install -y protobuf-compiler libprotobuf-dev这里有个容易踩坑的地方：不要用apt直接安装NCNN库，apt源里的NCNN版本太老，不支持最新的模型结构。正确做法是从源码编译，资源包里提供了一键安装脚本install_ncnn.sh，核心步骤如下：
git clone https://github.com/Tencent/ncnn.git cd ncnn mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release \ -DNCNN_VULKAN=OFF \ -DNCNN_BUILD_EXAMPLES=ON \ -DNCNN_PYTHON=ON .. make -j4 sudo make install注意编译参数：NCNN_VULKAN=OFF是关闭GPU加速，树莓派4B的GPU不支持Vulkan API，开了反而会报错。NCNN_PYTHON=ON会生成Python接口，部署时直接用Python调用比C++快多了。
编译时间大约需要40分钟到一个小时，取决于你使用的是4GB还是8GB内存版本，内存小了编译时有可能卡死，建议加swap空间：
sudo dphys-swapfile swapoff sudo nano /etc/dphys-swapfile # 将 CONF_SWAPSIZE 改为 2048 sudo dphys-swapfile setup sudo dphys-swapfile swapon3.2 PC端模型导出与NCNN转换流程
在PC上完成模型转换是最稳妥的流程。首先克隆YOLOv5-Lite源码仓库：
git clone https://github.com/ppogg/YOLOv5-Lite cd YOLOv5-Lite将训练好的.pt权重文件放到weights目录下，执行导出ONNX的脚本：
python models/export.py --weights weights/yolov5_lite_v2.voc.pt --img-size 640 --batch-size 1导出后得到yolov5_lite_v2.voc.onnx文件。下一步是用ONNX Simplifier简化模型结构，去掉一些冗余的计算节点：
python -m onnxsim yolov5_lite_v2.voc.onnx yolov5_lite_v2.voc.sim.onnx简化的意义在于：PyTorch导出的ONNX中经常有一些不影响结果的恒等映射和冗余算子，NCNN对这些算子支持不够好，简化后能避免很多莫名其妙的转换错误。
然后是ONNX转NCNN，这一步在PC上装NCNN环境后操作：
python convert/onnx2ncnn.py yolov5_lite_v2.voc.sim.onnx yolov5_lite_v2.voc.opt.param yolov5_lite_v2.voc.opt.bin这里特别强调：转换后一定要检查param文件末尾是否有维度变化的层。YOLOv5-Lite的检测头有两个输出分支，NCNN解析这些分支时偶尔会丢失维度信息。正确的情况是在param文件中能看到两个Reshape层，分别对应不同尺寸的特征图。如果看不到，你就需要手动在param文件的末尾补上这两行：
Reshape -1 0 1 1 = 0 1 1 1 1这个坑我当初卡了整整两天，最后是在NCNN的GitHub Issues里翻到一个日本开发者的回答才解决的。
3.3 树莓派上的模型部署与推理测试
把转换后的.param和.bin文件拷贝到树莓派的weights目录下，先跑一张图片测试流程是否畅通：
python deploy/image_detect.py --image test.jpg如果一切正常，你会看到终端输出检测到的目标类别、置信度和坐标，同时生成一张画有检测框的图片。我之前第一次成功运行时，看到屏幕上出现“person 0.87”的输出，那种成就感真的很强烈。
接下来测试摄像头实时检测。树莓派官方摄像头模块和USB摄像头我都试过，官方CSI接口的摄像头延迟更低，但需要执行sudo raspi-config开启Camera接口。USB摄像头即插即用，方便一些：
python deploy/camera_stream.py --camera 0实测结果：分辨率设为640×480，用NCNN四线程推理，YOLOv5-Lite的模型推理耗时约70ms，加上图像采集和前处理，整体FPS在13-15之间。CPU占用率在80%左右，树莓派4B的散热片温度会升到60摄氏度左右，建议加一个小风扇或散热片。
3.4 性能优化：量化与线程调优
如果你对15FPS还不满足，可以做两件事进一步优化。
INT8量化。用resource包里的量化脚本，将模型从FP32精度变成INT8精度。量化后模型大小可以压缩到约1.5MB，推理速度提升30%以上，但精度会有一定损失，表现为部分小目标检测不到。我实测下来，在VOC数据集上mAP大约下降5-8个点，对于实时性要求高的场景是可以接受的。
线程数和使用率调优。NCNN的num_threads参数不一定越大越好。树莓派4B虽然是四核CPU，但如果你的程序还有其他线程（比如视频采集线程、显示线程），线程数设置过大会导致CPU资源争抢，反而降低整体效率。我建议分场景测试，资源包默认4线程，如果你的程序比较重，可以尝试2线程配OpenMP并行，实测下来整体FPS不降反升。
4. 常见问题与排查技巧实录
整理了我在开发和调试过程中遇到的高频问题，直接以表格形式呈现，方便你对照排查。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 检测框严重偏斜、位置不对 | 模型输入尺寸与预处理尺寸不一致 | 检查letterbox代码，确认resize和padding的尺寸是640×640 |
| 摄像头画面卡顿严重 | 视频采集线程和推理线程冲突 | 使用多线程队列，采集和推理分离，设置frame buffer为1-2帧 |
| 编译NCNN时报错找不到protobuf | 依赖没有装全 | 重新执行sudo apt install protobuf-compiler libprotobuf-dev |
| 推理结果全为空 | 置信度阈值设置过高 | 将阈值从0.25调低到0.1测试，如果能看到框说明是阈值问题 |
| 模型转换后推理报错 | ONNX简化或转换过程中丢失了维度信息 | 检查param文件中检测层的Reshape配置 |
| 运行内存溢出 | 模型文件过大或图片尺寸设置过高 | 降低输入尺寸到320×320，或者改用INT8量化模型 |
| 检测速度只有5FPS左右 | 没有启用多线程推理 | 将NCNN的num_threads设为4，确认编译时开启了OPENMP |
4.1 容易忽略的细节问题
除了上面的表格，再分享几个我在实际操作中踩过的坑：
模型加载路径问题。很多人喜欢把param和bin文件放在项目根目录，然后直接用相对路径加载。这在PC上没问题，但在树莓派的systemd自启动服务中，工作目录可能和你预想的不一样，会导致模型加载失败。建议Always使用绝对路径，或者先os.chdir()切换到项目目录。
中文路径问题。如果模型文件路径包含中文，部分版本的NCNN会在加载时直接崩溃。这个坑比较隐蔽，因为报错信息并不直观，我只在客户的实际部署环境里遇到过。建议项目所有路径都用英文。
摄像头初始化失败。树莓派上如果同时接了CSI摄像头和USB摄像头，OpenCV的默认索引可能会指向错误的设备。可以用ls /dev/video*查看设备节点，然后显式指定video index。
功耗和散热问题。树莓派4B满负荷运行目标检测时，电流需求会达到2.5A以上。劣质的电源适配器会导致电压下降，系统自动降频，检测速度会骤降。我用的是官方5V/3A电源，确保供电稳定。散热方面，不要省这点钱，一个几十块的铝制散热壳加风扇能把温度控制在50度以内。
4.2 资源包使用建议
最后就资源包的使用场景给一些个人建议：
第一，先用默认模型跑通全流程，确认环境没问题之后，再开始训练自己的数据集。不要一上来就换模型，否则出了问题你很难判断是转换问题还是代码问题。
第二，不要盲目追求高精度。在树莓派这种边缘设备上，精度和速度永远是矛盾的。我在做一个工厂安全监测项目时，客户要求检测工人是否佩戴安全帽，VOC模型原本不包含这个类别，后来我训练了只包含“安全帽”和“人”两个类别的专属模型，mAP达到了90%以上，检测速度反而比20类的VOC模型更快，因为需要分类的类别少了，推理和NMS计算量都下降了。
第三，善用日志输出。我在这套资源里加了很多调试日志，正常运行时可以通过--debug参数控制是否输出每一帧的详细耗时信息。排查性能瓶颈时非常有用，建议你保留这些日志代码，不要删掉。
最后分享一个小技巧：在树莓派上做多路视频流检测时，不要为每一路单独创建推理线程，这样CPU会迅速耗尽。更合理的做法是创建一个独立的推理进程，多个视频源通过共享队列把帧送进来，推理进程按顺序处理。我用这个方法在树莓派4B上同时处理两路720p的视频流，整体FPS还能维持在8-10帧，实用价值很高。如果你也想扩展类似功能，这算是一个既简单又有效的方向。
本文还有配套的精品资源，点击获取
