当前位置：首页 > news >正文

上交AutoLab中科院提出OneDrive：探索原生VL模型能否统一自驾多种异构任务

news 2026/4/29 17:23:10

点击下方卡片，关注“自动驾驶之心”公众号

戳我->领取自动驾驶近30个方向学习路线

作者 | Yiwei Zhang 等
编辑 | 自动驾驶之心
本文只做学术分享，如有侵权，联系删文

>>自动驾驶前沿信息获取→自动驾驶之心知识星球

最近，Vision-Language Model（VLM）在多模态领域快速发展，但当它被引入自动驾驶时，一个基础性的矛盾开始变得不可忽视：自动驾驶本质上是一个异构多任务系统，需要同时输出多种结构化结果（如3D检测框、车道线与轨迹），而VLM则依赖自回归生成，以“逐token”的方式进行建模。换句话说，一个是并行预测问题，一个是序列生成问题。

这种解码范式上的差异，使得现有方法往往不得不引入多个decoder，通过串联或并联的方式拼接系统。虽然可以工作，但也带来了结构复杂、信息割裂，以及预训练模型能力难以充分复用等问题。

在这项工作中，我们尝试从另一个角度出发：在尽量保留预训练VLM结构的前提下，让同一个decoder统一这些异构任务(multi-paradigm tasks)。

论文标题：OneDrive: Unified Multi-Paradigm Driving with Vision-Language-Action Models
论文链接：https://arxiv.org/abs/2604.17915
代码链接：https://github.com/Z1zyw/OneDrive

这就是 OneDrive 的核心思路：One Decoder, Multiple Driving Tasks

为了更具体地理解这一思路，我们把方法大致可以分为三类（如图所示）：

(a) 双系统结构：将语言模型与自动驾驶模块解耦，分别使用独立的decoder；
(b) 级联结构（如Q-Former类方法）：通过中间模块将感知结果映射到语言模型，再进行后续推理；
(c) 本文方法：在同一个decoder中同时处理图像token、结构化query以及文本token。

前两类方法的共同特点是：不同任务依赖不同的解码结构，模型之间通过接口进行信息传递。这种设计虽然直观，但会引入额外的结构开销，同时限制信息在不同任务之间的直接交互。

相比之下，我们更关心的是：在不引入额外decoder的前提下，预训练VLM本身的能力，究竟能被利用到什么程度？

为回答这一问题，我们首先进行了一个简单但关键的先导实验。

具体而言，我们尝试将预训练 VLM 中 LLM 的不同模块迁移到并行 Decoder (自动驾驶场景3D目标检测任务)中，并分别测试 attention 与 feed-forward（FFN）预训练权重的作用。实验结果如图所示：

attention可以带来一定性能提升，而直接复用FFN反而可能导致性能下降甚至训练不稳定。

这一结果有两个直接结论：

预训练VLM中的attention模块具有较强的跨任务泛化潜力；
而FFN则更偏向于服务于原始的语言建模目标，难以直接迁移到结构化预测任务中。

所以，VLM中真正“可复用”的部分，是其建模token之间关系的能力，而不是具体的特征变换。这一观察直接影响了后续的设计：如果希望最大化利用预训练VLM，我们需要尽量保留attention结构，同时仅在必要位置对任务相关模块进行最小修改。

基于上述观察，OneDrive 的设计遵循一个非常直接的原则：

保留预训练VLM中可迁移的部分（attention），对不可直接复用的部分（FFN）进行最小程度的任务适配。

具体实现上，我们将自动驾驶中的不同任务统一表示为一组token，并与图像token、文本token拼接成一个共享序列，输入到同一个VLM decoder中进行处理。整体形式可以写为：

其中，不同任务通过各自的query token进行建模：

detection / lane：固定数量的结构化query（类似DETR / StreamPETR）
planning：基于轨迹初始化的planning query
text：标准自回归token

在这一统一表示下，所有token共享同一套causal attention，从而实现跨任务的信息交互。例如：

query token可以直接关注图像token（无需额外cross-attention）
planning可以依赖感知结果
文本生成也处在同一建模空间中

为了适配结构化预测与自回归生成之间的差异，我们仅在浅层decoder中引入两类轻量修改：

在感知query之间增加额外的self-attention，用于支持并行建模；
使用任务特定的FFN替换原有语言FFN，用于不同任务的特征变换。

值得注意的是，感知与规划任务主要在这些浅层模块中完成，而深层decoder则保持原始VLM结构，主要服务于更高层的语义建模（如文本生成）。基于这一分工，模型在统一结构下实现了任务解耦：一方面避免引入额外decoder，使不同任务能够在同一attention框架中协同优化，并充分复用预训练能力；另一方面，在无需文本输出时，仅前向浅层模块即可完成推理，从而显著提升效率。

实验结果

主要结果

NuScenes

NAVSIM

OneDrive 在多个自动驾驶基准上取得了稳定提升。在nuScenes open-loop评测中，OneDrive 在精度与安全性上均达到当前最优水平：平均轨迹误差降低至0.28 m，同时碰撞率下降至 0.18%，相比现有主流方法（如 ColaVLA、SOLVE-E2E）均有明显改进。在NAVSIM closed-loop评测中，OneDrive 同样表现出良好的稳定性与交互能力，取得86.8 PDMS的结果，在统一建模框架下超越基于独立query decoder的强基线。

消融实验

一个自然的问题是：在引入结构化预测任务后，是否会影响VLM原有的语言能力？实验结果表明并非如此。在相同数据设置下，OneDrive 文本生成的轨迹预测性能与现有方法保持一致甚至略有提升。这说明，在统一decoder框架中引入感知与规划模块，并不会削弱模型的语言建模能力。进一步地，我们分析了文本监督在训练过程中的作用。实验发现，在联合训练中保留文本loss，可以带来稳定但一致的性能提升，尤其体现在碰撞率等安全指标上。

除了精度与稳定性，OneDrive 在推理效率上也体现出结构上的优势。与依赖完整LLM前向或引入额外decoder的方案不同，OneDrive 将感知与规划任务集中在浅层decoder中完成。这意味着，在实际部署时，可以仅前向部分decoder层即可得到结构化输出，而无需执行完整的深层建模过程。

在 NAVSIM 设置下，这一设计将推理延迟从263 ms 降低至 156 ms（约40%提升）。相比之下，依赖完整模型前向的方案，其计算路径与任务解耦程度较低，难以在不牺牲性能的情况下实现类似的加速。在 nuScenes 设置中，由于需要将多视角图像token与大量query token拼接为长序列输入模型，整体序列长度显著增加。但即便在这一情况下，OneDrive 仍然能够保持可接受的推理延迟。

最后，我们对模型的3D感知能力进行了进一步分析。

尽管 OneDrive 在3D检测任务上取得了提升，但与当前主流的纯视觉3D检测方法相比，仍存在一定差距。为了进一步定位这一差距的来源，我们基于相同的视觉backbone，对比了标准3D检测框架（如StreamPETR）的表现。实验结果表明，在统一使用 InternVL-ViT 的情况下，我们的方法已经能够超过对应的检测baseline。这意味着性能瓶颈并不主要来自decoder设计，而更多与视觉表示本身有关。我们认为，这一差距主要来源于两个方面：