深度学习推理基础：推理与训练的区别、推理性能指标与典型推理流水线

在进入 CUDA 与 TensorRT 的工程实践之前，必须先厘清深度学习推理（Inference）与训练（Training）的本质差异。许多性能调优的决策——例如是否使用 FP16、是否做层融合、如何设置动态 batch——都源于这两种工作负载在目标、约束和硬件行为上的根本不同。本章将系统梳理推理与训练的区别，定义延迟、吞吐量、显存占用三大核心指标，并拆解一条从模型输入到最终输出的典型推理流水线，为后续章节的算子优化、引擎构建和部署架构打下共同的认知基础。

上图展示了训练与推理在阶段目标、计算流程和优化侧重点上的差异。训练是一个迭代收敛过程，前向传播、损失计算、反向传播和参数更新构成一个闭环，其核心诉求是模型精度；而推理则是将训练好的模型参数固定下来，对新的输入数据执行一次前向计算，其核心诉求是在延迟、吞吐量和显存约束下高效完成预测。下面逐一展开。

2.1 推理与训练的本质区别

核心原理：计算图与数据流的不同

训练阶段需要同时保存中间激活值（Activation）用于反向传播计算梯度，因此显存占用远高于推理。以 ResNet-50 为例，训练时 batch size 为 256 的 FP32 模型，显存占用通常在 12GB 以上；而推理时同一模型仅需保存前向计算的中间结果，显存占用可降至 2GB 以内。此外，训练对数值精度要求高，通常使用 FP32 甚至 FP64 累积梯度；推理则允许使用 FP16、INT8 等低精度格式，因为模型参数已经收敛，对微小数值扰动的容忍度更高。

从计算模式看，训练是典型的计算密集型 + 访存密集型混合负载，反向传播需要读取大量中间结果；推理则更偏向访存密集型，尤其是 batch size 较小时，内存带宽往往成为瓶颈。这一差异直接决定了优化策略：训练优化关注矩阵乘法效率（GEMM），推理优化则关注算子融合、内存复用和减少 Kernel 启动开销。

判断方法：从工程约束识别工作负载类型

在实际工程中，判断一个任务属于训练还是推理，最简单的标准是：模型参数是否在计算过程中被更新。如果参数固定不变，仅对输入做前向计算，即为推理。另一个判断依据是延迟敏感度——训练任务允许数秒甚至数分钟的等待，而在线推理服务通常要求 P99 延迟低于 50ms。

案例拆解：从训练到推理的精度与性能权衡

某安防场景的人脸识别系统，最初直接使用 PyTorch 训练好的 ResNet-50 模型（FP32）部署在 GPU 上，单张图片推理延迟为 12ms，显存占用 1.8GB。业务要求 P99 延迟低于 10ms，且 GPU 显存限制为 2GB。通过以下步骤完成优化：

1. 将模型导出为 ONNX，使用 TensorRT 构建 FP16 引擎，延迟降至 6.5ms；
2. 进一步尝试 INT8 量化，使用 500 张校准图片，延迟降至 4.2ms，但精度从 99.2% 降至 98.7%，仍在业务容忍范围内；
3. 最终选择 FP16 引擎，延迟 6.5ms，显存占用 1.2GB，满足约束。

这个案例说明，推理优化需要在精度和性能之间做显式权衡，而训练阶段通常不需要考虑这种取舍。

2.2 推理性能指标：延迟、吞吐量与显存占用

核心原理：三个指标的定义与相互关系

延迟（Latency）指从输入数据到达推理系统到输出结果返回的完整时间，通常以毫秒（ms）为单位。延迟指标需要关注分布而非平均值——P99 延迟（99% 请求的延迟上限）比平均延迟更能反映用户体验。例如，平均延迟 5ms 但 P99 延迟 50ms 的系统，在实时交互场景中仍可能被判定为不合格。

吞吐量（Throughput）指系统在单位时间内处理的样本数量，常用 QPS（Queries Per Second）或 FPS（Frames Per Second）表示。吞吐量与延迟并非简单的倒数关系——通过增大 batch size 可以提高吞吐量，但单样本延迟也会随之上升。例如，batch size 从 1 增加到 32，单样本延迟可能从 2ms 升至 8ms，但整体吞吐量从 500 QPS 提升到 4000 QPS。

显存占用（Memory Footprint）包括静态显存（模型权重、常量）和动态显存（中间激活、临时缓冲区）。显存占用直接影响可部署的模型规模和并发数。TensorRT 通过显存池（Memory Pool）复用中间缓冲区，可将显存占用降低 30%~50%。

判断方法：如何测量与评估

• 延迟测量：使用 CUDA 事件（cudaEventRecord）测量 GPU 时间，排除 CPU 预处理和后处理时间；使用 clock_gettime 测量端到端延迟。需预热 100 次后再统计，避免冷启动影响。
• 吞吐量测量：使用固定 batch size 连续发送请求，统计 1 分钟内处理的总样本数。注意区分“单流吞吐”和“多流吞吐”——多流（Multi-Stream）可以隐藏 CPU 与 GPU 之间的同步开销。
• 显存测量：使用 nvidia-smi 监控进程显存，或使用 CUDA 的 cudaMemGetInfo 获取空闲显存。TensorRT 引擎构建时可通过 setMaxWorkspaceSize 控制工作空间上限。

案例拆解：延迟与吞吐量的权衡决策

某广告推荐系统需要部署一个 3 层 MLP 模型，输入特征维度 1024，输出 256 维向量。GPU 为 T4（16GB 显存）。初始方案使用 batch size = 1，测得延迟 1.2ms，吞吐量 800 QPS。业务要求吞吐量达到 5000 QPS，且 P99 延迟不超过 5ms。

分析过程：单样本延迟 1.2ms 中，GPU 计算仅占 0.4ms，其余 0.8ms 为 CPU 预处理和 GPU 同步开销。通过增大 batch size 到 16，GPU 计算效率提升，单样本延迟升至 2.1ms，但吞吐量达到 4800 QPS。进一步使用 CUDA Graph 捕获推理流程，减少 Kernel 启动开销，单样本延迟降至 1.8ms，吞吐量达到 5600 QPS，满足要求。

2.3 典型推理流水线

核心原理：从原始输入到最终输出的完整链路

一条完整的推理流水线包含五个阶段：数据获取 → 预处理 → 模型推理 → 后处理 → 结果返回。在 GPU 部署场景中，预处理和后处理通常由 CPU 完成，模型推理由 GPU 完成，因此 CPU 与 GPU 之间的数据拷贝（H2D/D2H）成为关键瓶颈。

预处理包括图像解码（JPEG/PNG）、缩放、归一化、通道转换（NHWC/NCHW）等操作。这些操作在 CPU 上执行时，可能消耗与 GPU 推理相当的时间。例如，一张 1080p 图像的 JPEG 解码在 CPU 上约需 3~5ms，而 ResNet-50 的 GPU 推理仅需 1~2ms。因此，现代推理框架（如 TensorRT 的 PyTorch 集成）会将预处理也放到 GPU 上执行，使用 CUDA 核函数完成解码和缩放。

操作流程：构建高效推理流水线的步骤

1. 确定数据格式：明确输入张量的形状、数据类型（FP32/FP16/INT8）和内存布局（NCHW/NHWC）。
2. 设计预处理管线：将可 GPU 化的操作（缩放、归一化）迁移到 CUDA 上，减少 CPU 负载。
3. 选择推理引擎：根据模型类型和精度要求，选择 TensorRT 引擎或 ONNX Runtime GPU 版本。
4. 实现后处理：对于检测模型，后处理包括 NMS（非极大值抑制）；对于分类模型，后处理为 Softmax 和 Top-K 排序。
5. 优化数据拷贝：使用 CUDA 流（Stream）和异步拷贝（cudaMemcpyAsync）重叠 CPU 预处理与 GPU 推理。

案例拆解：YOLOv5 目标检测流水线优化

某工业质检项目使用 YOLOv5s 检测产品表面缺陷，输入 640×640 图像，输出为检测框和类别。初始流水线延迟 28ms，其中预处理 8ms（CPU 缩放+归一化）、GPU 推理 12ms、后处理 8ms（CPU 的 NMS）。优化过程：

• 将缩放和归一化迁移到 GPU 上，使用 CUDA 核函数处理，预处理时间降至 2ms；
• 将 NMS 替换为 TensorRT 的 EfficientNMS 插件，后处理降至 3ms；
• 使用 CUDA Graph 捕获整个推理流程，减少 Kernel 启动开销，GPU 推理降至 9ms。

优化后总延迟 14ms，吞吐量从 35 FPS 提升至 70 FPS，且显存占用从 2.1GB 降至 1.6GB。

常见误区与总结复盘

• 误区一：只关注 GPU 推理时间，忽略预处理和后处理。实际上，端到端延迟才是用户感知的指标。
• 误区二：认为 batch size 越大越好。当 batch size 超过 GPU 算力饱和点后，延迟会线性增加而吞吐量不再提升。
• 误区三：忽略显存碎片化。频繁分配和释放显存会导致碎片，TensorRT 的显存池机制可以有效缓解。

总结而言，推理与训练在目标、精度和资源约束上存在本质差异；延迟、吞吐量和显存占用是评估推理系统的三大核心指标，三者之间存在相互制约关系；典型推理流水线需要从端到端视角进行优化，将预处理、推理和后处理视为一个整体。理解这些基础概念，是后续学习 CUDA 算子优化和 TensorRT 引擎配置的前提。