4、延迟预算定义与测量：延迟预算的构成、如何测量NPU推理延迟、使用Arm Cycle模型与工具（如Vela）估算延迟

在嵌入式AI系统设计中，延迟（Latency）是比吞吐量（Throughput）更严苛的约束指标。对于Arm Ethos-U系列NPU而言，延迟预算（Latency Budget）并非一个简单的数字，而是一条从传感器中断触发到控制执行器动作的完整时间链。本章将系统拆解延迟预算的构成要素，介绍基于硬件计数器与逻辑分析仪的实测方法，并重点讲解如何利用Arm官方的Cycle模型与Vela编译器在芯片流片前获得高置信度的延迟估算。理解这一章，是后续所有剪枝策略能够落地的前提——因为剪枝的本质，就是在延迟预算的硬边界内，用精度换取时间余量。

上图展示了延迟预算的完整链路。在后续内容中，我们将逐一拆解每个环节的测量与估算方法，并重点聚焦NPU推理延迟这一剪枝操作最直接作用的变量。

4.1 延迟预算的构成：从传感器到执行器的完整时间链

延迟预算的制定必须从系统级视角出发，而非仅关注NPU本身。一个典型的Arm Cortex-M55 + Ethos-U55方案中，端到端延迟通常由四个不可压缩的串行阶段构成：传感器采集与DMA传输（t_sensor）、CPU预处理（t_pre）、NPU推理（t_npu）、后处理与输出（t_post）。其中t_npu通常占总延迟的60%~80%，但其余20%~40%的CPU与I/O时间同样不可忽视。

4.1.1 核心原理：延迟预算的分解模型

延迟预算的分解遵循“木桶效应”——系统总延迟由最慢的串行路径决定。在实时控制场景（如电机故障检测），中断响应时间（IRQ latency）和DMA传输时间往往被低估。例如，一个1MPixel图像传感器通过8-bit SPI接口传输，在20MHz时钟下需要约50ms，这远超NPU推理的2ms。因此，延迟预算表必须包含每个阶段的典型值、最大值和触发条件。

4.1.2 判断方法：如何确定预算分配

首先，根据应用场景确定硬性截止时间（Hard Deadline）。例如，工业伺服控制要求从图像采集到输出PWM信号不超过5ms。其次，预留20%的安全余量（考虑温度、电压波动导致的频率漂移）。最后，将剩余时间按经验比例分配：NPU占70%，CPU预处理占15%，传感器与后处理占15%。若初始分配后NPU超出预算，则进入剪枝优化流程。

4.1.3 实战场景：智能麦克风唤醒词检测

以关键词唤醒（KWS）为例，系统要求从麦克风采集到唤醒响应不超过50ms。实际测量发现：PDM麦克风DMA传输16kHz/16bit/20ms音频帧耗时20ms，CPU进行MFCC特征提取耗时8ms，Ethos-U55推理2层CNN耗时12ms，后处理与GPIO输出耗时2ms，总延迟42ms。此时NPU推理仅占28.6%，剪枝空间有限。但若将特征提取部分迁移至NPU的定制算子，可压缩至5ms，从而为更复杂的唤醒词模型留出空间。

4.1.4 常见误区与复盘

4.2 如何测量NPU推理延迟：从硬件计数器到逻辑分析仪

实测延迟是验证估算模型的最终依据。Arm Ethos-U系列NPU提供了Performance Monitoring Unit（PMU），可精确测量从命令下发到推理完成的总周期数。同时，通过GPIO翻转配合逻辑分析仪，可以获得系统级的端到端延迟。

4.2.1 核心原理：PMU与硬件事件

Ethos-U55的PMU包含多个计数器，可记录NPU活跃周期、空闲周期、MAC操作数、内存读写次数等。关键事件包括：NPU_START（命令队列开始执行）、NPU_COMPLETE（推理完成）、MAC_ACTIVE（MAC单元忙碌）。通过读取PMU寄存器，可精确计算t_npu = (完成周期 - 开始周期) / 时钟频率。

// 伪代码：读取PMU周期计数
volatile uint32_t *PMU_CYCLE_CNT = (uint32_t *)0x50023000;
uint32_t start = *PMU_CYCLE_CNT;
// 触发NPU推理
npu_run(&inference_job);
while (!npu_is_complete());
uint32_t end = *PMU_CYCLE_CNT;
float t_npu_ms = (float)(end - start) / (SYSTEM_CLOCK_HZ / 1000);

4.2.2 操作流程：三种测量方法对比

1. 方法一：PMU寄存器读取。精度最高（单周期），但需修改驱动代码，且无法测量CPU与NPU的交互延迟。
2. 方法二：GPIO翻转+逻辑分析仪。在NPU推理开始前拉高GPIO，完成后拉低。采样率建议≥100MHz，可同时观察多个信号（如DMA完成、中断触发）。
3. 方法三：实时操作系统时间戳。使用FreeRTOS的xTaskGetTickCount()，精度为1ms，适合粗粒度验证。

4.2.3 案例拆解：Vela编译后模型的实测校准

某视觉检测项目使用Vela编译后的YOLOv5s模型，Vela估算t_npu为4.2ms。实测PMU显示为4.8ms，偏差14%。分析发现：Vela假设内存带宽为4GB/s，但实际SDRAM在并发访问时带宽降至3.2GB/s。通过调整Vela的--memory-bandwidth参数重新编译，估算值修正为4.7ms，与实测吻合。此案例说明，测量不仅是验证，更是校准估算工具参数的依据。

4.2.4 常见误区与总结

4.3 使用Arm Cycle模型与Vela工具估算延迟

在芯片流片前或硬件调试阶段，必须依赖Arm提供的Cycle模型和Vela编译器进行延迟估算。Vela不仅是一个神经网络编译器，更是一个精确的性能预测器。

4.3.1 核心原理：Vela的两级估算机制

Vela首先将TFLite模型转换为Ethos-U自定义算子图，然后基于硬件配置（MAC数量、SRAM大小、内存带宽）生成性能估算。其内部包含一个Cycle级模拟器，逐层计算MAC利用率、内存访问冲突和DMA等待时间。关键参数包括：--accelerator-config（指定U55或U65）、--system-config（定义内存时序）、--memory-mode（选择SRAM或DDR）。

# 使用Vela估算延迟
vela path/to/model.tflite \
  --accelerator-config=ethos-u55-256 \
  --system-config=ethos-u55-high-end \
  --memory-mode=Shared_Sram \
  --output-dir=./vela_output
# 输出文件中的summary.txt包含总周期估算

4.3.2 操作流程：从模型到延迟报告的完整链路

1. 步骤1：模型准备。将训练好的模型转换为TFLite格式，并确保算子受Ethos-U支持（如不支持则自动回退到CPU）。
2. 步骤2：配置系统参数。根据实际硬件设置SRAM大小（如U55支持384KB或512KB）、时钟频率（如400MHz）、内存带宽。
3. 步骤3：运行Vela编译。生成优化后的模型和性能摘要。
4. 步骤4：解析报告。关注Total Cycles、MAC Utilization、Memory Stall Cycles三个指标。
5. 步骤5：迭代优化。若延迟超标，调整剪枝率或网络结构，重新编译。

4.3.3 案例拆解：Cycle模型指导剪枝决策

一个语音降噪模型在Vela估算中显示：总周期1,200,000，其中MAC运算占45%，内存访问占40%，控制开销占15%。通过分析层间延迟分布，发现第3层卷积（输入64通道，输出128通道）消耗了30%的周期，但贡献的精度增益仅为5%。对该层进行50%通道剪枝后，Vela估算总周期降至780,000（降低35%），实测精度损失仅0.7%。此案例展示了Cycle模型如何精确定位剪枝目标。

4.3.4 常见误区与复盘