点击下方卡片，关注“自动驾驶之心”公众号
戳我->领取自动驾驶近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设计，而更多与视觉表示本身有关。我们认为，这一差距主要来源于两个方面：
为适配VLM输入，视觉特征在进入decoder前通常经过下采样处理，导致空间分辨率受限；
现有VLM的预训练目标以语言对齐为主，并未显式优化空间结构建模能力。
因此，当前性能的上限，更多由视觉编码能力决定，而非decoder框架本身。
自动驾驶之心
求点赞
求分享
求喜欢
