【前言】 由于v5Lite仓库遗漏了不少历史问题，最大的问题是毕业后卷起来了，找不到时间更新。 上面是这篇博客的背景，那么先说下结论，使用 v5lite-e 模型，在 树莓派4B（4G内存） 上，有三种过程得到的三种结果：

那么接下来怎么做？Follow me

这个是老生常谈的问题了，在很早之前就已经提示过网友这个细节： http://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2020-08-24/

https://link.zhihu.com/?target=https%3A//shumeipai.nxez.com/download%23os

上一为老版，下一为新版，链接共包含64位 AArch64 架构、相关 A64 指令集的ARMv8-A架构集成的64位系统，求稳请使用老版，追求性能请使用新版，本文默认使用老版64位系统。

至于怎么刷系统，网上教程太多了，这里不展开篇幅。

没错，这篇博客使用的推理框架是阿里的MNN（本文使用2.7.0版本），正常编译的话，网上已经有非常多的教程了，但是好巧不巧，今天我们的主角是树莓派，只能好好折腾一下。

由于在博主的树莓派只有4G的运行内存，资源比较紧张，如果追求快，板上就肯定上不了fp32的模型，因此只能使用fp16或者bf16进行推理，这时候我们翻找源码中的CMakeLists，有这么两个参数，叫做MNN_SUPPORT_BF16及MNN_ARM82，这两个构建选项很关键，众所周知树莓派4B是基于ARMv8的架构，为了发挥其计算优势，博主刷上了aarch64的系统，这个时候使用bf16的半精度推理方式，无疑有极大的加成。

事不宜迟，我们开始编译推理需要的几个库，使用下面命令：

这个时候会报一个错，如下：

这是因为启动bf16进行构建时，源码的汇编指令嵌套过深，会导致编译时定义的宏无法展开，这个时候我们需要将指令集中所有关于FMAX和FMIN两个变量的嵌套调用展开，按照以下这种形式修改：

那么编译结束后，我们会使用到后面这三个动态库，一个是包含半精度运行方式的 libMNN.so，一个是进行图像处理的libMNNOpenCV.so，另一个是libMNNExpress.so.

这个时候，博主提供新的三种导出方式，具体哪种请根据自己的情况选择。

首先是第一种，自带ancher和grid匹配的方式，这是因为在群里经常被问到为什么检测框密密麻麻，有很大概率是后处理出了问题，为了规避这种情况，直接把anchor那些乱七八糟的东西给导出来，省去不必要的麻烦，如下：

接着是第二种，一种伪造end2end的导出模式，但实际上这种还是和end2end有一定区别，mnn暂未提供类似torchvison.nms处理张量后返回索引id的算子（官方有nms_，和本文想要的又有点不同），因为在这里只能精简下大家常用的end2end方式，将输出头的shape锁死，这样就可以正常导出mnn模型，如下：

最后是第三种，这种就是大家常用的end2end方式了，非常简单，网上也有一堆可以抄的代码，但这种目前支持的三方推理库较少，支持比较好的为onnxruntime，如下：

如果喜欢使用mnn推理，又是新手，建议使用第二种方式，但本文默认使用第一种。

这个真的要好好说一说，模型转化为onnx后又不验证下onnx是否能正常使用，精度和原模型对齐没，等使用三方推理框架部署上去后发现有问题，又觉得三方框架转化的模型无误，容易让一些新人陷入自我怀疑的死胡同~

以第一种方式为例，转化onnx的指令如下：

得到.onnx文件后用onnxsim刷一遍，抖掉胶水：

同理，其他模型也是这么操作，mnnd方式导出的模型检测头如下：

mnne方式带出的模型检测头如下：

得到转化后的onnx模型，我们验证下导出来的精度对齐没，使用验证脚本直接 python check.py

得到的对比结果如下： 左为原pt模型，右为导出的onnx模型，这时候就可以保证onnx确实没有问题。

三方库转化需要使用到 MNNConvert 工具，只要前面处理好了，这里基本都是一步过，在此之前我们先验证下onnx有没有官方不支持的算子：

如果没报错，那就下一步，开始转化：

讲几个比较重要的参数：

转fp16模型，只需要在后面加上 –fp16 标识符 转化后的mnn模型检测头如下： 转成int8量化模型的话，稍微要久一些，如下：

该过程大约需要10分钟，如果转成功了，会输出以下结果：

总体而言，int8量化的结果还是很不错的，每层网络fp32和int8的余弦距离基本都在99%左右。

转化结束后，所有模型大小如下：

如果对模型体积有精神洁癖，又不在乎那几个点的损失，强烈推荐使用int8模型，才900多k，在armv8上推理也比fp16的模型快17%左右。

这里真没啥好讲的，友友们看我提供在仓库里面的代码即可，这里简单挑两个细节说说就行，一个是mnnd的nms方式，是不用进行anchor配齐和grid匹配等操作，因为导出就已经处理掉了。

另一个是mnne的nms方式，这个更狠，每行张量的最后一个元素就是我们需要的class_id，很适合那些刚入门又不太想花时间去折腾C++的友友们。

展示下mnnd的推理耗时和结果，首先是静态图的方式：

咦… 等等，貌似有点不太对劲，精度不对啊，咋回事？

这个时候我们又要排查一圈，好在我们已经确定onnx模型是正确的，那问题出在哪？

找了几分钟，原来出在了 backendConfig.precision 这个参数上，我们重新翻回官方的指导手册，看到如下解释：

如果我们要使用回正常的精度，这时候就需要更改这个参数：

实测使用全精度后，在树莓派推理静态图片只有12帧，但使用半精度后，基本每个obj的score都降低了2-6个百分点，那如果我们又想快，又想保证精度，咋办？

这时候我们可以在box.score这里做一些骚操作：

此时得到一系列的对比如下：

为啥是这样？别问，照做就行了，你个小憨憨… 以上帧率计算包括了【图解码，前处理，向前推理，后处理，图保存】这五个过程，而并不是简单的向前推理。

接着是调用摄像头，带窗口显示的推理方式： 可以看到还是能勉强满足实时性的要求，帧率计算包括了【取帧，帧解码，前处理，向前推理，后处理，窗口显示】这六个过程。

以上测试数据均为预热三分钟后的结果！

官方手册：常见问题与解答 - MNN-Doc 2.1.1 documentatio

具体问题具体分析，举个例子，去年毕设中遇到这么一个业务场景，需要检测电梯中的电动车，那既然是电梯内，一般都属于大尺度目标，近距离场景的检测，这样我们可以把小尺度目标的feature进行cell skip，如下： 也就是对于小尺度的feature，我不需要每个cell都去预测，毕竟目标这么大，总有一些不长眼的cell采坑，为了降低计算量，每隔一个cell我才预测一次，但是这样的加速方法就是在赌你的枪有没有子弹，燕大侠看了都摇头，对于小尺度和遮挡严重的场景不适用，因此没有放入仓库中，伪代码如下：