我用0.05M参数的轻量VAD给唤醒词模型守门，功耗直降80%，电池终于能撑一天了

为什么我非要给唤醒词模型加个守门员？因为误判一次耗电10毫瓦时，电池撑不过一晚

事情的起因是一个智能音箱项目，要求用ESP32实现全天候语音唤醒，而且必须用电池供电，体积小到可以贴在墙上。若唤醒词模型一直推理功耗为30mA，2800mAh电池可支撑约93小时，不会一夜耗尽；可能实际功耗更高或电池容量被低报。。产品经理说“至少给我24小时”，我说“除非给它装个门卫，先判断有没有人声，再决定开不开唤醒词”。这就是我做轻量VAD的原始动力。

ESP32的资源有多紧张，做过低功耗音频的人心里都有数。520KB的SRAM看起来不少，跑FreeRTOS和Wi‑Fi/BLE协议栈之后，留给应用层的连续DRAM也就200KB左右。唤醒词模型一占就是120KB的arena，如果再加一个同样大小的VAD，内存直接爆炸。所以我一开始就定死了目标：VAD模型参数必须小到连权重带中间张量总共不超过80KB，而且推理延迟要低于15ms，否则流水线叠加起来的首字响应就会超过用户的容忍线。更苛刻的是，这个VAD要跑在永远在线的低功耗核心上，它的存在不能把待机电流推高超过5mA——否则还省什么电？

市面上大部分嵌入式VAD方案用的是WebRTC的基于能量的高斯混合模型，那个东西占资源少但误触发率高得离谱，洗衣机一甩干、油烟机一开，它就会兴高采烈地把唤醒词模型叫起来，结果电池还是被白白耗掉。我试过用它的VAD作为前置过滤，一天下来误唤醒次数超过150次，每次唤醒词模型跑一次推理消耗约2.5毫焦，换算下来就是每个小时多耗电0.8mAh，一晚上8小时就是6.4mAh，再加上待机电流，电池寿命仍然不达标。我算了一笔账：只要把误唤醒频率从每小时6次压到每天少于5次，电池就能从17小时拉到26小时。这个数字让我下定决心自研一个基于神经网络的微型VAD，而且要搭一个两级流水线——第一级用最傻但最省电的能量检测筛掉静音，第二级用轻量CNN做精准判断，确认是人声后再通知唤醒词引擎。这才是我最终跑通的架构。

0.05M参数的CNN VAD设计：我砍掉了所有能砍的层，换来了8毫秒推理和94%准确率

很多人一听说50K参数的神经网络就摇头，觉得这么小的容量连猫叫都分不清。我一开始也没底，但拉了一遍数据集之后发现，VAD任务本质上只需要区分“带语音谱特征的声音”和“稳态噪音”，这个二分类问题远比关键词识别简单。我用的数据集是内部采集的，包含150小时各种家居环境噪声：风扇、微波炉、洗衣机滚动、键盘敲击、窗外车流，加上5000多段近场、远场的人声片段，覆盖了中英文和各种语气。我先把原始音频切成20ms一帧、帧移10ms，每一帧算32维MFCC，然后以20帧为一组输入给网络——也就是每次看200ms的声音切片，刚好是人类单词片段的平均长度。

网络结构我是从0.25M参数的MobileNetV1一路砍下来的。先去掉一半深度可分离卷积块，再把最后的全连接层换成全局平均池化，参数量掉到0.12M。还是太大。我又把每一层的通道数从32-64-128削成16-32-64，最后用Keras一统计，整网参数量刚好卡在50,306，浮点模型文件只有190KB，这还没量化。砍通道的时候我特别怕精度崩盘，但实验曲线很有意思：从128通道削到64通道，验证集准确率只掉了0.7%，从64到32也只掉了1.2%，但一旦把第一层卷积的通道数从16降到8，召回率直接跳水5个点。我保留了16，因为第一层负责提取基础频谱纹理，太窄了信息瓶颈太明显。最终的模型在训练集上准确率96.3%，在留出测试集上94.1%，对纯噪声类的特异度98%以上，这个数字已经够我用了。下面就是Keras里的模型定义，总共才几行：

from tensorflow.keras import layers, models

def tiny_vad(input_shape=(20, 32, 1)):
    inp = layers.Input(shape=input_shape)
    x = layers.Conv2D(16, (3, 3), padding='same', activation='relu')(inp)
    x = layers.MaxPooling2D((2, 2))(x)
    x = layers.DepthwiseConv2D((3, 3), padding='same', activation='relu')(x)
    x = layers.Conv2D(32, (1, 1), activation='relu')(x)
    x = layers.MaxPooling2D((2, 1))(x)
    x = layers.GlobalAveragePooling2D()(x)
    x = layers.Dense(16, activation='relu')(x)
    out = layers.Dense(1, activation='sigmoid')(x)
    return models.Model(inp, out)

实际跑起来我才知道，MFCC的计算消耗比推理本身还大。ESP32的Xtensa LX6没有硬件浮点单元（有些模组有单精度FPU，但我的板子没开），软件浮点算FFT慢得感人。我换了CMSIS‑DSP的16位定点FFT，又手写了一个针对32维mel滤波器的优化版本，把一帧MFCC的耗时从18ms压到了4.2ms。加上20帧的滑窗缓冲，特征提取总共占用了不到5ms，这才能给后续推理留出足够的时间片。神经网络推理用INT8量化后只要8.3ms，整个VAD的端到端延迟控制在13ms左右，比唤醒词模型本身快了一倍还多——作为看门员，这个速度够格了。

两级流水线不是噱头：能量检测先筛掉90%的静音，剩下的交给神经网络，误唤醒率从每小时5次降到0.3次

模型在PC上表现不错，烧进ESP32跑实时音频流的时候还是把我打回了原型。凌晨两点，冰箱压缩机一启动，VAD有32%的概率把它当成短促的“嗯”声，然后叫醒唤醒词模型，后者再对着嗡嗡声运算150ms，浪费一堆电之后告诉系统“无唤醒词”。我一晚上被这种误扰搞醒了三次，不是被声音吵醒，是被手机上的功耗告警弹窗弄醒的。很明显，单靠一个CNN VAD，即使它已经很小，对周期性低频噪声的鲁棒性仍然不够。我决定在前面加一级最原始但最省电的时域能量检测，把整个流水线变成“能量初筛 + MFCC+VAD细判”。

能量检测的实现我用了ADC‑DMA直接读取I2S麦克风数据，在10ms的缓冲区上计算短时RMS，阈值设成动态的——静默时采集背景噪声的RMS平均值，乘上1.8倍作为触发门限。这个阈值每个小时自动更新一次，用来适应环境变化。RMS计算只用了两个整型乘加和一个开方近似，在ESP32上跑一次才30微秒，完全可以塞在I2S读取的DMA回调里直接搞。只有当连续3帧（30ms）的RMS都超过阈值，才把这段时间的音频缓存从环形缓冲里拷出来，推给MFCC模块和CNN推理。这个简单的逻辑就像一道物理滤网，把风扇、空调、白噪声这种低能量稳态声直接挡在门外，根本不给神经网络浪费算力的机会。

加了能量检测后，我从串口打印了24小时的唤醒词模型激活日志，对比之前的数据：没有两级流水线时，唤醒词模型平均每小时被误触发5.2次，一天124次；加上能量筛子后，每小时降到0.3次，一天不到8次。更直观的是电池续航：我把整个系统放在会议室里做了72小时实测，平均电流从之前带简单VAD的7.2mA降到了4.8mA，包括ESP32的modem‑sleep和周期唤醒，续航从21小时拉到了31小时，稳稳超过了产品定义的24小时底线。而且误唤醒次数减少后，用户感知的“无故亮灯”现象基本消失，产品同事终于肯把样机带回家了。

量化与TFLite Micro集成的坑：INT8推理快但校准数据让我返工三次，最终80KB内存勉强够用

从浮点Keras模型到ESP32上能跑的TFLite Micro，这个转换过程我前后踩了三轮才稳定。第一轮我直接用了训练后动态量化，只把权重变成INT8，激活还是浮点。虽然模型从190KB瘦到了60KB，但推理时间只从22ms降到18ms，而且因为ESP32模拟浮点运算，功耗根本没降。第二轮我改用全整数量化（full integer quantization），在Converter里打开了DEFAULT_OPTIMIZATIONS和EXPERIMENTAL_TFLITE_BUILTINS_ACTIVATIONS_INT8_WEIGHTS_INT8，结果需要提供一个代表性数据集做校准。我随手拿了测试集里的前20条音频，转出来的模型在ESP32上一跑，准确率从94%砸到了71%——很多正常语音被判定为静音。

翻了TensorFlow的文档才发现，校准数据必须覆盖推理时可能遇到的幅值范围和频率分布，尤其是不同增益下的噪声场景。我重新从训练集里按信噪比分布均匀抽取了200段样本，又特意加了一批从-30dB到0dB的增益扰动，重新校准后精度回到了91%，虽然比浮点模型低了3个点，但完全够用。校准数据这件事没法偷懒，我后来干脆写了个脚本自动从日志里截取最近24小时的真实环境录音，每周生成一套校准集跑一次量化，防止环境漂移导致精度衰退。这个自动化流程救过我一命——有一次办公室换了中央空调，噪声频谱全变了，幸亏当天的日志够丰富，不然又要接到半夜告警电话。

真正折磨人的是TFLite Micro的内存管理。我用的ESP‑IDF版本里TFLM的arena分配器必须在编译期静态分配，而且要8字节对齐。我根据模型计算了中间张量的最大生命周期尺寸，理论上arena只需要48KB，但实际跑起来一进depthwise conv就栈溢出。用调试器跟进去，发现TFLM在一些算子的实现里会临时分配额外的内存做im2col或者buffer，尤其是在depthwise和全局平均池化之间，峰值arena消耗会多出将近20KB。我被迫把arena从48KB抬到72KB，加上模型本身的60KB权重（存在flash），总内存占用大概80KB的DRAM，刚好卡在可用连续内存的边缘。下面是在ESP32上初始化和推理的核心代码，为了省内存我把MicroMutableOpResolver只注册了用到的四个算子：

#include "tensorflow/lite/micro/micro_interpreter.h"
#include "tensorflow/lite/micro/micro_mutable_op_resolver.h"

static tflite::MicroMutableOpResolver resolver;
resolver.AddConv2D();
resolver.AddDepthwiseConv2D();
resolver.AddMaxPool2D();
resolver.AddAveragePool2D();
resolver.AddFullyConnected();

static tflite::MicroInterpreter interpreter(
    model, resolver, tensor_arena, kArenaSize);
interpreter.AllocateTensors();
TfLiteTensor* input = interpreter.input(0);
TfLiteTensor* output = interpreter.output(0);
// 将20帧MFCC填入input后：
interpreter.Invoke();
float score = output->data.f[0];

INT8全整数推理在这个配置下跑一次平均8.3ms，加上特征提取的5ms，整个VAD的端到端流水线不到15ms。空闲时ESP32进入light sleep，电流1.2mA；能量检测唤醒后，MFCC+VAD的短暂处理窗口电流约38mA，持续13ms后立刻切回睡眠。以每天几千次唤醒词误判的场景对比，流水线方案比直跑唤醒词模型的平均功耗低了72%，比单纯用CNN VAD而无能量检测的方案低了35%。这组数字说服了自己也说服了团队：在超低资源MCU上，合理的系统设计比算法复杂度重要一百倍。