2、关键词识别基础：语音信号处理基础、MFCC特征提取、关键词识别模型架构（如TCN、CRNN、Attention）

关键词识别（Keyword Spotting, KWS）是端侧语音交互的入口级技术，其核心目标是在连续音频流中实时检测预设的唤醒词或命令词。与大规模语音识别（ASR）不同，KWS 通常只需要识别有限的词汇集合（如“你好小欧”、“打开空调”），因此模型规模可以压缩到数百 KB 至数 MB 级别，从而适配 MCU、DSP 或低功耗应用处理器。本章将系统拆解 KWS 的三大技术支柱：语音信号预处理与特征提取、MFCC 的工程化实现、以及主流轻量级模型架构（TCN、CRNN、Attention）的选型逻辑。理解这三者的协同关系，是后续在 ONNX Runtime 端侧部署中实现低延迟、低功耗推理的前提。

上图展示了 KWS 端侧部署的完整技术链路。从音频信号输入到最终触发指令，每个环节都直接影响延迟和精度。语音信号处理负责将原始波形转换为适合模型输入的二维特征图；MFCC 作为最经典的语音特征，在端侧依然占据主导地位；模型架构则决定了计算量和参数量。在 ONNX Runtime 部署阶段，我们需要将训练好的 PyTorch/TensorFlow 模型导出为 ONNX 格式，并进行量化、算子融合等优化。下面逐一深入每个模块。

2.1 语音信号处理基础：从波形到特征帧

核心原理：语音信号是非平稳的时变信号，但在短时间（10-30ms）内可视为平稳。因此，标准处理流程是：预加重 → 分帧 → 加窗 → 端点检测。预加重使用一阶高通滤波器（系数通常为 0.97）提升高频分量，补偿语音信号的高频衰减。分帧采用帧长 25ms、帧移 10ms 的滑动窗口，保证相邻帧有 60% 重叠，避免特征突变。加窗通常选择汉明窗（Hamming Window），其旁瓣衰减较大，能减少频谱泄漏。

判断方法或操作流程：在端侧实现时，需要注意以下流程细节：

1. 采样率选择：KWS 任务通常使用 16kHz 采样率（宽带语音），若 MCU 算力受限可降为 8kHz，但会损失高频信息，影响部分辅音识别。
2. VAD（语音活动检测）：基于短时能量和过零率的双门限法是最轻量的方案。计算每帧能量 E 和过零率 ZCR，当 E > T1 且 ZCR 在合理范围时判定为语音帧。T1 需根据环境噪声动态调整（如取前 10 帧噪声能量的 2 倍）。
3. 数据格式：端侧通常使用 16-bit PCM 编码，在送入特征提取前需转换为浮点数（除以 32768.0）。若使用 INT8 量化模型，则特征输入也需要量化到 [-128, 127]。

2.2 MFCC特征提取：工程化实现与参数调优

核心原理：MFCC（Mel-Frequency Cepstral Coefficients）模拟人耳对频率的非线性感知。其计算流程为：对每帧信号做 FFT 得到功率谱 → 通过 Mel 滤波器组（通常 40 个三角滤波器）进行频带能量汇总 → 取对数 → 做 DCT（离散余弦变换）得到倒谱系数。前 12-13 个系数保留，其余丢弃。为了捕捉动态特征，还会计算一阶差分（Δ）和二阶差分（ΔΔ），最终形成 39 维或 40 维特征向量（含能量项）。

判断方法或操作流程：在端侧实现 MFCC 时，需关注以下参数选择：

参数	典型值	端侧优化建议	影响
FFT 点数	512 (16kHz)	256 (8kHz)	频率分辨率：512点对应 31.25Hz/bin
Mel 滤波器数量	40	20-26	减少滤波器可降低计算量，但低频分辨率下降
DCT 系数数量	12-13	10-12	系数越少，抗噪性越强，但可能丢失细节
动态特征	Δ + ΔΔ	仅 Δ	动态特征增加 2/3 计算量，但提升 5-10% 准确率
窗函数	汉明窗	汉宁窗（计算更简单）	汉宁窗旁瓣更低，但主瓣稍宽

案例拆解：我们为一个唤醒词“小欧小欧”设计 MFCC 前端。初始参数：16kHz 采样率，FFT 512 点，40 个 Mel 滤波器，13 个静态系数 + Δ + ΔΔ = 39 维。在树莓派 4B 上测试，单帧 MFCC 计算耗时约 2.3ms（纯 Python 实现），C 语言优化后降至 0.4ms。进一步优化：将 Mel 滤波器组矩阵预先计算并存储为稀疏矩阵（40×257），避免重复计算；使用定点数（Q15 格式）替代浮点数，在 Cortex-M7 上可将耗时降至 0.15ms。最终，98 帧的 MFCC 提取总耗时约 15ms，满足实时性要求。

2.3 关键词识别模型架构：TCN、CRNN 与 Attention 的选型

核心原理：KWS 模型需要在时序上建模语音帧的上下文依赖。三种主流架构各有侧重：

• TCN（时间卷积网络）：使用因果空洞卷积（Causal Dilated Convolution）扩大感受野。堆叠 8-10 层，每层空洞率呈指数增长（1,2,4,8,...），感受野可达数百毫秒。TCN 的优点是并行度高（卷积可并行），推理延迟低，适合流式处理。
• CRNN（卷积循环网络）：前端用 2-3 层 CNN 提取局部特征，后端用 GRU/LSTM 建模长时依赖。CRNN 对时序变化更鲁棒，但 GRU 的循环依赖导致推理延迟较高（需逐帧计算）。
• Attention（自注意力）：轻量级 Transformer 或仅使用自注意力层。Attention 能直接建模任意距离的依赖，但计算量随序列长度平方增长。在端侧，通常限制序列长度（如 50 帧）并使用窗口注意力。

判断方法或操作流程：选择架构时，需根据目标平台和延迟预算决策：

1. 若平台为 MCU（Cortex-M4/M7）：优先选择 TCN，因为卷积算子可高度优化（使用 CMSIS-NN），且无循环依赖，内存占用可控。
2. 若平台为带 NPU 的应用处理器：CRNN 或 Attention 可能更合适，因为 NPU 对矩阵乘法加速效果好，GRU 可展开为矩阵运算。
3. 若需支持连续多词识别：Attention 架构更容易扩展输出头，但需注意序列长度限制。

2.4 端侧部署的模型优化与 ONNX Runtime 集成

核心原理：将训练好的模型部署到端侧，需经过导出 → 优化 → 量化 → 集成四个步骤。ONNX Runtime 提供了丰富的图优化和量化工具。在导出时，需固定输入形状（如 [1, 98, 39]）以利于内存预分配。量化推荐使用动态量化（权重 INT8，激活浮点）或全整型量化（权重和激活均为 INT8），后者需要校准数据集（约 100-500 条音频特征）。

操作流程：

1. 使用 torch.onnx.export 导出模型，设置 opset_version=12（支持更多量化算子）。
2. 使用 onnxruntime.quantization.quantize_dynamic 或 quantize_static 进行量化。
3. 使用 onnxruntime.transformers.optimizer 进行算子融合（如 Conv+BN+ReLU 融合）。
4. 在 C++ 端创建 Ort::Session，设置线程数为 2-4，开启 ORT_ENABLE_ALL 优化级别。

// C++ 端 ONNX Runtime 推理示例
Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "kws");
Ort::SessionOptions opts;
opts.SetIntraOpNumThreads(2);
opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);
opts.SetOptimizedModelFilePath("optimized_kws.onnx");
Ort::Session session(env, "kws_int8.onnx", opts);
// 输入张量: float32 [1, 98, 39]
std::array<int64_t, 3> input_shape = {1, 98, 39};
Ort::MemoryInfo mem_info = Ort::MemoryInfo::CreateCpu(OrtArenaAllocator, OrtMemTypeDefault);
Ort::Value input_tensor = Ort::Value::CreateTensor<float>(mem_info, mfcc_data.data(), mfcc_data.size(), input_shape.data(), input_shape.size());
// 推理
auto output_tensors = session.Run(Ort::RunOptions{nullptr}, input_names.data(), &input_tensor, 1, output_names.data(), 1);
float* output = output_tensors.front().GetTensorMutableData<float>();
// output[0] 为 "小欧" 的概率，output[1] 为 "其他" 的概率

案例复盘：在某智能音箱项目中，初始模型为 CRNN，导出 ONNX 后大小为 840KB，INT8 量化后降至 210KB。但推理延迟仍达 35ms（树莓派 4B）。通过分析 profiling 结果，发现 GRU 算子的 Scan 节点耗时占比 60%。解决方案：将 GRU 替换为 TCN 的因果卷积层，模型大小降至 180KB，延迟降至 15ms。同时，将 MFCC 提取从 Python 迁移到 C++（使用 KissFFT 库），整体流水线延迟从 55ms 降至 22ms，满足“唤醒词响应 < 100ms”的产品需求。