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：

可以看到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帧的识别结果中，如果某一类别的占比超过阈值，才输出该结果。比如N=5，阈值=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：

摄像头场景，RK3566芯片，YOLOv5n简化版+ShuffleNetV2：

智能门场景，定制0.2M参数网络，专用NPU：

几个个人体会：第一，端侧AI产品的瓶颈从来不是模型精度，而是工程细节。同样的模型，不同的预处理、不同的量化校准、不同的后处理逻辑，实际表现可能差一倍。第二，多模态融合是降低误判率最有效的手段，没有之一。纯视觉方案的天花板很低，加上重量和红外传感器之后，误判率能降两个数量级。第三，现场数据回流是模型持续改进的关键。实验室里永远模拟不出用户家里的所有场景，只有把现场数据用起来，模型才能越用越准。

还有一个容易被忽略的点是温度对传感器的影响。红外传感器在低温环境下灵敏度会下降，重量传感器在温度变化时会有零点漂移。这些都需要在固件层面做补偿。我遇到过冬天北方用户反馈喂食器不工作，最后发现是红外传感器在零下十度时触发距离从30厘米降到了10厘米，猫靠近了但没触发。加了温度补偿之后问题解决。

这个领域还有很多可以深挖的方向，比如用自监督学习减少标注依赖、用联邦学习在保护隐私的前提下利用多设备数据、用神经架构搜索针对特定NPU做模型定制。但这些都是后话，先把上面这些工程基础打牢，产品才能稳定跑起来。