隐私与体验的工程平衡点

智能语音设备的「离线」承诺常引发争议：用户期待隐私保护，厂商却需云端算力支持复杂交互。本文以搭载小智语音模组的设备为例，拆解技术实现中的灰色地带。

本地与云端的功能切分

1. 唤醒与VAD层（必须本地化）
2. 采用双麦克风阵列+Beamforming算法，信噪比需≥12dB
3. 典型功耗：ESP32-S3在低功耗监听模式下电流≤8mA
4. 误唤醒率须控制在<2次/24小时（需通过AEC回声消除优化）

5. 实现细节：需配置libvad的激进模式（VAD_MODE_AGGRESSIVE），帧长设置为30ms，牺牲5%召回率换取更低功耗

6. 命令词识别层（可本地/云端）

7. 10条以内短指令可本地部署（占用Flash约200KB）
8. 动态词槽更新需依赖云端同步（如涂鸦SDK的tuya_iot_update_dynamic_words）

9. 临界测试：当WiFi信号强度<-75dBm时，需验证本地fallback词库的触发成功率（建议≥98%）

10. 自然语言理解层（普遍云端化）

11. 本地部署70M参数LLM需至少4MB SRAM（当前仅RK3588等高端SoC支持）
12. 云端交互需强制TLS1.3加密+首包响应时间<800ms
13. 隐私陷阱：即使声称「仅上传文本」，前端ASR的音频特征仍可能泄露声纹信息（需频谱扰动处理）

电流预算的生死线

• 常驻监听模式
  ESP32-S3+双麦方案实测：
• 基础监听：5.8mA @ 3.3V
• 唤醒触发瞬间峰值：210mA/200ms
• 若搭配BLE Beacon扫描：额外增加3.2mA负载

• 优化案例：某安防设备通过禁用FFT频谱计算（改用过零率检测），降低0.7mA持续电流

• 临界条件
  今年mAh电池设备需满足：
  

  (5.8mA × 24h) + (210mA × 0.2s × 50次/天) ≈ 140mAh/天  
  → 理论续航14天（实际需预留30%余量）

• 残酷现实：若用户每天实际唤醒超100次，18650电池续航将直接腰斩

硬件选型的三个误区

1. 盲目追求NPU加速
2. 端侧NPU（如Himax WE1）对VAD无实质帮助，反而增加BOM成本$1.2~1.8

3. 真正受益的是本地化CNN声纹过滤（需2.5MB模型尺寸）

4. 忽视麦克风指向性

5. 全向麦在60dB环境噪声下误唤醒率是指向性麦的3倍

6. 建议优先选用信噪比≥65dB的MEMS麦克风（如TDK ICS-43434）

7. 低估OTA回滚成本

8. 当云端ASR模型更新时，必须保证旧版固件能兼容运行至少6个月
9. 案例：某厂商因强制升级导致10%设备因Flash不足变砖

合规表述建议

1. 硬件规格书
2. 明确标注「本地唤醒词识别+云端语义解析」架构
3. 披露常驻监听模块的功耗参数（非整机待机功耗）

4. 必须注明「设备在未联网时仅支持基础指令集」

5. 用户协议

6. 禁止使用「完全离线」等绝对化描述
7. 建议采用「本地优先处理」「仅在必要时连接云端」等表述

8. 需单独列出云端处理的数据类型（如声纹特征、交互日志等）

9. 技术白皮书

10. 公开音频数据流路径图（标明本地DSP处理环节）
11. 提供SDK层面的网络请求日志接口（如xiaozhi_get_cloud_req_log）
12. 披露语音数据在设备本地的最大缓存时间（建议≤72小时）

产品经理的决策清单

• [ ] 是否接受2%以内的误唤醒率以换取更低功耗？
• [ ] 动态词槽更新频率是否影响核心用户体验？
• [ ] 首包响应超时800ms的补偿方案（如本地fallback指令）
• [ ] 是否预留硬件端TEE环境用于敏感指令本地执行？
• [ ] 麦克风硬件降噪与软件降噪的优先级划分（成本敏感型产品建议硬件优先）
• [ ] 多用户场景下的声纹注册是否强制云端同步？（合规高风险项）

开发者的自检表

1. 功耗验证
2. 使用Joulescope测量唤醒间隔期的基底电流波动

3. 模拟弱网环境（200ms~2s延迟）测试本地词库触发稳定性

4. 隐私测试

5. 通过Wireshark抓包验证TLS加密是否全程启用

6. 检查ASR原始音频是否在设备端完成特征提取（非传输完整录音）

7. 异常处理

8. 强制断电测试：验证配置参数在Flash中的崩溃恢复率
9. 模拟云端服务中断7天，检查设备基础功能可用性

当前技术条件下，绝对的「离线智能」仍是伪命题。但通过明确技术边界与诚实披露，完全可以在隐私保护与体验流畅性之间找到工程最优解。关键在于：用硬件能力定义产品承诺，而非用营销话术透支技术底线。