2. 自动驾驶感知模型概览

自动驾驶感知系统要在车端实时回答三个问题：有什么（目标检测与分类）、在哪里（定位与测距）、空间是否可通行（占据与语义）。不同代际的模型结构正是围绕这三个问题演进的。理解它们的结构差异、计算特性和部署约束，是后续做中间表示（IR）转换与跨平台部署的前提。

一、四类主流结构的核心原理

CNN 系列是感知的基石。以 ResNet、RegNet 为骨干，通过卷积核在局部感受野上提取特征，配合 FPN 做多尺度融合，再接入检测头（如 CenterPoint、YOLO 系列）或分割头。其核心优势是局部性、平移等变性、权重共享，计算规整、算子成熟，对量化与定点化友好，是当前量产部署的主力。

Transformer 系列引入自注意力机制，用 Query-Key-Value 计算全局依赖。在感知中常见两种用法：一是作为骨干（如 ViT、Swin）替代 CNN；二是作为检测头（DETR、DINO），用可学习 Query 直接输出目标集合，省去 NMS 后处理。其优势是全局建模能力强、输出端到端；代价是注意力矩阵随 token 数呈平方增长，且包含 Softmax、LayerNorm、GELU 等对量化不友好的算子。

BEV（Bird's Eye View）系列解决的是多相机到统一俯视空间的转换。典型流程是：多路环视图像经骨干提特征，通过 LSS（Lift-Splat-Shoot）或 BEVFormer 的时空注意力，将图像特征投影到自车坐标系下的 BEV 网格，再在 BEV 特征上做检测、分割与预测。BEV 让多传感器在统一空间对齐，是规划控制模块可直接消费的表示。

Occupancy 系列进一步把空间离散为三维体素，预测每个体素的占据概率与语义类别（如 Occupancy Network、TPVFormer）。它不依赖预定义的目标框，能表达任意形状的障碍物与可通行区域，特别适合处理异形车辆、施工区域、散落物等长尾场景。代价是三维体素分辨率与显存、算力直接挂钩。

自动驾驶感知模型结构演进与部署特征 CNN 卷积网络 Backbone: ResNet / RegNet FPN 多尺度融合 检测头 + NMS 局部感受野 · 权重共享 算子规整 · 量化友好 Transformer ViT / Swin 骨干 Q-K-V 自注意力 DETR 式集合输出 全局依赖 · 端到端 Softmax/LayerNorm 难量化 BEV 鸟瞰视图 多相机图像输入 LSS / 时空注意力投影 BEV 网格检测/分割 统一自车坐标系 规划控制可直接消费 Occupancy 占据 3D 体素离散化 体素级语义预测 任意形状障碍表达 不依赖预定义框 显存/算力随分辨率增长 模型规模与计算特性 参数量：CNN 10M~80M；ViT-L 约 300M；BEV 常 50M~200M 计算量：CNN 数十~数百 GFLOPs；BEV/Occupancy 常超 500 GFLOPs 访存：注意力与体素采样访存密集，常成车端瓶颈 时延：端到端需 < 100ms，单帧预算通常 30~50ms 车端部署约束 算力：Orin 约 254 TOPS，Thor 更高，但仍需精打细算 功耗与散热：整芯片功耗受限，持续高负载会降频 精度：INT8 为主，部分算子需 FP16 或回退 FP32 算子支持：自定义算子、动态 shape 常导致部署失败

二、模型规模与计算特性的量化对比

把结构差异落到数字上，才能判断部署可行性。下表给出典型配置的量级参考（具体数值随版本与输入分辨率变化）：

结构类型 典型代表 参数量级 单帧计算量 主要瓶颈 量化友好度
CNN ResNet-50 + FPN 20M~40M 50~150 GFLOPs 卷积算力 高
Transformer ViT-L / DETR 100M~300M 200~600 GFLOPs 注意力访存 中低
BEV BEVFormer / LSS 50M~200M 300~800 GFLOPs 投影与采样 中
Occupancy OccNet / TPVFormer 80M~250M 500~1500 GFLOPs 3D 体素显存 中低

三、部署约束分析：从模型到车端的四道关卡

  1. 算力关卡：车端 SoC 的 TOPS 是峰值，实际有效算力受内存带宽、调度效率影响，通常只能发挥 30%~60%。BEV 与 Occupancy 的采样、投影算子往往无法打满算力。
  2. 精度关卡：INT8 量化对卷积友好，但 Softmax、LayerNorm、GELU、Sigmoid 等非线性算子量化误差大，常需保留 FP16 分支，形成混合精度图。
  3. 算子关卡：自定义算子（如可变形注意力、体素池化）在部分推理引擎中缺失，需要算子拆分或自定义实现，是跨平台部署最常见的失败点。
  4. 动态形状关卡：多相机输入数量、BEV 网格尺寸、体素分辨率若为动态，会导致编译期无法确定内存，需在 IR 阶段固化或分档。
常见误区：只看参数量判断模型轻重。实际上 BEV 与 Occupancy 的参数量可能不大，但中间特征图与采样操作带来的访存和显存开销远超同参数量的 CNN。部署评估必须同时看 FLOPs、访存量、峰值显存与算子支持度。

四、案例场景：城市 NOA 的感知栈组合

一个典型的城市 NOA 感知栈会组合多种结构：环视相机经 CNN 骨干提特征，用 BEV 模块投影到统一俯视空间，在 BEV 特征上跑检测与车道线分割，同时用 Occupancy 分支输出三维占据栅格，供规划模块判断可通行区域。此时部署约束体现为：

输入：6~11 路相机，分辨率 1920x1080 或 1280x720
骨干：CNN（INT8）→ 特征图 1/8、1/16、1/32
BEV：网格 200x200，通道 256，需 FP16 投影
Occupancy：体素 200x200x16，语义 16 类
时延预算：感知总时延 < 80ms
显存预算：< 4GB（含多帧缓存）
量化策略：卷积 INT8，注意力与 Softmax FP16

可以看到，模型结构的选择直接决定了 IR 需要表达什么：CNN 需要表达卷积、BN、激活的融合；Transformer 需要表达注意力与归一化；BEV 需要表达投影与网格采样；Occupancy 需要表达三维体素与稀疏操作。这正是后续中间表示设计要覆盖的算子集合。

复盘要点：评估一个感知模型能否上车，建议按“结构类型 → 参数量/FLOPs → 访存与显存 → 算子支持 → 量化误差 → 时延实测”的顺序逐层筛查。任何一层不通过，都要回到模型结构或 IR 转换策略上做调整，而不是等到板端实测才发现问题。

综上，CNN、Transformer、BEV、Occupancy 并非互相替代，而是按任务层次组合使用。理解它们的结构本质与计算特性，才能在中间表示与跨平台部署中做出正确的取舍：哪些算子必须原生支持，哪些可以融合，哪些需要降精度或拆分。这是第 2 章要建立的核心判断力。

← 上一章 📖 返回目录 下一章 →