3. 车载AI推理软件栈总览
在 NVIDIA DRIVE 平台上部署一个车载 AI 推理功能，开发者面对的并不是单一软件，而是一套从操作系统到应用框架的完整软件栈。很多初学者容易把 CUDA、TensorRT、cuDNN 混为一谈，或者误以为 DriveWorks 就是“另一个 TensorRT”。要真正理解性能优化发生在哪一层、问题应该在哪一层排查，必须先建立清晰的分层模型：每一层解决什么问题、向上暴露什么接口、向下依赖什么能力。
从最底层向上看，这套栈大致可以分为六个层次：DriveOS（车载操作系统与驱动）、CUDA（GPU 通用并行计算平台）、cuDNN（深度神经网络算子库）、TensorRT（推理优化与运行时）、DriveWorks（车载感知中间件与加速库）、DRIVE AV SDK（自动驾驶应用级框架）。它们不是简单的“谁替代谁”，而是各自承担不同职责、彼此协作。
各层职责与边界
DriveOS 是整个栈的根基。它基于 Linux 构建，但针对车载场景做了实时性、安全性和资源隔离的强化。DriveOS 提供 GPU 驱动、显示驱动、摄像头输入驱动以及安全启动机制。开发者通常不直接修改 DriveOS，但需要理解它决定了可用的 CUDA 版本、GPU 驱动版本以及系统级资源分配策略。例如，当多个推理任务共享 GPU 时，DriveOS 层面的调度策略会影响任务间的干扰程度。
CUDA 是 GPU 通用计算的基础平台。它向上提供编程模型（线程、块、网格）、运行时 API（内存分配、内核启动、流管理）和驱动 API。TensorRT 和 cuDNN 都构建在 CUDA 之上。理解 CUDA 的流（Stream）和事件（Event）机制，对于后续做多流并行推理、重叠数据传输与计算至关重要。一个常见的性能问题——推理延迟波动大——往往与 CUDA 流的使用方式有关。
cuDNN 是深度学习的算子库，提供卷积、池化、归一化、激活函数等标准算子的高度优化实现。它不负责图级别的优化，而是专注于单个算子或算子组合在 GPU 上的高效执行。TensorRT 在构建引擎时，会调用 cuDNN 或其他内核实现来完成具体计算。开发者一般不直接调用 cuDNN，但需要知道它的存在：当 TensorRT 的某个层融合策略失效时，底层可能回退到 cuDNN 算子，性能特征会发生变化。
TensorRT 是推理优化的核心层。它接收训练好的模型（ONNX、Caffe 等格式），执行层融合、精度校准（FP16/INT8）、内核自动调优、动态形状支持等优化，最终生成一个序列化的推理引擎（.plan 文件）。TensorRT 的职责是“把模型变成在特定 GPU 上跑得最快的执行计划”。它向上为 DriveWorks 和 DRIVE AV SDK 提供推理运行时，向下依赖 CUDA 和 cuDNN。实际部署中，TensorRT 引擎的构建通常在主机端完成，再部署到车载端，因为构建过程计算量大且需要目标 GPU 的精确信息。
DriveWorks 是车载感知的中间件层。它不只是一个推理库，而是一套面向自动驾驶感知任务的加速库集合，包括图像预处理（去畸变、缩放、格式转换）、点云处理、传感器标定、传感器融合、以及 DNN 框架集成。DriveWorks 的价值在于：它把车载感知中反复出现的、计算密集的预处理和后处理任务做了 GPU 加速，并提供了与 TensorRT 的无缝集成。例如，摄像头图像从 RAW 格式到推理输入张量的整个预处理链路，DriveWorks 可以提供比 CPU 实现高一个数量级的吞吐。
DRIVE AV SDK 位于最上层，是面向自动驾驶应用的完整框架。它定义了感知、规划、控制等模块的接口和编排方式，提供传感器抽象、数据记录与回放、可视化等工具。DRIVE AV SDK 会调用 DriveWorks 和 TensorRT 来完成具体的感知推理任务，但开发者更多是在应用层面组织功能，而不是直接操作推理引擎。
实际部署中的分层协作示例
假设我们要部署一个基于摄像头的目标检测模型。典型的协作链路是：DRIVE AV SDK 中的感知模块接收到摄像头帧，调用 DriveWorks 的图像预处理接口完成去畸变和缩放，预处理结果被送入 TensorRT 引擎执行推理，TensorRT 在底层通过 CUDA 流调度内核，并可能调用 cuDNN 算子完成卷积计算，最终输出检测框和类别。整个过程中，DriveOS 负责保证摄像头输入的时间戳准确、GPU 资源不被其他任务过度抢占。
理解这个分层模型的实际意义在于：当推理性能不达标时，可以按层排查。如果预处理耗时占比高，问题可能在 DriveWorks 的配置或 CPU-GPU 数据传输方式；如果推理本身慢，需要检查 TensorRT 的精度模式、层融合情况或动态形状设置；如果延迟波动大，可能需要检查 CUDA 流的使用和 DriveOS 层面的资源竞争。每一层都有对应的工具和指标，分层思维能避免“盲目调参”。
最后需要强调的是，这六层并不是严格的一对一依赖。DriveWorks 可以直接使用 CUDA 做自定义加速，DRIVE AV SDK 也可以绕过 DriveWorks 直接调用 TensorRT。但在标准部署路径中，按照分层职责使用各层能力，能获得最好的可维护性和性能可预测性。