OneDrive：基于统一Transformer解码器的端到端自动驾驶架构解析
1. 项目概述与核心挑战
最近几年，Vision-Language Models (VLMs) 在理解和生成多模态内容方面取得了令人瞩目的进展，这让很多研究者开始思考：能不能把这种强大的“大脑”直接塞进自动驾驶汽车里，让它像理解一张图片配文一样，理解复杂的驾驶场景并做出决策？这个想法听起来很美好，但实操起来却困难重重。最核心的矛盾在于，自动驾驶系统本质上是一个多任务、异构输出的复杂系统。它既要像语言模型那样，能进行连续的自回归推理（比如回答“前方那辆车想干嘛？”），又要像传统的感知模型那样，能并行地、结构化地输出一大堆结果（比如同时检测出周围所有的3D车辆、行人、车道线，并规划出一条未来几秒的轨迹）。这两种任务范式，一个像“串行讲故事”，一个像“并行画地图”，在模型架构上几乎是背道而驰。
因此，现有的方案大多走了折中路线。要么搞“双系统”，一个VLM负责聊天和高级推理，旁边再挂一个传统的感知-规划模型负责干活，两者各干各的，信息流不通畅。要么搞“级联系统”，先用一个模型做完感知，再把结果“喂”给VLM去做规划和解释，这种管道式设计容易误差累积，且无法进行端到端的联合优化。这些方案都导致了一个共同的问题：架构碎片化。预训练好的、拥有强大世界知识的VLM权重，无法被下游这些五花八门的任务解码器有效复用，相当于每次都要从头训练一个“驾驶专家”，既浪费了预训练的价值，也限制了模型的统一性和效率。
那么，有没有可能设计一个“万能解码器”，让一个Transformer解码器既能优雅地生成文本，又能高效地输出3D框和轨迹？这正是OneDrive这篇工作试图回答的问题。它的核心洞察非常巧妙：Transformer解码器的核心能力——因果注意力机制——或许比我们想象的更具通用性。这种原本为建模文本序列依赖而设计的注意力，其捕捉“查询-键-值”之间关系的能力，可能同样适用于建模“感知查询令牌”与“视觉特征”之间的关系。如果这个假设成立，我们就有可能以预训练的因果注意力为共享骨干，构建一个统一的多任务解码器。
2. OneDrive核心设计思路拆解
OneDrive的设计哲学可以概括为：统一序列，共享注意，任务特化。它没有去发明新的注意力机制，而是最大限度地尊重并利用了预训练VLM已有的能力，只在必要的地方做最小程度的改动。
2.1 统一令牌序列：把一切“摊平”处理
传统多任务系统为每个任务配备独立的“处理流水线”。OneDrive反其道而行之，它把所有需要处理的信息都“摊平”成一个长长的令牌序列。这个序列就像一张包含所有信息的“总清单”，其构成如下：
Z = [X_img, Q_det, Q_lane, Q_plan, X_text]
- X_img (图像令牌)：来自视觉编码器（如ViT）的多视角图像特征。
- Q_det (检测查询令牌)：一组可学习的向量，每个向量负责“关注”并最终预测一个潜在的3D物体（车、人、自行车等）。
- Q_lane (车道线查询令牌)：另一组可学习的向量，用于关注和预测车道线结构。
- Q_plan (规划查询令牌)：这是实现规划的关键。OneDrive为未来轨迹的每个预测时间步（例如，未来3秒，每0.5秒一个点）分配一个专用的规划查询令牌。这些令牌的初始化很讲究，通常从一个基础的轨迹锚点（例如，沿用当前车道线或参考历史轨迹）开始，并拼接上自车状态（速度、加速度等）的嵌入，让模型知道“我现在在哪，状态如何”。
- X_text (文本令牌)：用户输入的指令或问题，以及模型需要生成的文本回答。
这个设计妙在哪里？它强制所有异构的信息在同一个语义空间内共存，并通过同一个Transformer解码器进行处理。这意味着，当规划查询Q_plan想要决定“下一步往哪开”时，它可以通过注意力机制，直接“看到”并考虑到前面的图像特征X_img、检测结果Q_det和车道线Q_lane。这种隐式的
下载资源随意下
优质VIP博文免费学
优质文库回答免费看
付费资源9折优惠