4. 实时AI推理基础与性能指标

在 IGX 这类边缘实时 AI 平台上，判断一个推理系统是否“够快”，不能只看单次推理耗时。真正决定业务可用性的，是一组彼此耦合的指标：推理延迟、吞吐量、抖动、确定性与端到端时延。它们分别回答不同问题——单帧要等多久、单位时间能处理多少帧、最坏情况有多差、每次结果是否稳定可预测、从传感器到执行动作总共花了多久。理解这些指标的定义、测量位置与相互制约关系，是后续做性能调优和实时性保障的前提。

一、五个核心指标的定义与边界

推理延迟（Inference Latency）指从推理输入张量就绪，到输出张量可用的时间，通常包含数据搬运（H2D）、前向计算、后处理（NMS、解码等）三部分。它衡量的是“单次请求”的快慢，单位常用毫秒。注意：它不包含采集、预处理和下游执行。

吞吐量（Throughput）指单位时间内完成的推理次数，单位 FPS 或 inferences/s。它衡量系统整体处理能力，与延迟并非线性关系：批处理（batch）能显著提升吞吐，但会抬高单次延迟。

抖动（Jitter）指延迟的波动程度，常用延迟的标准差、P99 与 P50 之差、或最大-最小延迟差表示。抖动大意味着系统“时快时慢”，对控制类应用尤其危险。

确定性（Determinism）指在相同输入与相同配置下，输出结果与执行时间是否可重复。结果确定性关注数值一致，时间确定性关注延迟是否落在可预测区间。实时系统更关心时间确定性。

端到端时延（End-to-End Latency）指从物理事件发生（如相机曝光）到系统产生最终动作或输出的总时间，是业务真正感知的时延。它等于采集 + 传输 + 预处理 + 推理 + 后处理 + 决策 + 执行各段之和。

记忆要点：延迟看“单次多快”，吞吐看“整体多少”，抖动看“稳不稳”，确定性看“可不可预测”，端到端看“用户等多久”。

二、测量方法：在哪里打点，用什么工具

测量位置决定了指标的含义，必须明确打点边界。推荐在 IGX 上采用如下分层打点：

  • 推理延迟：在推理前后用 CUDA Event 打点，避免 CPU 计时受调度干扰。示例：cudaEventRecord(start) → 执行推理 → cudaEventRecord(stop) → cudaEventElapsedTime。
  • 端到端时延：在采集端打硬件时间戳（如 GMSL 相机触发时刻），在输出端打完成时间戳，两者相减。跨进程时用 PTP/硬件同步时钟。
  • 吞吐量：统计固定时间窗口内完成的推理次数，除以窗口时长；需注明 batch size 与并发流数量。
  • 抖动与确定性：连续采集至少数千次延迟样本，计算 P50/P95/P99、标准差与最大最小值，观察是否出现长尾。

常用工具包括 trtexec（TensorRT 自带，可直接输出延迟与吞吐）、Nsight Systems（时间线分析各段耗时与 GPU 利用率）、以及自研的埋点日志。下面给出一个 trtexec 的典型调用示例：

trtexec --loadEngine=model.plan \
        --shapes=input:1x3x640x640 \
        --warmUp=500 --duration=10 --avgRuns=100 \
        --useCudaGraph --dumpProfile

其中 --warmUp 用于预热，避免首次加载与缓存未命中污染统计；--useCudaGraph 可降低内核启动开销，对减小抖动有明显帮助；--dumpProfile 输出各层耗时，便于定位瓶颈层。

三、指标之间的权衡关系

这五个指标并非独立，而是存在明确 trade-off。下图展示了从输入到输出的完整信号链，以及各指标对应的测量位置与主要影响因素。

实时AI推理信号链与性能指标测量位置 传感器采集 相机/雷达 预处理 缩放/归一化 推理引擎 TensorRT/GPU H2D+计算+后处理 决策 规划/控制 执行 刹车/转向 端到端时延（E2E Latency） 推理延迟 吞吐量： 单位时间完成推理次数 = 完成帧数 / 时间窗口（受 batch、并发流、GPU利用率影响） 抖动： 延迟波动 = P99 − P50，受内核启动、内存分配、调度抢占、温度降频影响 核心权衡： Batch↑ → 吞吐↑ 但延迟↑；并发流↑ → 吞吐↑ 但抖动↑；精度↑ → 延迟↑；CUDA Graph → 抖动↓ 确定性目标：P99 延迟 ≤ 业务截止时间（如 33ms@30FPS），且抖动控制在可接受范围

从图中可以看出，端到端时延覆盖了整条链路，而推理延迟只是其中一段。优化时必须先明确业务截止时间（deadline），再倒推各段预算。例如 30FPS 的感知任务，端到端预算约 33ms，若采集+传输占 8ms、预处理占 4ms、决策执行占 5ms，则推理段必须控制在 16ms 以内，且 P99 不能突破该值。

四、优化目标与实操方向

优化不是盲目追求最低延迟，而是让 P99 延迟稳定落在截止时间内，同时满足吞吐需求。可按以下优先级推进：

  1. 降低单次延迟：使用 TensorRT FP16/INT8 量化、层融合、选择高效算子；用 --useCudaGraph 减少内核启动开销。
  2. 提升吞吐：在延迟允许范围内增大 batch；使用多 CUDA Stream 并发处理不同请求；启用 DLA 卸载部分算子。
  3. 抑制抖动：锁定 GPU 时钟（nvidia-smi -lgc）、关闭不必要的后台进程、使用固定内存（pinned memory）减少 H2D 波动、避免运行时动态内存分配。
  4. 保障确定性：固定输入尺寸与 batch，避免动态 shape 带来的重规划；预热充分后再进入正式统计。
  5. 端到端对齐：统一时钟源，采集端与推理端使用同一时间基准，确保各段耗时可直接相加。
常见误区：只看平均延迟而忽略 P99。在实时系统中，一次长尾抖动就可能导致错过截止时间，因此必须以 P99 或最大值作为验收依据。

五、一个可参考的验收指标示例

假设某 IGX 边缘节点运行 30FPS 目标检测，业务要求端到端不超过 33ms。可设定如下验收表（示例参数，非实测）：

指标目标值测量方法判断依据
推理延迟 P50≤ 10msCUDA Event 打点满足预算
推理延迟 P99≤ 16ms连续 5000 次采样不超截止时间
吞吐量≥ 30 FPS10s 窗口计数匹配帧率
抖动（P99−P50）≤ 5ms延迟分布统计波动可控
端到端时延 P99≤ 33ms硬件时间戳业务达标

测量时先预热 500 次，再连续采集 5000 次，记录每次延迟并排序取分位数。若 P99 超标，优先检查是否存在内存拷贝抖动、时钟降频或后台干扰；若吞吐不足，则考虑增大 batch 或增加并发流。通过这种“定义—测量—权衡—验收”的闭环，才能把实时 AI 推理从“能跑”推进到“稳定可交付”。

← 上一章 📖 返回目录 下一章 →