BEV 与 Transformer 自动驾驶感知方法的统一视角

2026年05月01日

Topic: BEV / Transformer Perception
Keywords: LSS, BEVFormer, PETR, Sparse4D, Occupancy, UniAD, TensorRT

知识图谱

下面这张交互式图谱展示本文涉及的 BEV + Transformer 感知论文之间的演进关系。点击节点可跳转到对应论文笔记；右下角按钮支持缩放、适应窗口和全屏。

🟢 显式 BEV 投影派（LSS / BEVDet / BEVDepth / BEVFusion）
🩵 Query / 隐式 BEV 派（DETR3D / PETR / BEVFormer / Sparse4D / StreamPETR / MapTR 系列）
🟡 上游通用检测（DETR / Deformable DETR）
🔵 占用 / 分割（Mask2Former / OccFormer）
🟣 端到端入口（UniAD，详见 《端到端自动驾驶的范式跃迁与路线之争》）

引言：在脱离单篇论文后重建体系

读完几篇 BEV 论文，再去看 Sparse4D、PETR、Occupancy，很容易陷入一种感觉：每个方法都看懂了，但合在一起又分不清谁解决了谁的问题。论文笔记里记录了大量”做了什么”，却很少串起”为什么这么做”。

本文不再做单篇方法的拆解，而是退后一步，把当前主流的多相机 3D 感知方法放到同一个坐标系下，回答三件事：

  1. 它们在解同一个什么问题？
  2. 各自在哪个维度上做了取舍？
  3. 工程落地时真正卡脖子的是什么？

适合的场景：脉络已经熟了，但碰到一个新方法时仍然要重新理一遍它属于哪条路线、和已有方法差在哪——这篇用来给自己做一次”维度对齐”。

0. 方法全景：三个正交维度与演进时间线

先把全文涉及的方法按”表示 × 几何 × 时序”三个维度铺开，本文剩余章节都是在解释这张图里每一格为什么这么填：

BEV 感知方法的三维度划分

时间线上，三条主线大致是这样并行演进、最终在端到端阶段汇合：

BEV / Transformer 感知方法演进时间线

1. 问题抽象：多相机 3D 感知的三个独立决策维度

把多相机 3D 感知拆开看，本质是回答三个独立的问题：

维度 问题 设计选择
表示（Representation） 用什么数据结构表达世界 Object / BEV / Occupancy
几何（Geometry） 如何把 2D 图像信息对齐到该表示 显式投影 / 隐式 embedding
时序（Temporal） 如何让前后帧保持一致与可预测 Warp / Attention / State

不同论文之所以看起来差异巨大，本质都是在这三件事上做不同组合。一旦把方法套到这张表里，就不会再被”又一个新模块”绕晕。

2. 三条主线：表示 + 几何的组合

2.1 LSS 系：显式几何 + 稠密 BEV

代表：LSS → BEVDet → BEVDepth。

数据流可以一句话概括：

$$\text{image} \xrightarrow{\text{depth}} \text{3D frustum} \xrightarrow{\text{splat}} \text{BEV} \rightarrow \text{task head}$$

关键变量是 depth 分布。每个像素预测一个离散深度概率，与 2D 特征做外积”举”到 3D 视锥体（lift），再按相机参数投影到 BEV 网格累加（splat）。

三代演进的本质

  • LSS：奠定了 lift-splat-shoot 的范式，但 depth 完全靠隐式监督学习，误差较大；
  • BEVDet：把 LSS 工程化（模块解耦 + BEV 数据增强），在 nuScenes 上验证了路线可行性；
  • BEVDepth：把整条 pipeline 里最不稳定的一环——depth——从”猜”变成”教”，引入 LiDAR 的显式深度监督，让 BEV 对齐质量上一个台阶。

路线评价

  • 优点：几何过程可解释，BEV 特征稠密、易于多任务复用；
  • 缺点：depth 误差会沿 image → depth → 3D → BEV 链路被放大，是典型的乘法误差链；
  • 定位：量产主流，工程链路最可控。

2.2 BEVFormer：BEV 空间 query

代表：BEVFormer。数据流：

$$\text{BEV grid query} \xrightarrow{\text{spatial cross-attn}} \text{multi-view image} \rightarrow \text{BEV feature}$$

它不再算 depth，而是让 BEV 网格上每个位置主动去图像里”找”自己的特征——通过相机参数生成参考点，再用 deformable attention 采样。

一个常见分类辨析：BEVFormer 是否属于 query-based

算，但不是 DETR 那种 object query。BEVFormer 的 query 是 BEV grid 上的每个位置（数量级 200×200 ≈ 4 万），表达的是”这个空间位置应该是什么特征”，而不是”图里有哪些物体”。

更精确的分类是：

路线 Query 含义 数量 任务形式
DETR object（语义） ~100 set prediction
BEVFormer BEV grid（空间） ~4 万 dense feature
PETR / Sparse4D object（3D） ~几百 3D set prediction

三者都用 Transformer + query，但 query 的语义和粒度完全不同。

路线评价

  • 优点：表达能力强，几何不依赖深度估计；时序自注意力天然融合历史 BEV；
  • 缺点：dense BEV query × multi-view image 的注意力开销很大，scaling 性较差；
  • 定位：研究友好，工程上常被简化或裁剪。

2.3 Sparse Query 系：对象级稀疏表示

代表：DETR3D → PETR → Sparse4D / StreamPETR。数据流：

$$\text{object query} \xrightarrow{\text{sample image features}} \text{3D object / state}$$

跳过了”建一张完整地图”这一步，直接用一组稀疏 query（几十到几百个）表征潜在物体。

Sparse Query 的三个进化阶段

阶段 代表 Query 含义 关键能力
Detection query DETR3D / PETR 单帧 3D object 跳过 BEV 直接预测 3D box
Tracking query StreamPETR / MOTR 跨帧 track query 跨帧延续，时序稳定
Stateful query Sparse4D 带状态的 object 显式建模位置 + 速度 + 历史

升级路径可以总结为：

$$\text{object} \rightarrow \text{track} \rightarrow \text{state}$$

从单帧目标，到跨帧 ID，再到带速度/加速度的状态向量——本质上越来越像一个可学习的 Kalman Filter（这一点放到 §5 详细展开）。

路线评价

  • 优点：稀疏、scaling 好、贴近下游任务（检测、跟踪、规划）；
  • 缺点：recall 依赖 query 数量与初始化策略，cold start 问题真实存在；
  • 定位：当前学术前沿与端到端方案的主力。

2.4 三条主线的横向对比

维度 LSS 系 BEVFormer Sparse Query 系
表示 稠密 BEV 稠密 BEV 稀疏 object
几何 显式 depth + splat 投影参考点 + attn 投影或 embedding + attn
时序 BEV warp BEV self-attn query 状态传播
工程友好度 高 中 高
表达能力 中 高 高
Scaling 中 较差 较好

3. 几何建模的两条路线：显式投影 vs 隐式编码

主线之外，还有一个常被忽略但很关键的维度：3D 位置信息是”算”出来的，还是”学”出来的？

3.1 Projection-based（显式几何）

代表：BEVFormer、DETR3D。直接利用相机内外参把 query 投影到图像平面，再做采样。

  • 几何约束强，几何关系可解释；
  • 对标定误差敏感——震动、温漂、安装偏差都会让多视角对齐崩坏；
  • 跨车型、跨标定迁移困难。

3.2 Embedding-based（隐式几何）

代表：PETR。把 3D 坐标通过 MLP 编码成 positional embedding，注入 2D 特征里，让网络自己学如何对齐。

  • 几何约束弱，但泛化更好；
  • 对标定不那么敏感，更容易跨设备部署；
  • 表达力依赖于 embedding 设计。

3.3 两条路线的本质区别

路线 本质
Projection 算位置
Embedding 学位置

这条暗线决定了一个方法能否优雅地处理跨车型、跨标定的部署问题，是 BEV Transformer 设计中独立于”表示选择”的另一维度。

4. 表示层级的演进：Object → BEV → Occupancy

表示 代表 特点
Object Sparse4D 稀疏、语义强、面向任务
BEV BEVFormer / LSS 空间结构清晰，便于多任务共享
Occupancy OccFormer 及后续 不依赖类别定义，更接近物理世界

Occupancy 为什么重要

它把问题从”那是辆什么车”退回到更原始的”那块空间是否被占用”：

$$\text{predict space, not objects}$$

这一退反而补上了基于类别的检测器面对异形 / 未见过物体时的兜底能力——翻倒的货车、散落的纸箱，都不必先识别成某个已知类别。再加一个时间维，”未来 T 秒这个空间是否会被占用”就是 4D Occupancy / Occupancy World Model 的雏形。

可以把这三层看作表达世界的不同抽象粒度：object 最稀疏、最贴任务；BEV 居中；occupancy 最稠密、最接近物理。

5. 时序建模的三种范式

时序部分常常被论文一笔带过，但它是 demo 与量产之间最大的鸿沟之一。

5.1 Warp：工程主流

$$\text{prev BEV} \xrightarrow{\text{ego motion}} \text{aligned BEV at } t$$

代表：BEVDet4D。用自车位姿把上一帧 BEV 特征几何对齐到当前帧。

  • 计算开销极低；
  • 几何稳定，不依赖学习；
  • 是大多数量产线的默认选项。

5.2 Attention（Memory）：BEVFormer / StreamPETR

把历史特征（BEV feature 或 query）存到 memory 里，用注意力融合。表达更强，但有几个隐性问题：

  • memory 存的是 feature，没有物理意义；
  • attention 不区分 1 帧前还是 10 帧前，时间是隐式的；
  • 长时间遮挡时容易漂移。

5.3 State Propagation：Sparse4D 的本质升级

不传特征，传带状态的 query——位置、速度、尺寸、朝向、历史 embedding 一起携带。每一帧做的不是 attention 融合，而是”predict + update”：

  • Predict：用上一帧 state 加速度推一步，得到先验位置；
  • Update：用当前图像观测做修正，更新状态。

这个范式可以直接类比 Kalman Filter，但扩展到非线性、非高斯、且观测来自高维图像特征——一个可学习的 Kalman Filter。

Memory 与 State 的本质差别

能力 Memory（attention） State（Sparse4D）
表达 feature 物理量（位置/速度）
时间 隐式 显式
运动建模 无 有
遮挡处理 弱 强
可解释性 低 高

直观比喻：memory 在”记过去”，state 在”推未来”。前者只会说”它刚才在那儿”，后者会说”它在以 10 m/s 往前开，所以现在应该在这儿”。

三种范式横评

范式 传递的对象 类比 适用场景
Warp 几何对齐的特征图 坐标变换 量产、低算力
Attention 历史特征 加权融合 dense 表达 + 中短时序
State 物体状态向量 滤波器 sparse 表达 + 长时序 / 遮挡

5.4 与经典 Kalman Filter 的本质差异

经典 Kalman 把”感知”和”跟踪”完全切开：检测器单帧出框，Kalman 单独做数值滤波。两个模块的误差不能互相回传，整体不是端到端。Sparse4D 的真正提升不在”替代 Kalman”，而在三件事一起做到了：

  1. 观测更强：观测不再是 bbox 中心，而是高维图像特征，attention 自动挑可信区域；
  2. 动态模型更真实：转移函数是网络学出来的，不再被”匀速 + 高斯”假设限制；
  3. 可端到端优化：检测损失、轨迹一致性、速度约束统一回传，模型自己学”什么时候该信观测、什么时候该信预测”。

代价是它失去了 Kalman 在”分布外场景”下的强先验保证——这是学习方法共同的脆弱点。

6. 多任务统一：query 的语义升级

UniAD 之后，”query”的含义又变了一次：不再只是 object 或 BEV grid，而是任务导向的载体——detection / map / track / motion / planning 各有自己的 query，并通过 attention 互相读写。

detection query  ──┐
map query        ──┼──► shared attention ──► planning
motion query     ──┤
track query      ──┘

这一步的意义在于：感知—预测—规划真正在同一个可微分网络里流动，过去模块化 pipeline 中的”信息瓶颈”被打通，是端到端路线的真正起点。沿这条线进一步发展的 SparseDrive 系列干脆把 BEV 也砍掉，让任务 query 直接在稀疏表示上互相读写。

6.1 在线矢量化建图：从栅格分割到 polyline query 的四步演进

在多任务统一的语境里，地图（map）是和检测、跟踪并列的一类 query。它的演进史是 BEV+Transformer 时代最干净的一条范式跃迁线，正好串起本文反复强调的”表示 → 几何 → 监督”三件套：

HDMapNet (2022)  →  VectorMapNet (2023)  →  MapTR (2023)  →  MapTRv2 (2024)
栅格 + DBSCAN     端到端栅格→矢量          一次性并行            +四把斧
                  (DETR + 自回归生成)        polyline query        (解耦+o2m+密集+3D)
阶段 关键洞察 代价
HDMapNet 三分支（语义+实例+方向）让 BEV 分割可启发式向量化；MLP 视图变换替代 IPM/LSS 后处理 pipeline 长，DBSCAN 失败模式难追溯
VectorMapNet 跳过栅格中介，DETR-style 关键点检测 + 自回归 polyline 生成（离散 200×100 token） 自回归推理串行，仅 2.9 FPS
MapTR 置换等价建模消除点序歧义；分层查询（实例 × 部件因子化）+ 分层匹配；一次前向并行预测 polyline 一对一匹配收敛慢、全局 self-attn 显存高
MapTRv2 解耦自注意力（$O(N^2 + N_v^2)$）+ 辅助一对多匹配（GT × K=6）+ 密集监督（depth/PV seg/BEV seg）+ centerline / 3D 扩展 训练显存翻倍（19 GB），但推理无代价

值得记住的几个跨论文规律：

  • “绕过中间表示”是这条线的主旋律：HDMapNet 还需要 DBSCAN，MapTR 把后处理彻底删掉，与 DETR 当年绕过 NMS 是同构动作；
  • 稀疏 query 的两难：一对一匹配收敛慢、显存高（MapTR 的瓶颈），MapTRv2 用”一对多匹配 + 密集监督 + 解耦注意力”组合拳化解，这套配方对所有 DETR-like 任务都通用；
  • 置换等价建模的可迁移性：任何”有序点集”的几何任务（路径、骨架、轮廓）都存在点序模糊问题，MapTR 的”置换组 + 最优匹配选择”是通用模板；
  • 矢量化建图直接喂到端到端规划：VAD / SparseDrive 等工作都把 MapTR/MapTRv2 的输出当作可微分的”地图 query”，进一步验证了 §6 的”任务 query 互相读写”模型。

把这条线加进来后，§6 的”detection / map / track / motion / planning query 在同一个 attention 中流动”才是完整的图——map query 不是抽象口号，而是已经被 MapTR 系列实现得很扎实的一类具体 query。

关于 planning query：UniAD → VAD/VADv2 → SparseDrive → DiffusionDrive 这条端到端规划路线已经超出 BEV 感知范畴，单独成文。详见 《端到端自动驾驶的范式跃迁与路线之争》，其中”评分派 vs 生成派”的对比与本节的”任务 query 互相读写”模型互为镜像。

7. 多传感器融合：工业现实

学术上纯视觉路线热度很高，但工业落地的主流仍是 camera + LiDAR，融合方式以 BEV 级融合为主（BEVFusion 是范式代表）：

  • LiDAR 提供准确深度，弥补视觉的几何不确定性；
  • Camera 提供语义和远处细节；
  • BEV 是两者天然的公共坐标系，比 early fusion 更工程友好。

这条路线的存在提醒我们：纯视觉方法的 SOTA 数字与可量产方案之间，还隔着一个”传感器现实”。

8. 工程落地：TensorRT 视角下的真问题

模型结构画在 PPT 上很美，但部署时遇到的瓶颈几乎都不在 backbone（backbone 直接 ONNX → TensorRT 即可），而在两类访存算子上。

8.1 两类难算子

类型 代表算子 难点
Gather（读） grid_sample 随机访存，cache miss
Scatter（写） bev_pool / voxel_pool 写冲突，需要 atomicAdd

一个核心结论：

Scatter 比 Gather 难优化得多。

读可以靠 cache 和 prefetch 缓解；写冲突几乎只能靠重组数据结构来回避。

8.2 LSS 系的部署瓶颈：scatter

核心算子是 voxel pooling / bev_pool。

朴素实现的问题

直接 atomicAdd(&bev[idx], val)：

  • 多线程写同一个 voxel index → warp 串行化；
  • 数据分布不同 → latency 抖动严重；
  • 完全随机写 → cache 几乎失效。

工业级解法：sort + segment reduce

1. 计算每个像素对应的 BEV index
2. flatten 成 (num_points,)
3. 按 BEV index 排序（thrust / radix sort）
4. 同 index 段内做 segment reduce

把”随机写”变成”分段连续写”，没有 atomic，性能稳定。代价是多一次 sort，但通常是值得的。

其他配套优化

  • camera projection 在 init 时预先算好，避免 runtime 大量矩阵运算；
  • 把 depth softmax → lift → projection → accumulate 融合成单 kernel；
  • NHWC 布局更利于 coalesced 访存。

8.3 BEVFormer 的部署瓶颈：deformable attention + grid_sample

算子层面

  • ONNX 的 GridSample 在旧版 TensorRT 不支持，新版本性能也差；
  • Deformable attention TensorRT 完全不支持，必须自己写 plugin；
  • bilinear sampling 的 4 个角点都是随机访存，cache 命中率低。

系统层面

  • BEV query 数量级 4 万 × N 相机 × K 采样点 → 计算量爆炸；
  • attention 对数值精度敏感，INT8 calibration 难做。常见折中是 backbone INT8 + attention FP16；
  • multi-view × multi-scale 的组合让显存与延迟同时上去。

落地策略

  • query 分块（tile）处理；
  • 投影点 base 部分预计算，runtime 只加 offset；
  • 把 sampling + weight multiply + reduce 融合到单个 kernel。

8.4 部署架构中的典型分工

这也部分解释了为什么量产线更偏好 LSS 系或 sparse query 系——不是它们更准，而是它们更可部署。一个常见的工业组合是：backbone + 大部分子图走 ONNX → TensorRT，少数关键算子（voxel pooling 或 deformable attention）写成自定义 plugin。

9. 被低估的部署陷阱：Train / Inference Gap

  • 训练：full sequence，可以并行处理整段时序；
  • 推理：streaming，每来一帧只能基于历史状态推一次。

二者之间的 gap 体现在：

  • BN 统计量在长序列与单帧上分布不一致；
  • 时序 query 在训练时往往用 GT 初始化，推理时只能 cold start；
  • 记忆队列的长度、warm-up 帧数等超参影响巨大。

Sparse4D 与 StreamPETR 的很多 trick，本质都是在弥合这个 gap。如果只看 nuScenes 分数而忽略它，部署时性能掉点几乎是必然的。

10. Scaling：量产部署的硬约束

方法 表示密度 Scaling 表现
BEVFormer dense BEV query 较差
LSS 系 dense BEV feature 中等
Sparse4D / StreamPETR sparse query 较好

输入分辨率、帧数、相机数翻倍时，三者的计算量增长曲线完全不同。这是 sparse query 路线在过去两年快速占据主导的根本原因之一——能不能上车，scaling 是先于精度的硬约束。

11. 统一抽象：Query–Sampling–Aggregation 三步范式

把所有上述方法压到最简形式，本质都可以写成：

$$\text{Output} = \text{Aggregation}\big(\text{Sampling}(\text{Query}, \text{Image features})\big)$$

这条公式背后的结构图：

Query–Sampling–Aggregation 统一抽象结构图

差异只在于 Query 是什么、Sampling 怎么做：

方法 Query Sampling Aggregation
LSS 系 pixel→frustum（隐式） depth × feature 外积 scatter / bev_pool
BEVFormer BEV grid projection + deformable attn attention 加权
PETR object 3D PE embedding lookup global attention
Sparse4D / StreamPETR object + state 4D 关键点 deformable attn attention + 时序传播
OccFormer voxel mask attention masked aggregation

理解这一点之后，再看一篇新论文，可以直接定位它在这张表里换了哪一格——通常就是它真正的贡献。

12. 向端到端与世界模型的延伸

上面这套抽象不仅适用于感知本身，对理解近一年的端到端与世界模型路线也成立——它们没有推翻这套框架，而是在 Query 这一格上继续做文章。

12.1 SparseDrive 系：把 query 升级成”任务载体”

  • UniAD 还保留 BEVFormer 作为 BEV 编码器，query 是任务级的（det / map / motion / plan），但底层依赖 dense BEV；
  • SparseDrive 直接砍掉 BEV，把整个端到端栈都搭在 sparse query 上——感知 query、地图 query、规划 query 在同一组稀疏表示里互相读写；
  • SparseDriveV2 进一步把规划 query 拆成 path query × velocity query 的笛卡尔积（10⁵ 量级候选），再用粗到细的层级评分筛选，把”生成 vs 评分”的路线之争推到了一个新高度。

本质上，这条线就是把 §2.3 的 sparse query 从感知层一路延伸到规划层——同一种数据结构贯穿全栈。

12.2 Occupancy → 4D 世界模型：把表示拓展到时间

  • §4 的 Occupancy 是”3D 静态空间是否被占用”，属于表示层级的扩张；
  • 加一个时间维 → “未来 T 秒这个空间是否会被占用” → 4D Occupancy / Occupancy World Model 雏形；
  • 进一步把动作（自车规划）作为条件输入，让模型在 latent 空间里预测未来 occupancy → 可交互的世界模型。

这条路线最大的意义是：规划不再只面对当前帧的检测结果，而是可以在 预测出的未来场景 上做评估。

12.3 三条主线的延伸一览

起点 延伸路径 当前前沿
LSS / BEV BEV → 多模态融合 → 端到端 BEVFusion → UniAD
Sparse query object → state → task query StreamPETR / Sparse4D → SparseDrive(V2)
Occupancy 3D occ → 4D occ → world model OccFormer → Occ World Model / VLA

13. 方法本质速记

LSS / BEVDet：先把世界算出来
BEVDepth：把最不稳的那一环（depth）钉死
BEVFormer：在 BEV 空间学会找信息
PETR：跳过几何，让网络自己学位置
Sparse4D：跳过地图，给每个对象建一个状态
StreamPETR：让 query 跨帧活下去
Occupancy：不问是什么，只问占没占
UniAD：让感知-预测-规划在 query 里流动
SparseDrive：把 sparse query 一路打通到规划
世界模型：让网络在脑海里预演未来

14. 从论文到算子：实践路径建议

在脉络体系成型之后，进一步的技术突破往往不再来自阅读量，而是来自对单个核心算子的深入掌握。以下是性价比较高的几个入口：

  • 手写一版 voxel pooling 的 CUDA kernel，对比 sort + segment reduce 与 atomicAdd 的性能差异；
  • 实现一遍 deformable attention，定量分析 grid_sample 在不同硬件上的实际瓶颈；
  • 复现 StreamPETR / Sparse4D 的 query 状态传播，完整复现训练-推理 gap 的调优过程；
  • 以开源 BEVFormer 为起点，走一遍 ONNX → TensorRT 的完整部署流程，系统性梳理每个失败点。

在这个阶段：吃透一个算子 > 多读十篇论文。

15. 结语：核心矛盾在表示与实现，而不在模型结构

回头看这一整篇文章，会发现 BEV 与 Transformer 感知方法的演进有一条很清晰的内在逻辑：**模型结构本身一直在收敛（都是 Transformer + 可微采样），真正分化的是”用什么形式表达世界”以及”如何让这种表达在硬件上跑起来”**。

  • 在表示上，方法从 dense BEV 走向 sparse object，又向 occupancy 拓展，最终在端到端框架里以 task query 的形式整合；
  • 在几何上，从 LSS 的硬投影，到 BEVFormer 的可微采样，再到 PETR 的隐式编码，约束越来越弱、可学习成分越来越多；
  • 在时序上，从单帧 detection，到 memory-based attention，再到带状态的 stateful query，越来越像一个学习版的 Kalman Filter；
  • 在部署上，瓶颈从模型结构转移到 scatter / gather 算子，scaling 性而非单点精度成为能否上车的硬约束。

如果只能记住一句话：

当前 BEV 感知的核心问题不是模型结构，而是用有限的表示去表达真实世界，并且在硬件上高效实现。

把握住这条主线，再看任何一篇新论文，都可以快速判断它在”表示 / 几何 / 时序 / 部署”这四个维度上具体动了哪一格——而通常那一格就是它真正的贡献所在。