课程导入：TinyML与唤醒词检测的概述、课程目标、学习路径与实战项目总览

TinyML是机器学习与嵌入式系统交叉领域中最具工程落地价值的方向之一。它关注如何在微控制器（MCU）、低功耗DSP或极小规模Linux系统上部署机器学习模型，使设备具备本地智能推理能力，而无需依赖云端。唤醒词检测（Wake Word Detection）是TinyML中最典型的应用场景——设备持续监听环境声音，当识别到特定词语（如“小爱同学”“Hey Siri”或自定义唤醒词）时，才启动后续更复杂的处理流程。本课程以ONNX为模型交换与部署的中间桥梁，带领你从零构建一个可运行在真实硬件上的唤醒词检测系统。你将经历数据准备、模型训练、模型转换、量化优化、嵌入式部署与实测调优的完整闭环。

1.1 TinyML的核心原理与工程约束

TinyML并非简单地将现有深度学习模型“压缩”后塞进单片机，而是从硬件特性出发重新审视整个机器学习生命周期。典型的TinyML设备使用ARM Cortex-M系列处理器（如STM32F4、nRF52840、ESP32-S3），主频通常在80MHz至240MHz之间，RAM容量从几十KB到几百KB不等，Flash存储为512KB至数MB。这些资源约束决定了模型设计必须遵循“小而精”的原则。

从计算角度看，唤醒词检测模型通常采用深度可分离卷积（Depthwise Separable Convolution）或轻量级循环结构（如GRU），参数量控制在10万至50万之间。以本课程使用的“Hey Nano”唤醒词为例，一个典型的DS-CNN（Depthwise Separable Convolutional Neural Network）模型，输入为49帧×10维MFCC特征，经过4层深度可分离卷积后，全连接层输出2个类别（唤醒词/非唤醒词），总参数量约23K，模型大小约92KB（FP32），INT8量化后仅23KB。

另一个关键约束是内存访问模式。MCU没有DRAM，所有数据存放在SRAM中，因此推理过程中的中间特征图（Feature Map）必须严格控制。例如，输入特征图大小为49×10×1，第一层卷积后变为25×5×8，第二层变为13×3×16，逐层递减，确保峰值内存不超过预设阈值。工程上常用“内存规划表”来逐层核算每个张量的生命周期，避免内存碎片和溢出。

1.2 唤醒词检测的技术原理与判断方法

唤醒词检测系统的工作流程可以分解为四个阶段：音频采集、前端处理、模型推理、后处理决策。音频采集阶段，麦克风以16kHz采样率、16bit量化精度持续采集环境声音，每帧长度为30ms（480个采样点），帧移为20ms，形成连续的音频流。前端处理阶段，对每一帧计算MFCC特征，通常取13维静态系数加上一阶差分，得到26维特征向量；为了捕捉时序上下文，将连续49帧特征拼接成49×26的二维特征图作为模型输入。

模型推理阶段，ONNX模型被转换为适合MCU执行的C代码或使用ONNX Runtime Micro解释器执行。以本课程采用的STM32F746G-Discovery开发板为例，其Cortex-M7内核主频216MHz，运行INT8量化的DS-CNN模型，单次推理耗时约45ms，满足实时性要求。后处理决策阶段，采用“滑动窗口+阈值判定”策略：模型每200ms输出一次唤醒概率，当连续3次概率超过0.7时判定为唤醒事件，同时触发2000ms的抑制窗口，防止重复触发。

判断一个唤醒词检测系统是否合格，需要同时考察三个维度：唤醒灵敏度（在噪声环境下能否正确识别）、误唤醒率（非唤醒词触发次数）、响应延迟（从说话到系统响应的时间）。实际测试中，我们会在安静环境、办公室噪声（约50dB）、街道噪声（约70dB）三种场景下分别采集200条测试语音，计算准确率和误唤醒率。

1.3 课程目标与学习路径规划

本课程的目标是让你掌握从零构建TinyML唤醒词检测系统的完整工程能力，具体包括：能够独立采集和标注语音数据集；熟练使用PyTorch训练轻量级唤醒词模型；掌握将PyTorch模型导出为ONNX并进行图优化和INT8量化的方法；能够在STM32等MCU上部署ONNX模型并完成实时推理；具备系统调试和性能调优的能力。

学习路径分为四个阶段，每个阶段都有明确的交付物。第一阶段（第1-7章）聚焦数据与模型训练，你将使用Google Speech Commands数据集的一个子集，训练一个初始DS-CNN模型，目标准确率达到92%以上。第二阶段（第8-14章）深入ONNX转换与优化，你将学习如何排查ONNX算子兼容性问题，使用onnxruntime进行精度验证，并实施INT8量化，将模型从FP32的92KB压缩至23KB。第三阶段（第15-22章）进入嵌入式部署，你将使用STM32CubeMX配置工程，集成CMSIS-NN加速库，实现音频采集、特征提取和模型推理的流水线。第四阶段（第23-30章）是系统联调与优化，包括功耗测量、延迟优化、鲁棒性增强以及实际场景测试。

1.4 实战项目总览：从“Hey Nano”到完整产品原型

本课程的实战项目是构建一个名为“Hey Nano”的唤醒词检测系统，最终运行在STM32F746G-Discovery开发板上。项目分为三个里程碑：里程碑A（第1-10章）完成模型训练与ONNX转换，交付一个可在PC端通过ONNX Runtime验证的INT8量化模型；里程碑B（第11-20章）完成嵌入式移植，实现音频采集、MFCC提取和模型推理的完整链路，在开发板上实现实时唤醒；里程碑C（第21-30章）完成系统优化，包括降低误唤醒率、优化功耗、增加自定义唤醒词支持，最终形成一个可演示的产品原型。

在里程碑A中，你将遇到第一个关键挑战：ONNX算子兼容性。PyTorch中的某些算子（如torch.nn.functional.pad）在导出ONNX时可能产生不兼容的节点。例如，DS-CNN中的深度可分离卷积在PyTorch中通常实现为分组卷积（groups=in_channels），导出ONNX后会产生GroupConv节点，而某些MCU推理引擎不支持该算子。解决方案是使用ONNX的算子重写功能，将GroupConv拆分为Conv + Reshape + Conv的组合。我们将在第9章详细讲解这一过程。

里程碑B的核心难点在于内存管理。STM32F746G拥有320KB RAM，但其中约128KB被图形显存占用（如果使用LCD显示），实际可用RAM约192KB。模型推理需要约64KB的中间缓冲区，MFCC特征提取需要约20KB，音频DMA缓冲区需要约16KB，剩余约92KB用于系统栈和堆。我们将在第16章提供详细的内存规划表，并演示如何使用STM32CubeMX的MPU配置来防止缓存一致性问题。

里程碑C的调优过程最具工程价值。初始模型的误唤醒率可能高达每小时5次，通过分析误唤醒样本，我们发现大部分误唤醒发生在“不”和“好”等相似发音的词语上。解决方案是增加对抗样本训练——在训练集中加入这些易混淆词语，并调整损失函数为Focal Loss，使模型更关注难分类样本。经过三轮迭代，误唤醒率降至每24小时0.8次，达到商用标准。

1.5 常见误区与总结复盘

初学者在TinyML项目中容易陷入几个典型误区。第一个误区是“模型越大越好”——在资源受限的MCU上，一个参数量超过100万的模型即使能运行，也会因内存溢出或推理超时而失去实用价值。正确的做法是先设定资源预算（RAM、Flash、延迟），再反推模型结构。第二个误区是“量化是最后一步”——实际上，量化感知训练（QAT）应该在模型训练阶段就纳入考虑，否则后训练量化（PTQ）可能导致精度下降超过5%。第三个误区是“忽略前端处理”——MFCC特征提取的参数（帧长、帧移、Mel滤波器数量）对唤醒准确率的影响不亚于模型结构本身。

从工程复盘角度看，本课程项目最宝贵的经验是“建立可重复的评估流程”。我们开发了一套自动化测试脚本，能够在PC端模拟MCU的推理环境，批量测试不同量化参数、不同阈值设置下的性能指标。这套流程使得每次模型更新后，都能在30分钟内获得完整的性能报告，大幅缩短了迭代周期。另一个重要经验是“硬件在环测试不可替代”——即使PC端模拟完全正常，实际部署后仍可能遇到DMA中断优先级冲突、FPU状态保存等问题，这些只能在真实硬件上暴露。

总结本章内容，TinyML唤醒词检测是一个典型的端到端工程问题，涉及数据、算法、系统和硬件的协同设计。本课程将引导你逐步构建完整的知识体系和实践能力，最终能够独立完成从模型训练到嵌入式部署的全流程。下一阶段，我们将从数据准备开始，深入讲解如何构建高质量的唤醒词数据集。