1. 课程导入

自动驾驶系统本质上是一台在车轮上持续运行的实时推理计算机。摄像头、激光雷达、毫米波雷达以每秒数十帧的频率产生数据，感知、预测、规划、控制等模型必须在几十毫秒内完成一轮推理，并把结果交给下游模块。任何一次推理延迟抖动，都可能被放大为刹车距离、转向时机上的偏差。因此，推理引擎性能优化不是“让模型跑得快一点”的锦上添花，而是决定自动驾驶功能能否安全落地的工程底座。

本课程面向已经具备一定深度学习与系统编程基础、希望把模型真正部署到车端并压榨出每一毫秒性能的工程师。我们将从推理引擎的运行时结构出发，逐层深入到算子、内存、调度、量化、编译与硬件协同，最终形成一套可复用的性能优化方法论。

一、学习目标：从“能跑”到“跑得稳、跑得省”

完成本课程后，你应当能够独立完成以下任务：

• 定位瓶颈：使用 profiling 工具区分计算瓶颈、访存瓶颈、调度瓶颈与同步瓶颈，而不是凭感觉调参。
• 理解引擎：说清一次推理从输入张量到输出张量，在运行时中经历了图调度、算子执行、内存分配与流同步的完整链路。
• 优化算子：针对卷积、矩阵乘、归一化、激活等高频算子，理解其计算密度与访存模式，并能选择合适的融合与实现策略。
• 压缩模型：掌握量化、剪枝、蒸馏在车端推理中的收益边界与精度代价，能设计可回退的量化方案。
• 协同硬件：理解 GPU、NPU、DSP 等异构算力的调度约束，能设计多流并行与算子卸载策略。
• 保障实时：建立延迟、吞吐、抖动、功耗、内存占用五维指标意识，能对端到端时延做预算分解。

二、核心概念：推理引擎到底在做什么

推理引擎是连接“训练好的模型”与“车端硬件”的中间层。它接收模型文件（如 ONNX、TorchScript 或自定义格式），经过图优化、算子选择、内存规划与代码生成，最终在目标硬件上执行。理解它，需要抓住四个核心概念。

计算图与算子：模型被表示为有向无环图，节点是算子，边是张量。优化往往从图层面开始，例如常量折叠、算子融合、死代码消除。算子融合是收益最直接的手段之一，把 Conv + Bias + ReLU 合并为一个内核，可以减少中间张量的读写。

内存与数据布局：车端推理的瓶颈常常不在算力，而在访存。NCHW 与 NHWC 的选择、张量对齐、内存复用、零拷贝共享，都会显著影响带宽利用率。一个典型的误区是只盯着 FLOPs，却忽略了每次算子执行背后的内存搬运成本。

调度与并行：推理引擎需要把算子分配到不同计算单元，并管理 CUDA Stream、NPU 队列或 CPU 线程池。多流并行能让感知模型与预测模型重叠执行，但也会引入同步开销与资源竞争。

精度与量化：FP32、FP16、INT8 甚至 INT4 的选择，直接决定算力利用率和内存占用。量化不是简单地把权重转成整数，而是需要校准、误差分析与逐层回退机制。

三、整体知识框架与实战路线图

本课程的知识框架可以概括为“一条主线、四个层次、五类指标”。主线是端到端推理延迟；四个层次分别是模型层、图与算子层、运行时层、硬件层；五类指标是延迟、吞吐、抖动、功耗与内存。下面的 SVG 展示了这一框架以及各模块之间的依赖关系。

实战路线图建议按“先建立基线，再逐层下钻”的顺序推进。第一步，搭建可复现的 profiling 环境，记录端到端延迟与各模块耗时；第二步，从图与算子层入手，做融合、布局转换与内核替换，通常能拿到第一波收益；第三步，进入运行时层，优化内存分配、多流调度与批处理策略；第四步，结合硬件特性做量化与算子卸载；最后，用端到端回归测试验证精度与实时性。

四、典型场景与常见误区

以一个典型的城市 NOA 场景为例：BEV 感知模型、时序融合模型、预测模型与规划模型串联运行，端到端预算约 100 ms。若感知模型单帧耗时 45 ms，其中卷积占 60%，那么仅靠算子融合与 INT8 量化，就可能把感知耗时压到 25 ms 以内，为下游留出更多余量。

但实践中常见三类误区。第一，只看平均延迟，不看 P99 抖动。车端最怕的是偶发卡顿，平均 30 ms 但 P99 达到 120 ms 的引擎，比稳定 50 ms 的引擎更危险。第二，盲目量化。对检测头或小目标分支做激进量化，可能造成召回率明显下降，必须逐层评估。第三，忽略数据搬运。很多“算力充足”的芯片，实际瓶颈是 HBM 带宽或 L2 缓存命中率，优化方向应从计算转向访存。

接下来的章节将沿着上述框架逐层展开：先讲清楚推理引擎的运行时结构与 profiling 方法，再进入算子优化、内存优化、量化与编译，最后落到多模型协同与端到端实时性保障。每一节都会给出可操作的参数、命令与判断依据，帮助你把这套方法论真正用到自己的项目里。