1. 先泼冷水ESP32 接上大模型离 AI 硬件还差半个产品化1.1 “能对话”和“能用”之间的鸿沟最近群里又有人在晒 ESP32 接大模型麦克风喊一句云端大模型回一段顺便开个灯视频配文是“ESP32 AI 硬件”。评论区一堆羡慕但我第一反应是这设备掉线一次、延迟五秒的时候视频里可没拍出来。ESP32 通过 WiFi 调用云端大模型 API在嵌入式里已经不算新鲜但把它叫 AI 硬件多少有点标题党。能对话的 demo 只证明链路通了不代表产品能用。一个能用的 AI 硬件要能在用户家里通电跑几个月扛得住弱网、噪声、误唤醒、断电重启甚至还要能在不拆机的情况下升级固件。这些全是工程问题而工程问题恰恰是大多数开源项目最不爱展示的部分。所以这篇我把自己的踩坑清单整理出来一共 8 个按踩坑顺序排适合所有准备把 ESP32 或类似单片机做成 AI 设备的创客、硬件工程师和产品经理。1.2 8 个工程问题全景图我先用一张表把这 8 个问题列出来后面逐个展开。这张表也是我自己做项目的检查清单每次画硬件框图和写软件架构时都会对着过一遍。编号工程问题典型现象不解决的后果1资源边界把大模型往 MCU 上塞内存溢出、启动崩溃2端云架构什么逻辑都写在设备端每次加功能都要重新刷固件3配网与断线重连用户连不上 WiFi、设备用几天离线客服爆炸、设备变成砖4音频前端吵一点就听不见唤醒率低、体验崩溃5流式低延迟说完话等 10 秒才有回应用户以为设备坏了6对话上下文多轮对话没记忆回答牛头不对马嘴7安全与密钥API Key 写在代码里密钥泄露、账单爆炸8OTA 与远程维护升级失败变砖只能寄回返修你可能会说这 8 个问题里只有 1、2 跟大模型有关其他是普通硬件也在做的事。对我特意没有把“模型选型”“提示词工程”这种算法岗位关心的问题放进去因为嵌入式这边真正绊倒人的恰恰是这些看着不 AI 的脏活。下面一个一个说。2. 资源、模型与网络先解决“能不能跑”2.1 问题一资源边界ESP32 的内存到底能装下什么ESP32 不是电脑哪怕常见的 ESP32-S3 带 8MB PSRAM听起来比 Arduino UNO 大很多但和语言模型需要的几百 MB 甚至几 GB 权重一比完全是另一个数量级。我算过一笔账0.5B 参数模型如果用 INT8 量化权重本身约 0.5GB就算你搞极端剪枝加上 KV Cache、激活值也要 200MB 往上。ESP32-S3 的 8MB PSRAM 离这个需求差了两个数量级更不用说算力了主频才 240MHz跑一遍推理要分钟级。所以任何告诉你“ESP32 本地跑大模型”的教程要么是把“大模型”这个词泛指成端侧语音识别、唤醒词模型要么就是在忽悠你。ESP32 上真正能跑的是 MicroWakeWord 这类唤醒词模型、ESP-SR 的离线命令词识别、端侧自训练的 KWS 模型甚至量化后的 MobileNet 图像分类。它跑不了 ChatGPT 那种按 token 自回归生成的 LLM。认清这个边界之后你的设计思路才不会一开始就跑偏ESP32 做感知和控制大模型在云端或者局域网里的强设备上两端协作而不是互相较劲。很多新手把大量时间花在试图压缩模型塞进单片机最后要么精度崩了要么推理速度不可用这是最不值得的投入。2.2 问题二端云架构到底哪些功能放在设备端既然本地跑不了大模型那就要重新划分职责。我一个已经量产的语音助手方案里本地做唤醒词检测、VAD 人声检测、按键控制、LED 反馈、板载传感器读取云端做 ASR 语音转文字、大模型对话、复杂 TTS。设备端只保留低延迟、敏感、不依赖网络的轻量功能云端承接所有需要重算力、大模型的服务。划分原则很直接哪个环节用户受不了延迟就往前端放哪个环节需要大量数据、大模型推理就往云端放。这个架构不止适用于音箱也适用于小车。我之前做过一个 ROS2 humble 串口桥接 ESP32 小车的项目底盘上的 ESP32 只负责电机速度环、编码器读取和串口协议上抛数据路径规划、SLAM、视觉识别全部在 PC 或开发板上跑。把大模型当云端“大脑”把 ESP32 当“手和脚”才是符合边界的 AI 硬件。反过来如果非要在 ESP32 上跑路径规划跑一步卡三步那就是满足技术癖好不是做产品。你在设计任何 AI 硬件之前先画一张数据流图标清楚每个模块跑在哪里这比选模型重要得多。2.3 问题三配网与断线重连最容易在交付环节翻车硬件工程师最容易忽视配网。你自己天天用串口调板子觉得网络理所当然但用户拿到设备第一步就是连 WiFi。没有流畅配网流程后面全白搭。ESP32 常用配网方式有 SmartConfig、SoftAP 配网、BLE 配网我的建议是不要只押注一种。个人项目我推荐 SoftAP 手机浏览器配网设备上电后自己开一个 AP用户手机连上去打开 192.168.4.1 填 WiFi 密码设备再切到 STA 模式连接路由器。代码量不大体验稳定。如果团队资源够可以再用 BLE 配网做无感交互但小项目没必要一开始就做。连上只是开始断线重连才是大头。ESP32 默认的 WiFi 重连逻辑不一定可靠有时候掉线后不会自动恢复需要你在事件循环里监听断开事件然后执行指数退避重连比如按 1s、2s、4s、8s 重试最多加到 60s 就不继续涨了避免疯狂扫网耗电。另外要配一个网络看门狗如果长时间探测不到外网软复位一次。我一个朋友的项目就是没做重连设备每隔两天就掉线最后用户只能拔电再插。这类问题不是大模型能救的是基础功。3. 拾音、交互与延迟再解决“好不好用”3.1 问题四音频前端模型再好也架不住麦克风收音如果做语音交互ESP32 的 ADC 直连模拟麦克风是很糟糕的选择内置 ADC 噪声大、采样率不稳定。正经做法是用 I2S 接口接数字麦克风比如 INMP441 是 I2S 输出的ESP32-S3 的 I2S 外设可以直接读。选麦克风时不光看灵敏度还要看信噪比SNR 大于 59dB 才算起步。焊接和结构也要注意麦克风开孔不能靠近扬声器开孔否则回声抑制难度陡增。很多人在功能验证时用开发板裸麦听起来还行一装进外壳声音全闷住了这就是结构设计没参与导致的。环境噪声和回声比想象中严重。我实测过同一套大模型问答系统安静环境下唤醒率 95%旁边放音乐就跌到 70%。后来加了双麦克风波束成形和 ESP-IDF 的 AEC/NS 音频前端才回到 90% 左右。所以你的产品想在客厅或车里用别只写一句“调用大模型”要把唤醒、降噪、自动增益这些当成正式模块去设计。不建议自己从零写降噪算法直接用乐鑫 ESP-SR 或第三方算法把精力放在参数调优和结构测试上。测试的时候要用真实噪声样本不要只躲在安静的办公桌旁边。3.2 问题五流式响应与低延迟用户不会等 3 秒很多人把链路做成“录音结束 - 上传 - ASR - 大模型完整输出 - TTS - 播放”整个过程 8 到 10 秒。这完全不可用。我做过一个方案把串行改成了流式用户说完话后语音先上传ASR 一边识别一边把已识别的文本送入大模型大模型开始生成后按句子切分第一句生成完立刻送 TTS 播放不用等全文。实测用户从说完到听到第一个字压到 1.5 到 2 秒是可能的。对智能音箱这类交互超过 3 秒用户就会重复喊第二遍。具体到 ESP32 端建议用 WebSocket 或 HTTP SSE 接收流式响应不要用一次性 HTTP 轮询。播放也最好用 I2S 接 DAC 和功放边收边播。另外要做一个中断机制用户说话时检测到唤醒词或按下按键立即停止当前 TTS 播放进入下一轮收听。否则用户想打断系统还在傻乎乎播上一段答案体验非常糟糕。这个“打断”逻辑看似小实际是语音交互里最核心的体验保障比模型选型影响更大。3.3 问题六对话上下文别让大模型变成没有记忆的接口ESP32 每次调用大模型 API默认是无状态的。如果你只把当前语音转出来的文本发过去大模型不知道灯现在是开是关、不知道用户上一句问过什么、更不知道设备自身的传感器读数。解决方法是把上下文主动塞给模型。我在 system prompt 里固定放一段设备信息设备名称、当前时间、灯状态、温度传感器读数然后把最近 N 轮历史作为 messages 一起传过去。多轮对话历史可以放在自己的服务器或本地环形缓冲区不需要 ESP32 存太多但每次请求要携带最近几轮的摘要。更稳的做法是让大模型输出结构化指令而不是自然语言。比如用户说“打开灯”模型 response 应该是一段 JSON{action: set_light, value: true}ESP32 端解析这个字段直接控制 GPIO。这样你不用让大模型直接碰硬件也方便做安全校验。我踩过的坑是大模型偶尔会输出多余的说明文字解析 JSON 会失败所以我一般在 API 参数里要求 JSON 输出解析失败时让模型重试一次或者在设备端做关键字兜底匹配。别拿自然语言当控制指令那会出安全问题。4. 安全、OTA 与量产最后解决“敢不敢卖”4.1 问题七密钥和设备身份很多 Demo 在裸奔我见过太多教程把云端 API Key 直接写在 ESP32 源码里编译烧录就完事。这种设备一旦到了用户手里任何人都可以用串口把 Flash dump 出来用 strings 命令搜出 Key。更别说固件可能被传到网上密钥一泄露别人就能用你的账号刷调用。对于个人项目至少要做到Key 不硬编码放在 NVS 分区烧录时单独写入同时把大模型 API 放到你自己可控的云端网关后面ESP32 只和你的网关通信网关再持有大模型 Key。这样即使 Flash 被 dump别人拿到的只是网关的设备凭据不是大模型账单入口。如果做产品设备身份认证建议用每台唯一的证书、私钥配合安全芯片或者 ESP32 的 Secure Boot 加 Flash Encryption。不要觉得“就一个几十块钱的板子不值得”。用一个设备凭据去刷你的大模型 API一个月烧掉几万 token 很容易都是真金白银。我在网关端还会做限流和异常检测同一把钥匙每秒请求多少次、凌晨疯狂调用全部报警。安全不是加一把锁是风险控制。4.2 问题八OTA 与远程维护设备交付后你还能看到它吗个人 DIY 可以接受 USB 刷机但做成产品后用户不可能拆开设备连串口。所以 OTA 是必选项。ESP32 的 native OTA 支持双分区App0 和 App1 轮流写入启动时会校验固件签名和 CRC。我在项目里加了一个启动健康位新固件启动后如果 5 分钟内没有上报心跳系统就自动回滚到上一个可用版本避免升级后变砖。第一次做 OTA 时我没做回滚结果升级了个有 bug 的固件所有设备启动崩溃只能挨个寄回那叫一个惨。OTA 之外还要有远程观测手段。我会在设备端用 MQTT 周期上报 free heap、WiFi RSSI、运行时间、当前版本号、最后一条错误崩溃时把 panic 信息存进 flash下次启动上报。没有这些数据你远程改 100 个设置都是瞎子。想在用户家里做 AI 硬件不要只盯着新功能先把“设备出问题我能不用上门就定位”这件事做好。很多产品最后死不是死在 AI 不够聪明而是死在维护成本失控。4.3 额外心得低功耗、成本和量产一致性原定 8 个问题说完了最后再补一个不算第 9 个但会在量产阶段找上门的点低功耗。如果设备是插电的那无所谓但如果是电池供电ESP32 长时间连着 WiFi 本身就是大电流待机几十 mA 都是正常的。要降到能接受的水平得用 modem sleep或者干脆让设备大部分时间 deep sleep用按键或外部唤醒词芯片来唤醒。我见过一个项目为了省电把 WiFi 断开只在拍照时连接结果每次唤醒第一件事是等路由器分配 IP用户体验大打折扣。省电和实时在线之间要做一个清醒的产品权衡没有标准答案。成本和量产一致性也一样容易被忽略。一两块 ESP32 模块看不出什么但量产时每个螺丝、每根排线、每个测试工位都算钱。我做过一个带语音和 Wi-Fi 的桌面小设备BOM 轻松到 60 多元加上外壳开模、包装、认证小批量两百台成本直接破 100。如果你的方案里有两颗 IC 可以合并、一个电容可以省掉必须提前做成本拆解。量产一致性则是另一个坑每台设备要烧录不同的 device secret工厂产线得写自动化烧录脚本不能让工人一个个点串口助手。这些看着和大模型无关但它们才是 AI 硬件能不能卖出去的真正前提。最后再说句个人体会我做的几个带大模型的设备真正花时间最多的地方几乎都不在大模型接口而是在配网页、处理噪声、搞 OTA 回滚、调电源这堆不 AI 的事情上。AI 硬件从来不是“ESP32 接个大模型就行”而是把一个“能演示的 demo”熬成“能扔到用户家里半年不管的系统工程”。你如果想做这类设备别急着上大模型先把上面 8 个问题过一遍有一个没想清楚后面都会连本带利还回来。
ESP32接入大模型做AI硬件？8个工程坑位清单与端云架构避坑指南
1. 先泼冷水ESP32 接上大模型离 AI 硬件还差半个产品化1.1 “能对话”和“能用”之间的鸿沟最近群里又有人在晒 ESP32 接大模型麦克风喊一句云端大模型回一段顺便开个灯视频配文是“ESP32 AI 硬件”。评论区一堆羡慕但我第一反应是这设备掉线一次、延迟五秒的时候视频里可没拍出来。ESP32 通过 WiFi 调用云端大模型 API在嵌入式里已经不算新鲜但把它叫 AI 硬件多少有点标题党。能对话的 demo 只证明链路通了不代表产品能用。一个能用的 AI 硬件要能在用户家里通电跑几个月扛得住弱网、噪声、误唤醒、断电重启甚至还要能在不拆机的情况下升级固件。这些全是工程问题而工程问题恰恰是大多数开源项目最不爱展示的部分。所以这篇我把自己的踩坑清单整理出来一共 8 个按踩坑顺序排适合所有准备把 ESP32 或类似单片机做成 AI 设备的创客、硬件工程师和产品经理。1.2 8 个工程问题全景图我先用一张表把这 8 个问题列出来后面逐个展开。这张表也是我自己做项目的检查清单每次画硬件框图和写软件架构时都会对着过一遍。编号工程问题典型现象不解决的后果1资源边界把大模型往 MCU 上塞内存溢出、启动崩溃2端云架构什么逻辑都写在设备端每次加功能都要重新刷固件3配网与断线重连用户连不上 WiFi、设备用几天离线客服爆炸、设备变成砖4音频前端吵一点就听不见唤醒率低、体验崩溃5流式低延迟说完话等 10 秒才有回应用户以为设备坏了6对话上下文多轮对话没记忆回答牛头不对马嘴7安全与密钥API Key 写在代码里密钥泄露、账单爆炸8OTA 与远程维护升级失败变砖只能寄回返修你可能会说这 8 个问题里只有 1、2 跟大模型有关其他是普通硬件也在做的事。对我特意没有把“模型选型”“提示词工程”这种算法岗位关心的问题放进去因为嵌入式这边真正绊倒人的恰恰是这些看着不 AI 的脏活。下面一个一个说。2. 资源、模型与网络先解决“能不能跑”2.1 问题一资源边界ESP32 的内存到底能装下什么ESP32 不是电脑哪怕常见的 ESP32-S3 带 8MB PSRAM听起来比 Arduino UNO 大很多但和语言模型需要的几百 MB 甚至几 GB 权重一比完全是另一个数量级。我算过一笔账0.5B 参数模型如果用 INT8 量化权重本身约 0.5GB就算你搞极端剪枝加上 KV Cache、激活值也要 200MB 往上。ESP32-S3 的 8MB PSRAM 离这个需求差了两个数量级更不用说算力了主频才 240MHz跑一遍推理要分钟级。所以任何告诉你“ESP32 本地跑大模型”的教程要么是把“大模型”这个词泛指成端侧语音识别、唤醒词模型要么就是在忽悠你。ESP32 上真正能跑的是 MicroWakeWord 这类唤醒词模型、ESP-SR 的离线命令词识别、端侧自训练的 KWS 模型甚至量化后的 MobileNet 图像分类。它跑不了 ChatGPT 那种按 token 自回归生成的 LLM。认清这个边界之后你的设计思路才不会一开始就跑偏ESP32 做感知和控制大模型在云端或者局域网里的强设备上两端协作而不是互相较劲。很多新手把大量时间花在试图压缩模型塞进单片机最后要么精度崩了要么推理速度不可用这是最不值得的投入。2.2 问题二端云架构到底哪些功能放在设备端既然本地跑不了大模型那就要重新划分职责。我一个已经量产的语音助手方案里本地做唤醒词检测、VAD 人声检测、按键控制、LED 反馈、板载传感器读取云端做 ASR 语音转文字、大模型对话、复杂 TTS。设备端只保留低延迟、敏感、不依赖网络的轻量功能云端承接所有需要重算力、大模型的服务。划分原则很直接哪个环节用户受不了延迟就往前端放哪个环节需要大量数据、大模型推理就往云端放。这个架构不止适用于音箱也适用于小车。我之前做过一个 ROS2 humble 串口桥接 ESP32 小车的项目底盘上的 ESP32 只负责电机速度环、编码器读取和串口协议上抛数据路径规划、SLAM、视觉识别全部在 PC 或开发板上跑。把大模型当云端“大脑”把 ESP32 当“手和脚”才是符合边界的 AI 硬件。反过来如果非要在 ESP32 上跑路径规划跑一步卡三步那就是满足技术癖好不是做产品。你在设计任何 AI 硬件之前先画一张数据流图标清楚每个模块跑在哪里这比选模型重要得多。2.3 问题三配网与断线重连最容易在交付环节翻车硬件工程师最容易忽视配网。你自己天天用串口调板子觉得网络理所当然但用户拿到设备第一步就是连 WiFi。没有流畅配网流程后面全白搭。ESP32 常用配网方式有 SmartConfig、SoftAP 配网、BLE 配网我的建议是不要只押注一种。个人项目我推荐 SoftAP 手机浏览器配网设备上电后自己开一个 AP用户手机连上去打开 192.168.4.1 填 WiFi 密码设备再切到 STA 模式连接路由器。代码量不大体验稳定。如果团队资源够可以再用 BLE 配网做无感交互但小项目没必要一开始就做。连上只是开始断线重连才是大头。ESP32 默认的 WiFi 重连逻辑不一定可靠有时候掉线后不会自动恢复需要你在事件循环里监听断开事件然后执行指数退避重连比如按 1s、2s、4s、8s 重试最多加到 60s 就不继续涨了避免疯狂扫网耗电。另外要配一个网络看门狗如果长时间探测不到外网软复位一次。我一个朋友的项目就是没做重连设备每隔两天就掉线最后用户只能拔电再插。这类问题不是大模型能救的是基础功。3. 拾音、交互与延迟再解决“好不好用”3.1 问题四音频前端模型再好也架不住麦克风收音如果做语音交互ESP32 的 ADC 直连模拟麦克风是很糟糕的选择内置 ADC 噪声大、采样率不稳定。正经做法是用 I2S 接口接数字麦克风比如 INMP441 是 I2S 输出的ESP32-S3 的 I2S 外设可以直接读。选麦克风时不光看灵敏度还要看信噪比SNR 大于 59dB 才算起步。焊接和结构也要注意麦克风开孔不能靠近扬声器开孔否则回声抑制难度陡增。很多人在功能验证时用开发板裸麦听起来还行一装进外壳声音全闷住了这就是结构设计没参与导致的。环境噪声和回声比想象中严重。我实测过同一套大模型问答系统安静环境下唤醒率 95%旁边放音乐就跌到 70%。后来加了双麦克风波束成形和 ESP-IDF 的 AEC/NS 音频前端才回到 90% 左右。所以你的产品想在客厅或车里用别只写一句“调用大模型”要把唤醒、降噪、自动增益这些当成正式模块去设计。不建议自己从零写降噪算法直接用乐鑫 ESP-SR 或第三方算法把精力放在参数调优和结构测试上。测试的时候要用真实噪声样本不要只躲在安静的办公桌旁边。3.2 问题五流式响应与低延迟用户不会等 3 秒很多人把链路做成“录音结束 - 上传 - ASR - 大模型完整输出 - TTS - 播放”整个过程 8 到 10 秒。这完全不可用。我做过一个方案把串行改成了流式用户说完话后语音先上传ASR 一边识别一边把已识别的文本送入大模型大模型开始生成后按句子切分第一句生成完立刻送 TTS 播放不用等全文。实测用户从说完到听到第一个字压到 1.5 到 2 秒是可能的。对智能音箱这类交互超过 3 秒用户就会重复喊第二遍。具体到 ESP32 端建议用 WebSocket 或 HTTP SSE 接收流式响应不要用一次性 HTTP 轮询。播放也最好用 I2S 接 DAC 和功放边收边播。另外要做一个中断机制用户说话时检测到唤醒词或按下按键立即停止当前 TTS 播放进入下一轮收听。否则用户想打断系统还在傻乎乎播上一段答案体验非常糟糕。这个“打断”逻辑看似小实际是语音交互里最核心的体验保障比模型选型影响更大。3.3 问题六对话上下文别让大模型变成没有记忆的接口ESP32 每次调用大模型 API默认是无状态的。如果你只把当前语音转出来的文本发过去大模型不知道灯现在是开是关、不知道用户上一句问过什么、更不知道设备自身的传感器读数。解决方法是把上下文主动塞给模型。我在 system prompt 里固定放一段设备信息设备名称、当前时间、灯状态、温度传感器读数然后把最近 N 轮历史作为 messages 一起传过去。多轮对话历史可以放在自己的服务器或本地环形缓冲区不需要 ESP32 存太多但每次请求要携带最近几轮的摘要。更稳的做法是让大模型输出结构化指令而不是自然语言。比如用户说“打开灯”模型 response 应该是一段 JSON{action: set_light, value: true}ESP32 端解析这个字段直接控制 GPIO。这样你不用让大模型直接碰硬件也方便做安全校验。我踩过的坑是大模型偶尔会输出多余的说明文字解析 JSON 会失败所以我一般在 API 参数里要求 JSON 输出解析失败时让模型重试一次或者在设备端做关键字兜底匹配。别拿自然语言当控制指令那会出安全问题。4. 安全、OTA 与量产最后解决“敢不敢卖”4.1 问题七密钥和设备身份很多 Demo 在裸奔我见过太多教程把云端 API Key 直接写在 ESP32 源码里编译烧录就完事。这种设备一旦到了用户手里任何人都可以用串口把 Flash dump 出来用 strings 命令搜出 Key。更别说固件可能被传到网上密钥一泄露别人就能用你的账号刷调用。对于个人项目至少要做到Key 不硬编码放在 NVS 分区烧录时单独写入同时把大模型 API 放到你自己可控的云端网关后面ESP32 只和你的网关通信网关再持有大模型 Key。这样即使 Flash 被 dump别人拿到的只是网关的设备凭据不是大模型账单入口。如果做产品设备身份认证建议用每台唯一的证书、私钥配合安全芯片或者 ESP32 的 Secure Boot 加 Flash Encryption。不要觉得“就一个几十块钱的板子不值得”。用一个设备凭据去刷你的大模型 API一个月烧掉几万 token 很容易都是真金白银。我在网关端还会做限流和异常检测同一把钥匙每秒请求多少次、凌晨疯狂调用全部报警。安全不是加一把锁是风险控制。4.2 问题八OTA 与远程维护设备交付后你还能看到它吗个人 DIY 可以接受 USB 刷机但做成产品后用户不可能拆开设备连串口。所以 OTA 是必选项。ESP32 的 native OTA 支持双分区App0 和 App1 轮流写入启动时会校验固件签名和 CRC。我在项目里加了一个启动健康位新固件启动后如果 5 分钟内没有上报心跳系统就自动回滚到上一个可用版本避免升级后变砖。第一次做 OTA 时我没做回滚结果升级了个有 bug 的固件所有设备启动崩溃只能挨个寄回那叫一个惨。OTA 之外还要有远程观测手段。我会在设备端用 MQTT 周期上报 free heap、WiFi RSSI、运行时间、当前版本号、最后一条错误崩溃时把 panic 信息存进 flash下次启动上报。没有这些数据你远程改 100 个设置都是瞎子。想在用户家里做 AI 硬件不要只盯着新功能先把“设备出问题我能不用上门就定位”这件事做好。很多产品最后死不是死在 AI 不够聪明而是死在维护成本失控。4.3 额外心得低功耗、成本和量产一致性原定 8 个问题说完了最后再补一个不算第 9 个但会在量产阶段找上门的点低功耗。如果设备是插电的那无所谓但如果是电池供电ESP32 长时间连着 WiFi 本身就是大电流待机几十 mA 都是正常的。要降到能接受的水平得用 modem sleep或者干脆让设备大部分时间 deep sleep用按键或外部唤醒词芯片来唤醒。我见过一个项目为了省电把 WiFi 断开只在拍照时连接结果每次唤醒第一件事是等路由器分配 IP用户体验大打折扣。省电和实时在线之间要做一个清醒的产品权衡没有标准答案。成本和量产一致性也一样容易被忽略。一两块 ESP32 模块看不出什么但量产时每个螺丝、每根排线、每个测试工位都算钱。我做过一个带语音和 Wi-Fi 的桌面小设备BOM 轻松到 60 多元加上外壳开模、包装、认证小批量两百台成本直接破 100。如果你的方案里有两颗 IC 可以合并、一个电容可以省掉必须提前做成本拆解。量产一致性则是另一个坑每台设备要烧录不同的 device secret工厂产线得写自动化烧录脚本不能让工人一个个点串口助手。这些看着和大模型无关但它们才是 AI 硬件能不能卖出去的真正前提。最后再说句个人体会我做的几个带大模型的设备真正花时间最多的地方几乎都不在大模型接口而是在配网页、处理噪声、搞 OTA 回滚、调电源这堆不 AI 的事情上。AI 硬件从来不是“ESP32 接个大模型就行”而是把一个“能演示的 demo”熬成“能扔到用户家里半年不管的系统工程”。你如果想做这类设备别急着上大模型先把上面 8 个问题过一遍有一个没想清楚后面都会连本带利还回来。