4、延迟测量核心概念：延迟定义、端到端延迟vs推理延迟、单次推理延迟vs吞吐量、实时性指标

在ESP32-C3端侧推理项目中，延迟（Latency）是最直观也最容易被误读的性能指标。许多开发者将“模型推理耗时”等同于“系统响应时间”，导致在HIL（Hardware-in-the-Loop）验证时出现阈值误判。本章从延迟的严格定义出发，厘清端到端延迟与推理延迟的边界，辨析单次推理延迟与吞吐量的关系，并给出实时性指标的判定方法。这些概念是后续测量方案设计与数据解读的基础，也是HIL测试用例通过/失败判定的核心依据。

上图展示了本章的核心概念框架。端到端延迟是一个完整的因果链路，从物理世界事件发生（如传感器检测到异常振动）到系统产生可观测响应（如GPIO拉高触发急停）之间的全部时间消耗。推理延迟只是这条链路中的一个环节，尽管它通常是计算密集度最高的部分，但绝不等于系统响应时间。吞吐量则从系统容量的视角描述处理能力，与延迟存在理论上的倒数关系，但在实际嵌入式系统中，由于任务调度、中断抢占和资源竞争，这种关系往往被打破。实时性指标则进一步引入时间约束（Deadline）和抖动（Jitter）的概念，用于判断系统是否满足确定性要求。

4.1 延迟的严格定义与测量边界

延迟在嵌入式系统中有明确的物理含义：从输入事件发生到输出事件生效所经过的时间间隔。在ESP32-C3端侧推理场景中，我们需要区分三个层次的延迟定义：物理事件延迟（传感器信号变化到数据寄存器可读）、软件处理延迟（数据从驱动层到应用层再到推理引擎）、系统响应延迟（从事件发生到执行器动作）。HIL验证中，通常以系统响应延迟作为最终考核指标，因为它直接反映用户可感知的行为。

测量延迟必须明确时间基准点。常见做法是在GPIO中断服务函数（ISR）入口打时间戳（使用esp_timer_get_time()或timer_get_counter_value()），在输出动作执行前再打一次时间戳。但要注意，ISR本身有进入和退出开销，如果时间戳放在ISR内部，会引入约2-5微秒的测量误差。更精确的做法是使用ESP32-C3内置的硬件时间戳寄存器，或者外接逻辑分析仪测量物理引脚电平变化。

4.2 端到端延迟与推理延迟的工程区分

端到端延迟（E2E Latency）包含完整的数据通路：传感器采样→数据搬运（DMA/SPI/I2C）→预处理（滤波、归一化、特征提取）→推理（模型前向计算）→后处理（阈值判断、非极大值抑制）→输出执行（GPIO/PWM/通信）。推理延迟（Inference Latency）仅指模型前向传播的耗时，即输入张量准备好到输出张量可用的时间。

在实际ESP32-C3项目中，两者差距可能非常显著。例如一个关键词唤醒（KWS）模型，推理延迟可能只有30ms，但端到端延迟可能达到120ms，因为音频采集需要20ms的帧缓冲、预处理需要15ms的FFT计算、后处理需要5ms的平滑滤波，再加上任务调度延迟和WiFi通信（如果结果需要上报）的10-50ms。如果HIL测试只测量推理延迟，会严重低估系统的真实响应时间。

在HIL测试中，建议同时记录推理延迟和端到端延迟。如果两者差距过大（例如超过3倍），说明系统瓶颈不在模型计算，而在数据搬运、任务调度或通信环节。此时优化模型参数（如量化、剪枝）对端到端延迟的改善有限，应优先优化DMA配置、任务优先级或通信协议。

4.3 单次推理延迟与吞吐量的权衡

单次推理延迟（Per-Inference Latency）衡量处理一个样本所需的时间，吞吐量（Throughput）衡量单位时间内处理的样本数量。理论上，如果系统完全串行且无额外开销，吞吐量 = 1 / 单次延迟。但ESP32-C3是单核处理器（RISC-V），且运行FreeRTOS，存在任务切换开销、中断抢占和缓存失效等问题，实际吞吐量通常低于理论值。

例如，某图像分类模型单次推理延迟为45ms，理论吞吐量为22.2 FPS。但实际测试中，由于每帧图像采集需要8ms（DMA传输），预处理需要5ms，任务调度平均开销3ms，实际端到端单帧处理时间为61ms，吞吐量降至16.4 FPS。如果使用批处理（batch size=2），推理延迟可能增加到80ms（因为内存带宽限制），但平均每帧处理时间降至40ms+8ms+5ms+3ms=56ms，吞吐量提升至17.9 FPS。这说明在资源受限的MCU上，批处理并不总是能提升吞吐量，需要实测验证。

吞吐量测量需要连续运行至少100次推理，记录总耗时并计算平均值。同时要记录最大单次延迟和最小单次延迟，以评估抖动。在HIL验证中，如果系统需要处理周期性输入（如每50ms一帧传感器数据），则吞吐量必须大于20 FPS，且最大单次延迟必须小于50ms，否则会出现数据积压或丢帧。

4.4 实时性指标：Deadline、Jitter与WCET

实时性不是“快”的同义词，而是“可预测”的代名词。实时性指标包括：截止时间（Deadline）——任务必须在规定时间内完成；抖动（Jitter）——多次执行延迟的偏差范围；最坏情况执行时间（WCET）——在所有可能输入和系统状态下，任务执行时间的上限。

对于ESP32-C3端侧推理，实时性分为硬实时和软实时。硬实时要求任何情况下都不能超过Deadline（如安全气囊触发、电机急停），软实时允许偶尔超时（如语音识别结果上报）。HIL验证中，需要根据应用场景设定不同的判定标准。

1. 硬实时判定：运行1000次测试，记录每次端到端延迟，要求100%样本小于Deadline。如果出现一次超时，则判定系统不满足硬实时要求。
2. 软实时判定：允许一定比例的超时（如<1%），但超时幅度不能超过Deadline的20%。例如Deadline=100ms，允许最多10次超过100ms但必须小于120ms。
3. 抖动评估：计算延迟的标准差（σ），要求σ < 0.1 × 平均延迟。如果抖动过大，说明系统存在不稳定的调度或中断竞争。

// 实时性测量伪代码（ESP32-C3 FreeRTOS环境）
#define TEST_ITERATIONS 1000
#define DEADLINE_US 50000  // 50ms硬实时要求

int64_t start_time, end_time;
uint32_t timeout_count = 0;
int64_t max_latency = 0;
int64_t min_latency = INT64_MAX;
int64_t sum_latency = 0;

for (int i = 0; i < TEST_ITERATIONS; i++) {
    // 触发外部事件（如GPIO中断）
    gpio_set_level(TRIGGER_PIN, 1);
    start_time = esp_timer_get_time();
    
    // 等待推理完成（使用信号量或事件组）
    xSemaphoreTake(done_semaphore, portMAX_DELAY);
    end_time = esp_timer_get_time();
    
    int64_t latency = end_time - start_time;
    sum_latency += latency;
    if (latency > max_latency) max_latency = latency;
    if (latency < min_latency) min_latency = latency;
    if (latency > DEADLINE_US) timeout_count++;
    
    // 复位触发信号
    gpio_set_level(TRIGGER_PIN, 0);
    vTaskDelay(pdMS_TO_TICKS(10)); // 等待系统稳定
}

float avg_latency = (float)sum_latency / TEST_ITERATIONS;
printf("Avg: %.2f ms, Max: %.2f ms, Min: %.2f ms, Timeouts: %u/%d\n",
       avg_latency/1000, max_latency/1000, min_latency/1000, timeout_count, TEST_ITERATIONS);

4.5 案例拆解：电机堵转检测的实时性验证

某工业设备使用ESP32-C3采集电机电流信号，通过CNN模型检测堵转状态，并在检测到堵转后10ms内切断电机电源。系统约束：电流采样率2kHz（每500μs一个样本），推理窗口大小64个样本（32ms），模型推理延迟约8ms，GPIO控制继电器动作需2ms。

初始现象：实验室测试中，推理延迟稳定在7.8-8.2ms，满足要求。但在HIL测试中，端到端延迟波动较大，部分测试超过15ms，导致继电器动作超时。

分析过程：通过逻辑分析仪测量发现，延迟波动主要来自两个环节：一是FreeRTOS任务调度，推理任务优先级低于WiFi任务，当WiFi进行TCP重传时，推理任务被抢占约3-5ms；二是ADC采样使用轮询模式，在CPU忙于推理时无法及时读取采样数据，导致数据丢失和窗口错位。

解决方案：将推理任务优先级提升至高于WiFi任务（但低于ISR），并将ADC采样改为DMA模式，使用双缓冲交替存储采样数据。同时将继电器控制逻辑放在高优先级任务中，由推理任务通过任务通知触发。

结果对比：优化后，端到端延迟稳定在9.2-10.5ms，最大延迟10.8ms，满足10ms硬实时要求（留出0.8ms余量）。抖动从原来的±3.5ms降低至±0.7ms。

复盘经验：实时性优化不能只关注推理引擎本身，任务调度、外设访问方式和中断优先级共同决定端到端延迟。HIL测试的价值在于暴露这些在纯软件测试中难以发现的时序问题。

4.6 常见误区与总结

在延迟测量与实时性评估中，以下误区需要特别注意：

• 误区一：将推理延迟等同于端到端延迟。这会导致系统实际响应比预期慢2-5倍，在安全关键场景可能造成事故。
• 误区二：使用平均值评估实时性。平均值掩盖了尾部延迟，一个系统平均延迟10ms但最大延迟100ms，仍然不满足50ms的Deadline要求。
• 误区三：忽略缓存和分支预测的影响。ESP32-C3没有数据缓存，但指令缓存（I-Cache）对推理延迟有显著影响。首次推理（冷缓存）可能比后续推理慢30-50%，测量时应区分冷启动和稳态。
• 误区四：在HIL测试中只测量单次延迟，不进行压力测试。系统在连续运行10分钟后，由于内存碎片化或WiFi重连，延迟可能劣化。