1. 为什么这个项目必须选端侧AI1.1 工业质检场景遇到的四道坎先聊聊我接触过的真实产线情况。之前帮某电子元器件厂的视觉工程师A同学做技术评估他们产线上的质检工位每天要过几千片电路板之前用传统机器视觉做了个检测方案只能看固定位置、固定角度的焊点换一种型号的板子就得重新调参数人稍微多漏检几个就喊流水线档不住。后来大家一致想到上AI模型但方案一开始都往云端服务那边靠。云端AI方案放PPT上很漂亮摄像头拍图、上传、推理、回传逻辑上是通的。可实际落地就暴露问题了。第一道坎是网络产线现场的环境复杂Wi-Fi穿了几道铁门之后时延忽高忽低经常出现图片传一半卡住的情况。第二道坎是数据敏感产线的产品照片属于工厂内部数据很多客户明确要求不能出工厂别说传公有云私有化部署在某些客户那里都要走好几轮审批。第三道坎是成本一套云端推理服务跑起来GPU实例、带宽、运维一年下来是一笔不小的开支产线一开就是两班倒扩容跟着流水线的节拍走成本非常刚性。第四道坎是时延很多质检位要求检测结果在1秒内反馈到工位屏幕整条线的节拍摆在那里云端往返多了那几十毫秒就成了压垮骆驼的稻草。这四道坎叠加起来结论很明确质检App必须把AI推理放到端侧去。HarmonyOS 5.0的端侧AI能力正好补上了这个位置模型直接跑在设备本地拍照、推理、出结果全部离线完成断网时也能继续产线节拍。数据不出设备隐私和合规问题同时解决。1.2 端侧AI落地的优势与边界有人说端侧AI就是“把云端模型塞进手机”这个理解方向对但实际操作没那么简单。端侧AI的本质是让推理计算发生在数据产生的地方省掉网络传输和云端排队的时间同时把数据留在本地。对于工业质检这种场景优势是实打实的第一个优势是确定性时延。我实测下来在HarmonyOS 5.0设备上用Neural Network Runtime跑一个轻量缺陷检测模型单帧推理稳定在80毫秒到150毫秒之间不会因为网络波动跳变。产线排程需要的是可预期的节拍这一点云端方案给不了。第二个优势是数据合规。质检图片不出设备从根本上规避了数据出厂的审批流程。很多工厂的IT部门一听“数据不出厂”立刻就点头了。第三个优势是离线可用。产线网络维护、车间断网等情况下质检照样运转只是结果暂存在本地网络恢复后再补传。这种容错能力对连续生产的场景太重要了。但边界也要讲清楚。端侧设备的内存和算力摆在那里你不可能把几十亿参数的视觉大模型直接塞进去跑。所以端侧AI质检项目的关键问题是——如何在受限资源下用最合适的小模型拿到生产线能接受的准确率。这里说的“能接受”不是实验室里的99.9%而是产线上“漏检率低于千分之几、误检率不影响节拍”的工程指标。后面我会专门讲模型选型和量化这些细节。1.3 HarmonyOS 5.0端侧AI能力盘点HarmonyOS 5.0这套系统在端侧AI这块不是空架子它有自己的端侧推理运行时外部训练好的模型经过转换后可以直接加载推理也支持对底层不同算子的统一调度。应用开发者不需要关心设备里的NPU是什么型号调统一接口就行系统会在不同算力单元之间做自动分配。更友好的是整个开发链路和现代移动端开发习惯是一致的应用侧用ArkTS写业务逻辑模型转换用Python脚本完成推理调用走异步接口不阻塞UI线程。对做过后端AI服务和Android/iOS开发的团队来说上手成本不算高。HarmonyOS统一了端侧推理的使用方式避免了“不同设备绑不同SDK”那套割裂体验。对这个质检项目来说这意味着同一套代码可以适配产线不同性能档位的设备低端设备跑小模型中高端设备跑稍大一点的模型业务层完全不用改。2. 整体方案设计与关键选型2.1 系统架构与数据流把整个质检App拆开看核心链路是这么一条工位相机持续采集图像App拿到预览帧后做预处理裁剪、缩放、格式转换送进端侧推理引擎模型输出缺陷类型、置信度和位置框App再根据业务规则判定“合格/不合格”然后把结果写到本地数据库并回显到工位屏幕。数据流上我按四层来设计采集层负责相机打开、预览帧获取、图像格式转换。预处理层把摄像头帧统一处理成模型输入要求的分辨率和色彩格式这一步不做任何AI计算纯CPU操作。推理层端侧推理运行时加载转换后的模型文件以异步方式执行推理输出后处理结果。业务层将推理结果映射为产线动作比如驱动指示灯、弹出缺陷图片、记录质检日志、调用工厂QMS/MES接口上报数据。初期只考虑单机版流程拍照、推理、展示、存储全部在设备本地完成。后续要对接工厂系统只需在业务层加一个网络上报模块核心链路完全不用动。这样设计的好处是把“端侧到底能干多少事”与“外界系统怎么衔接”解耦局部演进不必推翻重来。2.2 缺陷检测模型怎么选模型选型是整个项目最关键的决策之一。产线质检的目标是检测电路板上的焊点缺陷、划痕、异物、缺件等异常。这类任务属于典型的目标检测问题不是特别复杂但要求对小目标敏感、推理速度快。在HarmonyOS 5.0设备上做推理我给自己定的三条硬性指标模型大小在10MB以内转换后文件尽量在5MB上下单帧推理时间在200毫秒以内对目标缺陷类别的平均精度不低于85%。基于这几条我选了一个基于轻量级检测结构的模型以DNet-Quant这种尺寸级别的结构作为参考。训练阶段用工厂脱敏的历史缺陷样本集包含几千张标注了缺陷类型的图像。如果你们在业务上接触不到私有数据集可以用公开的工业质检数据集先跑通流程验证好端侧链路之后再换业务数据微调。模型具体用什么结构不是死规定关键是控制参数量、方便后续量化压缩。部署前我习惯在电脑上先做一次完整的离线验证把测试集跑一遍记录各类缺陷的精确率和召回率同时统计模型的计算量。这个步骤的目的不是追求指标好看而是确认缺陷类型分布是否和产线实际比例接近。有一个非常典型的坑训练集里A类缺陷多模型对A类学得特别好但产线上真正影响客户体验的是B类缺陷B类样本少导致召回率低。所以选模型前先做好训练集的类别平衡分析这个工作比换更大规模的模型更重要。2.3 开发环境与工具链准备开发环境这块我直接说结论。我用DevEco Studio作为IDE新建工程时选择支持HarmonyOS 5.0的应用模板语言用ArkTS。设备端调试建议准备一台真机因为模拟器在端侧推理性能和相机调用上和真机差距比较大尤其是跑模型和摄像头预览模拟器完全不是一回事。模型侧的工具链分三段训练用深度学习框架导出成通用格式再用HarmonyOS的模型转换工具把通用格式转成端侧推理运行时能加载的格式最后在应用工程里把这些文件放到resources模块下作为本地资源随App打包。转出来的模型文件要放在应用资源目录里方便应用读取。另一件容易被忽略的是权限声明相机权限、读写存储权限都得在配置里显式声明。第一次跑真机最容易碰到的问题就是相机预览黑屏十有八九是权限没弹或者没在配置文件里声明。3. 模型转换与端侧推理集成实操3.1 把训练得到的模型转成端侧格式训练好的模型不能直接拿给App用得先过一道转换工序。整个转换过程可以用Python脚本在开发机上完成产物是一个高度优化过的端侧模型文件里面已经把算子重写成了适合在移动端执行的形态并且支持后续量化压缩。假设你的模型已经导出成通用格式比如ONNX模型文件名为defect_detector.onnx输入尺寸是256x256转换步骤大致如下# 安装转换工具链具体安装命令以当前SDK版本文档为准 # 转换命令核心参数如下 python converter.py \ --input defect_detector.onnx \ --output defect_detector_v5.ms \ --input-shape input:1,3,256,256 \ --quant_type int8 \ --calibrate_data ./calibrate_images转换过程中有两个参数非常关键。一个是输入尺寸必须和应用侧预处理的输出保持一致你在这里写256相机帧就得先缩放成256另一个是量化类型用int8还是fp16直接决定模型文件和推理速度。工业质检场景我建议直接上int8后面单独讲精度补救。转换完成后记得检查生成的模型文件正常应该在几MB到十几MB之间。如果发现文件大到几十MB大概率是参数里混入了多余节点建议回到导出环节把推理用不到的辅助输出层去掉再转一次。3.2 量化与精度损失控制量化是把模型里的浮点参数变成低比特表示换来更小的体积和更快的计算。float32的模型转成int8之后体积直接缩到原来的四分之一推理速度通常也能提升一半以上。代价是精度会损失一些但这个损失可控。控制量化损失我的实操经验是三件事第一校准集必须来自真实场景。量化时需要一组有代表性的图片来统计参数分布范围我用的是产线脱敏的巡检图片而不是通用数据集。如果用普通图片做校准模型对产线光照条件下图像的特征分布估计不准量化后精度崩得很明显。第二量化后必须做逐类指标对比。我踩过一次坑整体平均精度只掉了1.5个百分点以为没问题一查分类指标发现划痕类缺陷的召回率掉了12个百分点正好是产线最关心的那一类。后来把校准集里划痕样本的量加上去重新量化才救回来。所以评估量化效果时一定要按缺陷类别分开看不能只看平均分。第三必要时对敏感层做保护。有些模型结构的第一个卷积层和最后一个输出层对精度影响特别大可以对它们保留float16或float32只量化中间层。HarmonyOS的转换工具链支持这种混合精度设置。3.3 用Neural Network Runtime加载模型并推理模型转换完成后就进入了App侧的核心编码阶段。HarmonyOS 5.0的端侧推理接口设计得比较干净核心就是两件事加载模型创建推理会话后异步执行。以下是我工程的简化示例保留了关键调用流程import { NeuralNetworkRuntime } from kit.PerformanceAnalysisKit; export class DefectDetector { private session: NeuralNetworkRuntime.Session null; private inputTensor: NeuralNetworkRuntime.Tensor null; private outputTensor: NeuralNetworkRuntime.Tensor null; // 初始化加载模型并创建推理会话 async init(msPath: string): Promisevoid { const options: NeuralNetworkRuntime.Options { enableFp16: false, // int8模型不需要开启fp16 enableQuantization: true // 模型已量化运行时不再重复量化 }; this.session await NeuralNetworkRuntime.createSession(msPath, options); this.inputTensor this.session.getInputTensor(0); this.outputTensor this.session.getOutputTensor(0); } // 执行推理输入预处理数据输出原始分值 async infer(inputData: ArrayBuffer): Promisenumber[] { this.inputTensor.setData(inputData); await this.session.runAsync(); return Array.from(this.outputTensor.getData()); } // 释放推理会话 release(): void { this.session?.destroy(); this.session null; } }代码看着不复杂但这里有几个细节必须提醒。创建会话是一次重量级操作模型解析、资源分配都在这一步完成所以App启动后只需要初始化一次不要每帧重复创建会话否则推理耗时直接翻几倍。另外推理接口有同步和异步两种虽然示例用的是异步但真正的耗时大头在模型计算本身异步只保证不卡UI线程不代表瞬时出结果。所以在业务设计上我会配合一个“推理中”状态让工位屏幕显示处理中避免用户以为卡死。端侧推理集成的坑大多不在接口本身而在数据格式的匹配。模型输入要求的是经过归一化的浮点数组而相机拿到的是字节流。所以从设备端图像到模型输入张量之间中间要插入一个专门的数据转换模块完成格式转换、缩放、去均值、除以标准差这几道工序。4. 质检APP核心功能实现4.1 相机采集与图像预处理工业质检App和普通拍照App最大的区别在于相机不是用户开一次拍一张而是要持续预览画面并在合适的时机抓帧做检测。HarmonyOS 5.0的相机能力提供了预览流我优先使用它拿帧而不是用拍照回调原因只有一个——速度。预览流持续输出每一帧数据App只需要从中取最新一帧延迟远低于“点一下快门再回调”的模式。代际实现我会拆成两块一是相机初始化配置分辨率和预览输出格式二是创建一个逐帧处理循环把预览帧送入预处理管线。相机初始化代码如下import { camera } from kit.CameraKit; async function initCamera(): Promisevoid { const cameraManager camera.getCameraManager(); const cameraDevices await cameraManager.getSupportedCameras(); const cameraDevice cameraDevices[0]; const outputCapability await cameraManager.getSupportedOutputCapability(cameraDevice); const previewProfile outputCapability.previewProfiles.find( (p) p.width 1280 p.height 720 ); const previewOutput await cameraManager.createPreviewOutput(previewProfile); const photoOutput await cameraManager.createPhotoOutput(outputCapability.photoProfiles[0]); this.cameraSession await cameraManager.createSession(); this.cameraSession.beginConfig(); this.cameraSession.addInput(cameraDevice); this.cameraSession.addOutput(previewOutput); this.cameraSession.commitConfig(); await this.cameraSession.start(); }实际开发中很多人把时间耗在“如何一帧不漏地检测”这是一个方向性错误。我采用的方式是预览流照常以30fps跑但质检检测只按产线节拍触发每2到3帧取一帧做完整推理即可没有必要求每一帧都推理。这样既保证检测频率跟得上产线速度又留出算力余量给后续功能。预处理环节是端侧AI容易翻车的高发区。模型训练时输入是正方形的RGB图而相机默认输出是横屏的YUV图尺寸可能是1920x1080。两种数据格式和宽高比都不一样如果直接把相机帧丢给模型输出的结果一定是一团乱码。我的预处理管线固定在C侧完成核心步骤如下把YUV格式转成RGBA格式按短边中心裁剪成正方形避免拉伸变形缩放成模型要求的输入尺寸比如256x256将RGB值归一化到0到1之间并按训练时的统计值做标准化。这一步全部用固定算法实现不用任何AI库纯逻辑处理。有一个容易被忽视的弯归一化的顺序和训练时保持一致顺序反了推理结果就是错乱的。我建议把这一小段逻辑单独封装成公共工具类写上单元测试每次改完预处理代码跑一遍回归测试保证后面改优化不会把归一化顺序改坏。4.2 推理结果后处理与缺陷定位模型输出的不是最终结论而是一组原始分数。目标检测模型通常输出三类信息缺陷类别概率、缺陷中心坐标、边框尺寸。这些数字在模型内部是以归一化坐标表达的要映射回原始图像坐标必须做后处理。后处理这个环节我同样建议用纯代码实现不依赖推理框架。步骤很固定先按置信度阈值过滤掉低分结果再对同一区域内重叠的多个框做去重保留置信度最高那个最后将归一化坐标乘以图像的缩放偏移系数还原到原始尺寸。口诀是置信度过滤在前去重在中间坐标还原放最后。这个顺序不能乱置信度阈值可以按缺陷类型分别设置。比如我用0.45作为默认阈值对容易漏检的微小缺陷类型单独设到0.35。每条产线的物料特性不同最合适的阈值要靠A/B测试来确定没有一劳永逸的通用值。后处理对外暴露的接口我定义成一个统一的数据结构export interface DefectResult { defectType: string; // 缺陷类别 confidence: number; // 置信度 x: number; // 缺陷中心x原图坐标 y: number; // 缺陷中心y原图坐标 width: number; // 缺陷区域宽度 height: number; // 缺陷区域高度 timestamp: number; // 检测时间戳 }这个结果结构贯穿整条业务链路上层不管是写日志、画框、上报都统一拿这一份数据。工程规范上我给这个结构加了序列化方法方便存SQLite或转JSON上报减少业务层重复编码。4.3 质检结果展示与数据闭环质检结果展示这块有个产品层面的关键点工位操作员要的不是一张标着框的图片而是一个清晰的操作指令。所以我在界面上用大色块区分结果绿色的合格品直接放行红色的不合格品在图片上标出缺陷位置同时给出“深度复检”的提示。每个缺陷上还能点开小图看细节放大图方便现场工程师快速判断是真实缺陷还是误检。数据闭环分成本地和对外两部分。本地侧我用SQLite保存每次检测记录一条记录包含时间、产品批次号、缺陷结果、缺陷图缩略图路径。这不仅是审计需要更是后续模型迭代的数据资产。对外侧通过业务模块对接工厂的QMS或MES系统。对接方式上每家工厂的接口都不一样有的提供HTTP接口有的只接受MQTT消息。初期建议先做一个统一的逻辑上报接口适配不同工厂通过配置切换不要让工厂协议影响核心质检链路。日志记录这件事我多说一句。产线上如果发生争议比如“这个产品当时到底检没检过”唯一能回答的就是质检日志。所以每一条检测记录不仅要写结果还要写入当时用的模型版本号、算法版本号、置信度阈值、设备编号。没有版本信息的质检日志一旦模型更新历史记录就解释不清了。5. 性能调优与高频问题排查5.1 端侧推理的三大瓶颈项目做到后期你大概率会被三个问题卡住耗时、内存、发热。耗时是一切优化的前提。先用profiling工具把“是否检测一帧的完整耗时”指出来包含相机抓帧、预处理、推理、后处理四段不能只盯着推理那80毫秒。我曾经遇到一个案例推理只要90毫秒但预处理因为每帧都重新分配内存硬生生多花了60毫秒。整个一帧的耗时从90毫秒变成150毫秒产线直接超节拍。这种因为内存抖动浪费时间的坑用profiling工具一看就暴露了。内存问题上最典型的错误是在预处理循环里频繁创建临时对象。每帧创建一个256x256的RGBA缓冲看起来没什么但120帧下来就会产生大量内存分配和GC卡顿就来了。正确做法是启动时把缓冲区和中间变量全部提前分配好检测循环里只做读写不做new。这个优化在工业环境中尤其重要因为质检设备经常7x24小时开机内存泄漏不了几天就会把设备拖到重启。发热问题难缠在于它不直接报错而是表现为推理耗时缓慢增长。开始时40毫秒的推理开机两小时后变成80毫秒这是热降频导致的。解决思路不是对抗物理规律而是让检测任务尽量短平快避免设备重负载时间过长。如果产线节拍允许我会把检测频率设计成“按需触发”只在产品经过光电传感器时启动检测让NPU有喘息时间。5.2 帧率与精度平衡的实测技巧这条经验是我在这个项目里觉得最值得分享的。帧率和精度的平衡不是单纯调一个变量就能解决的而是一个组合拳。先说模型侧。不要一上来就追求高精度大模型。我的流程是先在电脑上找一个中等精度的轻量基线模型把端侧链路整体跑通再根据产线实际表现逐步替换更大的模型或提升输入分辨率。链路没跑通之前就纠结模型精度是本末倒置。再说架构侧。推理不要放在UI主线程上这是铁律。我在工程里用一个独立的工作线程来处理相机帧和推理请求工作线程内部维护一个固定大小的帧队列。队列满时丢最旧的帧而不是阻塞相机这样可以保证UI线程永远流畅不会出现工位屏幕上动画卡成一帧一帧的情况。还一个细节是“模型预热”。首次推理通常比后续推理慢得多因为模型加载、内存初始化都在第一次调用时触发。我在App内部有一个专门的预热方法在后台预跑一次推理把这一笔开销放到初始化阶段消化掉正式检测时就不会出现第一帧延迟特别大的现象。预热这个操作看上去很小但产线上如果每班开机后第一件产品就被误判超时那就是大问题。另一个容易被忽略的调优点端侧推理后端支持多种计算单元调度。我建议在初始化时显式根据设备型号设置计算后端偏好性能优先选NPU兼容性优先选CPU。系统默认调度通常比较保守手动指定之后同样的模型推理耗时能差20%左右。5.3 常见问题排查速查表项目调试过程中我记录了一些高频问题整理成速查表供参考。现象可能原因排查思路解决方案相机预览黑屏相机权限未配置或未授权检查配置文件是否有相机权限声明运行时是否弹窗授权补声明权限代码里显式请求权限推理结果全是同一类别输入数据格式与训练时不一致检查预处理输出的通道顺序、尺寸、归一化值写预处理单测对照训练脚本逐项核对首次推理特别慢模型未预热用profiling看第一次推理的耗时分布初始化阶段预跑一次推理运行一段时间后内存上涨检测循环里有未被释放的对象用内存分析工具抓取GC日志缓冲区和中间对象改为启动时预分配推理耗时逐渐变长设备热降频观察CPU/内存温度变化趋势降低检测频率空闲时暂停推理会话设备A正常、设备B结果错乱底层算子兼容性差异分别在两台设备上对比输出张量手动指定计算后端或更新SDK重新出包模型文件读取失败资源路径错误或文件未打包检查resources下是否有模型文件确认打包配置使用正确的资源访问接口这张表对应的每一条我在项目上都亲自踩过。其中“输入格式不匹配”是最隐蔽的因为模型不会报错它会正常输出一个结果只是结果全是不合格的乱码。所以我在预处理模块里埋了一条自检逻辑初始化完成后拿一张已知类别的图片输入判断输出是否符合预期不符合就直接在日志里报错而不是让错误结果混进产线流程。5.4 上线前避坑清单上线前最后三天我通常会做一轮完整的验收测试这里列几条容易漏的项目第一低温/高温环境下跑稳定性验证。产线车间冬天和夏天的环境温度差异很大设备性能表现完全不一样。建议至少做一次连续8小时的高负载测试观察散热和推理耗时的变化曲线。第二断网恢复验证。质检设备的工作环境可能突然没网。验证一下断网状态下App是否还能正常检测、结果是否可靠暂存网络恢复后能否自动补传数据。这一步如果没验证真到断网那天整个质检流程就堵住了。第三多设备同型号一致性验证。同一批次的设备硬件一致但个体差异会导致性能有弱有强。如果在性能偏弱的设备上推理耗时超了产线节拍就要考虑适当降低输入分辨率或检测频率保证最差设备也能完成任务。第四数据备份与恢复。质检记录是生产过程数据不能丢。我习惯做两层SQLite数据定期导出到外置存储同时在网络恢复时同步到服务器。万一设备故障至少还有一份完整记录。第五升级回退机制。模型和App不可能一次做到完美后续肯定要迭代。预留一个稳定的升级通道并确保新版本出问题时能快速回退到上一版本。产线最怕的是升级后无法恢复一台设备卡在那里整条线停工。这些避坑项看上去琐碎但每一条背后都有实际项目教训。端侧AI质检本质上是一个系统工程模型只是一部分真正决定项目成色的是整个链路在真实产线环境中的稳定性和可靠性。最后再分享一个体会这个项目给我最大的经验是“先跑通再跑快”。很多人一上来就研究大模型、追求最准的检测率结果卡在端侧部署那一关。反过来先用一个轻量模型把端侧链路整体跑通哪怕检测精度只有85%只要产线能运转后面有的是时间微调模型、优化预处理、调阈值。链路不通模型再准也是空中楼阁。我后来在另一个视觉检测项目里也沿用了这个思路都是先把端到端跑通再回头打磨每一个环节省下来的调试时间远远超过前期“看似绕路”的那一步。