1. 项目概述与核心价值最近在折腾一块飞凌嵌入式的OKMX8MM-C开发板核心是NXP的i.MX8MMini处理器。这板子性能不错四核Cortex-A53加上一个Cortex-M4还有独立的GPU和NPU拿来玩嵌入式AI应用正合适。我这次的目标很明确就是要在这块Arm64平台上把OPEN AI LAB开源的Tengine推理框架给跑起来试试看它的图像识别能力到底如何。Tengine这东西在嵌入式圈子里口碑挺好它最大的优势就是不挑食你板子上有NPU或者GPU它能调用这些硬件加速单元来跑模型算力直接起飞就算只有通用的CPU它也能通过一系列深度优化把CPU的算力榨干让AI模型跑得比用其他通用框架快不少。对于像我们这种经常在各种不同配置的嵌入式设备上部署AI功能的开发者来说这种灵活性太重要了。这次体验我会从零开始记录在OKMX8MM-C上搭建Tengine环境、编译源码、运行测试的完整过程。重点不只是“怎么做”更会深入聊聊“为什么这么做”比如编译选项的取舍、模型选择背后的考量以及在实际运行中遇到的各种“坑”和解决思路。无论你是刚接触嵌入式AI的新手还是想寻找一个高效、轻量级推理框架的资深工程师相信这篇从一线实战中总结出来的记录都能给你提供直接的参考和启发。2. 开发环境搭建与系统选择2.1 硬件平台与系统选型考量我手头的这块OKMX8MM-C开发板核心是NXP i.MX8MMini应用处理器。这颗芯片的配置对于嵌入式AI应用来说算是“小康水平”4个主频最高1.8GHz的Cortex-A53核心负责通用计算和复杂逻辑1个Cortex-M4核心可以处理实时任务此外还集成了Vivante GC7000Lite GPU和Cadence Tensilica HiFi 4 DSP可作为NPU使用。这样的硬件基础运行轻量级神经网络推理是绰绰有余的。原厂通常会提供基于Yocto项目构建的Linux BSP板级支持包这套系统稳定、驱动完善但有时候软件包版本比较旧搭建一些最新的开发环境可能需要自己从头编译很多依赖库过程会比较繁琐。为了更快速地切入Tengine的试用我决定先采用一个更“通用”的Linux环境。我选择移植了Armbian系统具体是**Debian 10Buster**版本。Armbian社区为大量Arm开发板提供了高度优化和预配置的Debian/Ubuntu镜像其优势非常明显丰富的软件源直接使用Debian庞大的apt软件仓库安装编译工具链、开发库如OpenCV、Protobuf几乎是一行命令的事省去了交叉编译或手动编译依赖的麻烦。主线内核支持我使用的这个Armbian版本其U-Boot和Linux Kernel都是mainline上游主线的。这意味着它包含了最新的特性和安全补丁并且对像Tengine这类开源项目的兼容性通常更好。虽然某些板载外设的驱动可能不如原厂BSP完善但对于我们核心的AI推理测试来说CPU、内存、存储这些基础组件运行正常就足够了。开发友好系统开箱即用具备完整的编译环境gcc, make, cmake等我们可以直接在板卡上进行本地编译Native Build这比交叉编译要直观和简单得多尤其适合快速原型验证。注意选择主线系统还是原厂BSP取决于项目阶段。如果是产品原型验证、算法快速迭代Armbian这类系统效率更高。如果进入产品化阶段需要更严格的硬件稳定性、功耗控制和所有外设驱动支持那么基于原厂BSP进行定制化裁剪是更稳妥的选择。2.2 基础开发环境配置系统刷写并启动后首先需要更新软件源并安装一些基础工具和Tengine编译所必需的依赖库。通过SSH登录到开发板执行以下命令# 更新软件包列表 sudo apt update sudo apt upgrade -y # 安装基础开发工具 sudo apt install -y build-essential cmake git wget # 安装Tengine编译依赖 sudo apt install -y libprotobuf-dev protobuf-compiler libopencv-dev pkg-config这里解释一下几个关键依赖包的作用libprotobuf-dev protobuf-compilerProtocol Buffers是Google开源的一种数据序列化工具。许多AI模型尤其是Caffe框架的模型会使用.prototxt文件定义网络结构Tengine需要这些库来解析和加载此类模型。libopencv-devOpenCV计算机视觉库。Tengine的许多示例程序Example涉及图像加载、预处理如缩放、颜色空间转换和后处理如画检测框都需要调用OpenCV的函数。pkg-config一个帮助在编译时查找库文件路径和头文件路径的工具。在编译一些复杂的项目时它能自动为编译器提供正确的-I和-l参数。安装完成后建议重启一次系统确保所有新安装的库文件路径都被正确加载到系统环境中。3. Tengine源码编译与关键配置解析3.1 获取源码与目录结构初探Tengine的源码托管在GitHub上OPEN AI LAB维护得比较活跃。使用git命令克隆仓库这里有一个必须注意的关键参数git clone --recurse-submodules https://github.com/OAID/tengine.git cd tengine为什么一定要加--recurse-submodulesTengine项目使用Git子模块Submodule来管理一些第三方依赖库比如用于模型序列化/反序列化的组件。如果不加这个参数你克隆下来的主仓库里这些子模块目录是空的。在后续编译链接阶段就会因为找不到对应的源码或头文件而失败。错误信息可能类似fatal error: xxx.h: No such file or directory。所以这个参数确保了所有依赖的代码都被一次性完整下载。下载完成后可以浏览一下主要目录结构这对理解编译过程有帮助benchmark/: 性能基准测试程序源码。examples/: 丰富的示例程序如目标检测、人脸识别等是我们主要的测试对象。source/: Tengine引擎的核心源码。default_config/: 针对不同平台ARM64, ARM32, x86的默认编译配置文件。models/: 存放神经网络模型文件的目录需自行下载放入。3.2 编译配置的修改与深层原因Tengine使用一个基于Kconfig的配置系统。对于我们的平台ARM64 Linux模板配置文件是default_config/arm64_linux_native.config。在编译前我们需要根据实际情况修改它。使用文本编辑器打开该文件vim default_config/arm64_linux_native.config找到其中关于序列化器Serializer的配置项。你可能会看到类似下面的行# CONFIG_BUILD_SERIALIZER is not set或者CONFIG_BUILD_SERIALIZERn必须将其修改为CONFIG_BUILD_SERIALIZERy这个配置项至关重要它决定了是否编译模型格式转换相关的模块。Tengine支持加载多种格式的模型如Caffe、ONNX、TensorFlow等。这些模型通常不能直接被Tengine的推理引擎使用需要一个“序列化器”将其转换为Tengine内部的格式TMfile。如果我们不编译这些序列化器即设置为n那么在运行示例程序时当尝试加载一个.caffemodel或.prototxt文件时程序会因找不到对应的动态链接库如libcaffe-serializer.so而崩溃报错信息正是Shared library not found: libcaffe-serializer.so: cannot open shared object file: No such file or directory因此除非你百分百确定只使用Tengine原生格式.tmfile的模型否则请务必打开此选项。本次测试中下载的官方模型多为Caffe格式所以必须开启。3.3 执行编译与产物分析配置修改保存后在Tengine源码的根目录下执行编译脚本./linux_build.sh default_config/arm64_linux_native.config这个脚本会自动完成配置加载、依赖检查、编译和链接全过程。编译时间取决于i.MX8MMini的性能大约需要10-20分钟。编译成功后最重要的产出在build目录下build/install/lib/: 这里存放着编译生成的Tengine核心库文件libtengine-lite.so以及各个序列化器插件库libcaffe-serializer.so,libonnx-serializer.so等。部署时这些库需要被放置到系统的动态库路径如/usr/lib下或者通过LD_LIBRARY_PATH环境变量指定。build/benchmark/bin/: 生成的两个基准测试可执行文件bench_sqz和bench_mobilenet。它们不依赖外部模型文件内置了小型网络用于快速验证Tengine库是否被正确编译和链接。build/examples/: 示例程序的生成目录此时还是空的因为examples需要单独编译。我们可以立即运行基准测试来做个简单验证cd build/benchmark/bin/ ./bench_sqz ./bench_mobilenet如果看到程序正常运行并输出一系列层的计算时间如conv1 time: 5.21 ms和总耗时、总吞吐量如Total time: 25.34 ms, 39.46 FPS就说明Tengine核心库的编译是成功的并且能在当前硬件上正常进行推理计算。4. 模型准备与示例程序编译实战4.1 获取与放置模型文件神经网络模型是AI应用的“大脑”。Tengine的示例程序需要加载对应的模型文件才能工作。OPEN AI LAB提供了一个百度网盘链接里面包含了多种预训练好的模型Caffe格式。链接和提取码通常在项目的README或Wiki中能找到例如链接: https://pan.baidu.com/s/1Ar9334MPeIV1eq4pM1eI-Q 提取码: hhgc。由于全部模型文件体积很大可能超过1GB建议根据你打算测试的示例程序选择性下载。例如如果你只想测试mobilenet_ssd和mtcnn那么就下载对应的mobilenetssd.caffemodel、mobilenetssd.prototxt以及mtcnn相关的模型文件。下载完成后必须将这些模型文件通常是.caffemodel和.prototxt成对出现放置到Tengine源码根目录下的models文件夹中。这是示例程序默认寻找模型的路径。如果models文件夹不存在就创建一个。实操心得网盘下载的模型文件在Linux下可能需要解决解压和文件名编码问题。有时压缩包内是中文目录名解压后可能会乱码。建议在Windows或Mac上下载解压后通过SFTP工具如FileZilla上传到开发板的指定目录这样最省事。4.2 示例程序的独立编译Tengine的主编译脚本默认不会编译examples目录下的示例程序。我们需要进入examples目录进行单独编译。但在编译前有一个关键步骤配置Tengine的路径。修改编译配置进入examples目录找到linux_build.sh脚本注意这是examples目录下的不是根目录的那个。用编辑器打开找到设置TENGINE_ROOT路径的地方。默认可能是TENGINE_ROOT../这假设examples和tengine根目录是平级的。但在我们的编译结构中build目录在根目录下。更稳妥的做法是使用绝对路径。例如我的Tengine源码放在/root/tengine那么就修改为TENGINE_ROOT/root/tengine确保这个路径指向你克隆的Tengine源码的根目录里面应包含source,build等文件夹。执行编译在examples目录下执行以下命令mkdir build cd build ../linux_build.sh make -j4../linux_build.sh会调用CMake生成Makefilemake -j4则启动编译-j4表示用4个并行任务加快编译速度数字可调整为你的CPU核心数。编译成功后在examples/build/目录下就会生成一系列可执行文件例如faster_rcnnlighten_cnnmobilenet_ssdmtcnnssdyolov2YuFaceDetectNet这些就是我们接下来要进行测试的AI应用Demo。5. 主流目标检测模型实测与性能对比一切准备就绪现在可以开始激动人心的模型测试环节了。我会选择几个有代表性的目标检测模型使用相同的图片或各有侧重的图片来直观感受不同算法的效果和性能差异。测试前请确保终端当前工作目录在examples/build/下并且models文件夹里已经放置了对应的模型文件。5.1 Faster R-CNN高精度代表Faster R-CNN是两阶段Two-Stage检测器的经典之作。它先由区域提议网络RPN生成可能包含物体的候选框Region Proposals再对这些候选框进行分类和精确位置回归。这种结构通常精度很高但速度相对较慢。我们使用Tengine示例中自带的测试图片ssd_dog.jpg一般位于examples/build/images/或源码其他目录如果找不到可以自己准备一张包含狗、自行车、汽车的图片并指定路径。运行命令./faster_rcnn -m ../models/faster_rcnn.prototxt -w ../models/faster_rcnn.caffemodel -i /path/to/your/ssd_dog.jpg-m: 指定模型结构文件.prototxt-w: 指定模型权重文件.caffemodel-i: 指定输入图片路径程序运行后会在当前目录生成一张名为save.jpg的结果图。在我的测试中Faster R-CNN成功检测出了图片中的狗Dog、自行车Bicycle和汽车Car并用方框和标签进行了标注。作为精度标杆它的检测结果非常准确。性能观察在i.MX8MMini的CPU上运行未启用GPU/NPU加速处理单张图片耗时大约在1.5秒到2.5秒之间。这对于实时性要求不高的静态图片分析场景是可以接受的但显然无法满足视频流实时检测的需求。5.2 YOLOv2 与 SSD速度与精度的权衡YOLOv2和SSD都是单阶段One-Stage检测器的杰出代表。它们将目标检测视为一个统一的回归问题直接从图像像素到边界框坐标和类别概率因此速度通常比两阶段方法快一个数量级。YOLOv2测试使用与Faster R-CNN相同的图片。./yolov2 -m ../models/yolov2.prototxt -w ../models/yolov2.caffemodel -i /path/to/ssd_dog.jpg从输出结果看YOLOv2同样准确地检测到了狗、自行车和汽车。关键的数据来了其推理时间大约在300毫秒左右。相比Faster R-CNN的2秒速度提升了近6倍而精度肉眼观察几乎没有损失。这完美体现了单阶段检测器的速度优势。SSD测试我们换一张更复杂的图片例如包含多人、狗的街景来测试SSD。./ssd -m ../models/ssd.prototxt -w ../models/ssd.caffemodel -i /path/to/street_scene.jpgSSD的检测速度也很快与YOLOv2处于同一量级几百毫秒。但在我的某次测试中SSD模型将一只狗误识别成了“猫”。这说明了不同模型在不同数据集上训练后存在的特性差异。SSD这里指基于VGG的原始SSD对小目标的检测能力有时会弱于YOLOv2或后续改进版本。5.3 MobileNet-SSD为嵌入式而生MobileNet-SSD是SSD框架与MobileNet轻量级骨干网络Backbone的结合。MobileNet使用深度可分离卷积Depthwise Separable Convolution大幅减少了计算量和参数量专为移动和嵌入式设备设计。使用与测试SSD相同的街景图片./mobilenet_ssd -m ../models/mobilenetssd.prototxt -w ../models/mobilenetssd.caffemodel -i /path/to/street_scene.jpg结果很有意思之前被SSD误认的狗这次被MobileNet-SSD正确识别了。但是图片远处一个较小的人影却被漏检了。这反映了轻量化模型普遍面临的挑战在追求速度和低功耗的同时不可避免地会牺牲一部分精度尤其是对小目标和复杂场景的感知能力。速度对比MobileNet-SSD的推理时间大约在150-200毫秒比原始的SSD和YOLOv2又快了一倍左右。这个速度在i.MX8MMini上已经接近实时5-6 FPS如果后续能启用板载的NPU进行硬件加速达到20-30 FPS的实时检测是完全可期的。5.4 人脸检测专项测试YuFaceDetectNet vs MTCNN最后我们聚焦人脸检测这个垂直任务对比两个知名模型。YuFaceDetectNet这是深圳大学于仕琪老师开源的高性能人脸检测库libfacedetection的Tengine移植版。它以速度极快而闻名。./YuFaceDetectNet -i /path/to/group_photo.jpgMTCNN一个经典的多任务级联人脸检测框架通过三个级联网络P-Net, R-Net, O-Net逐步细化检测框精度非常高。./mtcnn -i /path/to/group_photo.jpg使用一张包含多张人脸的合影进行测试。两个模型都成功检测出了画面中的五张人脸。精度MTCNN在脸部关键点如眼睛、鼻子、嘴角的定位上通常更精细。速度在我的测试中YuFaceDetectNet的处理时间约为120毫秒而MTCNN约为180毫秒。YuFaceDetectNet确实更快但MTCNN的速度也完全可接受两者差距并不像目标检测模型中Faster R-CNN和YOLO那样悬殊。对于嵌入式人脸门禁、考勤机等应用这两个模型都是优秀的选择可以根据对精度和速度的侧重点来挑选。6. 常见问题排查与性能优化思路在实际部署和测试过程中你几乎一定会遇到各种问题。下面是我踩过的一些“坑”以及解决方案希望能帮你节省时间。6.1 编译与运行时的典型错误问题现象可能原因解决方案git clone后子目录为空编译时找不到头文件克隆时未使用--recurse-submodules参数重新克隆或进入仓库后执行git submodule update --init --recursive编译时提示fatal error: opencv2/opencv.hpp: No such file or directoryOpenCV开发包未安装或pkg-config未找到运行sudo apt install libopencv-dev。如果已安装尝试手动指定路径或在CMakeLists.txt中正确设置OpenCV_DIR运行示例程序时崩溃报错error while loading shared libraries: libtengine-lite.so: cannot open shared object file系统动态链接器找不到Tengine库将build/install/lib/路径加入LD_LIBRARY_PATHexport LD_LIBRARY_PATH/path/to/tengine/build/install/lib:$LD_LIBRARY_PATH。更持久的方法是将该路径加入/etc/ld.so.conf或创建.conf文件到/etc/ld.so.conf.d/然后运行sudo ldconfig运行程序时提示Shared library not found: libcaffe-serializer.so编译时未开启BUILD_SERIALIZER选项确保在arm64_linux_native.config中设置CONFIG_BUILD_SERIALIZERy并重新编译整个Tengine加载模型时卡住或报模型格式错误模型文件损坏或模型与程序不匹配或模型路径错误1. 检查模型文件MD5是否与官方提供的一致。2. 确认使用的模型文件如mobilenetssd.caffemodel是否与程序mobilenet_ssd匹配。3. 使用绝对路径指定模型文件或确保程序在正确的相对路径下运行。检测结果完全错误或没有框模型输入尺寸与图片预处理方式不匹配不同的模型要求输入图片的尺寸和归一化方式如像素值范围是0-1还是0-255是否减去均值不同。需要查看示例程序的源码看它是如何对cv::Mat进行预处理的并确保你的输入图片经过相同的处理。6.2 在i.MX8MMini上提升推理性能的探索目前我们的测试都是在CPU上进行的。i.MX8MMini内置的GPU和NPU才是发挥其AI性能潜力的关键。Tengine支持通过Vulkan后端调用GPU以及通过TIM-VX后端调用NPU进行加速。GPU加速Vulkan前提Linux内核需要包含Vulkan驱动并且安装Vulkan SDK。编译在Tengine配置文件中需要开启CONFIG_ARCH_BLASy和Vulkan相关的选项。编译时会链接Vulkan库。运行在程序中需要显式指定使用Vulkan后端来创建推理引擎。性能提升因模型和驱动优化程度而异通常能有数倍的提升。NPU加速TIM-VX前提这是性能提升最显著的路径。需要NXP提供的专用NPU驱动和软件栈如libovxlib。原厂的Yocto BSP通常会包含这些组件。编译配置Tengine时开启TIM-VX支持并指向NPU驱动和库的路径。运行程序会自动将符合条件的算子如卷积、池化卸载到NPU上执行。对于MobileNet这类网络在NPU上运行的速度相比CPU可以有10倍以上的提升真正做到实时高清视频分析。重要提示在Armbian这类主线系统上启用NPU通常比较困难因为缺少官方的闭源驱动和固件。如果追求极致的AI性能建议切换回NXP官方或飞凌嵌入式提供的BSP系统并在其基础上按照Tengine和NXP的官方指南重新编译支持TIM-VX的Tengine库。这是一个进阶话题涉及更复杂的交叉编译和环境配置但也是将i.MX8MMini性能榨干的必经之路。6.3 模型优化与部署建议在嵌入式设备上部署AI模型永远要在精度、速度和资源消耗之间做权衡。模型选择优先考虑专为嵌入式设计的轻量级网络如MobileNet系列、ShuffleNet、EfficientNet-Lite等。Tengine对这类模型的支持和优化通常更好。模型量化将训练好的FP32浮点模型转换为INT8整数模型可以大幅减少模型体积和内存占用并提升推理速度许多NPU对INT8有硬件加速支持。Tengine提供了模型量化工具。使用Tengine模型格式将Caffe、ONNX等框架的模型通过Tengine提供的模型转换工具convert_tool预先转换为Tengine独有的.tmfile格式。这种格式经过了优化加载速度更快并且可以集成预处理/后处理信息简化部署代码。针对具体场景裁剪模型如果你的应用只检测特定几类物体如只识别人和车可以考虑对开源模型进行微调Fine-tuning和裁剪Pruning移除无关的类别输出层和冗余通道进一步缩小模型。这次在飞凌嵌入式OKMX8MM-C上基于Tengine的体验让我对嵌入式AI开发的流程和挑战有了更直观的认识。从系统选择、环境搭建到源码编译、模型测试每一步都需要清晰的思路和对细节的把控。i.MX8MMini的CPU性能已经足以流畅运行多种轻量级AI模型而它预留的GPU/NPU硬件加速能力则为更高要求的实时应用打开了大门。选择像Tengine这样兼顾性能、易用性和硬件适配性的推理框架能让我们更专注于应用逻辑本身而不是底层算子的调试和优化。如果你手头也有类似的Arm开发板不妨按照这个流程试一试亲手部署几个AI模型感受一下在资源受限的嵌入式设备上运行现代人工智能的神奇魅力。
在i.MX8MMini开发板上部署Tengine：嵌入式AI推理实战指南
发布时间：2026/6/7 12:30:06
1. 项目概述与核心价值最近在折腾一块飞凌嵌入式的OKMX8MM-C开发板核心是NXP的i.MX8MMini处理器。这板子性能不错四核Cortex-A53加上一个Cortex-M4还有独立的GPU和NPU拿来玩嵌入式AI应用正合适。我这次的目标很明确就是要在这块Arm64平台上把OPEN AI LAB开源的Tengine推理框架给跑起来试试看它的图像识别能力到底如何。Tengine这东西在嵌入式圈子里口碑挺好它最大的优势就是不挑食你板子上有NPU或者GPU它能调用这些硬件加速单元来跑模型算力直接起飞就算只有通用的CPU它也能通过一系列深度优化把CPU的算力榨干让AI模型跑得比用其他通用框架快不少。对于像我们这种经常在各种不同配置的嵌入式设备上部署AI功能的开发者来说这种灵活性太重要了。这次体验我会从零开始记录在OKMX8MM-C上搭建Tengine环境、编译源码、运行测试的完整过程。重点不只是“怎么做”更会深入聊聊“为什么这么做”比如编译选项的取舍、模型选择背后的考量以及在实际运行中遇到的各种“坑”和解决思路。无论你是刚接触嵌入式AI的新手还是想寻找一个高效、轻量级推理框架的资深工程师相信这篇从一线实战中总结出来的记录都能给你提供直接的参考和启发。2. 开发环境搭建与系统选择2.1 硬件平台与系统选型考量我手头的这块OKMX8MM-C开发板核心是NXP i.MX8MMini应用处理器。这颗芯片的配置对于嵌入式AI应用来说算是“小康水平”4个主频最高1.8GHz的Cortex-A53核心负责通用计算和复杂逻辑1个Cortex-M4核心可以处理实时任务此外还集成了Vivante GC7000Lite GPU和Cadence Tensilica HiFi 4 DSP可作为NPU使用。这样的硬件基础运行轻量级神经网络推理是绰绰有余的。原厂通常会提供基于Yocto项目构建的Linux BSP板级支持包这套系统稳定、驱动完善但有时候软件包版本比较旧搭建一些最新的开发环境可能需要自己从头编译很多依赖库过程会比较繁琐。为了更快速地切入Tengine的试用我决定先采用一个更“通用”的Linux环境。我选择移植了Armbian系统具体是**Debian 10Buster**版本。Armbian社区为大量Arm开发板提供了高度优化和预配置的Debian/Ubuntu镜像其优势非常明显丰富的软件源直接使用Debian庞大的apt软件仓库安装编译工具链、开发库如OpenCV、Protobuf几乎是一行命令的事省去了交叉编译或手动编译依赖的麻烦。主线内核支持我使用的这个Armbian版本其U-Boot和Linux Kernel都是mainline上游主线的。这意味着它包含了最新的特性和安全补丁并且对像Tengine这类开源项目的兼容性通常更好。虽然某些板载外设的驱动可能不如原厂BSP完善但对于我们核心的AI推理测试来说CPU、内存、存储这些基础组件运行正常就足够了。开发友好系统开箱即用具备完整的编译环境gcc, make, cmake等我们可以直接在板卡上进行本地编译Native Build这比交叉编译要直观和简单得多尤其适合快速原型验证。注意选择主线系统还是原厂BSP取决于项目阶段。如果是产品原型验证、算法快速迭代Armbian这类系统效率更高。如果进入产品化阶段需要更严格的硬件稳定性、功耗控制和所有外设驱动支持那么基于原厂BSP进行定制化裁剪是更稳妥的选择。2.2 基础开发环境配置系统刷写并启动后首先需要更新软件源并安装一些基础工具和Tengine编译所必需的依赖库。通过SSH登录到开发板执行以下命令# 更新软件包列表 sudo apt update sudo apt upgrade -y # 安装基础开发工具 sudo apt install -y build-essential cmake git wget # 安装Tengine编译依赖 sudo apt install -y libprotobuf-dev protobuf-compiler libopencv-dev pkg-config这里解释一下几个关键依赖包的作用libprotobuf-dev protobuf-compilerProtocol Buffers是Google开源的一种数据序列化工具。许多AI模型尤其是Caffe框架的模型会使用.prototxt文件定义网络结构Tengine需要这些库来解析和加载此类模型。libopencv-devOpenCV计算机视觉库。Tengine的许多示例程序Example涉及图像加载、预处理如缩放、颜色空间转换和后处理如画检测框都需要调用OpenCV的函数。pkg-config一个帮助在编译时查找库文件路径和头文件路径的工具。在编译一些复杂的项目时它能自动为编译器提供正确的-I和-l参数。安装完成后建议重启一次系统确保所有新安装的库文件路径都被正确加载到系统环境中。3. Tengine源码编译与关键配置解析3.1 获取源码与目录结构初探Tengine的源码托管在GitHub上OPEN AI LAB维护得比较活跃。使用git命令克隆仓库这里有一个必须注意的关键参数git clone --recurse-submodules https://github.com/OAID/tengine.git cd tengine为什么一定要加--recurse-submodulesTengine项目使用Git子模块Submodule来管理一些第三方依赖库比如用于模型序列化/反序列化的组件。如果不加这个参数你克隆下来的主仓库里这些子模块目录是空的。在后续编译链接阶段就会因为找不到对应的源码或头文件而失败。错误信息可能类似fatal error: xxx.h: No such file or directory。所以这个参数确保了所有依赖的代码都被一次性完整下载。下载完成后可以浏览一下主要目录结构这对理解编译过程有帮助benchmark/: 性能基准测试程序源码。examples/: 丰富的示例程序如目标检测、人脸识别等是我们主要的测试对象。source/: Tengine引擎的核心源码。default_config/: 针对不同平台ARM64, ARM32, x86的默认编译配置文件。models/: 存放神经网络模型文件的目录需自行下载放入。3.2 编译配置的修改与深层原因Tengine使用一个基于Kconfig的配置系统。对于我们的平台ARM64 Linux模板配置文件是default_config/arm64_linux_native.config。在编译前我们需要根据实际情况修改它。使用文本编辑器打开该文件vim default_config/arm64_linux_native.config找到其中关于序列化器Serializer的配置项。你可能会看到类似下面的行# CONFIG_BUILD_SERIALIZER is not set或者CONFIG_BUILD_SERIALIZERn必须将其修改为CONFIG_BUILD_SERIALIZERy这个配置项至关重要它决定了是否编译模型格式转换相关的模块。Tengine支持加载多种格式的模型如Caffe、ONNX、TensorFlow等。这些模型通常不能直接被Tengine的推理引擎使用需要一个“序列化器”将其转换为Tengine内部的格式TMfile。如果我们不编译这些序列化器即设置为n那么在运行示例程序时当尝试加载一个.caffemodel或.prototxt文件时程序会因找不到对应的动态链接库如libcaffe-serializer.so而崩溃报错信息正是Shared library not found: libcaffe-serializer.so: cannot open shared object file: No such file or directory因此除非你百分百确定只使用Tengine原生格式.tmfile的模型否则请务必打开此选项。本次测试中下载的官方模型多为Caffe格式所以必须开启。3.3 执行编译与产物分析配置修改保存后在Tengine源码的根目录下执行编译脚本./linux_build.sh default_config/arm64_linux_native.config这个脚本会自动完成配置加载、依赖检查、编译和链接全过程。编译时间取决于i.MX8MMini的性能大约需要10-20分钟。编译成功后最重要的产出在build目录下build/install/lib/: 这里存放着编译生成的Tengine核心库文件libtengine-lite.so以及各个序列化器插件库libcaffe-serializer.so,libonnx-serializer.so等。部署时这些库需要被放置到系统的动态库路径如/usr/lib下或者通过LD_LIBRARY_PATH环境变量指定。build/benchmark/bin/: 生成的两个基准测试可执行文件bench_sqz和bench_mobilenet。它们不依赖外部模型文件内置了小型网络用于快速验证Tengine库是否被正确编译和链接。build/examples/: 示例程序的生成目录此时还是空的因为examples需要单独编译。我们可以立即运行基准测试来做个简单验证cd build/benchmark/bin/ ./bench_sqz ./bench_mobilenet如果看到程序正常运行并输出一系列层的计算时间如conv1 time: 5.21 ms和总耗时、总吞吐量如Total time: 25.34 ms, 39.46 FPS就说明Tengine核心库的编译是成功的并且能在当前硬件上正常进行推理计算。4. 模型准备与示例程序编译实战4.1 获取与放置模型文件神经网络模型是AI应用的“大脑”。Tengine的示例程序需要加载对应的模型文件才能工作。OPEN AI LAB提供了一个百度网盘链接里面包含了多种预训练好的模型Caffe格式。链接和提取码通常在项目的README或Wiki中能找到例如链接: https://pan.baidu.com/s/1Ar9334MPeIV1eq4pM1eI-Q 提取码: hhgc。由于全部模型文件体积很大可能超过1GB建议根据你打算测试的示例程序选择性下载。例如如果你只想测试mobilenet_ssd和mtcnn那么就下载对应的mobilenetssd.caffemodel、mobilenetssd.prototxt以及mtcnn相关的模型文件。下载完成后必须将这些模型文件通常是.caffemodel和.prototxt成对出现放置到Tengine源码根目录下的models文件夹中。这是示例程序默认寻找模型的路径。如果models文件夹不存在就创建一个。实操心得网盘下载的模型文件在Linux下可能需要解决解压和文件名编码问题。有时压缩包内是中文目录名解压后可能会乱码。建议在Windows或Mac上下载解压后通过SFTP工具如FileZilla上传到开发板的指定目录这样最省事。4.2 示例程序的独立编译Tengine的主编译脚本默认不会编译examples目录下的示例程序。我们需要进入examples目录进行单独编译。但在编译前有一个关键步骤配置Tengine的路径。修改编译配置进入examples目录找到linux_build.sh脚本注意这是examples目录下的不是根目录的那个。用编辑器打开找到设置TENGINE_ROOT路径的地方。默认可能是TENGINE_ROOT../这假设examples和tengine根目录是平级的。但在我们的编译结构中build目录在根目录下。更稳妥的做法是使用绝对路径。例如我的Tengine源码放在/root/tengine那么就修改为TENGINE_ROOT/root/tengine确保这个路径指向你克隆的Tengine源码的根目录里面应包含source,build等文件夹。执行编译在examples目录下执行以下命令mkdir build cd build ../linux_build.sh make -j4../linux_build.sh会调用CMake生成Makefilemake -j4则启动编译-j4表示用4个并行任务加快编译速度数字可调整为你的CPU核心数。编译成功后在examples/build/目录下就会生成一系列可执行文件例如faster_rcnnlighten_cnnmobilenet_ssdmtcnnssdyolov2YuFaceDetectNet这些就是我们接下来要进行测试的AI应用Demo。5. 主流目标检测模型实测与性能对比一切准备就绪现在可以开始激动人心的模型测试环节了。我会选择几个有代表性的目标检测模型使用相同的图片或各有侧重的图片来直观感受不同算法的效果和性能差异。测试前请确保终端当前工作目录在examples/build/下并且models文件夹里已经放置了对应的模型文件。5.1 Faster R-CNN高精度代表Faster R-CNN是两阶段Two-Stage检测器的经典之作。它先由区域提议网络RPN生成可能包含物体的候选框Region Proposals再对这些候选框进行分类和精确位置回归。这种结构通常精度很高但速度相对较慢。我们使用Tengine示例中自带的测试图片ssd_dog.jpg一般位于examples/build/images/或源码其他目录如果找不到可以自己准备一张包含狗、自行车、汽车的图片并指定路径。运行命令./faster_rcnn -m ../models/faster_rcnn.prototxt -w ../models/faster_rcnn.caffemodel -i /path/to/your/ssd_dog.jpg-m: 指定模型结构文件.prototxt-w: 指定模型权重文件.caffemodel-i: 指定输入图片路径程序运行后会在当前目录生成一张名为save.jpg的结果图。在我的测试中Faster R-CNN成功检测出了图片中的狗Dog、自行车Bicycle和汽车Car并用方框和标签进行了标注。作为精度标杆它的检测结果非常准确。性能观察在i.MX8MMini的CPU上运行未启用GPU/NPU加速处理单张图片耗时大约在1.5秒到2.5秒之间。这对于实时性要求不高的静态图片分析场景是可以接受的但显然无法满足视频流实时检测的需求。5.2 YOLOv2 与 SSD速度与精度的权衡YOLOv2和SSD都是单阶段One-Stage检测器的杰出代表。它们将目标检测视为一个统一的回归问题直接从图像像素到边界框坐标和类别概率因此速度通常比两阶段方法快一个数量级。YOLOv2测试使用与Faster R-CNN相同的图片。./yolov2 -m ../models/yolov2.prototxt -w ../models/yolov2.caffemodel -i /path/to/ssd_dog.jpg从输出结果看YOLOv2同样准确地检测到了狗、自行车和汽车。关键的数据来了其推理时间大约在300毫秒左右。相比Faster R-CNN的2秒速度提升了近6倍而精度肉眼观察几乎没有损失。这完美体现了单阶段检测器的速度优势。SSD测试我们换一张更复杂的图片例如包含多人、狗的街景来测试SSD。./ssd -m ../models/ssd.prototxt -w ../models/ssd.caffemodel -i /path/to/street_scene.jpgSSD的检测速度也很快与YOLOv2处于同一量级几百毫秒。但在我的某次测试中SSD模型将一只狗误识别成了“猫”。这说明了不同模型在不同数据集上训练后存在的特性差异。SSD这里指基于VGG的原始SSD对小目标的检测能力有时会弱于YOLOv2或后续改进版本。5.3 MobileNet-SSD为嵌入式而生MobileNet-SSD是SSD框架与MobileNet轻量级骨干网络Backbone的结合。MobileNet使用深度可分离卷积Depthwise Separable Convolution大幅减少了计算量和参数量专为移动和嵌入式设备设计。使用与测试SSD相同的街景图片./mobilenet_ssd -m ../models/mobilenetssd.prototxt -w ../models/mobilenetssd.caffemodel -i /path/to/street_scene.jpg结果很有意思之前被SSD误认的狗这次被MobileNet-SSD正确识别了。但是图片远处一个较小的人影却被漏检了。这反映了轻量化模型普遍面临的挑战在追求速度和低功耗的同时不可避免地会牺牲一部分精度尤其是对小目标和复杂场景的感知能力。速度对比MobileNet-SSD的推理时间大约在150-200毫秒比原始的SSD和YOLOv2又快了一倍左右。这个速度在i.MX8MMini上已经接近实时5-6 FPS如果后续能启用板载的NPU进行硬件加速达到20-30 FPS的实时检测是完全可期的。5.4 人脸检测专项测试YuFaceDetectNet vs MTCNN最后我们聚焦人脸检测这个垂直任务对比两个知名模型。YuFaceDetectNet这是深圳大学于仕琪老师开源的高性能人脸检测库libfacedetection的Tengine移植版。它以速度极快而闻名。./YuFaceDetectNet -i /path/to/group_photo.jpgMTCNN一个经典的多任务级联人脸检测框架通过三个级联网络P-Net, R-Net, O-Net逐步细化检测框精度非常高。./mtcnn -i /path/to/group_photo.jpg使用一张包含多张人脸的合影进行测试。两个模型都成功检测出了画面中的五张人脸。精度MTCNN在脸部关键点如眼睛、鼻子、嘴角的定位上通常更精细。速度在我的测试中YuFaceDetectNet的处理时间约为120毫秒而MTCNN约为180毫秒。YuFaceDetectNet确实更快但MTCNN的速度也完全可接受两者差距并不像目标检测模型中Faster R-CNN和YOLO那样悬殊。对于嵌入式人脸门禁、考勤机等应用这两个模型都是优秀的选择可以根据对精度和速度的侧重点来挑选。6. 常见问题排查与性能优化思路在实际部署和测试过程中你几乎一定会遇到各种问题。下面是我踩过的一些“坑”以及解决方案希望能帮你节省时间。6.1 编译与运行时的典型错误问题现象可能原因解决方案git clone后子目录为空编译时找不到头文件克隆时未使用--recurse-submodules参数重新克隆或进入仓库后执行git submodule update --init --recursive编译时提示fatal error: opencv2/opencv.hpp: No such file or directoryOpenCV开发包未安装或pkg-config未找到运行sudo apt install libopencv-dev。如果已安装尝试手动指定路径或在CMakeLists.txt中正确设置OpenCV_DIR运行示例程序时崩溃报错error while loading shared libraries: libtengine-lite.so: cannot open shared object file系统动态链接器找不到Tengine库将build/install/lib/路径加入LD_LIBRARY_PATHexport LD_LIBRARY_PATH/path/to/tengine/build/install/lib:$LD_LIBRARY_PATH。更持久的方法是将该路径加入/etc/ld.so.conf或创建.conf文件到/etc/ld.so.conf.d/然后运行sudo ldconfig运行程序时提示Shared library not found: libcaffe-serializer.so编译时未开启BUILD_SERIALIZER选项确保在arm64_linux_native.config中设置CONFIG_BUILD_SERIALIZERy并重新编译整个Tengine加载模型时卡住或报模型格式错误模型文件损坏或模型与程序不匹配或模型路径错误1. 检查模型文件MD5是否与官方提供的一致。2. 确认使用的模型文件如mobilenetssd.caffemodel是否与程序mobilenet_ssd匹配。3. 使用绝对路径指定模型文件或确保程序在正确的相对路径下运行。检测结果完全错误或没有框模型输入尺寸与图片预处理方式不匹配不同的模型要求输入图片的尺寸和归一化方式如像素值范围是0-1还是0-255是否减去均值不同。需要查看示例程序的源码看它是如何对cv::Mat进行预处理的并确保你的输入图片经过相同的处理。6.2 在i.MX8MMini上提升推理性能的探索目前我们的测试都是在CPU上进行的。i.MX8MMini内置的GPU和NPU才是发挥其AI性能潜力的关键。Tengine支持通过Vulkan后端调用GPU以及通过TIM-VX后端调用NPU进行加速。GPU加速Vulkan前提Linux内核需要包含Vulkan驱动并且安装Vulkan SDK。编译在Tengine配置文件中需要开启CONFIG_ARCH_BLASy和Vulkan相关的选项。编译时会链接Vulkan库。运行在程序中需要显式指定使用Vulkan后端来创建推理引擎。性能提升因模型和驱动优化程度而异通常能有数倍的提升。NPU加速TIM-VX前提这是性能提升最显著的路径。需要NXP提供的专用NPU驱动和软件栈如libovxlib。原厂的Yocto BSP通常会包含这些组件。编译配置Tengine时开启TIM-VX支持并指向NPU驱动和库的路径。运行程序会自动将符合条件的算子如卷积、池化卸载到NPU上执行。对于MobileNet这类网络在NPU上运行的速度相比CPU可以有10倍以上的提升真正做到实时高清视频分析。重要提示在Armbian这类主线系统上启用NPU通常比较困难因为缺少官方的闭源驱动和固件。如果追求极致的AI性能建议切换回NXP官方或飞凌嵌入式提供的BSP系统并在其基础上按照Tengine和NXP的官方指南重新编译支持TIM-VX的Tengine库。这是一个进阶话题涉及更复杂的交叉编译和环境配置但也是将i.MX8MMini性能榨干的必经之路。6.3 模型优化与部署建议在嵌入式设备上部署AI模型永远要在精度、速度和资源消耗之间做权衡。模型选择优先考虑专为嵌入式设计的轻量级网络如MobileNet系列、ShuffleNet、EfficientNet-Lite等。Tengine对这类模型的支持和优化通常更好。模型量化将训练好的FP32浮点模型转换为INT8整数模型可以大幅减少模型体积和内存占用并提升推理速度许多NPU对INT8有硬件加速支持。Tengine提供了模型量化工具。使用Tengine模型格式将Caffe、ONNX等框架的模型通过Tengine提供的模型转换工具convert_tool预先转换为Tengine独有的.tmfile格式。这种格式经过了优化加载速度更快并且可以集成预处理/后处理信息简化部署代码。针对具体场景裁剪模型如果你的应用只检测特定几类物体如只识别人和车可以考虑对开源模型进行微调Fine-tuning和裁剪Pruning移除无关的类别输出层和冗余通道进一步缩小模型。这次在飞凌嵌入式OKMX8MM-C上基于Tengine的体验让我对嵌入式AI开发的流程和挑战有了更直观的认识。从系统选择、环境搭建到源码编译、模型测试每一步都需要清晰的思路和对细节的把控。i.MX8MMini的CPU性能已经足以流畅运行多种轻量级AI模型而它预留的GPU/NPU硬件加速能力则为更高要求的实时应用打开了大门。选择像Tengine这样兼顾性能、易用性和硬件适配性的推理框架能让我们更专注于应用逻辑本身而不是底层算子的调试和优化。如果你手头也有类似的Arm开发板不妨按照这个流程试一试亲手部署几个AI模型感受一下在资源受限的嵌入式设备上运行现代人工智能的神奇魅力。
