2. 自动驾驶感知与推理基础

自动驾驶不是单一模型的“端到端黑箱”，而是一条从传感器到执行器的实时闭环链路。理解推理引擎的性能问题，必须先看清它在整车计算平台中的位置：它既不是传感器驱动，也不是规划控制，而是把感知模型“算出来”的那一层。推理引擎的效率，直接决定了感知结果能否在几十毫秒内送达下游模块。

一、自动驾驶系统架构：从感知到执行的五层链路

典型的自动驾驶系统可划分为五层：传感器层（摄像头、激光雷达、毫米波雷达、IMU、GNSS）、数据预处理层（时间同步、去畸变、坐标变换、ROI裁剪）、感知推理层（检测、分割、跟踪、融合）、预测与规划层（轨迹预测、行为决策、路径规划）、控制执行层（油门、刹车、转向）。推理引擎位于第三层，是整条链路中计算密度最高、时延最敏感的部分。

从数据流角度看，传感器产生的是原始帧或点云，预处理后变成张量或体素；推理引擎加载模型权重，执行前向计算，输出检测框、语义掩码、目标ID等结构化结果；这些结果再被跟踪与融合模块消费，形成稳定的环境模型。推理引擎的输入输出边界清晰，但它的性能波动会沿着链路向下游放大。

二、感知任务类型：推理引擎要“算”什么

感知任务决定了推理引擎的负载特征。常见任务包括：

• 2D/3D目标检测：输出边界框与类别，如YOLO、CenterPoint、BEVDet。计算以卷积和矩阵乘为主，对吞吐敏感。
• 语义分割：逐像素分类，如可行驶区域、车道线。输出分辨率高，后处理开销大。
• 实例分割：在分割基础上区分个体，常用于障碍物轮廓提取。
• 多目标跟踪：依赖检测结果做数据关联，如Kalman滤波、匈牙利匹配，计算量小但时序依赖强。
• 多传感器融合：将摄像头、激光雷达、毫米波结果对齐融合，如BEV融合、后融合。涉及坐标变换与特征拼接。

不同任务对推理引擎的要求不同：检测任务追求低时延高帧率，分割任务追求高分辨率下的显存效率，融合任务追求多输入流之间的同步与调度。调优时不能只看单一模型的延迟，而要看整条感知流水线的端到端表现。

三、推理引擎在车载计算平台中的位置与作用

车载计算平台通常由SoC（如Orin、地平线J5、Mobileye EyeQ）、GPU/NPU、DSP、MCU组成。推理引擎是运行在SoC上的软件层，负责：模型加载与图优化、算子调度与内存分配、多流并发与优先级管理、量化与精度校准。它向下对接硬件加速器，向上为感知算法提供统一的推理API。

以某L2+量产项目为例，感知流水线包含1个BEV检测模型、1个车道线分割模型、1个毫米波后融合模块。在Orin平台上，推理引擎需要同时管理3个计算流，并保证BEV检测的优先级最高。若引擎调度不当，分割模型的长尾延迟会阻塞检测流，导致整体帧率从30fps掉到22fps。

四、案例与场景：一次典型的推理性能问题

某项目在实车测试中发现：低速跟车时感知正常，但高速场景下偶发目标丢失。日志显示推理引擎的P99延迟从18ms飙升到45ms。排查后发现：高速场景下激光雷达点云数量增加，预处理后的体素张量尺寸变大，而推理引擎的显存池未做动态扩容，导致频繁的显存分配与拷贝。调整显存池策略并启用算子融合后，P99延迟回落到21ms。

# 推理引擎关键配置示例（伪代码）
inference_engine:
  model: bev_detection_v3
  precision: int8
  max_batch: 1
  stream_priority: high
  memory_pool:
    mode: dynamic
    initial_size: 512MB
    max_size: 1024MB
  operator_fusion: true
  fallback_to_fp16: ["DeformConv", "NMS"]

五、常见误区与复盘

理解推理引擎在车载计算平台中的位置，是后续性能分析与调优的起点。它上承感知算法，下接硬件加速器，中间还涉及内存、调度、量化等多重因素。只有把这条链路看清楚，才能在面对延迟、吞吐、精度问题时，快速找到真正的瓶颈所在。