延迟预算基础：定义延迟预算、端到端延迟组成与吞吐量权衡
在边缘部署TensorRT模型时，延迟预算（Latency Budget）是连接业务需求与工程实现的“契约”。它不是一个简单的数字，而是一套将用户可感知的响应时间拆解为可测量、可优化、可验证的工程指标的方法论。本章将系统讲解延迟预算的定义方法、端到端延迟的构成要素，以及延迟与吞吐量之间此消彼长的权衡关系，为后续的调优实战奠定量化基础。
2.1 延迟预算的定义与核心原理
延迟预算是指在满足业务服务水平协议（SLA）的前提下，系统从接收到输入到产生最终输出所允许消耗的最大时间。它不是一个单一数值，而是一个包含统计分布特征的约束集合。在边缘部署场景中，延迟预算通常以P50（中位数）、P95、P99分位数来定义，因为平均延迟无法反映尾部延迟对用户体验的破坏性影响。
定义延迟预算需要遵循三个核心原则：用户可感知原则——预算必须从最终用户体验倒推，而非从硬件能力正推；端到端原则——预算必须覆盖从数据采集到结果传输的全链路；可分解原则——总预算必须能够拆解到每个子模块，以便定位瓶颈和分配优化资源。
2.2 端到端延迟的五个组成阶段
一个典型的边缘推理系统，其端到端延迟由五个串行阶段构成。理解每个阶段的延迟特征和优化空间，是进行延迟预算分配的前提。
| 阶段 | 典型耗时占比 | 主要延迟来源 | 优化手段 |
|---|---|---|---|
| 采集 | 5%-15% | 传感器曝光、ISP处理、帧缓冲等待 | 硬件触发、ROI裁剪、降低分辨率 |
| 预处理 | 5%-10% | Resize、归一化、颜色空间转换、H2D拷贝 | GPU预处理、CUDA加速、避免CPU-GPU拷贝 |
| 推理 | 50%-70% | 模型计算量、算子效率、显存带宽 | TensorRT优化、量化、算子融合、动态Shape |
| 后处理 | 5%-15% | NMS、解码、阈值过滤、D2H拷贝 | GPU并行NMS、减少输出张量、异步拷贝 |
| 传输 | 5%-10% | 序列化、网络发送、协议开销 | 压缩、共享内存、零拷贝传输 |
在实际项目中，推理阶段通常占据主导地位，但不能因此忽略其他阶段。当推理延迟被TensorRT优化到极致后，预处理和后处理的占比会相对上升，成为新的瓶颈。这也是为什么延迟预算必须端到端审视的原因。
2.3 延迟与吞吐量的权衡机制
延迟（Latency）和吞吐量（Throughput）是边缘部署中最核心的一对矛盾。吞吐量通常以每秒处理的帧数（FPS）或推理次数（IPS）来衡量。二者的关系并非简单的线性反比，而是呈现出非线性拐点特征。
从系统角度看，提高吞吐量的主要手段是增大Batch Size和利用多流并行。然而，Batch Size增大意味着单个请求需要等待更多数据凑齐一个Batch，这会引入排队延迟；同时，大Batch会占用更多显存和计算资源，导致单个推理的耗时增加。因此，存在一个最优Batch Size，使得吞吐量达到峰值而延迟仍在可接受范围内。
// 延迟-吞吐量权衡的典型数据（基于Jetson Orin实测）
Batch=1: P99延迟=8ms, 吞吐量=120 FPS
Batch=4: P99延迟=14ms, 吞吐量=210 FPS
Batch=8: P99延迟=22ms, 吞吐量=260 FPS
Batch=16: P99延迟=38ms, 吞吐量=280 FPS // 拐点出现
Batch=32: P99延迟=65ms, 吞吐量=270 FPS // 吞吐量下降上述数据揭示了两个关键现象：第一，吞吐量在Batch=16时达到峰值，之后反而下降，这是因为显存带宽和计算资源已饱和；第二，P99延迟随Batch增大呈超线性增长，从8ms飙升至65ms。在实际部署中，我们需要通过压测找到这个拐点，并选择拐点左侧的配置作为工作点。
2.4 实战案例：智能相机的延迟预算分配
某工业质检项目需要在边缘设备（Jetson AGX Orin）上部署TensorRT加速的缺陷检测模型，业务要求如下：
- 传送带速度：0.5m/s，相机视野宽度0.4m，要求每帧覆盖无遗漏
- 最大允许处理时间：80ms/帧（即最低12.5 FPS）
- P99延迟必须小于100ms，否则触发停机保护
- 系统需同时处理2路相机输入
初始方案与问题：工程师最初将模型直接转换为TensorRT FP16引擎，Batch=1，测得推理延迟为35ms，但端到端延迟达到95ms，接近上限。进一步分析发现：采集阶段占用12ms（相机曝光+ISP），预处理占用8ms（CPU端Resize+拷贝），推理35ms，后处理15ms（CPU端NMS），传输25ms（通过以太网发送结果到PLC）。
分析与优化过程：
- 瓶颈定位：通过NVIDIA Nsight Systems分析，发现预处理和后处理均在CPU执行，且存在多次CPU-GPU数据拷贝，浪费约18ms。
- 优化措施：将预处理迁移到GPU（使用CUDA核函数），后处理NMS改用TensorRT的EfficientNMS插件，传输改用共享内存+零拷贝方式。
- 参数调整：将Batch从1调整为2（两路相机合并推理），推理延迟从35ms增至42ms，但整体吞吐量提升。
优化后结果：
| 阶段 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| 采集 | 12ms | 10ms | 减少曝光等待 |
| 预处理 | 8ms | 3ms | GPU加速 |
| 推理 | 35ms | 42ms | Batch=2 |
| 后处理 | 15ms | 4ms | EfficientNMS |
| 传输 | 25ms | 5ms | 零拷贝 |
| 端到端P99 | 95ms | 64ms | 降低32.6% |
复盘经验：本案例的核心教训是不要只优化推理阶段。当推理延迟占比从37%降至65%时，其他阶段的优化空间反而更大。同时，Batch=2的决策是在保证P99延迟低于100ms的前提下做出的，如果Batch=4虽然吞吐量更高，但P99延迟会达到88ms，风险过高。
2.5 常见误区与总结
在延迟预算的制定和执行过程中，工程师常犯以下错误：
- 误区一：只关注平均延迟。平均延迟掩盖了尾部延迟问题，必须使用P95/P99作为设计指标。
- 误区二：忽略采集和传输阶段。在分布式边缘系统中，网络抖动可能导致传输延迟占30%以上。
- 误区三：静态分配预算。延迟预算应随负载动态调整，例如在低峰期可以增大Batch提升吞吐，高峰期则减小Batch保证延迟。
- 误区四：混淆GPU时间与端到端时间。TensorRT的profiler显示的kernel时间只是推理阶段的一部分，不包含排队和拷贝时间。