📄 论文信息
- 标题：SparseDrive V2: Fully Sparse End-to-End Autonomous Driving
- 方向：全稀疏（Fully Sparse）端到端自动驾驶
- 一句话总结：用一组稀疏查询（sparse queries）把检测、跟踪、在线建图、运动预测、规划全部串起来，彻底抛弃稠密 BEV 特征图，在大幅降低计算量的同时把规划性能推到第一梯队。
🤔 要解决什么问题？稠密 BEV 的算力原罪
在 UniAD 之后，显式端到端几乎成了自动驾驶学术界的默认范式。但无论是 UniAD 还是 VAD，它们都建立在一个昂贵的地基上——稠密的 BEV（Bird’s Eye View）特征图。
典型流程是：先把环视多相机图像通过 LSS（Lift-Splat-Shoot）或 BEVFormer 之类的视角变换压成一张俯视图，再用这张稠密俯视图去做检测、建图、预测、规划。这套范式有效，但有个致命缺点：
| 痛点 | 原因 | 后果 |
|---|---|---|
| 计算量随分辨率平方爆炸 | BEV 特征图是 $H \times W$ 的网格，注意力/卷积都对它做稠密计算 | GPU 算力和显存吃紧 |
| 大量算力浪费在空白区域 | 真正的目标（车、人、车道线）只占 BEV 的几个像素，其余是天空/地面/空地 | 有效信息密度极低 |
| 时序融合更重 | 多帧 BEV 拼接要对齐、堆叠、做时序注意力 | 延迟进一步上升 |
| 上车部署困难 | 车端 Orin 等芯片跑不动如此重的 BEV backbone | 落地受阻 |
简单说，稠密 BEV 是在用一个 $H \times W$ 的"地毯式搜索"去寻找本就稀疏的几个目标——这在信息论上就是低效的。
SparseDrive 系列的核心拷问是：既然路上有意义的东西（车、人、车道、自车轨迹）本来就稀疏，那为什么中间表示非要稠密？能不能从图像到规划，全程只用一组稀疏的 query？
这就是 全稀疏（Fully Sparse） 范式的出发点。
🌱 从 SparseDrive V1 到 V2：全稀疏的进化
V1：证明"全稀疏可行"
SparseDrive V1 第一次把"全稀疏"做到了端到端全流程。它的贡献是证明可行性：
- 用**稀疏实例查询（instance queries）**做检测和跟踪，每个 query 直接从多相机图像特征里"抠"出一个目标，绕开 BEV。
- 用**稀疏地图查询（map queries）**做在线建图，每个 query 对应一段车道线/边界。
- 把运动预测和规划做成并行双分支，而不是 UniAD 那种串行接力，让自车轨迹和其他车轨迹同时生成。
- 引入数据驱动的锚点（data-driven anchors），用聚类得到先验轨迹作为参考，加速收敛。
V1 已经在 nuScenes 和 NAVSIM 上证明了：不用 BEV，精度不降反升，算力却大幅下降。
V2：把"全稀疏"打磨到工程级
V2 在 V1 的地基上做了一轮系统性打磨，主要进化方向有四条：
| 进化点 | V1 | V2 | 带来的收益 |
|---|---|---|---|
| 检测与下游解耦 | 实例查询直接喂给运动/规划 | 引入更干净的特征隔离，下游任务从独立特征接口取信息 | 下游不再被检测噪声拖累 |
| 质量感知记忆库 | 简单的历史 query 缓存 | 按置信度/质量加权维护跨帧记忆 | 时序更稳，遮挡/截断鲁棒性提升 |
| 前瞻式运动预测 | 以当前位姿为参考 | 显式建模"自车未来位姿"作为预测锚点 | 减少坐标变换误差，轨迹更准 |
| 规划安全设计 | 基本轨迹回归 | 强化碰撞约束与多模态轨迹选择 | 碰撞率进一步下降 |
一句话概括 V2 的定位：V1 是"能不能稀疏"，V2 是"能不能把稀疏做到又准又快又稳"。
💡 核心思想：一组稀疏查询统一一切
SparseDrive V2 的设计哲学可以浓缩成一句话：
从图像到规划，全程只用稀疏 query 作为信息载体，永远不构造稠密的 BEV 网格。
它用两类稀疏查询描述整个驾驶场景：
- 实例查询（Instance Queries）：每个 query 代表一个动态智能体（车、人、骑行者），编码它的类别、位置、速度、历史轨迹，并跨帧保持 ID 连续。
- 地图查询（Map Queries）：每个 query 代表一段静态路网元素（车道线、道路边界、人行横道、停止线），以矢量形式存在。
再加上一个特殊的 自车查询（Ego Query） 代表"我自己这辆车"。这三类 query 构成了对场景的完整稀疏描述：谁在动（实例）、路在哪（地图）、我要怎么开（自车）。
这与 UniAD/VAD 的本质区别在于：UniAD 的 query 是在稠密 BEV 之上"再叠加"的，而 SparseDrive 的 query 是从图像特征直接"抠"出来的，中间根本没有稠密图这一层。
🏗️ 整体架构：全稀疏信息通路
V2 的整体流程是一条全程稀疏、全程可微的通路：
多相机图像 ➜ 图像骨干 + 多尺度特征 ➜ 稀疏实例查询（检测/跟踪） ➜ 稀疏地图查询（建图） ➜ 并行双分支：运动预测 / 规划 ➜ 输出
关键在于：全流程没有任何一张稠密 BEV 特征图，所有任务都在稀疏 query 之间通过注意力交互。下面逐段拆解。
第 1 段：稀疏感知——检测与跟踪
负责从多相机图像里检测目标并跨帧跟踪。
- 输入：多相机图像特征 + 上一帧的实例查询（带记忆）
- 机制：每个实例查询通过**可变形注意力（Deformable Attention）**直接从多相机特征图上采样若干参考点，无需先把特征拼成 BEV
- 输出：当前帧的 3D 检测框 + 更新后的实例查询（保持 ID 连续）
- 亮点：检测的精度与稠密 BEV 方法相当，但计算量只与 query 数量（≈几百）成正比，与 BEV 分辨率无关
V2 还引入了质量感知的记忆库：不是简单把上一帧 query 全部缓存，而是按置信度和跟踪质量加权，让高质量的实例在时序中占更大权重，遮挡和截断场景下的鲁棒性显著提升。
第 2 段：稀疏建图
负责实时矢量化建图——检测车道线、道路边界等。
- 输入：图像特征 + 地图查询
- 输出：矢量化的地图元素（每条线用若干有序点表示）
- 作用：给预测和规划提供结构化道路约束，“车该往哪条车道开”
地图查询与实例查询是对称的：动态目标 + 静态路网，共同构成场景的稀疏骨架。V2 对地图查询的编码做了增强，使长程车道（如弯道、匝道）的拟合更准。
第 3 段：运动预测的稀疏设计
这是 SparseDrive 区别于 UniAD 的关键架构差异。UniAD 是"检测 ➜ 预测 ➜ 规划"串行接力；SparseDrive V2 把运动预测和规划做成并行双分支，共享上游特征但各自独立输出。
运动预测分支对每个实例查询预测未来多模态轨迹：
- 输入：实例查询 + 地图查询（通过交叉注意力让"车"知道"自己被哪条车道约束"）
- 输出：每个智能体的多条候选未来轨迹 + 概率
- 亮点——前瞻式设计：V2 显式地把"自车未来位姿"纳入预测的坐标系参考，而不是用当前位姿。这减少了预测与规划之间的坐标变换误差，因为规划和预测本来就是在"未来坐标系"里对齐的。
运动预测的稀疏性体现在：只对被检测到的几百个实例做预测，而不像稠密方法那样对整个 BEV 网格的未来占用都算一遍。这是算力节省的大头。
第 4 段：规划模块
规划分支拿到自车查询 + 实例查询 + 地图查询，输出自车未来轨迹。
- 输入：自车查询 + 全部实例/地图查询（通过注意力让自车"看到"所有目标和路网）
- 输出：自车未来 waypoints
- 关键设计：
- 用数据驱动的锚点作为轨迹参考（聚类自数据集），模型只需预测相对偏移，收敛快、分布合理
- 强化碰撞约束：把规划轨迹与实例预测轨迹、地图边界一起做几何校验，惩罚可能碰撞的方案
- 多模态轨迹选择：生成多条候选轨迹，结合舒适性、合规性、安全性打分选出最优
值得注意的是，规划分支与运动预测分支共享上游特征但独立输出，这意味着自车轨迹不依赖其他车的轨迹预测结果——避免了"预测错了 ➜ 规划跟着错"的误差级联，两条分支可以并行推理，延迟更低。
全流程总结
| 模块 | 输入 | 输出 | 是否稠密 | 角色 |
|---|---|---|---|---|
| 感知（检测/跟踪） | 图像特征 + 实例查询 | 实例查询 | 全稀疏 | “周围有谁” |
| 建图 | 图像特征 + 地图查询 | 地图查询 | 全稀疏 | “路怎么走” |
| 运动预测 | 实例 + 地图查询 | 多模态轨迹 | 全稀疏 | “别人会怎么动” |
| 规划 | 自车 + 实例 + 地图查询 | 自车轨迹 | 全稀疏 | “我该怎么开” |
⚡ 为什么稀疏能赢？算力对比
SparseDrive V2 最大的卖点不是"精度第一"，而是**“精度不输甚至更好，算力却低一个数量级”**。稀疏取胜的逻辑可以拆成三笔账：
| 对比维度 | 稠密 BEV 方法（UniAD 等） | SparseDrive V2 |
|---|---|---|
| 注意力复杂度 | 与 BEV 像素数 $H \times W$ 相关（往往上千） | 仅与 query 数量相关（≈几百） |
| 时序融合开销 | 多帧 BEV 对齐拼接，重 | 只需缓存历史 query，轻 |
| 有效信息密度 | 大量算力花在空区域 | 算力全部花在有意义的目标上 |
| FLOPs | 高（数倍于 V2） | 显著更低 |
| 推理延迟 | 难以实时 | 更接近车端实时部署 |
| 显存占用 | 大 | 小 |
更关键的是，稀疏表示的天花板更高：当大家想提升精度时，稠密方法只能堆 BEV 分辨率（算力平方级增长），而 SparseDrive 只需增加少量 query（算力线性增长），扩展性（scaling）天然更优。这一点和 DETR 之于传统检测、大模型里稀疏 MoE 的思路是一脉相承的——用稀疏换效率，用效率换规模。
📊 实验结果：又准又快
SparseDrive V2 在三大主流基准上全面验证了全稀疏路线。
nuScenes：规划与感知双优
在 nuScenes 规划任务上，V2 在 L2 误差和**碰撞率（Collision Rate）**两个核心指标上达到第一梯队，碰撞率尤其低，说明安全性出色。同时检测（NDS）、跟踪（AMOTA）等感知指标也保持竞争力，证明全稀疏不损失感知能力。
NAVSIM：规划专用基准的强表现
NAVSIM 是更接近真实驾驶评分的规划基准（含无碰撞、可行驶方向、舒适性等多维度指标）。V2 在其上表现优异，尤其在符合导航指令、保持车道、平顺性等子项上领先，体现了稀疏地图查询 + 前瞻预测的设计价值。
OpenLane：车道建图精度提升
V2 在 OpenLane 等车道线检测基准上，凭借增强的地图查询编码，对长程弯道、分叉匝道这类难例的拟合精度较 V1 进一步提升。
综合对比表
| 方法 | 范式 | 规划精度 | 计算量 | 延迟 | 可部署性 |
|---|---|---|---|---|---|
| UniAD | 稠密 BEV + 串行 | 高 | 很高 | 高 | 难 |
| VAD | 矢量化 + 轻量 | 较高 | 中 | 中 | 中 |
| SparseDrive V2 | 全稀疏 + 并行 | 高 | 低 | 低 | 好 |
🔗 与 UniAD / VAD / DiffusionDrive 的对比
把 SparseDrive V2 放回整个端到端自动驾驶的脉络里，能更清楚地看到它的位置。
vs UniAD：从稠密到稀疏
UniAD 是范式的奠基者，确立了"显式端到端 + query 贯通 + 规划导向"的路线，但地基是稠密 BEV，算力沉重。SparseDrive V2 继承了 UniAD 的"query 通路 + 显式表示 + 规划导向"内核，但把表示从稠密换成全稀疏，既延续了 UniAD 的灵魂，又解决了它的算力原罪。可以理解为 “UniAD 范式的稀疏化重构”。
vs VAD：都向量化，但 V2 更彻底
VAD 也主张向量化、轻量化，但它仍保留了较重的 BEV 编码环节，只是把后续表示向量化。V2 则连前端编码都稀疏化，彻底去掉稠密 BEV 这一层，效率更优。两者方向一致，V2 走得更远。
vs DiffusionDrive：稀疏 vs 扩散
DiffusionDrive 是另一条新路线——用扩散模型（Diffusion Model）做规划，擅长生成多模态、分布合理的轨迹，在复杂交互场景下表现亮眼，但扩散过程天然带来多次采样、延迟高的问题。
| 维度 | SparseDrive V2 | DiffusionDrive |
|---|---|---|
| 核心机制 | 稀疏 query + 注意力 | 去噪扩散采样 |
| 多模态 | 锚点驱动的多候选 | 扩散天然多模态 |
| 延迟 | 低（前向一次） | 较高（多步去噪） |
| 优势场景 | 实时部署、全流程统一 | 复杂交互下的轨迹多样性 |
两者其实可以互补：SparseDrive 的稀疏骨架负责实时性与全流程统一，扩散思想可以在规划末端增强多模态质量——未来两者的融合是个值得期待的方向。
四者一脉相承
| 工作 | 核心传承 | 主要进化 |
|---|---|---|
| UniAD | 范式奠基 | 显式端到端，规划导向（稠密） |
| VAD | 向量化 | 轻量化、提速（半稀疏） |
| SparseDrive V2 | query 通路 + 显式表示 | 全稀疏、并行、可部署 |
| DiffusionDrive | 规划质量 | 扩散多模态（重规划） |
📝 个人思考
读 SparseDrive V2 最让我触动的是它对**“表示"的极致较真**。自动驾驶领域过去十年的很多争论，归根到底都是在吵"用什么表示”——是稠密栅格、还是矢量、还是 query、还是隐式特征。V2 用一套干净的稀疏 query 把感知到规划全串起来，并且实证了"稀疏不输稠密、甚至更优"，这背后是一个非常深刻的洞见：真实世界的驾驶场景本就是稀疏的，稠密只是历史包袱，不是必需品。这与自然语言处理里"用 token 取代连续向量"、检测里"用 DETR 取代 anchor 地毯式搜索"是同一种思想胜利——让表示的结构去匹配问题的结构。
第二点启发在并行优于串行。UniAD 的串行接力（检测➜预测➜规划）虽然有信息流清晰的好处，但天然带来误差级联和延迟累积。V2 把运动预测和规划做成并行双分支、共享特征独立输出，既打破了"上游错则下游全错"的链条，又降低了推理延迟。这种**“共享上游、解耦下游”**的架构思想，在工程上极为实用——任何面临"误差级联 + 实时性"矛盾的系统（不止自动驾驶）都可以借鉴。
第三点是关于效率与规模的辩证。V2 告诉我们：省下来的算力不一定用来"做得更便宜"，而可以用来"做得更大"。因为稀疏方法的算力是随 query 数线性增长的，未来可以堆更多 query、更长的时序、更丰富的语义，而不会像稠密 BEV 那样指数爆炸。稀疏化本质上是为后续的 scaling 解除封印——这和当前大模型领域"稀疏 MoE 换来万亿参数"的逻辑完全一致。我倾向于认为，端到端自动驾驶的下一个突破，不会来自把 BEV 堆得更密，而会来自把稀疏表示做得更丰富、更长上下文。
最后一点是对落地价值的体会。一篇端到端论文如果只能在实验室的 A100 上跑、车端 Orin 跑不动，那它离真正改变出行还差十万八千里。V2 把延迟和显存压到接近车端可接受的范围，这种"为部署而设计"的自觉，比纯粹的刷榜更值得尊敬。毕竟，自动驾驶的终极考场不是排行榜，而是真实道路上的每一秒。
SparseDrive V2 的价值，在于它让"全稀疏端到端"从一个激进的学术想法，变成了一条可工程化、可扩展、可上车的现实路线。
📖 这是论文精读系列的第 7 篇。全稀疏路线你更看好谁？欢迎留言讨论。