4、延迟预算基础：延迟的定义、组成与分解方法

在NXP eIQ边缘部署中，延迟预算（Latency Budget）是连接业务需求与技术实现的桥梁。无论是工业视觉检测、智能零售终端，还是车载感知系统，用户感知到的“响应快慢”并非单一指标，而是由多个阶段延迟叠加而成的综合结果。本章将系统梳理延迟的定义体系、预算的组成与分解方法，并厘清延迟与吞吐量这对关键性能指标之间的辩证关系，为后续基于eIQ工具链进行延迟测量与优化打下坚实的理论基础。

4.1 延迟的定义体系：从端到端到单阶段

核心原理：在边缘部署场景中，延迟并非单一数值，而是一个具有层次结构的指标体系。从用户或系统外部观察，端到端延迟（End-to-End Latency）是指从输入事件发生（如图像传感器曝光开始、网络报文到达）到输出结果可用（如控制信号发出、检测框显示）的完整时间间隔。而在系统内部，这个总延迟被划分为多个可独立测量和优化的阶段延迟。

具体而言，端到端延迟可分解为以下核心组成部分：

• 采集延迟（Acquisition Latency）：传感器从物理世界捕获信号到数据可供处理器读取的时间。对于摄像头，包括曝光时间、读出时间、MIPI/CSI传输时间。
• 预处理延迟（Preprocessing Latency）：数据从原始格式转换为模型可接受输入格式的时间。典型操作包括图像缩放（Resize）、归一化（Normalize）、通道转换（RGB↔BGR）、数据类型转换（uint8→float32）等。
• 推理延迟（Inference Latency）：神经网络模型在NPU/CPU/GPU上执行前向计算的时间。这是AI部署中最受关注的指标，通常以毫秒（ms）为单位。
• 后处理延迟（Post-processing Latency）：将模型原始输出转换为业务可用结果的时间。包括非极大值抑制（NMS）、阈值过滤、坐标映射、结果序列化等。
• 传输与调度延迟（Transport & Scheduling Latency）：数据在内存、DMA、IPC或网络间拷贝与排队的时间，以及RTOS/Linux调度器引入的任务切换时间。

4.2 延迟预算的组成与分解方法

判断方法或操作流程：延迟预算分解的核心目标是将业务层的时间约束（Service Level Agreement, SLA）逐层映射到每个功能模块的技术指标上。推荐采用自顶向下分解、自底向上验证的方法：

1. 确定端到端SLA：与产品经理确认用户可接受的最大响应时间。例如，工业质检要求从拍照到分拣信号输出不超过100ms。
2. 识别关键路径：绘制数据流图，标记从触发到响应的所有串行环节。注意区分并行路径（如双摄像头采集）与串行路径。
3. 初步分配预算：根据经验或理论估算，将总预算按比例分配给各阶段。建议预留15%-20%的裕量应对抖动。
4. 逐模块测量与校准：使用eIQ Toolkit的profiling功能、Linux的 perf 工具或硬件定时器，实测各阶段实际耗时。
5. 迭代调整：若某阶段超支，优先优化占比最大的模块；若整体超支，需与业务方协商调整SLA或硬件方案。

4.3 延迟与吞吐量的关系：并非简单的倒数

核心原理：吞吐量（Throughput）定义为单位时间内系统能处理的样本数量，通常以FPS（Frames Per Second）表示。许多开发者误以为 延迟 = 1/吞吐量，这在单任务串行处理时成立，但在实际边缘系统中，两者是独立但相互影响的指标。

关键区别在于：延迟衡量的是单次任务的完成时间，而吞吐量衡量的是系统的并行处理能力。通过流水线（Pipeline）架构，可以在不降低单帧延迟的前提下提升吞吐量。例如，将采集、预处理、推理、后处理分配到不同硬件单元并行执行，虽然单帧延迟仍为各阶段之和，但系统每帧间隔可缩短至最慢阶段的耗时。

常见误区或总结复盘：

• 误区一：追求极致低延迟必然牺牲吞吐量。实际上，通过合理的流水线设计，两者可以兼得。eIQ的NPU支持多上下文（Multi-context）执行，可同时运行多个推理任务。
• 误区二：批处理（Batch）总是有益的。在边缘设备上，批处理会增加内存带宽压力，且当batch size超过NPU内部缓存时，性能可能不升反降。建议在eIQ中测试batch=1、2、4的实际吞吐量。
• 误区三：忽略延迟抖动（Jitter）。对于实时控制系统，P99或P99.9延迟比平均延迟更重要。RTOS的优先级反转、Linux的CFS调度器都可能导致偶发高延迟。
• 复盘要点：延迟预算不是一次性的静态工作，而是需要随模型迭代、输入分布变化、负载波动持续监控的动态过程。建议在eIQ部署中建立延迟监控看板，记录每个阶段的耗时分布。