去年帮朋友做第一批AIoT宠物产品时我在智能门上撞见了一个特别典型的场景邻居家那只体型偏大的金毛路过门口门铃检测到动物给用户推了一条猫咪来访的通知。用户打开App一看录像里明显是一条狗还是别人家的狗当场就发消息来问是不是识别模型出了问题。这个事让我彻底意识到一个问题猫狗识别在AIoT设备上的落地跟在一台服务器上跑通Demo完全是两码事。模型在云端针对公开数据集调得再漂亮放到喂食器、摄像头、智能门这些端侧设备上要面对的就不只是猫和狗两个类别还有红外夜视、低算力、弱网、误触、隐私各种现实约束。这篇文章就把我在几个实际项目里积累的经验完整梳理一遍包括端侧推理方案的选型逻辑、数据怎么采、模型怎么压、三类硬件各自的部署差异以及踩过的一些坑和排查思路。希望能给正在做或者在评估这类产品的朋友一些参考。1. 先讲清楚为什么猫狗识别必须放在端侧很多人第一反应是这种识别任务直接走云端API不就行了吗但真正做过喂食器、摄像头、智能门的人会告诉你端侧推理不是跟风是这几个场景硬逼出来的。1.1 喂食器首先要过的坎是断网和延迟喂食器的使用环境是家庭客厅、阳台或者宠物笼旁边理论上Wi-Fi应该稳定但实际不是。我统计过一批测试设备一周的数据夜间时段Wi-Fi信号波动导致的连接中断比例相当高而宠物猫又偏偏喜欢在凌晨三四点活动。如果识别逻辑完全依赖云端猫一靠近食盆画面传上去到云端返回结果中间一旦网络抖动吐粮动作就会卡顿甚至丢失。更关键的是延迟。云端单次识别的往返时间在200毫秒到1秒之间浮动叠加设备端图像采集和上传的时间从猫出现在镜头前到设备执行吐粮动作总延迟经常超过2秒。猫的耐心可没这么长它探头闻两下没动静就走了等你识别完食盆前面已经空了。端侧推理把这段延迟压缩到几十毫秒猫还没离开指令已经执行了。1.2 摄像头场景里隐私和带宽是绕不开的两座山家用摄像头做宠物识别最核心的问题是画面要不要上传。许多用户对家里宠物摄像头的隐私非常在意他们可以接受云端保存录像但不能接受每一帧画面都被某个服务来回分析。这个需求是合理存在的端侧推理的价值就在于AI分析直接完成只把猫来了狗在拆家这类事件结果和对应的短视频片段推给用户绝大部分画面数据不出设备。带宽账也很好算。一路720P的H.264视频实时上传理论上需要1-2Mbps的上行带宽而很多家庭的宽带上传本身就有限再加手机、电视、电脑在抢网持续推流的结果就是卡顿。端侧识别之后只需要在检测到目标时上传一段几秒钟的关键片段带宽消耗下降了一个数量级。1.3 智能门的识别-反馈链路必须控制在一秒内智能门宠物门/智能猫门的逻辑是宠物靠近门上的摄像头设备识别出来的是自家猫/自家狗就开锁放行是陌生动物或者人就不动。这个场景对延迟的要求比喂食器还要苛刻——宠物是不会站在那里等着你识别的它走到门前嗅一下如果门没有反应它可能就直接走开或者开始挠门。我们内部定过一个目标从宠物进入检测区域到门锁动作端到端延迟不能超过800毫秒如果条件允许尽量压到500毫秒以内。走云端识别这条链路光网络往返就不止这个数所以智能门产品几乎没有任何选择必须端侧搞定。还有一个容易被忽视的点是本地联动。智能门不光是识别还要跟锁体通信、触发电机、做安全校验这些动作如果在端侧由同一套逻辑统一调度可靠性远比跨网络调用高。有人统计过跨云服务的联动故障率比本地联动高出一个数量级这在涉及门锁安全的产品里是无法接受的。2. 硬件选型和模型压缩先定算力边界再定算法方案确定了要端侧推理之后下一步不是急着找模型而是先明确设备的硬件平台能提供多少算力。我见过太多项目把服务器上的大模型硬塞进端侧设备结果要么跑不动要么发热严重最后推倒重来。正确的顺序是先定算力再选模型结构最后做压缩。2.1 三类常见端侧平台的算力画像产品选型时我习惯把市面上主流的端侧平台分成三类来看这里不点名具体芯片只按实际能力划分入门级MCU加轻量NPU算力在0.5 TOPS到1 TOPS左右内存几十MB级。适合做极低帧率的检测比如喂食器只用1秒一帧做触发判断。这类平台跑不了太大的网络模型通常要压到2MB以内精度得靠数据策略来补。中端SoC四核或八核低功耗CPU搭配2-3 TOPS的NPU内存256MB到512MB。这是目前喂食器和智能门的主流配置能跑5MB-10MB的模型帧率能做到2-5 FPS检测加分类两级流水线基本没有压力。中高端IPC SoC支持4K编解码NPU在4-6 TOPS内存1GB以上。适合摄像头这类需要处理更高分辨率、同时在多路流上做分析的设备模型可以放宽到15MB左右。我给朋友的建议也很直接如果产品还没有定型先按可能要同时处理检测和分类两个任务来估算算力需求宁可预留30%的冗余也不要卡着极限选芯片。因为软件上后面每加一个需求比如识别装猫粮的碗、识别宠物进食行为都要消耗额外的算力。2.2 主干网络选型和INT8量化实操模型结构上我踩过一圈之后的经验是端侧宠物识别不需要追求SOTA精度而是要在召回率和算力开销之间找平衡。检测部分用轻量化的单阶段检测网络YOLO系或类似结构的轻量版即可主干用比MobileNetV3稍强一级的网络分类部分用更小的轻量分类网络专门负责区分猫和狗以及其他类别。最关键的优化手段是量化。训练好的FP32模型权重动辄十几MB直接跑在中端SoC上内存占用高、推理速度慢。用训练后量化PTQ把模型转成INT8体积能压到原来的四分之一左右推理速度提升2-3倍缺点是精度会有一定损失。如果你发现INT8量化后召回率掉得厉害尤其是夜间红外图像这类分布偏移大的场景就得上量化感知训练QAT把量化误差在训练阶段就模拟进去。我在一个摄像头项目里做过对比同一份数据集PTQ方案在白天场景猫的召回率只降0.5个百分点但夜间红外场景降了接近3个百分点换成QAT之后夜间差距缩回到0.8个百分点以内这个差距在真实产品里就是偶尔漏一次和经常漏的区别。2.3 知识蒸馏让大模型的经验替小模型开路如果业务上希望保留的分类细度较高比如要区分不同品种或年龄段又受限于算力我的经验是引入知识蒸馏先训练一个参数量大的教师模型然后把教师模型输出的软标签soft label拿来训练端侧的小模型。蒸馏的好处不光是精度提升更明显的是让小模型在模棱两可的样本上更稳定。举个例子一只花纹很特殊的狸花猫跟某些田园犬幼崽在形态上有相似之处小模型自己学的时候很容易在高置信度的错误答案上自信地犯错。蒸馏之后它会继承教师模型对这类难样本的犹豫和倾向输出概率分布更平滑实际部署中反而更可靠。我们测试过蒸馏后的小模型在难样本上的错误率比直接训练降低了约30%。3. 数据采集和标注猫狗识别的真正护城河在数据算法结构选得再好公开数据集里的猫狗图片跟实际设备拍到的画面差距也很大。Bert、大黄、豆豆这些真实宠物在家里的样子与ImageNet里摆拍的猫狗完全是两码事。我做了几个项目后最大的体会是这场仗的胜负手是数据不是网络结构。3.1 同一种猫在不同环境下的特征漂移端侧设备拍摄的宠物图像有一个核心特点环境多样性极大而目标对象又高度相同。同一只布偶猫白天在窗台上逆光拍是一种颜色晚上开灯后暖光下又是另一种色调到了夜间红外模式整张图变成黑白灰纹理细节丢失一大半。算法如果只见过自然光下的图像一到晚上就开始眼拙。我后来定了一条规矩所有训练数据必须按设备实拍为主公开数据集只能做预训练或者补充。实拍数据要覆盖几个固定维度光线自然光、暖光、冷光、红外夜视、角度俯视、平视、仰视、距离0.3米、1米、3米、遮挡宠物经过家具后面、半个身子在画面外。每个维度都要有足够的样本量不然模型在真实场景里一定会出问题。3.2 负样本的收集难度远比正样本大另一个容易被忽略的点是负样本。猫狗识别里的其他类别包括人、其他动物、扫地机器人、玩具、植物影子这些画面里的常见物体。负样本的重要性在于它能直接压制误报率。我见过有个团队把检测模型的阈值调得很高结果猫漏检率上去了调低阈值人路过就会被当成狗。原因就是负样本太少模型没见过人长什么样自然不知道该把人归到哪去。负样本的采集策略我建议是来源混杂室内人的各种姿态坐着的、走动的、只露出腿的、其他常见宠物兔子、仓鼠、还有非生物包、盆栽、宠物玩具、倒影。负样本数量至少要占总数据量的30%-40%这是一个很实用的经验值。3.3 标注标准遮挡、多目标、运动模糊的处理标注标准这件事如果团队里没有统一后面模型训练和评测都会乱套。我踩过几次坑之后总结了一套标准直接拿来用在项目里检测框必须紧贴目标可见部分。猫从家具后面探出半个头就只框半个头不要脑补出完整身体。区分漏检样本和难样本。两个目标重叠在一起后面那只只露一只耳朵的标注时仍然要给框但要在标签里注明遮挡程度方便分析。运动模糊不删除。宠物跑动时画面模糊是真实产品里必然出现的一定要让模型见过这类模糊图。多目标场景单独清点。三只猫同时出现在画面里模型输出三个框才叫正确合并成一个框就是错误。这套标准看着简单但能保证团队里标注人员和算法工程师对什么是对的理解一致减少大量无效沟通。4. 算法流水线检测、分类、跟踪如何在端侧协同模型不是单独跑的端侧算力有限所有模块必须串成一条高效的流水线。我在项目里反复调整后的方案是先检测后分类再跟踪用不同的帧率调度来平衡算力与响应速度。4.1 两级结构的必要性不分尊卑的串行处理早期我试过用一个多任务模型同时输出框和类别省去了分类步骤但实际效果并不理想。多任务模型在算力受限设备上检测头和分类头互相抢资源导致边界框抖动和类别置信度都不稳定。后来改回检测分类两级结构检测网络在整帧图上找目标输出候选框分类网络只对候选框区域做二次判断输出猫/狗/其他三类概率。两级结构的总算力开销反而比单模型低因为分类网络的输入很小计算量可以忽略不计而检测网络不需要承担分类压力专注把框打准。4.2 帧率调度不是每一帧都需要满负荷推理帧率策略是一个性价比极高的优化手段。我的做法是分模式处理待机模式设备没有检测到任何运动目标时以较低帧率跑检测比如每秒1帧省电省算力。激活模式一旦检测到有目标进入画面立即提高帧率比如每秒3-5帧并启动分类和跟踪。休眠模式连续一段时间比如30秒没有目标退回待机模式。这里有个细节运动检测本身用像素差分这类传统方法就能做成本极低不需要让神经网络去扛。用传统运动检测当闹钟把神经网络从待机模式里唤醒这套组合在低功耗设备上非常重要。4.3 置信度融合与目标跟踪解决同猫不同命的问题单帧识别结果在端侧是不可以直接信的操作信号。一只猫走过镜头前中途被桌子腿挡住半秒模型在这一帧输出低置信度如果设备以这一帧为准可能就漏掉了触发动作。我的处理方式是把跟踪结果与时序平滑结合起来目标被跟踪到后维护一个滑动窗口记录最近N帧的分类结果只有连续M帧都判定为同一类别且平均置信度超过阈值才确认触发。具体参数我建议按设备形态来调喂食器可以要求连续3帧确认因为吐粮动作稍慢一点问题不大智能门则建议缩短到2帧确认因为门锁动作本身还要花时间宠物不会一直等着。时序确认的代价是增加了延迟但也显著降低了单帧误判带来的误操作风险。# 端侧推理循环的核心调度逻辑伪代码 state idle for frame in camera_stream(): if state idle: if motion_detect(frame): # 传统运动检测几乎不耗NPU state active continue # 当前帧直接进入激活态分析 elif state active: detections detector(frame) # 检测网络跑一次 for det in detections: if det.score conf_det: # 检出低置信度跳过 continue label classifier(crop(frame, det.box)) tracker.update(det.box, label) if tracker.confirmed(): act_on_device(tracker.category()) if no_target_for(30): state idle这个伪代码里的关键在于motion_detect作为第一道闸门承担了大部分空转时间的算力消耗NPU只在真的有事发生时才被调用。对电池供电的喂食器来说这套逻辑能把整机平均功耗往下拉一大截。5. 三种硬件形态的部署差异同一个模型三种调法同样的猫狗识别模型放到喂食器、摄像头、智能门里参数和策略是完全不一样的。很多人以为改了模型大小就行实际差别远不止这些。5.1 喂食器低功耗常开是核心矛盾喂食器的典型场景是24小时通电插电款或电池供电便携款无论哪种形态功耗都是关键指标。插电款虽然不用考虑电池消耗但设备表面温度会影响宠物靠近的意愿我实测过外壳温度超过40度时部分猫咪会明显抗拒接近食盆区域。所以推理策略要尽量被动化大部分时间处于极低功耗待机只靠运动检测维持最低频率的巡逻。喂食器的另一个特殊点是视角。食盆和摄像头的位置关系决定了猫的朝向猫低头吃饭时脸是朝下的背对着摄像头模型看不到正脸。我刚开始做时没注意这一点用一堆正脸数据训练出来的模型在真实场景里经常识别不到猫的背面导致猫都吃完了设备还没反应过来。后来专门补充了臀部和背面的视角数据识别率才上来。触发动作方面喂食器建议做预触发延迟确认检测到猫靠近时先做好出粮准备待连续确认后再执行避免猫咪只是路过食盆就被吐了一堆粮。5.2 摄像头持续视频流上的时域平滑比单帧精度更重要摄像头是唯一一种画面一直在动的设备宠物会在画面里跑来跑去模型每一帧的检测结果天然会抖动。摄像头的部署要点是不要追求每一帧都判断精准而是要做好时域上的平滑和事件化。事件化是摄像头的产品逻辑核心。用户真正关心的不是检测到猫而是猫什么时候来的猫干了什么。我在摄像头项目里额外加了一个简单的行为分类目标静止、目标移动、目标逗留。如果一只猫出现在画面里并逗留超过5分钟这通常比路过更有提醒价值。这个行为分类不需要额外跑一个模型用跟踪模块里目标框的位置变化速度就能推断出来。另一个摄像头特定的挑战是画面比例。家用摄像头大多是广角画面边缘的宠物会被拉伸变形同一个模型在画面中心识别得好好的宠物一走到边缘就反复漏检。解决方案有两个训练时增加边缘区域的裁剪样本或者推理时对画面边缘目标做额外的置信度修正。前者治本后者治标建议都做上。5.3 智能门快速唤醒与防误触的平衡艺术智能门的识别逻辑核心是门禁识别对了要果断开门识别错了开门是安全隐患。所以智能门产品要在快速唤醒和严格防误触之间找到平衡。快速唤醒要求设备从低功耗待机到检测出结果的时间尽量短。我在智能门项目里用的策略是运动传感器只负责有没有目标靠近这个二进制判断触发后立即以最高帧率跑推理流水线同时门锁动作设计成分阶段执行——先完成朝向判断和靠近判断再结合类别判断决定是否真正落锁。防误触的做法是把其他类别的判定做得更保守。智能门跟喂食器不一样宁可漏一次猫挠门没开也不能误放一只陌生动物进屋。所以智能门分类阈值要比喂食器高不少而且必须加目标离开判断如果一只猫在门前了分类结果不稳定设备应该保持锁定等目标离开画面后才恢复待机而不是在分类结果反复横跳时冒险动作。三种设备的优先级差异我用一张表整理过贴在这里方便对照设备形态首要指标识别触发策略负面风险容忍度喂食器低功耗常开预触发连续确认漏一次问题不大误触发浪费粮食摄像头事件连续性时域平滑逗留判断漏检影响用户体验误报产生打扰智能门安全性与延迟快速唤醒保守分类漏一次可接受误开门不可接受6. 实测踩坑四个经典问题的完整复盘再好的方案设计真正部署到用户家里总会遇到预料之外的事。下面这几个坑都是我在真实测试中踩过并且完整排查过的写出来供各位参考。6.1 夜间红外模式下的人眼反光误判有一次摄像头项目做夜间测试模型频繁报告检测到猫但回看录像画面上什么都没有偶尔有用户路过。排查链路是这样的先怀疑是运动检测误触发检查后发现运动触发的区域确实有目标然后导出这些帧给分类模型看模型输出的最高类别确实是猫再人工查看原图发现在红外模式下人眼的反光点非常接近猫眼在红外下的光斑特征。进一步分析后确认检测网络把眼球反光区域当成潜在目标框出来分类网络在低分辨率裁剪图里看到的又是一团亮斑跟猫脸特征有重叠。修复方案有两个一是检测阶段增加目标尺寸合理性过滤眼球反光产生的候选框通常尺寸极小远低于宠物目标最小尺寸阈值直接丢弃二是训练阶段增加大量红外环境下的人眼、猫眼对比样本让分类网络学会区分亮斑和猫脸。两招齐上之后夜间误报率下降了约七成。6.2 短腿犬视角导致的下半身漏检智能门项目里有个用户的宠物是只柯基个子矮靠近门上的摄像头时画面里只出现半个背部和脊背曲线没有头没有腿。检测模型反复漏检即使检测到了分类网络也倾向于判成其他因为它没见过只有脊背加上两条短腿这种构图。排查后发现问题出在公开数据集的视角偏差上公开数据里狗的图像绝大多数是站立全身照或正脸照很少有从高处俯拍一只矮狗靠近的机位。修复方法是针对性的数据采集在模拟门上安装了与真实产品同机位的摄像头录制了多只不同体型的宠物靠近门的画面专门标注这类局部身体样本然后做数据增强——把正常样本随机裁剪掉上半身强制模型学习只看到脊背也要能认出是狗。补了这批数据之后短腿犬的召回率恢复到了和普通犬接近的水平。6.3 主人和宠物同时出现在画面时的优先级冲突摄像头项目里有个真实反馈用户在家自家猫走到摄像头前面然后主人也走到猫旁边想把它抱走。这时候系统该报什么如果只有猫/狗/其他三个类别人一入画检测网络输出两个框一个猫一个其他分类没问题但跟踪模块在框匹配时出现了混乱把人和猫的轨迹串了导致用户收到的提醒一会儿是猫出现在客厅一会儿是未识别目标出现在客厅体验很差。排查后发现问题出在跟踪的匹配策略上目标框距离较近时匈牙利匹配容易把类别不同的轨迹错配在一起。修复方法是给跟踪器的匹配代价矩阵加一个惩罚项——类别不同的候选框匹配代价上调强制同类才优先匹配同时系统消息推送增加同屏多人多宠的合并逻辑只在首次出现时通知一次后续变化通过状态更新推送而不是重复打扰用户。6.4 设备发热导致推理掉帧进而引发级联误判这是最隐蔽的一个坑。某台喂食器测试机在持续运行一小时后识别响应明显变慢而且开始出现明明没有猫却偶尔触发吐粮的怪象。一开始我以为是模型过拟合或者偶发误判后来查设备日志发现发热导致CPU降频NPU任务排队实际推理帧率从设计的2 FPS掉到了0.3 FPS系统在低帧率下依然按原参数累积连续确认就出现了旧帧的检测结果被延迟处理和新帧结果叠加的时序错乱。修复分两层硬件层面优化散热贴布局软件层面增加时间戳有效窗口——超过0.8秒未更新的检测结果不允许参与确认累积同时引入了降频标记检测到NPU负载持续过高时主动降低待机帧率避免算力过载。这个问题也给我提了个醒端侧推理的性能测试一定要做长时压测不能只看开机前三分钟的表现。7. 验收指标、灰度发布与长期维护的实操经验产品做到后期最大的问题不是能不能跑通而是怎么证明它稳定。这一章讲的是我在几个项目里沉淀下来的验收和维护方法。7.1 一套能真实反映现场表现的评测标准很多团队验收模型时只用测试集准确率这个指标在AIoT场景下会骗人。因为测试集通常是均衡分布的而真实场景里无目标画面占了绝大多数时间。一个模型在工作日里可能99%的帧都在处理空画面误报率哪怕只有1%按一天86400帧算也是几百次误触发用户早就疯了。我的验收标准是分场景组合评测白天、夜间红外、逆光、遮挡、多目标、运动模糊六类场景分别统计检测召回率、分类准确率、误报率。更关键的是要算每日误报次数这个产品级指标而不是只看模型的百分数。当时我们内部定的及格线是一台设备每天误触发不超过3次否则就得回到数据环节补样本。这个标准看上去苛刻但实际运行起来确实能守住用户体验的底线。7.2 现场数据的闭环回流机制模型上线不是终点长期维护靠的是现场数据回流。我在每个设备上都加了难样本上报功能当跟踪目标在连续多帧里保持低置信度比如最高置信度只有0.4-0.6设备会把这一小段视频匿名化后上传作为候选难样本存入云端。每周对这些样本做一次人工复核和标注补充进训练集再定期发布模型更新。这套机制跑起来之后模型每个月都能看到上个星期用户家里新发生的情况老问题会越来越少。比如有个用户家养的是纯黑猫夜间场景下模型识别率一直不稳定正是通过难样本回流专门积累了黑色宠物在低照度下的数据才把推送准确率拉上去。7.3 OTA升级模型时的兼容性测试最后提醒一句OTA升级很容易被人忽略。模型文件不是换了就完事新模型跟旧版本驱动、推理框架、后处理逻辑之间都可能存在兼容性问题。我见过一次事故新模型在部分旧型号设备上因为图像输入尺寸的处理逻辑不兼容所有检测结果都偏移了约5%的画面位置导致推送的截图框不准。所以我的固定流程是每次模型更新前先拿三种典型设备型号做冒烟测试覆盖待机唤醒、连续推理、长时间运行三个场景如果有一个环节不合格就不发布。同时OTA包必须带版本回滚机制万一发布后出现大范围问题可以一键退回上一个稳定版本。看似多了一道工序但能规避的线上事故风险非常大。聊到这儿几个项目的经验差不多都摊开说完了。如果让我用一句话总结AIoT场景下猫狗识别的核心那就是算法只是链条上的一环真正决定产品好坏的是对设备形态、功耗、延迟、场景数据的综合把控。尤其建议打算入手的团队第一次做别急着优化精度先完整跑通端侧采集—识别—动作—回传这条链路中间所有的坑都会逼你把方案调整到位。另外再分享一个小技巧在所有设备上都留一个调试接口方便远程导出某一帧的模型输出结果排查问题时能省下大量时间。