1. STM32N6边缘AI项目全景

STM32N6 是 ST 推出的面向边缘 AI 的高性能 MCU 系列，核心特征不是“把神经网络跑起来”这么简单，而是把 NPU 加速、图像/音频采集、实时控制、低功耗与安全启动 放进同一颗芯片里。理解它的定位，先要把它和三类常见方案区分开：一类是传统 Cortex-M MCU 加轻量推理库，算力有限；一类是 Cortex-A 应用处理器加 Linux，算力强但功耗、启动时间和实时性代价高；还有一类是专用 AI 加速芯片，推理快但外设整合与实时控制弱。STM32N6 的典型位置，是在这三者之间：用 Neural-ART NPU 承担卷积、矩阵乘等张量密集计算，用 Cortex-M55 负责调度、前后处理与实时任务，用丰富的外设接口连接摄像头、麦克风、传感器和执行器。

从交付场景看，STM32N6 常见的边缘 AI 项目可以归为四类。第一类是视觉检测，例如产线零件缺陷识别、仪表读数、人员/安全帽检测，输入通常是 DCMI/CSI 摄像头图像，输出是类别、置信度和检测框。第二类是音频事件识别，例如玻璃破碎、异常噪声、关键词唤醒，输入是 I2S/PDM 麦克风，输出是事件标签与时间戳。第三类是传感器融合与预测，例如电机振动异常、设备状态预测，输入是多路 ADC/SPI 传感器数据，输出是健康度或告警等级。第四类是人机交互，例如手势、姿态、存在检测，强调低延迟与低功耗常开。四类场景的模型结构、输入带宽和实时性要求不同，但项目生命周期的主干是一致的。

一个可交付的 STM32N6 边缘 AI 项目，通常经历六个阶段：需求与指标定义、数据采集与标注、模型训练与量化、部署与固件集成、板端验证与调优、量产与维护。很多项目失败并非模型精度不够，而是指标定义阶段就埋下隐患：只写“识别准确率 95%”，却没有定义输入分辨率、帧率、光照条件、误报率上限、功耗预算和启动时间。对 STM32N6 而言，建议在需求阶段就锁定以下可验收指标：模型输入尺寸（如 224×224×3 或 96×96×1）、推理帧率（如 15 FPS 或 30 FPS）、端到端延迟（采集到输出，如 ≤80 ms）、NPU 占用率、内存占用（权重与激活值分别统计）、功耗模式与平均电流、以及误报/漏报的接受边界。这些指标会直接决定后续模型选型与量化策略。

下面这张图给出 STM32N6 边缘 AI 项目的全景关系：左侧是真实世界的输入对象，中间是芯片内部的采集、预处理、NPU 推理与后处理链路，右侧是交付结果与验证指标，底部是贯穿始终的数据与模型资产流。

这张图里最容易被忽视的是底部那条资产流。很多团队把“模型训练完”当成项目结束，但在 STM32N6 上，真正决定交付质量的是量化模型与部署固件之间的一致性：训练时用的输入归一化方式、量化校准集分布、NPU 算子支持范围，任何一处与板端不一致，都会导致精度骤降或推理失败。因此，项目从一开始就要把数据集、训练脚本、量化配置、部署工程和验证日志当作同一套可追溯资产来管理。

课程实战目标围绕一个完整的交付闭环展开：以一个可运行的视觉或音频示例为载体，从指标定义开始，完成数据准备、模型训练与 INT8 量化、使用 STM32Cube.AI 或 ST Edge AI Developer Cloud 生成部署代码、在 STM32N6 开发板上集成摄像头/麦克风与 NPU 推理、测量端到端延迟与内存占用，最后形成一份可复现的验证记录。过程中会反复遇到三类典型问题：模型精度在量化后下降、NPU 不支持某些算子需要回退到 CPU、以及内存带宽成为帧率瓶颈。课程不会只给结论，而是带着读者看日志、看配置、看测量数据，逐步定位并解决。

需要特别说明的是，STM32N6 的 NPU 擅长的是规则化的张量计算，不是所有网络都能原样加速。项目早期就应确认模型中的算子是否在 NPU 支持列表内，卷积、深度可分离卷积、全连接、池化通常支持良好，而某些自定义算子、动态形状或复杂后处理可能需要放在 Cortex-M55 上执行。把这条边界提前画清楚，比训练完再改网络结构代价小得多。下一阶段的工作，就是围绕这条边界去选择模型与设计数据管线。