1. 本章学习目标

学完本章后，应能够理解：

1. 为什么“搭载 Cortex-M4 和几个传感器”不等于拥有 AI 硬件加速器。

2. 如何区分普通 MCU、具备 ML / DSP 加速指令的 CPU，以及专用 NPU。

3. TinyML 中 Vibration、Voice、Vision 三类任务的计算需求为什么逐级增加。

4. Arm Cortex-M55、Helium 和 Ethos-U55 / U65 分别承担什么角色。

5. CMSIS-NN 和 Vela 编译器如何把模型映射到 Cortex-M 与 Ethos-U。

6. 为什么模型推理性能不仅取决于乘加运算次数，也取决于内存和数据搬运。

7. 如何根据 EEG、ECG、EMG、PPG、HRV、GSR / EDA 的任务复杂度选择硬件，而不是盲目购买所谓“AI 开发板”。

---

2. 本章内容导读

近年来，很多开发板都会在名称或宣传中加入“AI”字样，但板载传感器本身不会自动赋予设备人工智能能力，普通 Cortex-M4 也不会因为被安装在“AI 开发板”上就变成专用 AI 芯片。

本章从“什么才是真正的 AI 硬件加速”出发，介绍 Arm 面向端侧机器学习形成的一条性能路线：普通 Cortex-M 通过 CMSIS-NN 优化运行模型，Cortex-M55 借助 Helium 向量扩展提升 DSP 和机器学习计算效率，再由 Ethos-U55 / U65 microNPU 专门加速神经网络。与此同时，Vela 编译器负责分析模型，把可支持的网络算子交给 NPU，把暂时无法支持的部分留给 CPU。

本章最重要的结论是：

AI 加速能力
≠ 开发板名称里带有“AI”
≠ 板载传感器数量多
≠ 单纯提高 CPU 主频

真正的 AI 加速能力
= 合适的计算架构
+ 专用指令或 NPU
+ 优化内核
+ 模型编译器
+ 合理的内存系统
+ 可验证的延迟与能耗提升

---

3. “AI 开发板”的 AI 到底在哪里？

3.1 传感器不是 AI 加速器

一块开发板可能带有：

• 麦克风；

• 摄像头；

• 加速度计；

• 陀螺仪；

• 温湿度传感器；

• PPG、ECG 或其他生理信号传感器。

这些器件负责感知外界，是数据来源，但它们本身通常不负责执行神经网络。

可以把整个系统分成三层：

传感器：
负责采集声音、图像、振动或生理信号

处理器：
负责滤波、特征提取、模型推理和设备控制

软件与模型：
决定如何从数据中得到分类或预测结果

因此，“板载很多传感器”只能说明它方便采集数据，不能证明它拥有更强的 AI 运算能力。

---

3.2 能运行模型，不等于有专用硬件加速

普通 Cortex-M4、STM32、nRF52 或 ESP32 也可以运行小型机器学习模型。只要模型足够小，使用 C / C++ 实现推理，就能够在没有专用 NPU 的 MCU 上完成分类。

但这里应区分三个层级：

层级	硬件特点	代表方式	是否属于专用 AI 加速
通用 MCU 运行 ML	使用普通 CPU 指令执行模型	Cortex-M4、M7 等运行小型模型	否
CPU 内置 DSP / ML 增强指令	通过 SIMD、点积、向量指令提升计算效率	Cortex-M55 + Helium	属于 CPU 级加速，但不是独立 NPU
专用神经网络加速器	由专门硬件执行卷积、矩阵乘法等网络运算	Ethos-U55 / U65	是

因此，比较准确的说法是：

• Cortex-M4 可以运行机器学习；

• Cortex-M55 是针对 DSP 和 ML 增强的通用 CPU；

• Ethos-U55 / U65 才是专门面向神经网络推理的 microNPU。

Arm 官方将 Cortex-M55 描述为首批采用 Helium 向量处理技术、面向高效 DSP 和机器学习的 Cortex-M CPU；Ethos-U55 则被定义为面向受限嵌入式系统、专门加速 ML 推理的 microNPU。(Arm)

---

4. TinyML 的三类典型负载：Vibration、Voice、Vision

本章按照计算需求由低到高，把 TinyML 应用大致归纳为三个方向：

Vibration 振动 / 时序传感器
→ Voice 语音
→ Vision 视觉

Arm 官方 TinyML 资料同样将应用归纳为 Vibration、Voice 和 Vision，并分别覆盖异常检测、关键词识别、自动语音识别、目标检测和姿态估计等任务。(Arm)

4.1 Vibration：振动和低维时间序列

Vibration 不应只理解为电机振动，它可以代表一类低维、连续的传感器时间序列任务，例如：

• 工业电机振动异常检测；

• 人体动作识别；

• 设备健康监测；

• 传感器融合；

• 简单 ECG、PPG、EDA 状态分类；

• 基于统计特征的 EMG 动作识别。

这类任务通常具有以下特点：

• 输入通道较少；

• 数据维度相对有限；

• 常使用统计特征或频域特征；

• 模型可以是决策树、SVM、小型 MLP 或 1D CNN；

• 很多任务可以在普通 Cortex-M4 / M7 上完成。

---

4.2 Voice：语音和多阶段信号处理

语音任务的计算链通常更长：

麦克风采样
→ 降噪
→ 回声消除
→ 波束形成
→ 分帧和加窗
→ MFCC / 频谱特征
→ 神经网络推理
→ 关键词或语音结果

简单的 Keyword Spotting，关键词检测，可以运行在普通 MCU 上；完整的 Automatic Speech Recognition，自动语音识别，则通常需要更高算力、更多内存和更复杂的模型。

这里有一个非常重要的认识：

一个完整语音应用的耗时，不只来自神经网络，还来自前端信号处理。

即使把神经网络加速了几十倍，如果波束形成、降噪、回声消除和 MFCC 仍然很慢，整个系统也不一定获得相同比例的加速。

---

4.3 Vision：视觉任务

视觉任务通常计算量最大，因为一张图像本身就包含大量像素。常见任务包括：

• 图像分类；

• 人体存在检测；

• 人脸识别；

• 手势检测；

• 缺陷检测；

• 目标检测。

视觉任务不仅需要更多乘加运算，还需要保存较大的输入张量和中间特征图，因此 RAM、Flash 和内存带宽都会成为限制。

---

4.4 三类任务并没有绝对边界

Vibration、Voice、Vision 只是一种粗略的计算量分级。实际需要多少算力，还取决于：

• 输入通道数量；

• 采样率或图像分辨率；

• 时间窗口长度；

• 网络层数；

• 模型参数数量；

• 数据精度；

• 目标准确率；

• 推理频率；

• 前处理复杂度。

例如，同样是语音任务：

单麦克风 + 2 个关键词

与：

多麦克风 + 波束形成 + 降噪 + 连续语音识别

对硬件的要求完全不同。模型准确率每提高一点，也可能需要显著增加模型宽度、深度和计算量。

---

5. Cortex-M55：带有 ML 能力的 CPU，而不是独立 NPU

5.1 Helium 是什么？

Cortex-M55 的关键技术是 Arm Helium，也就是 Arm M-Profile Vector Extension，简称 MVE。

普通 CPU 往往一次处理一个或少量数据，而向量指令可以在一次指令中并行处理多个数值。例如，神经网络和数字信号处理中经常需要执行：

多个采样值同时相乘
多个乘法结果累加
向量点积
滤波器卷积
矩阵运算

Helium 可以提高这类操作的执行效率，特别适合：

• FIR / IIR 滤波；

• FFT；

• 音频处理；

• 图像处理；

• int8 神经网络；

• 向量点积；

• 多通道传感器处理。

Arm 官方给出的特定基准结果显示，Cortex-M55 相比此前 Cortex-M 处理器可获得最高约 5 倍 DSP 性能和 15 倍机器学习性能提升；这些数字是特定条件下的官方性能指标，并不代表所有模型都能得到相同加速。(Arm)

---

5.2 为什么 int8 点积很重要？

量化神经网络经常使用 int8 参数和激活值。一个卷积层，本质上需要反复计算：

[
y=\sum_{i=1}^{n}x_iw_i+b
]

其中：

• (x_i) 是输入；

• (w_i) 是权重；

• (b) 是偏置；

• 乘法和累加会执行大量次数。

Cortex-M55 的向量和点积能力可以一次处理多个 int8 数据，提高卷积、全连接层等操作的效率。

这也是为什么同样运行 int8 模型，M55 通常比只依靠普通标量指令的 MCU 更高效。

---

5.3 AI 计算也是内存访问问题

本章有一个很容易被忽略但非常重要的观点：

机器学习不仅是计算问题，也是数据访问问题。

模型推理需要不断读取：

• 网络权重；

• 输入数据；

• 中间特征；

• 偏置参数；

• 量化参数。

如果处理器计算速度很快，但内存无法及时提供数据，计算单元仍会等待。

因此，评估 AI 硬件不能只看：

主频
MAC/s
TOPS

还要看：

SRAM 容量
Flash 带宽
缓存
总线
数据复用
权重压缩
中间张量占用

这也是为什么模型大小和 RAM 峰值往往比单纯的参数数量更能决定一个模型是否可以部署。

---

5.4 Cortex-M55 的安全能力

Cortex-M55 支持 TrustZone，可将系统划分为安全区域和非安全区域，用于隔离密钥、安全启动、敏感固件和普通应用代码。对于联网 IoT 和可穿戴生理信号设备，这类硬件隔离有助于提高系统机密性和完整性。(Arm)

但 TrustZone 并不意味着产品自动安全。实际系统还需要：

• 安全启动；

• 固件签名；

• 通信加密；

• 密钥管理；

• 权限控制；

• 安全升级；

• 漏洞测试。

---

6. Ethos-U55：真正面向 MCU 系统的 microNPU

6.1 microNPU 是什么？

NPU 是 Neural Processing Unit，神经网络处理单元。它不是为了替代整个 CPU，而是专门处理神经网络中高度重复的计算，例如：

• 卷积；

• 矩阵乘法；

• 全连接层；

• 激活函数；

• 池化；

• 循环网络中的部分计算。

Ethos-U55 是为受限嵌入式和 IoT 设备设计的 microNPU。它通常与 Cortex-M CPU 配合使用，而不是独立运行整个程序。Arm 官方说明其支持常见 CNN 和 RNN 运算，并能在受限面积和功耗条件下加速端侧 ML 推理。(Arm)

---

6.2 CPU 和 NPU 如何分工？

一个完整系统通常按下面方式运行：

Cortex-M CPU：
负责传感器采集
负责滤波和特征处理
负责系统控制与通信
负责模型中 NPU 不支持的算子

Ethos-U microNPU：
负责支持的卷积、矩阵乘法等神经网络子图

因此，NPU 并不是把 CPU 完全替换掉，而是形成异构计算系统：

通用控制和信号处理
→ CPU

重复密集的神经网络运算
→ NPU

这也是 M55 与 U55 配合的意义：M55 擅长通用程序、DSP 和向量计算，U55 专门加速神经网络。

---

6.3 Ethos-U55 的可配置性

Ethos-U55 可以按照不同硬件面积、功耗和性能目标配置为不同规模。课程介绍的配置范围为每周期 32、64、128 或 256 次 Multiply-Accumulate，乘加运算。

配置越大：

• 峰值计算能力越高；

• 芯片面积通常越大；

• 功耗可能更高；

• 对存储和总线的要求也更高。

因此，NPU 并不是越大越好，而要与实际模型和功耗目标匹配。

---

6.4 权重压缩为什么有价值？

Ethos-U 支持压缩模型权重。压缩不仅能减小模型存储空间，还能减少从 Flash 或其他存储器读取数据的次数。

这会同时改善：

• 模型大小；

• 存储带宽；

• 数据搬运能耗；

• 部分推理延迟。

在嵌入式系统中，移动数据有时比执行一次乘法更耗能，因此降低数据搬运往往与提高计算能力同样重要。

---

7. Ethos-U65：从 MCU 级系统扩展到更大边缘平台

Ethos-U65 延续了 Ethos-U55 的架构思路，但支持更高性能、更多系统配置，并可应用于 Cortex-A、Cortex-R 和 Neoverse 等平台。它也支持带有 DRAM 的系统，而不仅限于 MCU 常见的片上 SRAM 和 Flash 架构。Arm 当前资料显示，U65 可提供约为 U55 两倍的端侧 ML 性能，并支持 Cortex-M 裸机 / RTOS 系统以及 Cortex-A 富操作系统系统。(Arm)

两者可以简单理解为：

对比项	Ethos-U55	Ethos-U65
主要定位	面积和功耗受限的 MCU / IoT 系统	更高性能边缘与端点系统
常见配合	Cortex-M	Cortex-M、Cortex-A、Cortex-R 等
存储环境	片上 SRAM、Flash 为主	可扩展至带 DRAM 的系统
最大配置	课程中介绍到 256 MAC/cycle	可扩展到 512 MAC/cycle
适合任务	关键词识别、轻量视觉、嵌入式分类	更复杂语音、视觉和边缘任务

需要注意，U55 和 U65 是芯片厂商可集成到 SoC 中的处理器 IP，并不是购买任意 Cortex-M 开发板就自动拥有这些 NPU。

---

8. Vela：连接神经网络模型与 Ethos-U 的桥梁

8.1 只有硬件，没有编译器也不够

神经网络模型由许多算子组成，例如：

Conv2D
Depthwise Conv2D
Fully Connected
Pooling
Reshape
Softmax
LSTM

NPU 不一定支持模型中的所有算子，而且不同算子还可能受到尺寸、数据类型和参数配置限制。

因此需要编译器完成：

1. 分析模型计算图；

2. 判断哪些算子可以在 NPU 上运行；

3. 把这些算子组成可加速子图；

4. 生成 NPU 命令序列；

5. 压缩和重新组织权重；

6. 保留无法加速的 CPU 算子。

Vela 就承担这一工作。

---

8.2 Vela 的模型部署流程

课程中的流程可以整理为：

在电脑上训练神经网络
        ↓
转换并量化为 TensorFlow Lite 模型
        ↓
使用 Vela 离线编译器分析模型
        ↓
将支持的网络子图编译为 Ethos-U 命令
        ↓
生成新的优化版 TensorFlow Lite 模型
        ↓
部署到 Cortex-M + Ethos-U 系统

Arm 官方文档说明，Vela 会将 LiteRT / TensorFlow Lite 模型编译为适合 Ethos-U 运行的优化版本。它会识别 NPU 支持的子图；无法映射到 NPU 的部分仍保留，由 CPU 上的相应内核执行。(Arm开发者)

---

8.3 CPU fallback 是什么？

假设模型结构如下：

Conv2D
→ ReLU
→ 某个 NPU 不支持的特殊算子
→ Fully Connected

Vela 可能把支持的部分交给 Ethos-U：

Conv2D + ReLU
→ NPU

特殊算子则退回 CPU：

特殊算子
→ Cortex-M

这就是 CPU fallback，CPU 回退执行。

CPU 回退并不意味着整个模型不能运行，但如果回退算子很多，CPU 与 NPU 之间需要频繁交换中间数据，就可能降低整体性能。

因此，在设计模型时不能只问：

模型准确率高不高？

还要问：

这个模型的算子能否被目标 NPU 高效支持？

---

8.4 CMSIS-NN 的作用

对于运行在 Cortex-M CPU 上的网络部分，可以调用 CMSIS-NN 优化内核。

CMSIS-NN 针对不同 Cortex-M 能力提供不同实现，包括：

• 无 SIMD 的 Cortex-M；

• 带 DSP 扩展的 Cortex-M4 等处理器；

• 带 MVE / Helium 的 Cortex-M55。

它包含卷积、全连接、池化、激活、Softmax 和 LSTM 等优化函数，并遵循 TFLM 的 int8 / int16 量化规范。(arm-software.github.io)

完整的软件与硬件关系可以概括为：

模型
↓
Vela 分析和划分计算图
↓
支持的算子 → Ethos-U
不支持的算子 → Cortex-M + CMSIS-NN

---

9. 为什么“神经网络快了”不代表整个应用快了？

课程给出了两个不同层次的性能示例。

9.1 只测试神经网络

在课程中的语音识别网络示例里：

• M4 使用 CMSIS-NN，相比未优化参考内核获得明显加速；

• 使用带 Helium 的 Cortex-M55 后继续提升；

• 再加入 Ethos-U55 后，神经网络本身获得更大幅度的加速。

该示例用于展示从参考内核、优化软件、向量 CPU 到专用 NPU 的逐层性能提升，但结果只适用于课程中的特定模型、平台和配置，不能直接当作所有项目的固定倍数。

---

9.2 测试完整语音助手

完整语音助手除了神经网络，还包括：

• 波束形成；

• 回声消除；

• 降噪；

• 音频均衡；

• MFCC；

• 编解码；

• 关键词检测；

• 语音识别。

课程中的完整应用示例显示，M55 与 U55 的组合不仅缩短推理时间，还显著降低能耗；但整体加速倍数低于“只测试神经网络”时的理论提升，因为应用中仍有大量非神经网络工作。

这说明评价 AI 硬件时应测量：

端到端延迟
而不只是单个神经网络延迟

整个应用每次处理的能耗
而不只是 NPU 峰值 TOPS

---

10. 如何判断一块板是否真正具备 AI 加速能力？

可以从下面五个问题判断。

检查问题	应关注的内容
芯片是否有 ML 专用架构？	向量扩展、点积指令、NPU、DSP 或其他加速单元
是否有配套优化库？	CMSIS-NN、CMSIS-DSP、厂商 NN / DSP 库
是否有模型编译工具？	Vela、模型转换器、量化器、算子分析工具
支持哪些模型和数据格式？	int8 / int16、CNN、RNN、具体算子列表
是否有真实性能数据？	延迟、RAM、Flash、能耗、CPU 回退比例

购买开发板前还应区分以下宣传：

宣传说法	实际含义
“AI 开发板”	可能只是适合学习和采集数据
“支持 TinyML”	通常说明能够运行小型模型
“AI-capable CPU”	CPU 有利于 ML / DSP 的指令或架构
“内置 NPU”	通常表示有专用神经网络加速单元
“X TOPS”	只是峰值指标，不能单独代表真实应用速度

---

11. 本章硬件选型地图

根据课程内容，可以得到下面的粗略选择思路：

任务复杂度	典型任务	可考虑的平台
较低	统计特征分类、简单异常检测、低维传感器	Cortex-M4 / M33 / M7，普通 ESP32、STM32、Nordic
中等	多通道时序、小型 1D CNN、关键词检测	Cortex-M55、带高效 DSP / ML 指令的 MCU
较高	高级语音、轻量视觉、较复杂 CNN / RNN	Cortex-M55 + Ethos-U55
更高	完整语音识别、更复杂视觉、DRAM 模型	更高性能系统 + Ethos-U65 等 NPU

这只是架构层面的指导。最终选择仍应以具体模型的：

• 准确率；

• 推理延迟；

• RAM；

• Flash；

• 能耗；

• 运算符支持；

• 成本；

为依据。

---

12. 与生理信号 TinyML 项目的联系

本章对生理信号项目最重要的启发，不是再次重复“采集—训练—部署”的流程，而是明确：

生理信号设备是否需要 AI 加速器，应由实际计算负载决定，而不是由项目名称决定。

12.1 不同生理信号对硬件的需求并不相同

信号	常见计算特点	一般硬件需求	NPU 的潜在价值
GSR / EDA	低采样率、慢变化、统计与峰值特征较多	普通 MCU 通常足够	简单分类时价值有限，复杂多模态网络时才明显
HRV	主要是心搏检测后的窗口统计特征	普通 MCU 通常足够	传统特征模型通常不需要 NPU
PPG	滤波、峰值检测、运动伪迹处理	M4 / M33 / ESP32 / STM32 可完成	使用原始波形 CNN 或多通道模型时可能有帮助
ECG	较高采样率、QRS 检测、波形分类	中等性能 MCU	1D CNN、长窗口或多导联模型可能受益
EMG	采样率较高，常含多通道和频域处理	DSP 性能较重要	多通道 CNN、手势识别网络可能明显受益
EEG	多通道、高数据量、频谱和时空特征复杂	RAM、DSP 和算力要求较高	深度网络、睡眠分期或多通道模型更可能需要 NPU
多模态融合	多种传感器同步、特征融合	内存和算力需求最高	NPU 对复杂融合网络更有价值

这是基于各信号典型数据规模和算法特点做出的工程判断；具体是否需要 NPU，仍需使用真实模型测试。

---

12.2 GSR / EDA 项目未必需要 NPU

以 GSR / EDA 疼痛相关状态识别为例，如果模型输入是：

• 均值；

• 标准差；

• 斜率；

• SCR 次数；

• 上升时间；

• 恢复时间；

再使用 Random Forest、小型 SVM 或小型 MLP，普通 ESP32-S3、STM32 或 Nordic MCU 通常就可能满足实时要求。

这时盲目使用 NPU可能带来：

• 工程复杂度增加；

• 开发板成本增加；

• 算子适配工作增加；

• 实际收益很小。

因此，对 GSR / EDA 项目更重要的往往是：

采集电路质量
标签可靠性
被试者差异
滤波和特征设计
模型泛化能力

而不是先购买更强的 AI 加速器。

---

12.3 EEG、EMG 和多模态模型更可能受益

如果项目发展到：

多通道 EEG
+ EMG
+ PPG
+ EDA
+ IMU

并使用多分支 CNN、时序网络或较复杂特征融合模型，那么：

• RAM 峰值会增加；

• 中间张量会增大；

• 推理延迟会上升；

• CPU 占用会变高。

这时 Cortex-M55 的 Helium 或 Ethos-U 类 NPU可能带来实际价值。

但仍需要确认：

1. 网络是否已完成 int8 / int16 量化；

2. 关键算子是否被 NPU 支持；

3. Vela 编译后 CPU fallback 是否过多；

4. 前处理是否反而成为主要瓶颈；

5. RAM 和 Flash 是否足够；

6. 节省的能耗是否值得增加硬件成本。

---

12.4 生理信号系统中的理想分工

对于复杂的多通道生理信号设备，可以采用：

MCU / CPU：
ADC 与数字传感器采集
滤波和重采样
通信和任务调度
安全控制
部分特征提取

NPU：
运行支持的 CNN / RNN / MLP 子图

确定性程序：
检查模型置信度
限制输出范围
处理传感器断线
执行安全策略

其中最值得注意的是：

NPU 只负责提高神经网络计算效率，并不会自动改善数据质量、标签可靠性、模型公平性或医疗安全性。

---

13. 关键概念解释

概念	通俗解释	技术解释	本章中的作用
AI-capable CPU	更适合运行 AI 的通用处理器	包含向量、DSP 或 ML 相关指令的 CPU	解释 Cortex-M55 的定位
Hardware Accelerator	专门替某类计算加速的硬件	针对特定操作设计的数据通路和计算单元	区分普通 MCU 与真正加速器
Helium / MVE	Cortex-M 的向量计算能力	Armv8.1-M 的 M-Profile Vector Extension	提高 DSP 和 ML 效率
SIMD	一条指令处理多个数据	Single Instruction, Multiple Data	支持滤波、点积和矩阵计算
MAC	乘法并累加	Multiply-Accumulate	神经网络和 DSP 的基础运算
microNPU	给小型设备使用的 NPU	面向低功耗嵌入式设备的神经网络加速器	Ethos-U55 / U65 的定位
Vela	模型与 Ethos-U 之间的编译桥梁	将 TFLite 模型优化为 Ethos-U 可执行形式	决定哪些算子由 NPU 执行
CPU fallback	NPU 不支持时交给 CPU	未被编译进 NPU 子图的算子由 CPU 运行	影响真实端到端性能
CMSIS-NN	Cortex-M 神经网络优化库	面向量化网络的高效计算内核	加速 CPU 侧模型运算
Memory bandwidth	数据供给速度	存储器与处理器之间的传输能力	解释为什么算力高不等于应用快
Hardware–software co-design	硬件和模型共同设计	联合优化架构、网络、量化、内存和工具链	本章最核心的方法论

---

14. 本章案例复盘：完整语音助手为何需要 CPU + NPU？

环节	更适合的计算单元	原因
麦克风采样	CPU / 外设	需要实时控制 DMA、I²S 等接口
波束形成	CPU + DSP / Helium	属于典型数字信号处理
回声消除和降噪	CPU + DSP / Helium	算法控制和向量计算并存
MFCC 特征提取	CPU + DSP / Helium	包含 FFT、滤波器组和对数运算
神经网络	Ethos-U NPU	卷积和矩阵运算密集
结果判断	CPU	需要阈值、状态机和业务逻辑
设备控制	CPU	需要确定性控制外设

这个案例表明，一个真正高效的 TinyML 系统通常不是“所有任务都放进 NPU”，而是让每种计算运行在最合适的硬件上。

---

15. 本章还不能解决的问题

本章解释了 AI 硬件加速路线，但还不能直接回答：

1. 某个具体模型在目标芯片上的 RAM 峰值是多少。

2. Edge Impulse 导出的模型能否完整映射到 Ethos-U。

3. 某个算子为什么会发生 CPU fallback。

4. 如何为特定芯片编写 Vela 配置文件。

5. 如何实测每次推理的能耗。

6. 如何测量前处理、模型和后处理各自的耗时。

7. 如何设计包含 Cortex-M 和 NPU 的具体 SoC。

8. 多通道 EEG / EMG 网络需要多大的 SRAM。

9. 模型精度与计算量之间的最佳平衡点在哪里。

10. 使用 NPU 后是否能够满足具体医疗或工业安全标准。

这些问题需要在后续章节中结合真实模型、目标开发板和性能分析工具进一步验证。

---

16. 本章总结

本章最突出的收获是学会识别“能运行 AI”和“具备 AI 加速器”之间的区别。传感器只负责提供数据，普通 Cortex-M 可以依靠软件运行小型模型，Cortex-M55 通过 Helium 向量扩展提高 DSP 与机器学习效率，而 Ethos-U55 / U65 则使用专用 microNPU 加速神经网络。Vela 编译器负责把可支持的模型子图交给 NPU，CMSIS-NN 则优化 CPU 侧计算。真正的 TinyML 性能来自模型、CPU、NPU、内存和工具链的协同，而不是开发板包装上的“AI”字样。对于生理信号项目，也不应先问“哪块 AI 板最强”，而应先测量任务的采样率、模型结构、RAM、延迟和能耗，再判断普通 MCU、向量 CPU 或专用 NPU 哪一种最合适。

---

17. 参考资料

资料名称	类型	链接	与本章内容的关系
Arm Cortex-M55	官方文档	Arm Cortex-M55	说明 Helium、ML / DSP 性能、TrustZone 和 M55 的定位。(Arm)
Arm Ethos-U55	官方文档	Arm Ethos-U55	说明 U55 是面向受限嵌入式系统的 microNPU。(Arm)
Arm Ethos-U65	官方文档	Arm Ethos-U65	说明 U65 的性能、DRAM 支持和 Cortex-A / M 扩展能力。(Arm)
Arm tinyML Applications	官方资料	Arm tinyML Resources	用于说明 Vibration、Voice、Vision 三类 TinyML 任务。(Arm)
CMSIS-NN Software Library	官方文档	CMSIS-NN Documentation	说明 Cortex-M 上的卷积、全连接、池化和量化优化内核。(arm-software.github.io)
Ethos-U Vela Compiler	官方文档	Vela Compiler Documentation	说明如何把 LiteRT / TFLite 模型编译为 Ethos-U 优化模型。(Arm开发者)
Arm Ethos-U Vela	官方开源项目	Vela GitLab Repository	提供 Vela 源代码和模型优化工具
LiteRT for Microcontrollers	Google 官方文档	LiteRT for Microcontrollers	说明量化神经网络在 MCU 上的基本推理运行时
TinyML for Ubiquitous Edge AI	综述论文	arXiv:2102.01255	解释 TinyML 的低功耗定义及硬件—软件协同背景。(arXiv)
Measuring What Really Matters: Optimizing Neural Networks for TinyML	学术论文	arXiv:2104.10645	强调应结合真实硬件测量延迟、能耗和实现效果，而不能只看理论运算量。(arXiv)