ESP32-S3端云协同实战：从零搭建AI语音陪伴设备

最开始我只是想做一个能摆在床头、可以聊天的“电子宠物”。当从抽屉里翻出那块吃灰很久的 ESP32-S3-DevKitC-1 开发板时，我并没有想到，几个月后它会变成一台支持离线唤醒、在线对话、还能远程升级的 AI 陪伴设备。整个过程最大的收获，不是这块板子有多能打，而是我一步步验证了一条“端侧做端侧该做的事，云侧做云侧该动脑的事”的端云架构路子，并且这条架构能持续演进，不被某一家模型厂商或某一种硬件形态绑死。

这篇内容想把完整的搭建过程拆开讲清楚：为什么选 ESP32-S3，音频链路怎么通，唤醒词怎么落地，云端大模型对话怎么编排，延迟怎么压进两秒，以及最重要的是——怎么设计一套能“持续演进”的架构，让设备联网后还能不断变聪明。适合正在做 AIoT 原型、想做语音交互硬件、或者单纯好奇“一块开发板怎么接大模型”的朋友参考。

1. 项目整体设计思路：不是把开发板接到大模型就完事

1.1 这个项目要解决的真实问题

市面上很多“AI 硬件”演示，本质上就是把麦克风录一段音，送到云端识别成文字，再丢给大模型返回一段话，最后用 TTS 念出来。逻辑上没错，但真要落地成日常能用的设备，问题会冒出一大堆：

• 唤醒怎么办？设备不能一直录音上传，成本和隐私都受不了，得有一个本地的“小耳朵”始终监听。
• 打断怎么办？设备正在说话时用户开口了，要不要立刻停？
• 断网怎么办？家里 Wi-Fi 抖动、云端服务超时，设备是变砖还是退回本地能力？
• 延迟怎么控？从“用户说完”到“设备开口”，超过两秒就会觉得“这设备好蠢”。
• 模型升级怎么办？今天接入的模型是 A，明天想换成 B，不能重新烧固件。
• 唤醒词不准怎么办？灵敏度调高了误唤醒频发，调低了叫不醒。

所以这套方案的核心不是某个单一功能，而是把上述问题统一到一个分层架构里：端侧负责实时性要求高的部分，云侧负责智力密集的部分，两端通过一条设计良好的链路协作。

1.2 ESP32-S3 芯片选型的四个理由

先说结论：如果做“语音交互 + 简单控制”的陪伴设备原型，ESP32-S3 是现阶段性价比很高的选择。

第一，算力足够且专门为语音场景做了优化。ESP32-S3 是双核 Xtensa LX7，最高 240MHz，带向量扩展指令，跑 ESP-IDF 官方的 ESP-SR 语音识别框架时，唤醒词和语音活动检测（VAD）可以在本地实时完成。实测下来，双核跑“唤醒监听 + Wi-Fi 协议栈 + 音频采集”还有不少余量。

第二，内存和存储配置灵活。芯片自带 512KB SRAM，很多模组还外挂了 8MB 或 16MB 的 PSRAM。做音频缓存、协议栈缓冲、TTS 播放缓冲都非常吃内存，没有 PSRAM 会非常局促。我用的开发板是 8MB PSRAM 的版本，整个开发过程基本没被内存卡过脖子。

第三，外设接口齐全。I2S 直接接数字麦克风和数字功放，I2C 接传感器，UART 接屏幕或舵机，GPIO 控制灯和电机。这意味着一块板子既能做“陪伴聊天”，也能顺手把“开灯”“摇尾巴”“显示表情”这些动作一起做了。

第四，生态成熟。ESP-IDF 本身就是做物联网产品级的框架，OTA 升级、Wi-Fi 断线重连、低功耗管理都有现成组件。相比在裸机 MCU 上从零搞网络协议栈，省下来的时间可以全花在业务逻辑上。

有人会问：为什么不用树莓派或 RK3588 这类更强的板子？答案很简单：成本和功耗。树莓派跑本地大模型确实可以，但一块树莓派加散热和电源，成本是 ESP32-S3 方案的十倍以上，待机功耗也高一个数量级。陪伴设备是长时间待机的产品，不是训练服务器。

1.3 整体端云链路预览

这条链路可以概括为六个环节：

1. 麦克风采集音频（16kHz/16bit/单声道）。
2. 端侧 ESP-SR 做唤醒词检测和语音活动检测，判断用户是否在说话。
3. 设备通过 Wi-Fi 把音频流推送到云端接入层（WebSocket 长连接）。
4. 云端依次调用 ASR 识别服务、大模型对话服务、TTS 语音合成服务。
5. 合成好的音频数据回传到设备端。
6. 设备端通过 I2S 功放播放音频，同时保持监听，随时准备被打断。

这里面最关键的设计原则是：音频是唯一的交互媒介，但智能逻辑全部在云端，端侧只保留“听的耳朵”“说话的嘴”和“动手的四肢”。这样后续无论换更强的模型，还是加入新的技能，都不需要动硬件。

2. 端云分工：哪些逻辑放端侧，哪些放云端

2.1 为什么不能全端侧，也不能全云端

先算一笔账：本地跑一个 7B 参数的量化大模型，模型文件普遍在 3GB 以上，推理一次需要至少 4GB 内存。ESP32-S3 的 PSRAM 一共才 8MB，差了三个数量级，所以“在 ESP32-S3 上直接跑大模型”这条路在物理上就不通。

但反过来，如果把所有逻辑都放云端也不行。设备断电断网就完全变成一块砖头；用户说“打开灯”这种固定指令也要等云端绕一圈，延迟高且不稳定；还有人会担忧隐私——房间里所有对话都实时上传，体验上就很别扭。

所以最终采用“端云协同”的折中方案：

• 端侧负责毫秒级响应的能力：唤醒词检测、语音活动检测、简单指令识别、回声消除、播报控制。
• 云侧负责高智力密度的能力：自由对话理解、长短期记忆、情感陪伴、语音合成、各类技能编排。
• 两边重叠的部分（比如简单指令也可以云端再兜底识别一次）作为容错冗余。

2.2 端侧具体做什么：唤醒、降噪、本地指令

我把端侧的能力收敛成三个模块：

第一个是唤醒。使用 ESP-SR 的 WakeNet，支持自定义唤醒词。实测中文三音节和四音节唤醒词效果最好，比如“你好小灵”，四个字既不容易误唤醒，叫起来也顺口。如果唤醒词太短（比如“小灵”两个字），模型很难区分日常对话中的相似音节，误唤醒率会明显上升。

第二个是语音活动检测。这解决的是“用户说完没有”的问题。设备采集到声音后，需要判断人声开始和结束的边界，把有效语音段截出来再上传。ESP-SR 自带的 VAD 模型可以设置静音阈值，太灵敏会把呼吸声也当成语音，太迟钝又会切掉句尾。我最终把阈值调到了 0.15 附近，并且加了一段 300ms 的尾音缓冲，确保“嗯”“啊”这类语气词不会导致句子被提前切断。

第三个是本地指令表。我内置了十几个高频固定指令，比如“打开台灯”“关闭台灯”“讲个冷笑话”“现在几点”。识别逻辑很简单，端侧跑一个轻量关键词匹配，匹配上就走本地执行路径，不需要联网。这一层让设备在弱网环境下也保留基本可用性，体验提升非常明显。

2.3 云端具体做什么：ASR、大模型对话、TTS

云端这条链路由三个服务组成，我用一个对话网关服务串起来：

• ASR 服务负责把音频变成文字。我在接入时选择了支持 WebSocket 流式识别的方案，一边收音频一边出中间识别结果。这样用户话音刚落，识别文本基本已经可用，省掉了“录音完整上传再等结果”的往返时间。
• 大模型对话服务负责语义理解和回复生成。这里没有直接用裸的模型 API，而是在外面包了一层对话编排层，把系统提示词、多轮历史、用户画像、内容安全过滤都做在这里。对比直接调 API，这种方式的优势是后续可以随时换模型供应商，对话逻辑对设备端完全透明。
• TTS 服务负责把文字变成语音。为了让设备尽快“开口”，我选择支持流式返回的 TTS，先合成第一句话的开头就立刻下发给设备端播放，而不是等整段音频合成完。实测首包音频 600 毫秒左右就能到设备，体感上比非流式方案快了近一倍。

2.4 让系统可持续演进的三个关键设计

“可持续演进”不是一句口号，而是架构里实实在在的约束条件。我总结下来有三个关键设计必须从第一天就做：

第一，端侧和云侧之间只走“音频帧 + 文本消息 + 控制指令”三类协议，禁止端侧解析任何业务数据。这样云端改业务逻辑、换模型、调整人设，设备端固件完全不用动。

第二，云端必须做模型网关层。设备端和对话服务都不直接依赖具体模型的 SDK，而是统一走一套兼容接口。换模型时只需要改网关配置，客户端协议零改动。这避免了“换一个模型就要重新发一版固件”的灾难。

第三，OTA 通道和日志链路要优先搭建。很多硬件项目是把功能做完才补 OTA，结果发现升级分区没留、证书没烧、日志没法远程拉取，只能拆机刷固件。我是先把升级通道打通，再开始写业务逻辑，后面的迭代效率完全不一样。

3. 端侧核心实现：从开发板到能说话的硬件

3.1 硬件连接与音频链路搭建

我用的硬件清单如下：

INMP441 是 I2S 接口的 MEMS 麦克风，接法非常固定：VDD 接 3.3V，GND 接地，SCK 接 I2S 时钟，WS 接字选择信号，SD 接数据输入。MAX98357A 那边同样走 I2S，BCLK、LRC、DIN 分别接对应引脚，GAIN 引脚悬空即可获得默认 9dB 增益。

这里有几个容易踩的坑：

• INMP441 的 L/R 引脚决定它输出在左声道还是右声道。我把它接高电平（右声道），代码里读数据时就要听右声道，左右搞反会导致噪声数据一片混乱。
• MAX98357A 的供电电流不能忽视，峰值时可能到 1A 以上。如果和开发板共用同一个稳压源，低电量时会出现喇叭破音甚至开发板重启。建议功放供电单独走一路，至少保证电源能提供 2A 电流。
• I2S 时钟引脚不要和 Wi-Fi 天线走线靠太近，否则音频数据会出现偶发丢帧，表现就是播报时“滋啦”一声杂音。

3.2 ESP-SR 唤醒词与 VAD 配置实操

ESP-SR 不是开箱即用的，需要先在 ESP-IDF 里把组件拉下来。如果是在现有工程里加，可以用idf.py add-dependency "espressif/esp-sr"的方式引入。

关键配置都在menuconfig里：

• 唤醒词模型：Component config → ESP-SR → Wake word engine → Wake word model，选择对应的中文唤醒词模型文件。默认带几个预置模型，如果都不满意，可以用 ESP-SR 的训练服务训练自定义唤醒词，训练出来的是一个.bin文件，放到工程里并配置路径即可。
• VAD 模式：VAD model → VAD mode，可选 0 到 3 四档。0 最灵敏，3 最迟钝。我这里选 2，配合代码里的尾音缓冲，实测在正常家居噪声下效果最好。
• 音频输入格式：Audio front-end里确认是 16kHz、16bit、单声道。如果麦克风通道配置不对，后面唤醒和识别都会出问题。

代码层面的逻辑可以简化为：

1. 初始化 I2S 麦克风，持续读取音频帧。
2. 每帧音频同时喂给 WakeNet 和 VAD。
3. 一旦 WakeNet 检测到唤醒词，设置状态为 “listening”，开始积累音频。
4. VAD 检测到人声结束后，把缓存的有效音频取出来，打包上传云端。
5. 在等待云端返回期间，继续跑 WakeNet，一旦再次检测到唤醒词，立即打断当前播放并开始新一轮录音。

3.3 音频数据打包与上传协议

音频上传协议我设计得很简单，但很实用。设备端和云端建立 WebSocket 长连接后，所有上行音频都是二进制帧。帧结构如下：

音频编码我选了 Opus，20ms 一帧，码率控制在 24kbps 左右。原始 PCM 16kHz/16bit/单声道是 256kbps，Opus 压缩后不到原来的十分之一。这不仅省流量，更关键的是让弱网环境下的上行更稳定。开发调试时也可以用原始 PCM 格式，但原型验证之后建议尽早切到 Opus。

这里要提醒一句：ESP-IDF 自带 Opus 编解码库，但需要自己在idf.py menuconfig里把esp_opus组件打开。否则在代码里调用opus_encode时会链接不到函数。

3.4 端侧状态机与本地回退策略

一个语音交互设备的端侧状态，我用一个简单的状态机来管理：

这个状态机最大的作用是防止死锁。比如设备正在 UPLOADING 时网络超时，要能自动回到 IDLE 并提示“网络好像不太好，请稍后再试”。如果没有状态机制约，很容易出现“一直停留在录音中”这种诡异 Bug。

本地回退策略也很重要。我在设备里内置了一个 JSON 格式的本地指令表，包含开关灯、播放白噪音、报时间这类不依赖网络的技能。当 Wi-Fi 断开或云端连续三次超时时，设备自动进入“本地模式”，本地指令全部可用，自由对话提示“联网后我才能陪你聊天”。这个设计看起来不起眼，但决定了设备在断网时是“小废物”还是“基本可用”。

4. 云端服务层：对话网关的实现细节

4.1 ASR 接入与音频切片策略

ASR 服务我选用的是支持流式识别的云端方案。WebSocket 上行音频后，服务端会持续返回“中间结果”和“最终结果”。

实际开发时有一个经验：不要等整个句子说完再处理。我的做法是：

1. 设备端每隔 20ms 发送一个 Opus 音频帧。
2. 云端 ASR 客户端实时把音频帧转发给识别服务。
3. ASR 服务返回的中间结果，先缓存在上下文里。
4. 当收到“最终结果”标记时，把完整句子拼好，送入下一步对话编排。

音频切片的时间不能太长。 最开始我试过 200ms 一个包，结果 ASR 服务端频繁报“音频帧间隔超时”，识别率也下降。后来改为严格按照 20ms 一包（正好一个 Opus 帧），问题立刻消失。这个细节一定要在协议设计时考虑进去：端侧的帧周期要和云端 ASR 服务的期望对齐。

4.2 大模型对话编排：人设、记忆与内容安全

大模型对话服务是整个设备“情商”的核心。我没有把它做成简单的“请求-响应”接口，而是做成了一个带上下文的对话引擎。

• 人设（System Prompt）：通过系统提示词设定 AI 陪伴者的性格、说话方式、知识边界。比如我设置的是“温柔可靠的朋友，说话简洁自然，偶尔幽默”。这套人设直接影响回复质感，值得反复打磨。
• 多轮记忆管理：把用户和设备的历史对话存在云端内存里，同时做长度裁剪。否则对话轮数一多，请求上下文会膨胀到超出模型窗口长度。我的策略是只保留最近 10 轮对话，更早的内容做摘要后拼接在系统提示词里。
• 技能路由：对话引擎收到用户文本后，先过一个轻量的意图分类器。如果是“打开台灯”这类明确指令，直接走设备控制服务下发指令给端侧，不占用大模型推理；只有自由聊天、开放问答才走大模型。这样既省钱又降低延迟。
• 内容安全过滤：在送入大模型之前和拿到回复之后，分别做一轮内容安全筛查。这是 AI 应用上线的硬性要求，不能省略。具体做法是维护一个敏感词表，再用一个轻量文本分类器做二次过滤，命中风险就返回预设的安全话术。

对话编排的伪代码如下：

def process_user_message(user_text, session_id, device_id): session = memory.get_session(session_id) intent = intent_classifier.classify(user_text) if intent.action == "device_control": control_payload = skill_manager.execute(intent) return {"type": "control", "payload": control_payload} messages = build_messages(session.system_prompt, session.history, user_text) reply = model_gateway.chat(messages, temperature=0.7) if safety_checker.is_unsafe(reply): reply = SAFE_FALLBACK_REPLY session.add_turn(user_text, reply) session.trim_history(max_turns=10) return {"type": "chat", "reply": reply}

4.3 TTS 语音合成与流式下发

TTS 我最终选了流式合成的方案。流程是：

1. 对话网关拿到大模型回复文本后，立刻调用 TTS 服务。
2. TTS 服务边合成边返回音频分片。
3. 网关每收到一个分片，就通过 WebSocket 下发给设备端。
4. 设备端收到第一个分片就开始播放，后续分片按顺序排队。

这个方案把“等待完整音频”的时间省掉了。实测从大模型生成完文本到设备端发出第一个字，流式方案能比非流式快 400 到 800 毫秒。对用户感知来说，这就是“反应快”和“反应慢”的分水岭。

TTS 服务的语音选型也很重要。陪伴设备不宜用新闻联播式的字正腔圆，音色温暖、语速偏慢、带一点感情起伏的更适合。我最后选定了一款支持 SSML 标记的 TTS，用<break time="200ms"/>来控制句间停顿，用<prosody rate="0.95">调整语速，生成效果自然不少。

4.4 延迟预算拆解：两秒响应的目标怎么实现

整条链路里，每个环节都有延迟，必须逐项拆解、做预算。

整条链路预算加起来约 1.7 到 3.0 秒。实测在家庭 Wi-Fi 环境、云端服务正常时，整体响应约 2 秒；网络抖动时会到 2.5 秒。这个体感对于陪伴设备来说可以接受，但不是终点。后续计划通过“端侧预测用户说完时机提前预请求大模型”的方式进一步压缩到 1.5 秒以内。

优化延迟时一定要按阶段打点，记录每个环节的时间戳。一句话的完整日志串起来，哪个环节超时一目了然。什么都不记录直接拍脑袋优化，大概率会浪费大量时间在错误的地方。

5. 可持续演进：OTA、模型网关与形态扩展

5.1 固件 OTA 升级的坑与方案

设备联网后的第一件大事，就是能远程升级固件。ESP-IDF 的 OTA 机制比较成熟，但有几个坑必须先知道。

需要在分区表里留出双 OTA 分区。即ota_0和ota_1各占约 1.5MB，加上一个factory分区做最终兜底。升级时固件写入非当前运行的 OTA 分区，写入完成后校验 SHA-256，通过后切换启动分区并重启。万一新固件启动失败（连续三次崩溃），bootloader 会自动回滚到旧分区。

升级文件的传输不能直接裸传大文件。一个小固件也有 1MB 左右，直接走不稳定的 HTTP 很容易传到一半断掉。我加了断点续传逻辑，设备端记录已接收偏移量，重连后从偏移处继续下载。实测在 50% 丢包率的弱网环境下也能最终升级成功。

最容易被忽略的是升级触发时机。 设备正在播放音频、正在对话时，绝对不能重启。我在云端下发升级指令前会先查询设备状态，只有 IDLE 状态才允许升级。这个看似简单的约束，避免了一大堆线下返修问题。

5.2 云端模型可插拔：模型网关层

模型网关是整个云端架构里最重要的抽象层。设备端和对话编排层都不关心底层用的是哪个大模型，只调用模型网关的统一接口：

class ModelGateway: def __init__(self): self.provider = os.getenv("LLM_PROVIDER", "openai_compatible") self.base_url = os.getenv("LLM_BASE_URL") self.api_key = os.getenv("LLM_API_KEY") self.model_name = os.getenv("LLM_MODEL_NAME") def chat(self, messages, temperature=0.7): if self.provider == "openai_compatible": # 统一走 OpenAI 兼容协议 ...

接新模型时，只需要更新环境变量：LLM_BASE_URL指向新模型的端点，LLM_MODEL_NAME改成新模型名称。如果新模型不支持 OpenAI 兼容协议，再为网关增加一个 provider 分支即可。

网关层还要统一处理超时、限流、重试。 大模型服务偶尔会抽风，网关会自动重试一次，并在第二次失败时返回降级话术。不能让模型服务的故障直接暴露成设备的“哑巴”。

5.3 从陪伴设备扩展到其他形态

这套端云架构最大的价值是可复用。我后来把同一套架构快速迁移到了两个新硬件上：一个是带表情屏幕的桌面机器人，一个是支持按键交互的儿童故事机。改动量比预期小很多。

原因在于架构上做了清晰的边界：端侧只负责“音频采集、播放、物理控制、状态上报”；云端只负责“感知、理解、决策、生成”。任何新的硬件形态，只要具备麦克风、喇叭、网络这三样东西，就可以接入同一个云端大脑。

如果要扩展视觉能力，比如加一个摄像头做表情识别，也只需要在端侧增加一个“图像上传”通道，云侧增加一个“视觉理解”服务。主干架构完全不需要推翻。这也是我认为这套方案能“持续演进”的根本原因：它不是为某一个产品定制的，而是为“设备接入智能”这件事设计的基础设施。

6. 常见问题与排查技巧实录

6.1 唤醒词识别率低、误唤醒频繁

这是我调试过程中最闹心的一环。先说排查思路：

• 先确认麦克风通道正确。我用 INMP441 时发生过左右声道接反，识别率惨不忍睹，但很多人不会想到是声道问题。
• 再看环境噪声。靠近风扇、空调出风口时，误唤醒会明显增加。VAD 的阈值可以适当调高，让设备只在“相对安静”的环境下才响应唤醒。
• 唤醒词本身也很关键。两个字的唤醒词几乎必然误唤醒，四个字的明显好很多。在实际场景里连续测试一周，记录误唤醒次数，再决定是否换模型。有些唤醒词模型自带相似词，需要尽量避开生活高频词。

6.2 对话延迟时高时低

延迟波动最大的瓶颈通常不在设备端，而在云端服务的冷启动和网络链路。

排查方法是给每个环节加时间戳日志。设备端打印音频发送时间，云端网关打印收到时间、ASR 返回时间、大模型首 token 时间、TTS 首包时间。把一条完整请求的日志拼接起来，立刻能定位是哪个环节慢。

我踩过的一个坑是云端服务在多设备同时请求时出现排队。网关旁路了数据库查询和日志上报导致阻塞，后来把日志改成异步上报，延迟就稳定下来了。另一个因素是 DNS 解析和 TLS 握手。长连接能避免每次请求都重新握手，所以 WebSocket 比 HTTP 调用在延迟表现上有明显优势。

6.3 设备播报时出现杂音和破音

这个问题通常和电源、功放增益、音频格式有关。

先检查电源：是否用了额定电流不足的充电头？功放和主控共地是否良好？这些都可能导致电流噪声。再调低功放增益，MAX98357A 的 GAIN 引脚可以选择 3dB、6dB、9dB、12dB 等不同档位。如果喇叭额定功率只有 1W，强行上 12dB 增益必然破音。最后检查音频格式：设备端初始化 I2S 时要匹配 TTS 返回的采样率，比如 16kHz 的音频用 48kHz 播放，声音就会“变速”甚至出现嘶嘶声。

6.4 调试设备时的高效技巧

我强烈建议给设备加一个“调试按键”和“调试模式”。长按按键后，设备会把接下来 30 秒的原始音频保存到 SD 卡或上传到云端日志服务。这样用户报障“唤醒不了”时，能直接拉到当时的音频文件人工回听，比猜原因高效得多。

云端日志要带设备 ID 和请求 ID。设备端每个请求都生成一个递增序号，云端每一步处理都带着这个序号打日志。排查问题时，用设备 ID 和请求 ID 一把梭出来，整条链路的情况全在眼前。没有这套日志体系，做语音交互设备的排障效率会低到让人崩溃。

写在最后的实践经验

这套“从一块 ESP32-S3 开发板到 AI 陪伴设备”的端云架构，我前后跑了几个月，最大的体会是：端侧和云侧的边界一定要定义得早、定义得稳。设备端一旦被业务逻辑绑架，后续每一次模型升级、技能扩展都会变得寸步难行。反过来，只要边界清晰，端侧哪怕只有最简单的音频采集和播放能力，云端也可以不断给它注入新的智能。

最后再分享一个小技巧：从一开始就在代码里加上时间戳打点，连调试串口打印都不需要太复杂，只要能让你事后拼出“麦克风采集、上行、ASR、大模型、TTS、播放”的完整时间线，你的优化效率就会比别人高一个数量级。等到做延迟优化和问题定位时，你会由衷感谢当初那个愿意多写几行日志的自己。