AIoT端侧猫狗识别实战:从模型选型到多模态融合的工程化落地

发布时间:2026/10/19 13:00:16
AIoT端侧猫狗识别实战:从模型选型到多模态融合的工程化落地 1. 从一个喂食器的误触发说起AIoT端侧识别的真实门槛去年帮一个做宠物硬件的团队看他们的智能喂食器样机场景很简单猫靠近就出粮狗靠近不出粮防止狗偷吃猫粮。听起来是个二分类问题ImageNet上随便一个MobileNet都能跑到95%以上的准确率。但实际部署到设备上之后问题全来了——猫在夜里从侧面靠近红外补光下的灰度图像让模型把猫识别成了狗两只猫同时出现在画面边缘模型因为检测框重叠直接判定为“未知物体”拒绝出粮最离谱的是有一次喂食器对着窗户外面一只流浪猫的影子投在窗帘上设备连续出粮直到粮仓空了。这件事让我意识到猫狗识别在AIoT场景里从来不是一个“模型准确率”问题而是一个系统工程问题。你在PC上跑出来的99%准确率到了端侧设备上受限于算力、内存、功耗、传感器质量、光照条件、安装角度能保住85%就算不错了。而喂食器、摄像头、智能门这三个场景对识别的要求又完全不同——喂食器要的是“宁可错判为猫也不能把狗放进来”摄像头要的是“持续追踪并分类记录”智能门要的是“毫秒级响应且零误开”。这篇文章不打算讲怎么训练一个猫狗分类模型网上这类教程已经够多了。我想聊的是从模型到产品之间那段没人愿意细说的工程距离——算力怎么选、模型怎么裁、数据怎么采、误判怎么兜底、OTA怎么迭代。这些内容在论文里找不到在开源项目的README里也不会写但恰恰是决定一个AIoT产品能不能量产的关键。如果你正在做端侧视觉相关的产品或者准备把某个视觉模型塞进嵌入式设备里下面这些踩坑经验应该能帮你省掉至少两三个月的试错时间。2. 三个场景拆开看喂食器、摄像头、智能门到底要什么2.1 智能喂食器二分类背后的多目标难题喂食器的核心逻辑看起来是“猫来了出粮狗来了不出”但实际产品定义远比这复杂。首先多猫家庭需要区分是哪只猫——有的猫在吃药需要控制食量有的猫刚做完手术需要额外补充营养。这就从二分类变成了多分类个体识别。其次喂食器通常安装在墙角或狭窄空间摄像头视角受限猫可能只露出半个身子或一个尾巴。第三喂食器的工作距离很近通常20到50厘米这个距离下广角镜头会产生明显的畸变猫的脸部特征被拉伸得面目全非。我实测过几个方案用YOLOv5n做检测MobileNetV3做分类在瑞芯微RV1109上跑单帧推理大概80毫秒勉强能到12帧左右。但问题是喂食器不需要连续推理它只需要在红外传感器触发后拍几张照片做判断。所以更合理的做法是事件驱动多帧投票——红外触发后连拍5帧每帧独立推理取多数结果。这样单帧推理时间可以放宽到200毫秒模型容量就能大一倍准确率提升非常明显。另一个容易被忽略的点是负样本的定义。很多团队只采集猫和狗的图片但实际场景里会出现空碗、人手、玩具、影子、飞虫、反光。这些都应该作为独立的负样本类别参与训练否则模型会强行把任何移动物体归到猫或狗里。我建议至少设置“猫”“狗”“其他”三个类别其中“其他”类要覆盖尽可能多的干扰场景。2.2 智能摄像头持续追踪与分类的算力平衡摄像头场景和喂食器完全不同。摄像头是持续工作的需要实时检测、追踪、分类还要把结果推送到云端或本地存储。这里最大的挑战是算力分配——如果每一帧都跑完整的检测分类再强的芯片也扛不住。实际产品中通常采用“检测-追踪-分类”三级流水线轻量检测器每帧运行发现目标后启动追踪器追踪器稳定跟踪若干帧后再触发分类器做精细识别。这个流水线设计的关键参数是触发阈值。检测器置信度低于某个值时只记录不分类高于阈值才启动后续流程。阈值设高了会漏掉很多目标设低了会频繁触发分类器导致算力浪费。我的经验是检测置信度0.3作为记录阈值0.6作为分类触发阈值追踪器连续3帧确认同一目标后才启动分类。这样在典型家庭场景下分类器的调用频率可以降低80%以上。追踪器的选择也有讲究。ByteTrack在端侧表现不错但内存占用偏高轻量级的Kalman滤波IOU匹配虽然简单但在目标交叉时容易丢失ID。我最后用的是简化版ByteTrack——去掉低分检测框的二次匹配只保留高分框的轨迹关联内存占用降低40%在猫狗这种运动相对规律的目标上效果够用。2.3 智能门零误开的硬约束怎么满足智能门是三个场景里要求最苛刻的。喂食器误判了最多浪费点猫粮摄像头误判了最多记录错一条数据但智能门误判了——把狗识别成猫然后开门让狗跑出去或者更严重的把陌生人识别成家庭成员——这是产品事故。智能门的猫狗识别通常用于“宠物进出管理”比如只允许猫通过宠物门狗不能通过。这里的核心指标不是准确率而是误接受率。假设每天有20次宠物靠近一年7300次如果误接受率是0.1%一年会有7次误开。对于宠物门来说7次误开可能意味着狗跑出去7次这是不可接受的。所以误接受率必须控制在0.01%以下也就是万分之一的水平。要达到这个水平单靠模型本身几乎不可能。必须加多模态验证视觉识别之后再用重量传感器确认体重范围用红外对管确认通过时的体型轮廓。只有视觉、重量、轮廓三者都判定为猫才触发开门。这样即使视觉模型误判了重量和轮廓也能兜底。实测下来三重验证可以把误接受率降到0.001%以下。另外智能门的响应时间要求很高宠物走到门前到门打开不能超过300毫秒否则宠物会失去耐心走开。这意味着从传感器触发到电机启动整个链路必须在300毫秒内完成。视觉推理最多只能占100毫秒剩下的时间要留给传感器读取、逻辑判断、电机驱动。所以智能门上的模型必须是极致轻量的我用的是一个只有0.2M参数的定制网络在专用NPU上跑一次推理只要15毫秒。3. 端侧模型选型为什么MobileNet不是唯一答案3.1 参数量、FLOPs和实际延迟的三角关系很多团队选模型时只看参数量和FLOPs觉得越小越快。但实际部署过就知道FLOPs和实际延迟的相关性只有0.6左右。一个FLOPs很低的模型如果算子不被NPU支持回退到CPU执行延迟反而比FLOPs高但全NPU支持的模型大好几倍。我做过一组对比测试在RV1109上跑不同模型输入都是224x224模型参数量FLOPsNPU支持率实测延迟MobileNetV23.4M300M85%45msMobileNetV3-Small2.5M120M70%62msShuffleNetV2 1.0x2.3M146M95%28ms定制CNN0.8M80M100%15ms可以看到MobileNetV3-Small虽然FLOPs最低但因为Hardswish激活函数和SE模块在NPU上支持不好实际延迟反而最高。ShuffleNetV2的通道混洗操作虽然看起来复杂但主流NPU都做了针对性优化实际表现最好。所以选模型的第一步不是看论文里的指标而是拿目标芯片的NPU支持算子列表去筛。不支持的操作要么替换要么接受CPU回退的代价。我通常的做法是先列一个候选模型清单然后逐个在目标芯片上跑benchmark只看实测延迟和内存占用不看论文指标。3.2 量化不是万能药什么时候该用FP16什么时候必须INT8量化是端侧部署的标配但量化的坑也最多。INT8量化能把模型大小压缩到FP32的1/4推理速度提升2到4倍但代价是精度损失。对于猫狗识别这种细粒度分类任务INT8量化后的精度损失可能达到3到5个百分点。我的经验是分情况处理检测网络用INT8检测任务对精度不那么敏感INT8量化后mAP下降通常在1到2个点可以接受。分类网络用FP16分类任务对精度敏感FP16量化后精度损失几乎为零速度比FP32快一倍左右。关键决策层用FP32最后的分类头或者决策逻辑保持FP32确保输出稳定。还有一个容易被忽略的点是量化校准集的选择。很多团队直接用训练集的子集做校准但训练集和实际部署场景的分布往往不一致。比如训练集里猫狗都是白天拍摄的但设备实际工作在夜间红外模式下。用白天数据校准的INT8模型到了夜间红外图像上精度会崩。所以校准集必须包含实际部署场景的各种光照条件最好直接用设备采集的测试数据做校准。3.3 我为什么最终选了ShuffleNetV2做主干经过多轮对比我在猫狗识别项目里最终选了ShuffleNetV2 1.0x作为分类主干检测用的是YOLOv5n的简化版。原因有几个第一ShuffleNetV2的通道混洗操作在瑞芯微、晶晨、全志这几个主流NPU上都有原生支持不需要CPU回退。第二它的精度在ImageNet上比MobileNetV2高1个点左右参数量还更少。第三它的结构规整量化友好INT8量化后精度损失只有1.5个点。检测部分用YOLOv5n的简化版主要是把Focus层换成了普通卷积把SPPF换成了SPP减少了算子种类。虽然精度略降但NPU支持率从75%提升到了95%实际延迟从60毫秒降到了25毫秒。选模型的时候不要迷信论文指标一定要拿目标芯片实测。同一个模型在不同NPU上的表现可能差好几倍。4. 数据采集与标注那些标注规范不会告诉你的事4.1 猫狗数据的特殊性姿态、光照、遮挡猫狗识别和普通人脸识别、车辆识别最大的不同是姿态变化极大。猫可以蜷成一团、伸懒腰、跳跃、钻箱子狗可以站立、趴卧、奔跑、摇尾巴。同一个个体在不同姿态下的视觉差异可能比不同个体在同一姿态下的差异还大。所以数据采集时必须覆盖尽可能多的姿态。我的做法是每只猫狗至少采集500张不同姿态的图片包括正面、侧面、背面、俯视、仰视以及各种身体蜷缩和伸展的状态。光照条件要覆盖白天自然光、夜间红外、室内暖光、逆光、阴影。遮挡情况要包括部分遮挡被家具挡住一半、严重遮挡只露出头或尾巴、以及多目标重叠。这里有个实操技巧用视频抽帧代替拍照。让猫狗在自然状态下活动用摄像头连续录制然后按每秒2到5帧抽帧。这样采集到的姿态分布比摆拍自然得多而且效率高。我通常录10分钟视频就能抽出1000到2000张有效帧。4.2 标注的粒度分类标签还是检测框标注粒度取决于任务需求。如果只是喂食器的“猫来了出粮”只需要图像级分类标签。但如果是摄像头的“追踪并记录每只猫的活动”就需要检测框和个体ID。我的建议是至少标注检测框即使当前任务只需要分类。原因有两个第一检测框可以裁剪出更干净的目标区域提升分类精度。第二后续如果要升级到多目标追踪检测框数据可以直接复用不需要重新标注。标注检测框时要注意框的松紧度。太松会把背景引入太紧会切掉耳朵尾巴等特征。我的标准是框的边缘距离目标身体轮廓留出5到10个像素的余量确保关键特征完整。对于遮挡情况只标注可见部分不要脑补被遮挡的区域。个体ID标注是另一个坑。多猫家庭里两只同品种的猫可能长得非常像标注员很难区分。我的做法是先给每只猫拍一组标准照正面、侧面、背面标注员对照标准照标注。如果实在无法区分就标为“未知个体”不要强行标错。4.3 负样本的采集比正样本更重要前面提到过负样本的重要性这里展开说。负样本的质量直接决定了模型的误报率。我通常把负样本分为几类空场景没有猫狗的画面包括空房间、空喂食器、空门口。干扰物体玩具、抱枕、影子、反光、飞虫、窗帘飘动。人体人手、人腿、人的影子。智能门场景里人体是重要的负样本。其他动物鸟、老鼠、仓鼠等。如果产品可能遇到这些动物必须作为负样本。负样本的数量建议是正样本的2到3倍。采集方式可以主动构造在设备前放置各种干扰物录制视频抽帧。也可以从实际部署中收集误报样本这是最宝贵的负样本来源。我见过太多团队只采集正样本模型上线后误报率居高不下。负样本的采集工作量应该是正样本的两倍以上。5. 误判兜底与多模态融合怎么把误接受率压到万分之一5.1 视觉之外的传感器重量、红外、超声波纯视觉方案在猫狗识别上的误接受率很难做到万分之一以下。必须引入其他传感器做交叉验证。喂食器和智能门场景里最实用的传感器是重量传感器和红外对管。重量传感器的逻辑很简单猫的体重通常在2到6公斤狗的体重从1公斤到50公斤不等。如果视觉判定为猫但重量传感器读数超过8公斤就否决视觉结果。这个逻辑可以把大型犬误判为猫的概率降到接近零。红外对管的逻辑是测量通过物体的高度和宽度。猫通过时的高度通常低于30厘米狗通过时的高度从20厘米到80厘米不等。如果视觉判定为猫但红外对管检测到高度超过35厘米就否决。这两个传感器的成本都很低重量传感器几块钱红外对管几毛钱。但带来的误接受率下降是数量级的。5.2 时序一致性校验连续多帧的投票机制单帧误判可以通过时序一致性来过滤。具体做法是连续N帧的识别结果中如果某一类别的占比超过阈值才输出该结果。比如N5阈值0.8意味着5帧里至少4帧判定为猫才最终输出“猫”。这个机制对静态目标效果很好但对快速移动的目标可能失效。比如猫快速跑过5帧里可能只有2帧拍到猫其他3帧是空场景。所以时序窗口的长度要根据目标运动速度自适应调整。我的做法是检测到目标移动速度快时缩短窗口到3帧目标静止或慢速时延长窗口到7帧。另一个技巧是加权投票。不是简单计数而是根据每帧的置信度加权。置信度高的帧权重更大置信度低的帧权重更小。这样可以进一步降低误判。5.3 拒绝机制不确定的时候选择“不知道”很多团队追求模型对所有输入都给出一个分类结果但实际产品中允许模型输出“不确定”比强行分类更安全。当模型对某一帧的置信度低于某个阈值时输出“未知”交给后续逻辑处理。在喂食器场景里“未知”意味着不出粮等下一帧再判断。在智能门场景里“未知”意味着不开门等宠物再靠近一点或者换一个角度再判断。在摄像头场景里“未知”意味着只记录不分类后续可以人工标注或者云端二次识别。拒绝机制的阈值设定需要权衡。阈值太高拒绝率上升用户体验变差阈值太低误判率上升。我的经验是把阈值设在模型输出概率分布的熵值上熵值高于某个值时判定为“不确定”。这样比固定概率阈值更鲁棒。6. 从实验室到量产OTA迭代与现场数据回流6.1 模型OTA的工程实现端侧设备的模型更新不像云端那么方便需要考虑带宽、存储、回滚。我的做法是差分更新双分区备份。差分更新是指只传输新旧模型的差异部分而不是整个模型文件。一个2MB的模型差分后可能只有200KB传输时间从几分钟降到几秒。实现方式可以用bsdiff或者自研的差分算法。双分区备份是指设备上保留两个模型分区新模型写入备用分区验证通过后再切换。如果新模型导致异常可以快速回滚到旧分区。这个机制在量产设备上是必须的否则一次错误的OTA可能导致大批设备变砖。OTA的触发策略也很重要。不要一次性全量推送先推1%的设备观察一周的误报率和崩溃率没问题再推10%最后全量。这个灰度节奏可以根据设备数量调整但一定要有。6.2 现场数据的自动回流与标注设备部署到用户家里之后会遇到各种训练集里没有的场景。这些现场数据是最宝贵的改进素材。但直接上传用户家里的视频涉及隐私问题必须做脱敏处理。我的做法是设备端只上传模型不确定的帧和误判的帧而且上传前做本地脱敏——只保留目标区域的裁剪图背景全部模糊化。这样既保护了用户隐私又拿到了改进模型所需的关键数据。上传的数据需要自动预标注。可以用一个更大的云端模型做初步标注然后人工审核。这样标注效率能提升5到10倍。审核后的数据加入训练集重新训练模型再通过OTA推送到设备。6.3 版本管理与回滚策略模型版本管理经常被忽视但出了问题的时候至关重要。我建议每个模型版本都记录以下信息训练数据版本、训练超参数、量化配置、测试集指标、部署设备型号、部署时间。回滚策略要提前定义好。什么情况下触发回滚我的标准是新版本部署后一周内如果误报率上升超过20%或者崩溃率超过0.1%自动触发回滚。回滚过程要全自动不需要人工介入。还有一个经验不要频繁更新模型。每次更新都有引入新问题的风险。我通常把模型更新频率控制在每月一次紧急修复除外。每次更新前在测试设备上跑至少一周的稳定性测试。7. 一些实测数据与个人体会最后分享几组实测数据都是我在实际项目中跑出来的供参考。喂食器场景RV1109芯片ShuffleNetV2 1.0x INT8量化输入224x224指标数值单帧推理延迟15ms内存占用8MB猫狗二分类准确率96.2%多猫个体识别准确率88.5%误接受率狗判为猫0.3%加入重量传感器后误接受率0.02%摄像头场景RK3566芯片YOLOv5n简化版ShuffleNetV2指标数值检测延迟25ms分类延迟18ms追踪帧率20fps检测mAP0.591.3%分类准确率94.7%智能门场景定制0.2M参数网络专用NPU指标数值推理延迟15ms误接受率纯视觉0.5%误接受率三重验证0.001%响应时间传感器到电机280ms几个个人体会第一端侧AI产品的瓶颈从来不是模型精度而是工程细节。同样的模型不同的预处理、不同的量化校准、不同的后处理逻辑实际表现可能差一倍。第二多模态融合是降低误判率最有效的手段没有之一。纯视觉方案的天花板很低加上重量和红外传感器之后误判率能降两个数量级。第三现场数据回流是模型持续改进的关键。实验室里永远模拟不出用户家里的所有场景只有把现场数据用起来模型才能越用越准。还有一个容易被忽略的点是温度对传感器的影响。红外传感器在低温环境下灵敏度会下降重量传感器在温度变化时会有零点漂移。这些都需要在固件层面做补偿。我遇到过冬天北方用户反馈喂食器不工作最后发现是红外传感器在零下十度时触发距离从30厘米降到了10厘米猫靠近了但没触发。加了温度补偿之后问题解决。这个领域还有很多可以深挖的方向比如用自监督学习减少标注依赖、用联邦学习在保护隐私的前提下利用多设备数据、用神经架构搜索针对特定NPU做模型定制。但这些都是后话先把上面这些工程基础打牢产品才能稳定跑起来。