我用自己攒的一个语音助手“小智”说事。它就是个基于ESP32的小盒子放在床头平时喊一句“小智小智”它会回一声“在呢”然后听我下指令。有一次校园网断了我又习惯性喊“小智小智”它居然照样回了一句“在呢”。我当时愣了一下——断网了唤醒还能用那到底哪些操作根本不依赖网络哪些一断网就废顺着这个问题我把一次完整唤醒从麦克风到服务端整个链路拆了一遍也终于把设备端和服务端的分工彻底搞清楚了。这篇文章就顺着“一次唤醒”来讲适合所有在做智能音箱、语音助手、ESP32语音设备或者被“断网后设备还能干什么”这个问题困扰过的人。1. 一次唤醒背后的链路拆解很多人以为喊一声“小智小智”是“说给云端听的”其实完全不是。从物理层面看这句话从你的嘴出发先到的是设备上的麦克风然后在设备本地就被处理掉了。真正的云端要等唤醒成功之后才参与进来。1.1 从麦克风到唤醒词设备端的第一道关卡小智用的麦克风是INMP441一颗I2S数字输出的MEMS麦克风。它不像老式驻极体麦克风那样需要ADC采样而是直接把数字音频流通过I2S总线送给ESP32。这样做的最大好处是抗干扰强模拟信号在板子上走线短不容易被电源波动搞出底噪。A采样率是16kHz16bit单声道。这个配置是语音识别领域的“万金油”——人声频率范围基本都在8kHz以内16kHz采样刚好满足奈奎斯特采样定理再多就是浪费算力和带宽。我见过有新人把采样率配成44.1kHz结果模型本地推理时间直接翻倍唤醒响应明显变卡其实就是做了无用功。唤醒词检测用的是本地推理。ESP32里跑的是一个很小的神经网络模型输入是一帧一帧的音频特征输出是“是唤醒词/不是唤醒词”的概率。比较常见的做法是先用语音活动检测VAD判断当前有没有人说话没人说话就完全不跑唤醒模型这样可以把平均功耗压得非常低。只有在检测到人声片段之后才把这段音频送进唤醒模型做推理。低功耗语音唤醒能在这类MCU上跑起来靠的并不是魔法而是模型做得足够小。一个训练好的DS-CNN或者TC-ResNet参数量通常只有几十万用int8量化之后占用内存也就几百KB。在ESP32-S3这种带向量指令的芯片上单次推理大概20到50毫秒就能完成。唤醒词模型只负责识别“小智小智”这四个字的发音模式不需要理解任何语义所以它完全可以在本地实时跑。1.2 唤醒之后的云端接力ASR、语义理解与TTS一旦唤醒词被命中设备端的任务就变了从“一直听”变成“认真录”。此时ESP32会继续录音直到检测到说话停顿超过一定时间比如600毫秒然后把这一段音频打包通过WiFi发给服务端。服务端接下来干三件事。第一件事是自动语音识别ASR把音频转成文字。这一步为什么不能放在设备端因为模型体积摆在那里。一个像样的中文ASR模型即使是轻量版也有几百MB甚至几个GB的规模ESP32的闪存和内存根本装不下更别说实时跑。服务端ASR可以随时更新词库和语言模型今天刚出的网络热词明天就能听懂。第二件事是语义理解也就是“理解你说了什么”。小智的对话能力接的是一个大语言模型用户说“把客厅灯调暗一点”模型要能拆出意图是“调整灯光”实体是“客厅灯”和“调暗”。这种推理能力没有几十亿参数根本扛不住本地MCU不用想完全属于服务端的工作。第三件事是语音合成TTS把回答的文字转成语音再把音频流回传给设备播放。现在的TTS音色越来越自然但代价是模型复杂度极高而且需要大量算力做推理加速。设备端只有一个很小的扬声器和一个解码芯片它干不了这个活只能等服务端把音频下发给它。1.3 谁在什么时候做了什么把整个流程按时间线排开设备端和服务端的职责其实非常清晰。我用一张表列出来阶段执行方具体工作断网影响麦克风采集设备端INMP441持续采集16kHz音频不受影响人声检测设备端VAD判断是否有人说话不受影响唤醒词识别设备端本地神经网络推理识别“小智小智”不受影响录音缓存设备端唤醒后录制用户指令音频不受影响音频上传设备与服务端之间通过HTTP/WebSocket上传音频断网即失败语音识别服务端ASR将音频转成文字不可用语义理解服务端LLM解析意图并生成回答不可用语音合成服务端TTS把回答转成音频不可用音频播放设备端接收音频并播放无音频可播指令执行设备端控制灯、继电器等外设不受影响看完这张表就明白了设备端负责“听得到、认得出、做得到”服务端负责“听得懂、想得明白、说得出来”。两边各管一段缺了谁都会导致某个环节失灵。2. 断网之后小智还能做什么回到标题那个问题断网后小智还能做什么答案是凡是只依赖设备端的功能一样都还在凡是需要服务端参与的全部失效。但实际产品的体验差异往往在于设计了哪些离线可用的功能。2.1 本地点灯与离线命令词不联网也能干的活我在小智上做了三个不依赖网络的命令词“开灯”、“关灯”、“切换模式”。这三个词不是走云端的而是在本地用另一个小模型识别的。整个流程是唤醒成功后设备端持续录音但录下来的音频同时做两路处理——一路准备上传云端另一路先在本地跑命令词识别。如果本地识别出“开灯”就直接控制GPIO把灯打开压根不等云端结果。这样做的好处非常明显延迟极低。本地命令词识别从录音结束到执行指令一般100毫秒以内就能完成基本上你刚说完“开灯”灯就亮了。而云端链路从上传音频到ASR再到返回指令最少也要几百毫秒加上网络波动体验差距很大。断网时这个本地命令词通道就成了救命稻草。我实测过校园网断掉之后小智依然能响应“开灯”“关灯”只是不能回答“今天天气怎么样”这种需要联网的问题。对用户来说偶尔断网不至于完全变成板砖这比什么都依赖云端的设计要稳得多。2.2 真正离不开服务端的三个环节断网后彻底不能用的就是前面说的ASR、语义理解和TTS这三个环节谁也离不开服务端。先说ASR。语音识别看起来简单但它涉及声学模型、语言模型、解码器三大部分中文还要处理同音字、多音字、方言口音各种情况。哪怕只是做一个“听懂命令”的离线ASR也需要至少几百MB的模型这在ESP32这种跑着FreeRTOS的MCU上是不可能的。更关键的是ASR的词典需要持续更新——今天新出的产品名昨天可能还不在词表里。再说语义理解。对话这件事本质上是概率推理。服务端能接大模型随时调整prompt、更新知识库、切换人格这些迭代完全在服务端完成设备端不需要升级任何东西。一旦做成离线设备端就只能理解预设的那几条命令语法稍微变一变就听不懂了。TTS也一样。离线TTS在小盒子上不是不能跑但效果天差地别。云端TTS可以做到近乎真人本地跑那种几百MB的神经网络TTS不说内存根本装不下就算装下了单条回答合成也要等好几秒体验完全不可接受。2.3 断网降级策略产品端怎么设计体验既然知道断网后哪些能用哪些不能用产品上就要做降级设计。我的做法比较简单在设备端维护一个“离线模式标记”。逻辑大概是这样的设备定时向服务端发心跳请求如果连续几次失败就把状态切到离线。此时唤醒词照常响应但不再尝试上传音频而是直接进入本地命令词识别。如果用户说的话不在本地命令词表里就播放一段预置音频“我暂时无法联网请稍后再试。”播放完后自动灭灯等待下一次唤醒。这个策略真正要解决的是“不要假装听懂了”。我曾经见过一个项目断网后设备还在把音频往云端传客户端一直转圈最后超时才报错体验非常糟。更合理的设计是设备端准确感知网络状态快速降级别让用户对着空气说话。超时时间也需要仔细调。太短弱网环境下动不动就切换离线模式误判严重太长断网后设备傻等用户以为坏了。我的经验是心跳间隔3秒连续3次失败也就是9秒判定离线恢复后自动回到在线模式。3. 方案选型背后的逻辑为什么这样分工有人可能会问为什么不把唤醒也放到云端为什么不用一台树莓派把所有事都扛下来说到底这条端云分工的边界是被功耗、成本、延迟和隐私逼出来的。3.1 唤醒必须放在设备端的三点理由理由一是功耗。小智平时待机功耗只有几十毫瓦可以一直开着。如果唤醒要依赖云端设备就必须把所有音频实时上传WiFi链路一直保持高功耗待机功耗直接翻几十倍。现在的低功耗语音唤醒设计基本要求设备在“听”但并不“开脑”的状态下功耗压到毫瓦级。只有听到唤醒词才“开机”这才是智能音箱能做常驻待机的根本。理由二是延迟。本地唤醒可以做到200毫秒内响应这个“在呢”的及时感非常重要。如果唤醒词要上传到云端识别RTT少说几百毫秒用户会明显感觉到“说完话没有立刻回”交互的顺滑感一下就没了。理由三是隐私。唤醒词检测只处理很短一段音频的声学特征不需要留下原始音频。如果所有音频都经过云端就算只是几帧唤醒词用户也会介意“我的说话声是不是一直在传出去”。把唤醒留在本地是从设计上给用户一个隐私边界。3.2 对话能力为什么留在服务端对话能力放服务端核心原因是“模型在快速演化”。大语言模型的迭代速度是按月算的今天接的模型下个月可能就有更强的替代品。如果把对话模型放在设备端每一次升级都意味着所有存量设备要重新刷固件、重新烧录模型成本高到离谱。另外服务端还能做多设备协同。你在客厅喊一句“播放音乐”服务端知道你靠近的是客厅音箱会自动选择正确的设备响应。这种全局状态的管理本地设备是看不到的只有云端有这个上帝视角。算力就更不用提了。即便是目前最轻量的大模型也不是MCU能跑得动的。哪怕未来的模型能压缩到几十MB推理一次所消耗的内存带宽和电耗也远超一颗ESP32的能力范围。让专业的事留在专业的地方这是工程上最理性的选择。3.3 端云接口约定一次HTTP请求怎么走设备端和服务端之间的接口我用的是一个非常朴素的HTTP协议。唤醒后录制音频以二进制流POST到服务端的/v1/asr接口服务端返回识别文本然后设备端把这个文本和会话ID一起POST到/v1/chat接口拿到回答文本最后再POST到/v1/tts接口拿到合成的音频流。三个接口串起来就是一次完整的对话。用HTTP而不是WebSocket或MQTT是因为HTTP足够简单一个功能简单的服务端几个小时就能写好调试也方便。设备端ESP32用内置的HTTPClient库就能搞定不引入额外依赖。真正的实时流式交互比如要看打字机式逐字回复WebSocket会更合适但用在智能音箱这种短指令交互场景里HTTP的“请求-响应”模式已经足够。这里有一个关键点接口的超时和重试策略必须在设备端写清楚。我通常把单次请求超时设为5秒失败后重试2次每次间隔1秒。如果仍然失败就触发离线降级逻辑。这个参数不能设得太短否则弱网环境下稍微慢一点就误判失败也不能太长否则断网时用户要傻等十几秒才得到反馈。4. 复现一个“小智”式本地唤醒与云端对接如果你也想自己动手做一套“断网后还能用部分功能”的语音助手我把整个实操流程写出来包含硬件接线、模型部署、服务端搭建三条线。4.1 硬件选型与接线主板我用的是ESP32-S3-DevKitC比起经典ESP32它有更好的AI推理能力和更大的PSRAM跑唤醒模型更从容。麦克风用INMP441I2S数字输出单颗就能做单声道拾音。接线很简单INMP441的SCK接ESP32的GPIO 4WS接GPIO 5SD接GPIO 6L/R脚接地选择左声道数据3.3V接电源GND共地接线完成后先跑一遍官方的I2S单音测试确认能读出数据再说后面的事。这里最容易踩的坑是INMP441的L/R引脚悬空导致左右声道数据错位读出来全是噪声。我第一次试的时候就是这个问题折腾了两个小时才反应过来。4.2 唤醒词模型的训练、量化与部署唤醒词模型我用的思路是训练一个小型CNN输入是16kHz音频的Mel频谱特征。开源社区有很多成熟方案可以参考比如openWakeWord和microWakeWord前者适合在Python里训练后者专门为嵌入式落地优化。训练前要准备正样本和负样本。正样本是多个不同人说的“小智小智”至少几百条最好有男声、女声、不同语速和距离。负样本是各种其他语音和噪声包括电视声、音乐、空调噪声、脚步声等等。正负样本的比例大概在1比3到1比5之间负样本太少容易疯狂误唤醒。模型训练好之后导出为ONNX再做int8量化最后转成ESP32能用的格式。这一步非常关键因为float32的模型在ESP32上跑起来既慢又占内存int8量化后推理速度和内存占用都能优化好几倍。部署时我用ESP-DL库来做推理。初始化后主循环不断读取麦克风数据每隔20毫秒切一帧先过VAD判断有没有人声没人声就跳过有人声就送进唤醒模型。模型输出概率超过阈值一般设0.6左右就认为唤醒成功。4.3 本地命令词与服务端API的配合唤醒成功后设备进入“录音指令”状态。这里我做了一个分流录完的音频先丢进本地命令词识别模块同时准备上传云端。这么做的原因是本地命令词延迟低能先响应如果本地没匹配上再等云端的ASR结果。本地命令词识别没必要再训练一个大型模型。固定几个词比如“开灯”“关灯”“切换模式”用一个简单的关键词检测模型就够了。我在ESP32上跑了microWakeWord改的命令词模型三个词的识别准确率和唤醒词差不多。本地命中后的操作直接走GPIOif (matchedWord 开灯) { digitalWrite(LED_PIN, HIGH); } else if (matchedWord 关灯) { digitalWrite(LED_PIN, LOW); } else if (matchedWord 切换模式) { digitalWrite(MODE_PIN, !digitalRead(MODE_PIN)); }如果没有本地命中就把音频POST给服务端。服务端接口用Python的FastAPI写三个接口很干净app.post(/v1/asr) async def asr(file: UploadFile): audio await file.read() text asr_engine.recognize(audio) return {text: text} app.post(/v1/chat) async def chat(req: ChatRequest): reply llm_chat(req.text, req.session_id) return {reply: reply} app.post(/v1/tts) async def tts(req: TTSRequest): audio tts_engine.synthesize(req.text) return Response(contentaudio, media_typeaudio/wav)设备端ESP32发起请求的方式也很直接用HTTPClient库HTTPClient http; http.begin(http://your-server/api/chat); http.addHeader(Content-Type, application/json); int code http.POST({\text\:\今天天气怎么样\}); if (code 200) { String resp http.getString(); // 解析resp拿到回答文本继续请求TTS } http.end();4.4 服务端接口的测试方法服务端写完别急着和硬件联调先用工具把接口测通。我习惯用两个方式一是curl命令行直接测试二是用Postman做流程调试。比如测试ASR接口curl -X POST http://server:8000/v1/asr \ -F filetest.wav测试Chat接口curl -X POST http://server:8000/v1/chat \ -H Content-Type: application/json \ -d {text: 今天天气怎么样, session_id: 123}这一步能帮你把问题和硬件隔离开。接口都通了再接ESP32联调出了错就能确定问题出在设备端的请求格式还是音频采样数据上。省得一边查硬件一边查服务端两头猜。5. 常见问题与排查技巧实录实际做这个项目我踩了不少坑。很多问题看起来像是网络导致的实际根因却在硬件或代码逻辑上。这里把最典型的几类问题整理出来。5.1 断网后唤醒无反应问题多半在本地很多人说“断网后唤醒词都不灵了”第一反应是网络问题。但前面分析过唤醒词检测根本不依赖网络。如果断网后连“在呢”都没有那问题一定出在设备端本身跑不了。可能的原因有三个一是麦克风没工作供电或者接线松了二是唤醒模型被误删或者闪存坏了三是主循环里出现了阻塞唤醒检测线程压根没跑起来。排查时先看串口日志看有没有持续的音频电平打印。连蓝牙音箱放一段音乐看日志里的音量有没有波动没有波动就说明音频采集有问题。5.2 唤醒成功但没有回答链路怎么定位如果唤醒有反应灯亮了但没有任何回答问题就出在唤醒之后的链路上。这时候从前往后逐个排查先看设备端有没有尝试发HTTP请求再看服务端日志有没有收到请求再看服务端返回有没有超时。我遇到过一种很隐蔽的情况服务端接口能通但TTS接口返回的音频播放不出来。查了半天发现是HTTP响应头里的Content-Type写错了设备端的解码库不认这个格式直接静音。所以排查链路的时候不能只看“有没有返回”还要看返回的内容和设备端的解析逻辑是否匹配。5.3 误唤醒和延迟高的排查方向误唤醒是本地唤醒最常见的痛点。阈值从0.6调到0.8误触发确实少了很多但远距离喊话的成功率也下降了。这里有个平衡技巧与其一味调阈值不如在唤醒后加一道“二次确认”。唤醒成功后设备播放一句“我在请讲”然后才开始录音。这样即使有误唤醒用户也没有被突然打断的突兀感。延迟高的问题要分三段看录音时间、网络时间、服务端处理时间。设备端录音结束到发出请求之间的时间一般可以优化到50毫秒内网络RTT如果在局域网内基本是1到2毫秒服务端处理时间要重点盯着ASR和LLM的耗时。哪一段变慢就单独优化哪一段不要笼统地说“设备响应好慢”。5.4 断网体验设计的三个避坑点最后分享三个我在设计断网体验时踩过的坑。第一超时时间不能太短。一开始我把心跳间隔设成1秒、失败2次就判定离线结果WiFi稍微波动一下设备就在线离线来回横跳用户体验反而更差。后来改成间隔3秒、连续3次失败稳定很多。第二降级提示要友好但要有边界。设备离线时可以播放“我现在只能用本地命令了”但这句话本身不能太长否则离线提示就会卡住下一次唤醒的录音节奏。我的做法是播放一个极短的提示音配合状态灯颜色变化传递“离线模式”这个信息而不打断操作流。第三本地命令词必须覆盖高频操作。如果你只做了“开灯”和“关灯”平时用得最多的其实是“调亮度”那断网后用户还是会觉得设备废了。做需求分析时先统计日常使用频率最高的三到五个操作把这几个做成离线可用效果比做一堆花哨的离线技能要好得多。我在实际调试里最深的体会是判断断网问题永远先看本地链路再看云端链路。唤醒词本身不联网如果断网后连唤醒都没反应那大概率不是网的问题而是麦克风、模型或电源的问题。这个思路帮我省掉了大量无意义的后台排查时间。端云分工这件事说到底就是各干各擅长的活设备端负责轻快灵的实时响应服务端负责重而深的智能处理把两边的能力边界想清楚了不管断不断网用户手里的设备都不会变成砖头。
