3、延迟预算基础：延迟的定义、测量单位、影响延迟的关键因素（算子、内存、带宽、并行度）
在嵌入式AI系统设计中，延迟（Latency）是衡量推理性能的核心指标之一。对于基于Arm Ethos-U NPU的系统，延迟预算（Latency Budget）是指在满足实时性或交互性要求的前提下，为一次完整的推理任务分配的可接受时间窗口。理解延迟的构成、测量方法以及关键影响因素，是进行系统调优和资源规划的前提。本章将系统性地拆解延迟预算的基础概念，帮助开发者建立从理论到实践的完整认知框架。
3.1 延迟的定义与测量单位
延迟在AI推理场景中通常指从输入数据到达系统（如传感器中断、DMA传输完成）到输出结果可供应用层使用的总时间。对于Arm Ethos-U NPU，这个时间包含三个主要阶段：数据输入与预处理、NPU核心计算、输出后处理与传输。需要特别注意的是，延迟与吞吐量（Throughput）是两个不同的概念——延迟关注单次任务的完成时间，而吞吐量关注单位时间内处理的任务数量。在实时控制系统中（如工业视觉检测），延迟是硬性约束；在交互式应用中（如语音唤醒），延迟直接影响用户体验。
测量单位的选择取决于系统的时间尺度。对于Ethos-U55/U65这类面向微控制器的NPU，典型推理延迟在数百微秒到数十毫秒之间，因此常用单位包括：
- 时钟周期（Cycle）：用于底层性能分析，如NPU主频500MHz时，一个周期为2ns。
- 微秒（µs）：适用于单层算子或小模型的延迟测量。
- 毫秒（ms）：适用于完整模型端到端延迟的评估，也是延迟预算规划的主要单位。
测量延迟时，应使用硬件计时器（如Arm Cortex-M内核的DWT->CYCCNT寄存器）或NPU内置的性能计数器（Performance Monitor Unit, PMU）。软件层面的计时函数（如clock()）可能因操作系统调度或中断干扰而产生误差，在裸机环境下推荐使用以下方法：
// 使用DWT时钟周期计数器测量延迟（Cortex-M33示例）
volatile uint32_t *DWT_CYCCNT = (uint32_t *)0xE0001004;
volatile uint32_t *DWT_CTRL = (uint32_t *)0xE0001000;
*DWT_CTRL |= (1 << 0); // 使能DWT
uint32_t start = *DWT_CYCCNT;
// 执行NPU推理（如调用ethosu_run）
ethosu_run(&inference_data);
uint32_t end = *DWT_CYCCNT;
float latency_ms = (float)(end - start) / (SystemCoreClock / 1000.0f);3.2 影响延迟的关键因素分析
延迟的构成可以分解为四个相互关联的维度：算子执行时间、内存访问时间、带宽限制和并行度利用率。理解每个维度的作用机制，是进行延迟预算控制的基础。
3.2.1 算子执行时间
算子（Operator）是神经网络的基本计算单元，如卷积、全连接、池化、激活函数等。Ethos-U NPU针对这些算子进行了硬件加速，但不同算子的执行效率差异显著。影响算子执行时间的主要因素包括：
- 计算量（MACs）：乘累加操作的数量，直接决定NPU的MAC阵列需要工作多少个周期。例如，一个3x3卷积，输入通道64，输出通道64，特征图尺寸32x32，其MACs = 3×3×64×64×32×32 = 37,748,736次。
- 算子类型：标准卷积、深度可分离卷积、池化等算子在NPU上的硬件映射效率不同。深度可分离卷积虽然MACs较少，但内存访问模式更复杂，可能引入额外开销。
- 量化与激活函数：8位量化（int8）是Ethos-U的默认优化格式，但某些算子（如Sigmoid）可能需要查表或混合精度处理，增加额外周期。
在Vela编译器（Arm官方NPU编译器）中，算子会被转换为NPU可执行的命令流。Vela的优化日志会显示每个算子的预估周期数，这是分析算子延迟的第一手资料。
3.2.2 内存访问与层级
Ethos-U NPU通常与Cortex-M内核共享系统内存，典型的内存层级包括：
| 内存层级 | 典型容量 | 访问延迟（周期） | 用途 |
|---|---|---|---|
| NPU内部SRAM | 256KB - 1MB | 1-2 | 权重、激活值缓存 |
| 系统SRAM（紧耦合） | 512KB - 2MB | 5-10 | 中间特征图、DMA缓冲 |
| 外部DRAM（如DDR4） | 64MB - 1GB | 50-100 | 模型权重、大尺寸输入 |
内存访问延迟对整体延迟的影响往往被低估。当NPU需要从外部DRAM读取权重时，DMA传输时间可能超过计算时间。Vela编译器通过算子融合（Fusing）和权重重排（Weight Reshuffling）来最大化SRAM利用率，减少DRAM访问次数。
3.2.3 带宽瓶颈
带宽（Bandwidth）指单位时间内可以传输的数据量，单位通常为字节/秒（B/s）或兆字节/秒（MB/s）。在Ethos-U系统中，带宽瓶颈可能出现在以下位置：
- 总线带宽：AHB或AXI总线的位宽和时钟频率决定了理论最大带宽。例如，32位AHB总线在100MHz下理论带宽为400MB/s。
- DMA传输效率：DMA控制器在传输非对齐数据或小数据块时，效率会显著下降。理想情况下，DMA应进行突发传输（Burst Transfer）。
- 内存控制器效率：外部DRAM的页命中率、刷新周期等会影响实际可用带宽。
计算带宽需求的方法：对于一次推理，总数据流量 = 权重读取量 + 输入/输出特征图读写量。如果NPU主频为400MHz，MAC阵列为128个MAC/周期，则峰值计算能力为400M×128 = 51.2 GMAC/s。若每个MAC对应2字节（int8权重+int8激活），则所需带宽为102.4 GB/s，这远超系统总线能力。因此，实际系统必须依赖数据复用（如权重驻留SRAM）来降低带宽需求。
3.2.4 并行度与调度
Ethos-U NPU内部包含多个并行计算单元（如MAC阵列、激活单元、池化单元），它们可以流水线工作。并行度的影响体现在两个层面：
- 算子内并行：单个卷积层内，多个输出通道可以并行计算。Ethos-U的MAC阵列宽度（如128个MAC）决定了同时计算的乘累加数量。
- 算子间并行：不同层之间可以通过流水线重叠执行。例如，当第N层的计算正在进行时，DMA可以预取第N+1层的权重。
Vela编译器在生成命令流时会自动进行调度优化，但开发者可以通过调整网络结构（如减少层间依赖）来提升并行度。此外，如果系统中有多个NPU核心（如Ethos-U65支持双核心），还需考虑任务划分和同步开销。
3.3 延迟预算的制定与验证流程
制定延迟预算不是简单的估算，而是一个迭代的工程过程。以下是一个经过验证的四步流程：
- 需求分析：明确应用场景的延迟上限。例如，工业缺陷检测要求端到端延迟小于50ms，语音唤醒要求小于100ms。
- 基线测量：使用Vela编译后的模型在目标硬件上运行，通过PMU获取各阶段的延迟数据。记录算子级延迟、DMA等待时间、CPU与NPU的同步开销。
- 瓶颈定位：将总延迟分解为计算时间、内存等待时间、通信时间三部分。使用饼图或柱状图可视化占比，找出最大瓶颈。
- 优化迭代：针对瓶颈采取优化措施（如算子替换、内存重排、并行度调整），每次修改后重新测量，确保延迟逐步逼近预算目标。
--weight-reshape选项优化权重布局；(2) 将输入图像从224x224裁剪为192x192（精度损失0.3%）；(3) 启用NPU与CPU的异步执行模式。优化后延迟降至38ms，满足预算要求。此案例说明，内存访问和带宽往往比计算量更值得关注。
3.4 常见误区与总结
在延迟预算控制中，开发者常陷入以下误区：
- 误区一：只关注MACs。MACs是理论计算量，实际延迟受内存带宽、数据复用率、NPU利用率等多重因素影响。一个MACs较低但内存访问频繁的模型，可能比MACs较高但数据局部性好的模型更慢。
- 误区二：忽略CPU与NPU的同步开销。在裸机系统中，CPU需要等待NPU中断或轮询状态寄存器，这种同步等待可能消耗数百微秒。使用双缓冲或异步回调可以隐藏这部分延迟。
- 误区三：将平均延迟当作设计目标。对于实时系统，应关注最坏情况延迟（Worst-Case Execution Time, WCET）。中断、DMA冲突、内存刷新都可能导致延迟抖动。
- 误区四：过早优化。在未进行基线测量前就修改网络结构或硬件配置，往往事倍功半。正确的做法是先测量、后分析、再优化。
总结而言，延迟预算控制是一个系统性的工程问题，需要从算子、内存、带宽、并行度四个维度综合考量。开发者应建立“测量-分析-优化-验证”的闭环思维，充分利用Vela编译器的性能报告和NPU的PMU计数器，将延迟预算从模糊的估算转化为精确的工程指标。在下一阶段的课程中，我们将深入探讨如何利用Vela编译器进行算子级优化，以及如何通过内存规划进一步压缩延迟。