手头同时在推三个看起来八竿子打不着的硬件产品项目宠物翻译机、婴儿护理助手、AI故事机。它们的产品形态完全不同用户群体也不重叠但干到后面我发现三个项目的技术架构其实惊人地一致底层都是同一套“实时音视频 多模态AI”的骨架。宠物机要实时识别猫狗的肢体和叫声婴儿机要盯着宝宝有没有翻身、哭闹和危险动作故事机要听懂孩子的语音并现场编故事念出来本质上都是“传感器采集数据 → 多模态理解 → 生成反馈”的闭环。这篇文章我就把这三个项目拆开讲顺便聊一个我们在其他行业里用同样架构做过的智慧交通事故检测系统给正在做端侧AI设备或音视频应用中台的人做个参考。1. 架构拆解三个产品共用一套骨架先说最初级的疑问这三个产品从外观到使用场景没有一处相似凭什么说架构是一套你如果把“功能”两个字去掉只看数据流就会发现所有端侧智能设备本质上都在重复同一件事。1.1 从场景抽象出统一闭环拿最典型的实时音视频设备来说宠物翻译机、婴儿护理助手、AI故事机都躲不开这条链路采集 → 预处理 → 感知 → 理解与决策 → 生成 → 回放或推送用一张文本图表示就是摄像头麦克风持续采集 → 噪声抑制/抽帧/编码 → YOLO目标检测或语音事件识别 → 行为状态机或大模型推理 → TTS合成/音效生成/告警推送 → 用户听到声音、看到画面或收到通知宠物翻译机里的实现是摄像头拍摄猫狗姿态麦克风收录叫声先判断“这是兴奋的摇尾巴还是害怕的炸毛”再结合吠叫/喵叫的音频特征最后输出一句类似“狗狗现在情绪很兴奋想让你陪它玩”的话。婴儿护理助手复杂一些摄像头拍宝宝睡姿和位置麦克风收哭声和呼吸声温湿度传感器采集环境数据模型判断“宝宝是否处于趴睡状态”“哭声属于饥饿、疼痛还是困倦”“室内温度是否过高”触发条件满足后给家长手机推一条分级报警。AI故事机相对简单孩子按下按钮说“给我讲个恐龙冒险的故事”语音转写成文本后送入LLM生成分章节的儿童故事再用定制音色TTS输出同时驱动一段AI插画或动画表情。三个场景差别很大但落到系统设计图上都是同样的几个模块在换不同的模型和交互策略。所以我在项目里一直强调一件事不要为每个产品单独从零搭一套AI中台而是把整个感知链路抽象成一个统一的“实时感知引擎”。1.2 端云协同边缘优先这三个产品对实时性都有硬要求但又不允许永远在线依赖云端。宠物机和婴儿机很多时间放在家里一旦断网或网络波动就必须本地兜底故事机虽然可以联网但孩子一句“再讲一遍”如果等上3秒体验就崩了。所以我会把架构拆成三层层级承担任务典型硬件/技术延迟要求设备端采集、降噪、抽帧、轻量推理、本地播放摄像头、麦克风阵列、NPU芯片、YOLO小模型本地推理 ≤ 100ms边缘网关多设备联动、协议解析、模型按需下发家庭网关、容器编排、MQTT事件响应 ≤ 400ms云端大规模模型训练、复杂语义理解、日志分析GPU训练集群、LLM/VLM、CKPT管理兜底请求 ≤ 1s婴儿护理助手有个典型场景夜间摄像头在卧室拍视频家长在客厅看手机。如果把原始视频一直推上云隐私压力大带宽也扛不住。我们的做法是设备端先做画面中人形/婴儿区域检测只在检测到姿态变化或哭声异常时才上传一小段低分辨率裁剪片段到云端做二次确认。这样既保证实时性又能把隐私数据控制在一个很小的范围内。这套三层结构三个产品通用。宠物机重推理轻语义端侧放一个轻量分类模型就够了故事机轻推理重语义端侧只做语音唤醒和STT真正生成故事的LLM放云上婴儿机则两者都重要所以分级报警逻辑必须做完整。2. 核心技术点逐个啃从采集、感知到生成很多团队一上来就调大模型结果发现设备端根本跑不动最后只能全部上云还搞得体验很烂。我个人的习惯是先解决采集和预处理因为这一步决定了后面的识别准确率上限。2.1 实时音视频采集与预处理宠物机第一版硬件用了普通广角摄像头结果猫在客厅角落走动时虚焦严重后来换了低照度感光和大光圈镜头才解决。婴儿机则要考虑红外夜视宝宝在黑暗中睡觉时不能开补光灯否则会刺激眼睛但红外画面喂给YOLO目标检测模型又容易出现掉检测的坑。我们当时的做法是训练样本里混入20%的红外灰度图专门做数据增强。音频侧我踩过的坑更大。宠物机想识别猫叫结果家里电视声、吸尘器声、窗外车流声全被收进去。后来上了一个标准预处理链# 端侧音频预处理伪代码 import webrtcvad import numpy as np def process_audio_frame(frame, sample_rate16000): # 1. 先做回声消除和降噪避免扬声器声音干扰识别 frame acoustic_echo_cancellation(frame) frame noise_suppression(frame) # 2. VAD检测有效语音段空闲帧直接丢弃 vad webrtcvad.Vad(2) if not vad.is_speech(frame, sample_rate): return None # 3. 音量归一化防止远近差异影响分类 frame peak_normalize(frame) return frame完整流程包括回声消除AEC、噪声抑制NS、自动增益控制AGC、VAD语音活动检测。不做这四步就去跑叫声分类准确率会直接掉到不够用的水平。视频抽帧方面固定帧率抽帧加事件触发抽帧并行。宠物机平时1帧/秒抽帧做运动检测一旦检测到目标进入画面就切成10帧/秒婴儿机则用区域ROI裁剪只对婴儿床区域做高分辨率检测。这比全画面跑模型的算力开销省很多。2.2 视觉、语音、文本多模态理解这三个产品恰好覆盖了多模态AI的三大类输入视觉、语音、文本。视觉这边我们核心用的是YOLO系列做目标检测。宠物机用YOLOv8n检测猫狗主体并裁剪出目标区域再送入姿态估计模型婴儿机用YOLOv5s检测婴儿、床围、枕头和毛绒玩具通过目标之间的相对位置关系判断是否有窒息风险。婴儿机里还有一个细节光检测婴儿还不够必须判断婴儿面部是否被遮挡所以输出层里加了“face_covered”类别。语音这块宠物机是音频事件分类不是语音识别我们把叫声片段切出来提取梅尔频谱和Mel Cepstral特征送入CNN分类器。婴儿哭声分类也差不多但在预训练特征上做得更重用了VGGish模型抽取音频embedding再挂一个四分类头区分饥饿、疼痛、困倦和恐惧。文本这块主要靠ASR和LLM。故事机的STT我们一开始用云端通用模型但孩子口齿不清、句子结构乱识别率惨不忍睹。后来引入儿童语音适配数据和领域纠错词表效果才起来。LLM则是主故事生成引擎负责把“恐龙冒险”“去月球”“和小兔子做朋友”这类指令扩写成完整故事线。多模态融合是这套架构最需要注意的地方。我给婴儿机定过一个规则只靠哭声分类报警会有大量误报必须满足“哭了”和“在摇床上翻滚”两个条件同时成立才触发高风险等级。这就是典型的晚期融合策略。宠物机如果只靠尾巴摆动判断兴奋猫在玩耍时也会摇尾巴所以要把视频姿态、叫声频段、甚至耳朵朝向一起做加权判断。2.3 生成与反馈链路实时音视频产品的最终体验是由输出端决定的。宠物翻译机如果只合成一句冷冰冰的“当前情绪兴奋”用户不会觉得它智能。我们后续接入了音色合成把狗的特定情绪对应到一段更接近犬类发声规律的声音同时附带一句人声说明听起来就像“翻译机先汪汪两声再告诉你狗想干什么”。AI故事机的生成链路最重。孩子说完故事主题后LLM先生成一个带插画提示词的故事大纲再把大纲按三到五章生成正文每条生成结果过内容过滤最后TTS合成有叙事感的音频同时在屏幕上渲染角色画面。这里面有一个很容易被忽略的问题TTS一次性合成太长的音频会导致首句延迟极高必须按句子流式拼接让孩子在1秒内先听到开头。婴儿护理助手的输出其实不是声音而是报警和状态推送。我们设计了多级反馈低级别是App内提示“宝宝动了一下”中级别是推送“宝宝翻身到趴睡姿势”高级别则是电话呼叫家长。输出策略本身也要做成可配置否则孩子一动就推消息家长两天就卸载了。3. 三个产品的落地实现要点同一个架构落到三个产品上具体工程实现各有各的讲究。我按产品拆开说每个产品都给一份可以直接抄作业的要点。3.1 宠物翻译机行为识别加情绪映射宠物翻译机最容易翻车的地方是“翻译”这个词被消费者过度期待。猫狗根本没有人类语言不可能做到逐字翻译。我们的产品定位是“情绪和需求理解助手”只输出状态标签和行动建议。技术上分两条线音频事件线用Wake Word模型检测特定吠叫/喵叫把叫声段截取下来提取声学特征分类到兴奋、饥饿、警戒、无聊、痛苦五个情绪桶。视觉行为线用YOLO检测猫狗的位置再用骨骼关键点模型识别尾巴位置、耳朵朝向、身体蜷缩程度。尾巴竖直、耳朵前倾大概率是兴奋尾巴夹紧、身体低伏往往对应恐惧。最后把两条线做融合例如音频判定“警戒”视觉判定“炸毛”合并输出“狗狗现在警戒心很强可能是听到了门外陌生的声音先不要强行靠近它”。数据集是最大的成本。公开的猫叫狗叫数据集很杂噪声场景不一致。我们后来自己录了三只猫两条狗连续采集一个月又花钱标注了一批负面样本吸尘器声、门铃声、脚步声才把误识别率压到可接受范围。3.2 婴儿护理助手状态机加分级报警婴儿护理助手的核心不是“识别哭声”而是“在一个连续时序里判断状态变化”。宝宝饿了的哭声、困了揉眼睛的动作、翻身被压住的风险必须放在一个状态机里管理。我们的状态机设计大约是初始状态: 检测到婴儿在床中 → 睡眠状态: 闭嘴无哭声呼吸平稳 → 躁动状态: 翻身次数增加发出吭哧声 → 哭闹状态: 哭声分类触发 → 危险状态: 趴睡 面部遮挡 持续无动作在做视觉检测时YOLO检测完婴儿位置之后再用一个轻量分类网络判断婴儿姿态区分仰卧、侧卧、俯卧。这里有个经验趴睡不一定危险但要结合面部遮挡和活动时长判断所以我们引入了时间窗口短时间趴睡不报警超过20秒且检测到面部大面积被遮挡才升级为高风险。哭声分类我建议用“预训练特征加小的分类头”不要从零训练大模型。我们用VGGish提取embedding后接三个全连接层参数量只有不到2M在端侧芯片上跑一次只要15ms。四类哭声准确率能做到85%左右但真实家庭环境里总有猫叫、手机铃声干扰所以还会加一个环境音自动校准机制。另外隐私是婴儿机绕不开的坎。我们设备端视频默认只做特征提取不上传原始视频。家长在App上回看录像也是从本地SD卡读取云端只保留报警事件和对应的裁剪片段摘要。3.3 AI故事机语音交互加安全生成AI故事机更像一个慢速实时系统它对延迟的容忍度比婴儿机高一点但对内容安全的要求又最高。孩子直接和它对话生成的每个字都要保证适合儿童。语音交互流程是先本地唤醒词识别“小智小智”唤醒后开始录音等孩子说完一个句子再送入STT。这里有一个关键点孩子说话没有明确停顿我们用了静音检测加最大时长双重机制比如连续1.2秒没检测到声音就判定句子结束最多等5秒防止孩子思考时被截断。LLM生成故事之前要经过两道关卡输入侧安全关键词黑名单加意图分类孩子说“讲个带刀的故事”这类表述会被改写为“讲个骑士保护城堡的故事”。输出侧安全每次生成的文本先过一个儿童内容过滤器再交给TTS。第三方开源大模型偶尔会输出抽象内容这个过滤器不能省。为了让故事有延续感我们维护了一个简单的人物卡孩子第一次说“主角是小红”后面每次新故事都会自动带入小红再加上“喜欢冒险”的性格标签。这不需要长记忆系统只需要在Prompt里拼接几行结构化记忆就够用。4. 工程化路上的坑延迟、功耗、隐私、误报这些产品不是跑通Demo就算完真正走到量产阶段每一分钟都在跟延迟、功耗、误报和隐私打交道。4.1 延迟链路优化我先给一份我们实际用的延迟预算表单位毫秒模块宠物翻译机婴儿护理助手AI故事机采集与预处理403530视觉/语音推理807050语义理解与决策3020150生成与回放5040300整体端到端≤250≤200≤800婴儿机端到端控制在200毫秒内靠的是设备端NPU跑YOLO。故事机整体800毫秒看起来不高但孩子实际感知是按下按钮到听见第一个词的时间所以我们采用流式TTS第一句话的音频帧一旦生成就立即播放不用等整段故事合成完。一个经验不要把所有模型都扔到NPU上跑。有些后处理逻辑放在CPU上更灵活NPU主要扛卷积和Transformer的密集计算。我见过团队为了把某个模型塞进NPU折腾两周做量化重训最后发现收益还不如把预处理优化一下来得大。4.2 功耗与散热这三个设备都是家用电器的形态不是数据中心服务器功耗必须压住。宠物翻译机如果插着电永远满负荷跑用户摸到外壳发热就会退货。我们加了动态调频策略平时只跑VAD和低帧率运动检测CPU负载低于10%检测到猫狗进入画面才唤醒NPU做YOLO推理。事件过去5秒自动回到低功耗状态。婴儿机因为是长时间连续监控功耗压力更大。优化方案是分两级模型第一级是一个极小的运动检测网络在低分辨率灰度图上跑每秒判别画面是否变化只有在画面明显变化时才唤醒大模型做细粒度分析。这套策略把平均功耗从4.8W降到了2.1W电池模式下晚上能撑整夜。4.3 误报率控制与个性化做婴儿机的时候误报是比漏报还麻烦的事。漏报可以靠提高灵敏度补偿误报太多家长会直接关机。我们用了两个技巧长窗口状态确认单帧识别到趴睡不会马上报警必须连续N帧确认再用一个轻量跟踪器判断婴儿是否真的维持该姿态而不是转身瞬间的误检。个性化环境消噪每个家庭底噪不同猫叫、空调声都可能触发哭声分类。我们在设备首次安装后采集一周环境音样本自动计算一个“家庭噪声基底”在推理时做频谱扣除。宠物翻译机的误报更隐蔽。猫在舔毛时发出呼噜声如果模型训练数据里没有这种样本就会把它当成“痛苦”类别。后来我们在标注体系里增加了一个“未知/其他”类凡是置信度不超过阈值的都归到这一类宁可不说也不要说错。4.4 隐私与数据安全儿童设备没有隐私保护基本无法上线。AI故事机会收集孩子语音和偏好婴儿机会涉及婴儿视频这两类数据都是高敏内容。我们的原则是能本地处理就绝不上传。婴儿机的视觉特征提取、故事机的唤醒词识别、STT中的首轮粗识别都放在设备端。云端只收脱敏后的特征、文本转写结果、模型日志不收原始音频和视频。用户必须能一键清空数据。故事机在App里提供了“清除我的语音数据”按钮点击后云端和端侧同时删除。5. 从这三个场景到智慧交通检测一个复用度极高的模式代码和架构在行业间迁移这件事我们后来在智慧交通事故检测分析系统项目里又验证了一次。那个系统和宠物机、婴儿机从场景上毫无关系但打开系统结构一看又是同一套“实时音视频 多模态AI”的模式。5.1 智慧交通事故检测系统的架构参考在智慧交通行业里常见需求是道路摄像头拍到交通事故后自动识别并告警。早期都是靠人工盯监控屏人盯久了会疲劳。我们做的智慧交通事故检测分析系统基本流程是路侧摄像头实时视频流通过RTSP接入YOLO目标检测识别车辆、行人、摩托车、护栏、交通标志等道路元素多模态AI分析模块综合目标位置、运动轨迹、速度变化、碰撞时间TTC判断是否发生异常事件检测到疑似事故后触发截图取证、告警推送并同步给后台调度系统。这里如果用我第一次架构时的视角去看它就是一个“比较大的婴儿护理助手”摄像头是传感器YOLO是视觉感知时空调度算法是状态机告警和截图回传是生成与反馈。5.2 从宠物机到交通检测哪些模块可以直接复用我要强调的是复用不是把婴儿机的代码硬搬到交通场景而是复用整套技术骨架。项目里能直接迁移的模块有实时视频流接入层摄像头RTSP拉流、H.264解码、抽帧调度这部分几乎不改。目标检测推理服务YOLO系列模型的训练、量化、端侧或边缘部署流程完全一致只换数据集和类别数。事件状态机婴儿机的多级报警状态机逻辑可以直接重构为交通事故分级联动。告警通知链路App推送、短信、电话呼叫设备端和云端之间的消息通道是同一套。换的只是行业模型和数据业务逻辑被放在应用层所以切换成本比大多数人想象的低。我们当时两组后端开发在原有代码基础上三周就完成了一个交通事件检测Demo。5.3 给做类似设备的团队的选型建议如果团队正在规划一个新的实时音视频加多模态AI设备我的建议是先把这四件事定下来明确端到端延迟目标不要先想用什么模型先算每个环节能分到多少毫秒选一个带NPU或GPU加速的端侧芯片预留足够的量化压缩空间把感知引擎、状态机、告警模块做成三个独立服务方便横向迁移到别的产品线先在本地把闭环跑通再考虑云端加持别一开始就设计一个必须联网才工作的设备。最后再说一个个人很深的体会多模态AI这个词听起来很玄但落到工程上其实就是把视觉、语音、文本各自的模型接好再用一套清晰的状态转换把它们串起来。真正拉开项目差距的往往不是模型多先进而是采集质量、预处理链路、延迟预算、误报控制这些“脏活累活”。宠物翻译机、婴儿护理助手、AI故事机包括智慧交通事故检测全都在验证同一件事实时感知加多模态理解是可以做成一套可复用的行业底座的。