NCNN 生产落地案例：产线视觉质检与车载 DMS

NCNN 生产落地案例：产线视觉质检与车载 DMS

案例一：产线视觉质检（ARM Linux 加 Vulkan）

背景：某产线需要在工控机上就地判断零件外观缺陷，图像不出厂区，设备是 ARM 架构的工控板，带 Mali GPU。

做法：用 PyTorch 训练检测模型，经 TorchScript 加 pnnx 转成 NCNN；先跑浮点版本对齐精度，再做 INT8 量化压成本；推理端启用 Vulkan 走 GPU，CPU 只负责前后处理。

关键配置：opt.use_vulkan_compute = true 并配合 net.set_vulkan_device(0) 指定设备；开启 fp16 打包与存储；线程数按大核数量设置；打开 lightmode 控制内存峰值。量化时用产线实拍图作为校准集，预处理参数与推理代码逐字对齐。

效果：单帧耗时进入产线节拍允许的范围，整机功耗与发热可控。具体数字随板卡与模型而异，以实测为准。

踩的坑：一是校准集用了实验室图片，产线光照差异导致误判，换用实拍图后恢复；二是 Vulkan 开启后首帧耗时明显偏高，必须先预热几帧再进循环；三是优化模型时没留意 fp16 存储选项，量化版本与浮点版本混用导致一次加载失败。

案例二：车载 DMS 驾驶员状态监测（Android）

背景：车载设备基于 Android，需要在本地实时判断驾驶员疲劳状态，不能依赖网络，且设备型号多、GPU 驱动质量参差不齐。

做法：人脸检测与关键点模型都编译为 NCNN 的 arm64 静态库，通过 JNI 调用；Vulkan 做成可开关项，启动时探测设备能力，不支持就直接走 CPU 多线程；模型做 INT8 量化以减少内存占用。

关键配置：JNI 层只创建一次 ncnn::Net 并复用，避免反复加载模型；opt.num_threads 按 get_big_cpu_count() 设置；在低电量场景用 set_cpu_powersave 调整策略。

效果：在无 GPU 的中低端设备上也能保持可用的实时性，功能表现跨机型一致。

踩的坑：一是早期每次调用都新建 Net，模型反复加载导致明显卡顿，改成单例后消失；二是没做 Vulkan 能力探测，部分设备上直接崩溃，加上探测与回退后稳定；三是 NDK 与 STL 选项不一致，与宿主 App 的其他原生库冲突，统一为 c++_static 后解决。