1. 课程导入与NVIDIA DRIVE全景

智能驾驶计算平台并不是“把一块高性能 GPU 装进车里”这么简单。它要同时满足车规可靠性、功能安全、实时性、功耗与散热约束，还要承载感知、融合、预测、规划、控制等多类负载。NVIDIA DRIVE 正是围绕这一目标构建的软硬件协同平台：底层是车规级 SoC 与安全架构，中间是 DriveOS、CUDA、TensorRT 等运行时与加速库，上层是 DRIVE AV 等参考应用与开发者 SDK。理解这三层如何咬合，是后续所有章节的基础。

从车载计算到集中式智能驾驶平台

早期 ADAS 采用分布式 ECU：前视摄像头、毫米波雷达、泊车控制器各自独立，算力分散、数据难以共享。随着感知模型从传统特征工程转向深度神经网络，算力需求呈数量级增长，架构也随之演进为“集中式计算 + 区域网关”。NVIDIA DRIVE 的产品家族正对应这一演进路径：

• DRIVE PX / Xavier 时代：以 Xavier SoC 为代表，集成 CPU、GPU、DLA（深度学习加速器）、PVA（可编程视觉加速器），单芯片算力约 30 TOPS 级别，支持 L2+ 到 L3 的域控制器方案。
• DRIVE Orin 时代：单颗 Orin 提供约 254 TOPS（INT8）算力，支持多传感器融合与更高等级自动驾驶，可通过多颗 Orin 级联扩展算力。
• DRIVE Thor 时代：面向集中式中央计算，单颗芯片算力达到 1000 TOPS 级别，支持舱驾融合，将智能座舱与自动驾驶负载整合到同一 SoC。

需要强调的是，算力数字只是选型的一个维度。实际项目中还要看有效算力利用率、内存带宽、功能安全等级（ASIL）、功耗与散热能力。例如同样标称 254 TOPS，若模型无法高效映射到 DLA 或 TensorRT，实际可用算力可能大幅下降。因此本课程会反复强调“算力—模型—工具链”三者的匹配关系。

软硬件协同开发范式

NVIDIA DRIVE 的开发范式可以概括为“硬件抽象 + 分层软件 + 参考应用”。硬件层提供 SoC、传感器接口（GMSL、以太网、CAN）与安全岛；系统软件层由 DriveOS 提供实时调度、内存管理、Hypervisor 与安全服务；加速层包括 CUDA、TensorRT、cuDNN 以及 NvMedia、DriveWorks 等中间件；应用层则是感知、融合、规划控制等模块。开发者通常不会直接操作寄存器，而是通过 DriveWorks 的传感器抽象、TensorRT 的模型推理接口来构建流水线。

一个典型的开发闭环是：在主机上用 PyTorch 训练模型 → 导出 ONNX → 用 TensorRT 在目标 Orin 上做 INT8 量化与引擎构建 → 通过 DriveWorks 接入摄像头数据 → 在环仿真或实车采集数据上验证精度与延迟。这个闭环中，量化校准集的选择、层融合策略、DLA 与 GPU 的算子分配，都会直接影响最终性能。

课程实战项目总览

本课程以一个“多传感器融合的 L2+ 智能驾驶功能”为主线项目，贯穿 30 个章节。项目假设使用一颗 DRIVE Orin 作为域控制器，接入 1 路前视 8MP 摄像头、4 路环视摄像头、1 个前向毫米波雷达与 1 个 IMU/GNSS 组合定位模块。目标功能包括：车道线检测、车辆与行人检测、毫米波雷达目标融合、车道保持与自适应巡航的简化控制输出。

项目会分阶段推进：先完成 DriveOS 环境搭建与传感器数据接入，再部署感知模型并做 TensorRT 优化，随后实现雷达与视觉的目标级融合，最后在仿真环境中验证端到端延迟与功能逻辑。每个阶段都有可观察的中间结果，例如摄像头帧率、推理延迟、融合后的目标列表、控制指令输出等。这些中间结果就是判断“是否做对”的依据。

平台分层与数据流关系

下图给出 NVIDIA DRIVE 平台的分层结构，以及从传感器到控制输出的主要数据流。它同时标出了开发者最常接触的接口层与关键工具链，便于在后续章节中快速定位自己所在的开发位置。