课程导入：TinyML与Ethos-U NPU的定位
边缘人工智能的落地正在经历一场深刻的范式转移：从云端集中推理转向设备端实时处理。TinyML作为这一转移的核心技术分支，致力于在毫瓦级甚至微瓦级功耗预算内运行神经网络模型。然而，当模型从MCU裸奔的Cortex-M内核迁移到带有NPU（神经网络处理单元）的Ethos-U系列加速器时，开发者往往面临一个尴尬的现实——模型能跑，但延迟预算失控。本课程正是围绕这一痛点展开：如何在Ethos-U NPU上系统性地优化模型延迟，使其满足实时性要求，同时不牺牲精度与能效比。
本章作为课程的开篇，将首先厘清TinyML与Ethos-U NPU在嵌入式AI生态中的定位，明确学习目标与课程整体框架，并通过一个典型的智能语音唤醒词案例，揭示NPU延迟优化的核心矛盾与解决思路。
上图展示了本课程的核心知识框架：左侧为TinyML技术栈的四个层次，中间为Ethos-U NPU的关键硬件特性，右侧则归纳了延迟优化的四个主要维度。后续所有章节都将围绕这一框架展开，从硬件原理到编译器行为，从算子映射到系统级流水线设计，逐步构建完整的NPU延迟优化方法论。
1.1 TinyML的边界与Ethos-U的硬件定位
核心原理：TinyML并非简单的“小模型在MCU上运行”，而是一套完整的系统工程方法论。其边界条件由三个硬约束定义：功耗预算（通常低于10mW）、内存预算（通常低于1MB）、实时性要求（通常低于100ms）。Ethos-U系列NPU正是为突破这些约束而设计的专用加速器——它不是通用计算单元，而是一个可配置的、面向卷积神经网络（CNN）的脉动阵列处理器。
Ethos-U55（面向Cortex-M55）与Ethos-U65（面向Cortex-M85）的架构差异决定了优化策略的不同。U55采用紧耦合内存设计，NPU直接访问SRAM，延迟低但容量受限；U65则支持通过AXI总线访问外部DDR，容量更大但存在带宽瓶颈。理解这一差异是延迟优化的前提——在U55上，优化重点是激活值复用；在U65上，优化重点则转向DMA传输调度。
| 硬件特性 | Ethos-U55 | Ethos-U65 | 对延迟优化的影响 |
|---|---|---|---|
| MAC阵列规模 | 32/64/128/256 | 256/512 | 决定单周期算力上限 |
| 片上SRAM | 最大1MB | 最大4MB | 决定激活值驻留能力 |
| 外部内存接口 | 无（仅紧耦合） | AXI 64-bit | U65需考虑DDR带宽竞争 |
| 权重压缩 | 支持8x/16x | 支持8x/16x | 减少Flash读取时间 |
| 典型工作频率 | 200-400MHz | 400-800MHz | 直接影响指令周期 |
NPU_CYCLE_COUNT事件ID为0x00，而U65中该事件ID为0x01。错误的PMU配置会导致延迟数据完全失真。1.2 学习目标与课程框架设计
判断方法：本课程的学习目标不是“学会使用Vela编译器”，而是建立一套可复用的延迟优化决策框架。具体而言，完成本课程后，学习者应具备以下四种能力：
- 诊断能力：能够通过Ethos-U PMU计数器、Vela编译报告、以及Arm Cycle模型，定位延迟瓶颈在算子层、内存层还是系统调度层。
- 映射能力：理解卷积、深度可分离卷积、全连接等常见算子如何映射到NPU的MAC阵列，并能预判不同算子形状（如3x3 vs 5x5卷积）的性能差异。
- 调优能力：掌握Vela编译器的高级参数（如
--block-config、--memory-mode），能够针对特定模型结构调整编译策略。 - 系统协同能力：设计CPU与NPU的异步流水线，利用中断和DMA实现数据预取，隐藏NPU的启动延迟。
课程框架分为五个模块，每个模块对应一个优化层次：
- 模块一（第1-5章）：硬件基础与工具链——Ethos-U架构、Vela编译器原理、PMU性能分析。
- 模块二（第6-12章）：算子级优化——卷积映射、激活函数融合、Padding策略、量化感知。
- 模块三（第13-20章）：内存与数据流优化——SRAM分区、DMA调度、权重重排、内存复用。
- 模块四（第21-26章）：系统级流水线——双核通信、中断驱动、多模型调度。
- 模块五（第27-30章）：实战案例与性能调优方法论——语音唤醒、图像分类、异常检测的完整优化闭环。
1.3 案例背景：智能语音唤醒词的延迟困境
案例拆解：我们以一个典型的“关键词唤醒”（KWS）模型为例，说明延迟优化的完整分析路径。该模型基于DS-CNN（Depthwise Separable Convolutional Neural Network），输入为40通道的Mel频谱特征，时间窗口为30帧（每帧10ms），输出为“Hi, Edge”唤醒词的概率。
初始环境与约束：
- 硬件平台：Cortex-M55 @ 400MHz + Ethos-U55 @ 400MHz，SRAM 512KB
- 模型参数：参数量 42KB，激活值峰值 180KB，计算量 2.8M MACs
- 实时性要求：P95 延迟 < 50ms（即95%的推理必须在50ms内完成）
- 初始性能：使用Vela默认配置编译，实测P95延迟为 87ms，严重超标
初始现象与数据：通过PMU计数器采集到以下关键指标：
PMU事件报告（初始配置）：
- NPU_CYCLE_COUNT: 34,800,000 cycles (87ms @ 400MHz)
- NPU_IDLE_CYCLE_COUNT: 12,400,000 cycles (35.6% 空闲)
- AXI_READ_BEAT_COUNT: 2,100,000 beats
- AXI_WRITE_BEAT_COUNT: 890,000 beats
- MAC_UTILIZATION: 42.3%分析判断过程：MAC利用率仅42.3%，且NPU空闲周期占比高达35.6%，说明瓶颈不在算力而在数据供给。进一步检查Vela编译报告发现，模型被分割为17个NPU算子块，其中第5块（对应第一层Depthwise Conv）的激活值溢出到外部Flash，导致每次计算都需要从Flash重新读取输入特征图。
实际操作步骤：
- 调整Vela的
--block-config参数，将第一层Depthwise Conv的输入切分为2个时间子块，使每个子块的激活值适配SRAM剩余空间（512KB - 180KB = 332KB可用）。 - 启用
--weight-compression=16x，将权重从42KB压缩至2.6KB，减少Flash读取时间。 - 修改CMSIS-Driver的DMA配置，将输入特征图的加载改为双缓冲模式，与NPU计算重叠。
结果对比：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| P95延迟 | 87ms | 41ms | 52.9% |
| MAC利用率 | 42.3% | 78.6% | +36.3% |
| NPU空闲周期 | 35.6% | 12.1% | -23.5% |
| AXI读取量 | 2.1M beats | 1.2M beats | -42.9% |
风险与代价：子块切分增加了NPU算子块数量（从17个增至23个），导致指令存储占用增加约1.2KB。同时，双缓冲DMA需要额外占用2个DMA通道，在资源紧张的系统中可能不可用。此外，16x权重压缩引入了约0.3%的精度损失（从98.2%降至97.9%），在唤醒词场景中可接受。
1.4 常见误区与课程学习建议
常见误区：初学者在接触Ethos-U优化时，容易陷入以下三个误区：
- 误区一：盲目追求MAC利用率100%。实际上，由于Padding、激活函数融合等开销，MAC利用率超过85%已属优秀。过度追求利用率可能导致过度切分算子块，反而增加指令开销。
- 误区二：忽略CPU与NPU的协同。Ethos-U并非完全独立工作，它需要CPU配置指令流、处理中断、管理DMA。如果CPU侧代码效率低，NPU依然会等待。
- 误区三：只关注单次推理延迟。在连续推理场景（如语音流），吞吐量比单次延迟更重要。优化目标应明确是P50、P95还是P99延迟。
总结复盘：本章通过KWS案例展示了延迟优化的完整闭环——从PMU数据采集、瓶颈定位、Vela参数调整到最终效果验证。后续章节将逐一深入每个环节的技术细节。建议学习者在阅读后续章节时，始终带着三个问题：这个优化手段作用于哪个硬件模块？它改变了哪些PMU计数器的数值？在什么条件下会失效？只有将优化手段与硬件行为建立因果联系，才能真正掌握NPU延迟优化的精髓。