智能家居设备上的语音交互以往大多依赖云端识别，但网络波动、上传延迟和隐私担忧让端侧推理变得越来越有吸引力。涂鸦 IoT 平台是智能家居行业常用的设备接入与管理底座，它并不限定语音方案，却提供了灵活的模组 SDK、OTA 与设备控制通道，适合把端侧语音识别模型集成到真实产品中。端侧方案的难点在于模型必须足够小，同时要保持可用的唤醒率和命令词准确率。
一、边缘语音与涂鸦平台结合的整体思路
端侧语音识别在智能家居场景中通常分为两个任务：唤醒词检测和命令词识别。前者负责把设备从低功耗待机状态拉起来，后者负责把用户语音转成具体动作，例如打开灯光、调高温度或切换场景。云端方案确实能处理复杂句，但每次交互都需上传音频，离线时设备直接失去语音能力。涂鸦生态内的网关、中控面板、智能音箱等产品如果引入端侧识别，能在断网情况下保留基础控制能力，同时减少云服务成本。
涂鸦 IoT 平台提供 TuyaOS、联网模组和标准 DP 点协议。语音模型输出识别结果后，可以映射到布尔型、枚举型或数值型 DP，再通过本地联动或涂鸦云下发到目标设备。以开关面板为例，模型识别到“打开灯光”后，MCU 只需调用涂鸦 DP 上报接口把开关状态置为 true，App 和云端状态会同步更新。这个链路不需要额外语音云服务，也无需把音频送出设备。
开发前需要确定模组的计算资源。例如一些 Wi-Fi 模组带有 Arm Cortex-M33 或 M4 内核，可用 Flash 可能只有 2MB，SRAM 在 256KB 到 512KB 之间。端侧模型压缩后应控制在 1MB 以内，理想情况在 300KB 到 600KB，才能给音频缓冲、协议栈和业务逻辑留出足够空间。基于这个约束，模型选型和量化策略比单纯追求准确率更重要。
二、端侧语音模型选型与量化部署
唤醒词检测可以选用轻量卷积网络，比如 DS-CNN 或 TC-ResNet，这类模型参数量小，对 Mel 频谱或 MFCC 特征比较友好。命令词识别如果只需要几十个固定命令，可以使用同一套特征输入，设计为多分类 CNN 或轻量 Conformer。对于中文智能家居，命令词通常包括设备名、动作和区域，词汇表可以控制在 30 到 100 个，这样模型不会过于复杂。
在模型训练阶段，建议使用 16kHz 单声道音频，经过预加重、分帧、加窗和 40 维 Mel 特征提取。训练平台可以用 TensorFlow 或 PyTorch，训练完成后转换到端侧推理格式。以 TensorFlow Lite 为例，导出 int8 量化的过程如下：
import tensorflow as tf
def representative_dataset_gen():
for _ in range(100):
data = tf.random.normal([1, 98, 40])
yield [data]
converter = tf.lite.TFLiteConverter.from_saved_model('kws_model')
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset_gen
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8
tflite_model = converter.convert()
with open('kws_int8.tflite', 'wb') as f:
f.write(tflite_model)
这段代码把浮点模型转换为 int8 模型，通常可把体积缩小到原来的四分之一左右，同时推理速度也会有明显提升。量化过程中需要用有代表性的音频特征做校准，校准样本最好覆盖不同说话人、不同背景噪声和不同距离，否则量化误差会导致唤醒率明显下降。
模型放到设备上后，需要选择推理引擎。Arm 内核可以使用 TensorFlow Lite for Microcontrollers 或 ONNX Runtime Embedded，配合 CMSIS-NN 内核加速。若模组性能有限，还可以先剪枝，移除影响较小的通道，再量化。端侧推理的典型流程会先做特征缓存，然后每隔 10ms 滑动一次窗口，把 98 帧 Mel 特征送到模型，输出唤醒词或命令词的概率。实际工程里往往需要两次连续触发或后验平滑来降低误唤醒。
三、涂鸦设备接入与语音指令映射
接入涂鸦平台的设备通常需要在涂鸦开发者平台创建产品，定义 DP 点，并下载对应模组的 TuyaOS SDK。语音识别结果并不直接与涂鸦协议绑定，而是在本地业务层完成映射。比如定义 DP 1 为总开关，DP 2 为亮度，DP 3 为场景模式，当语音模型输出“打开灯光”时，程序将 DP 1 置为 true 并调用上报接口。
设备端初始化代码通常包含 TuyaOS 初始化、产品信息配置和 DP 数据上报接口。以下是一个简化示例，展示语音识别回调里如何上报 DP：
#include <tuya_iot.h>
#include <string.h>
#define DPID_SWITCH 1
extern int run_voice_model(int16_t* pcm, int len);
static void report_switch(bool on) {
TY_OBJ_DP_S dp;
memset(&dp, 0, sizeof(dp));
dp.dpid = DPID_SWITCH;
dp.type = PROP_BOOL;
dp.value.dp_bool = on ? 1 : 0;
tuya_iot_dp_report(NULL, &dp, 1);
}
void voice_task_entry(void) {
int16_t pcm[480];
while (1) {
int ret = run_voice_model(pcm, 480);
if (ret > 0) {
report_switch(true);
}
}
}
这个示例假设 run_voice_model 已经封装了特征提取和模型推理。实际项目中音频采集通常放在单独任务里，通过 DMA 搬运 PCM 数据，推理任务消费音频队列，避免阻塞采集。语音识别返回命令词 ID 后，可以维护一个命令词到 DP 动作的映射表，例如“打开灯光”对应开关 DP，置为 true；“调亮一档”对应枚举 DP，增加一档亮度。
本地联动和 App 同步时需要注意 DP 上报频率。语音命令触发一次只上报一次，不应在循环中反复上报同一状态。涂鸦云会通过 MQTT 或 HTTP 协议同步到 App，若设备离线，涂鸦本地联动仍然可以基于网关或同一个 MCU 下发控制。对于跨设备场景，可以借助涂鸦的本地场景或规则引擎，把语音识别结果关联到其他设备，但最好保留本地直控路径以降低延迟。
四、音频前端处理与工程调优
端侧语音识别的效果很大程度取决于音频前端。单麦克风方案在安静环境下可用，但在客厅、厨房等有电视、油烟机噪声的场景中容易误触发。双麦克风阵列配合简单的波束成形和噪声抑制可以提升信噪比，不过会增加 BOM 成本和调试复杂度。工程上至少要做自动增益控制，把麦克风增益调整到合适范围，避免声音过小导致特征值接近静音，或声音过大导致削顶失真。
特征提取的帧长、帧移和窗函数要与训练阶段严格一致。训练时如果使用 30ms 帧长、10ms 帧移和汉明窗，设备端也必须相同，否则特征分布会偏离训练集。音频采集建议使用 16kHz、16bit、单声道，I2S 外设时钟配置错误是常见问题之一，例如把采样率配成 44.1kHz 而没有重新训练模型，识别率会明显下降。可以在设备启动时打印一帧 PCM 的能量和过零率，快速判断音频链路是否正常。
内存与实时性也要提前规划。模型推理期间如果占用过多栈空间，可能影响协议栈和 OTA 流程。建议把模型权重放置在 Flash 的只读区，激活张量放在 SRAM 中，并用静态分配替代动态内存。若使用 CMSIS-NN 加速，需要确认模组的 DSP 扩展是否开启，否则只能退回普通内核实现。调试误唤醒时，可以记录每次触发前后的音频能量和模型输出概率，通过阈值调整和连续触达门控来平衡唤醒率与误唤醒。