3. STM32N6 AI软件生态概览
STM32N6 是 ST 第一款带自研神经网络加速器（Neural-ART，简称 NPU）的 MCU，它的 AI 软件生态并不是单一工具，而是由若干定位不同、彼此衔接的组件构成。理解这套生态的关键，不是记住每个工具的名字，而是搞清楚“谁负责把模型变成能在 NPU 上跑的代码、谁负责把它集成进工程、谁提供现成的模型和参考实现、谁负责在 PC 端做量化和验证”。本节围绕 STM32Cube.AI、STM32CubeMX 扩展包、STM32 Model Zoo 以及第三方工具链这四类角色，说明它们的定位与协作关系。
四类角色的定位
STM32Cube.AI 是核心的模型转换与代码生成引擎。它接收来自 TensorFlow Lite、ONNX、Keras 等框架训练好的模型，做图解析、算子映射、内存规划，最终生成可在 STM32 上编译的 C 代码。对 STM32N6 而言，Cube.AI 还承担一项特殊职责：把模型中适合 NPU 的算子映射到 Neural-ART 加速器，其余算子回落到 Cortex-M55 的 Helium（MVE）指令或标量实现。因此它既是“转换器”，也是“硬件映射决策者”。
STM32CubeMX 扩展包（X-CUBE-AI）是 Cube.AI 在 CubeMX 图形化环境中的集成形态。它把模型分析、内存估算、代码生成、以及可选的验证功能嵌入到 CubeMX 的工程配置流程里。开发者可以在 CubeMX 中直接导入模型、查看每层算子的 RAM/Flash 占用、选择是否启用 NPU、生成带 AI 推理接口的工程骨架。它的定位是“工程集成入口”，让 AI 部分和外设初始化、时钟树、引脚配置在同一套工程里完成。
STM32 Model Zoo 是 ST 官方维护的模型与参考应用仓库。它提供已经针对 STM32 系列（含 STM32N6）验证过的模型，覆盖视觉（图像分类、目标检测、姿态估计）、音频（关键词识别）、传感（异常检测）等场景，并附带预处理/后处理代码、量化脚本和性能基准。它的定位是“起点与参照”：当你不想从零训练模型，或想先跑通一条完整链路时，Model Zoo 提供可直接复现的样例；当你自研模型时，它提供量化配置和性能对比的基线。
第三方工具链 指 ST 之外、但在这条链路中承担关键环节的工具，典型包括：模型训练框架（TensorFlow / PyTorch）、量化与优化工具（TensorFlow Lite Converter、ONNX Runtime 量化工具、ST Edge AI Developer Cloud 等）、以及嵌入式编译调试链（STM32CubeIDE、GCC、IAR、Keil）。它们的定位是“上游供给与下游落地”：训练和量化在 PC 端完成，编译调试在嵌入式端完成，Cube.AI 处在中间做桥接。
协作关系：从模型到 NPU 上运行
把四类角色串起来，一条典型的协作链路是：在 PC 端用 TensorFlow/PyTorch 训练模型 → 用 TFLite Converter 或 ONNX 工具做训练后量化（PTQ），得到 int8 模型 → 在 CubeMX 中通过 X-CUBE-AI 导入模型，查看算子映射与内存占用 → Cube.AI 生成 C 代码，其中 NPU 可加速的算子被标记并调度到 Neural-ART → 在 CubeIDE/IAR 中编译，链接到 STM32N6 工程 → 用 Model Zoo 中的预处理/后处理代码补齐前后处理 → 在板端运行并用基准数据核对延迟与精度。Model Zoo 既可以在最前面作为模型来源，也可以在最后作为对照基线。
实际使用中的关键判断
在真实项目里，这套生态最容易出问题的环节往往不是“能不能转换”，而是“转换后性能是否符合预期”。这里有几个值得注意的判断点。
第一，算子映射决定性能上限。Cube.AI 在分析模型时会给出每层算子的执行位置。如果卷积、全连接等重算子被映射到 NPU，延迟通常能显著下降；如果因为算子版本或结构不被支持而回落到 M55，延迟会明显上升。因此导入模型后，应优先查看算子映射报告，而不是直接编译运行。
第二，量化方式影响精度与兼容性。STM32N6 的 NPU 主要面向 int8 推理，训练后量化（PTQ）是最常用的路径。如果 PTQ 后精度下降过多，需要考虑量化感知训练（QAT），或在 Model Zoo 中寻找同类模型的量化配置作为参考。量化校准集的选择也会直接影响精度，不能随意用少量图片代替。
第三，内存占用需要提前估算。Cube.AI 会给出权重、激活和工作区的 RAM/Flash 占用。STM32N6 虽然有较大的片上内存，但视觉类模型的工作区仍可能成为瓶颈。建议在 CubeMX 阶段就确认内存预算，必要时调整输入分辨率或模型结构。