OneDrive：统一解码器实现自动驾驶VLA模型的异构任务处理

自动驾驶端到端学习视觉语言动作模型

于 2026-06-02 03:02:50 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 项目概述与核心挑战

最近几年，自动驾驶领域最让人兴奋的趋势之一，就是大模型技术的渗透。从最初基于规则和传统感知-预测-规划模块的“拼装”式系统，到如今端到端（End-to-End）框架的兴起，大家的目标越来越清晰：构建一个能像人类一样，看、想、动一体化的智能驾驶大脑。Vision-Language-Action（VLA）模型就是这个方向上的关键探索，它试图将视觉语言模型（VLM）强大的场景理解和推理能力，与最终的控制动作生成直接打通。

然而，理想很丰满，现实却很骨感。当你真正动手去搭建这样一个系统时，一个根本性的矛盾就摆在了面前：解码行为的异构性。简单来说，一个完整的驾驶系统需要同时干好几件“性质”完全不同的活儿：

感知与结构化输出：比如检测周围的3D边界框、识别车道线。这类任务通常是“并行”的——模型需要同时、独立地输出多个目标的位置和属性，每个输出之间没有严格的先后顺序依赖。
轨迹规划：预测或生成未来一段时间内自车的一条连续轨迹。这可以看作是一种结构化的序列预测。
语言生成与推理：回答“前方那辆车意图是什么？”或解释“我为什么选择变道”。这是典型的“自回归”任务——像聊天一样，一个字一个字地生成，后面的词严重依赖于前面已生成的词。

传统的做法，是为这些不同的“工种”配备不同的“工具”（解码器）。例如，用基于DETR的并行解码器处理感知，用另一个网络头做轨迹回归，再单独接一个语言模型解码器来生成文本。这就好比一个工厂里，感知、规划、语言三个车间各自为政，中间隔着厚厚的墙（接口），不仅信息流通不畅（限制了跨任务的一致性优化），而且每个车间都得自己养一套人马（模型参数），计算开销大，模型也显得臃肿。

更棘手的是，当我们想利用现成的、在海量图文数据上预训练好的VLM（比如InternVL、Qwen-VL）作为基础时，这种“分车间”的做法会带来严重的架构偏离。预训练VLM的核心是一个为自回归文本生成而优化的Transformer解码器，其注意力机制是严格因果的（只能看前面，不能看后面）。如果我们为了做并行感知，强行把它改造成非因果的、全连接的注意力，或者在外面挂接全新的解码模块，就相当于放弃了预训练模型最宝贵的“知识”——那些已经学会的、关于如何建立视觉token与语言token之间关联的注意力模式。这常常导致训练不稳定、性能不佳，或者为了弥补性能差距而不得不引入额外的传感器（如激光雷达），背离了纯视觉端到端系统的初衷。

那么，一个核心问题就浮现了：能否让一个单一的、预训练好的VLM解码器，在不破坏其原有因果注意力结构的前提下，同时优雅地处理感知、规划和语言生成这些异构任务？ 这正是OneDrive这篇工作试图回答并解决的问题。它不是一个简单的模型堆叠，而是一次对Transformer解码器本质能力的深度挖掘和重新设计。

2. OneDrive的核心设计思路：统一解码的哲学

面对异构解码的挑战，OneDrive选择了一条看似激进实则优雅的路径：不增加新的解码器，而是将所有任务“翻译”成同一种“语言”，让它们在同一个解码器里和谐共处。这套“语言”就是Token序列。

2.1 统一Token序列：万物皆可Token化

OneDrive最根本的洞察在于，无论是图像像素、一个待检测的物体、一条待规划的未来轨迹点，还是一段待生成的文本，都可以被表示为Transformer解码器中的一个Token。通过精心设计这些Token的排列和初始化方式，就能让同一个解码器处理它们。

具体来说，模型输入的完整Token序列 Z 是这样构造的： Z = [X_img, Q_det, Q_lane, Q_plan, X_text]

我们来逐一拆解：

X_img (图像Token)：环视相机（通常是6个视角）的图像经过视觉编码器（如ViT）后，被展平为一系列视觉Token。这是模型感知世界的“原材料”。
Q_det (检测查询Token)：一组可学习的向量，每个向量负责“关注”并最终输出一个3D检测框（位置、尺寸、朝向、类别等）。其数量是预设的（比如100个），对应可能存在的最大目标数。这些Token被放置在图像Token之后，意味着在解码器的因果注意力机制下，它们可以“看到”并依赖于所有的视觉信息。
Q_lane (车道线查询Token)：另一组可学习向量，专门用于输出车道线的结构化信息（如中心线点序列）。其设计理念与检测查询类似。
Q_plan (规划查询Token)：这是实现规划的关键。OneDrive为未来轨迹的每一个预测时间步（例如，未来3秒，每0.5秒一个点，共6个点）分配一个专用的规划查询Token。这些Token被初始化为一个基于历史轨迹或简单规则生成的“锚点”轨迹，并额外拼接了一个表示自车状态（如速度、加速度）的嵌入。规划Token被放在感知Token之后，因此它们能“看到”图像和感知结果，从而做出基于环境的规划决策。
X_text (文本Token)：用户输入的指令或问题，以及模型需要自回归生成的回答。它们被放在序列的最后。

设计意图解析：这个序列顺序是经过深思熟虑的。它模拟了一个符合认知逻辑的信息流：先看环境（图像），再理解环境中有什么（感知），然后基于环境理解决定怎么走（规划），最后用语言描述或解释这个过程（语言）。这种顺序使得因果注意力机制能够自然地建立从视觉到感知，再到规划和语言的条件依赖关系。

2.2 混合解码层：在统一中保留特性

虽然所有Token都在一个序列里，但不同任务对特征交互和变换的需求确实不同。OneDrive没有粗暴地使用完全相同的解码层，而是引入了混合解码层（Mixed Decoder Layers） 的概念，主要在浅层网络中进行微调。

2.2.1 共享的因果注意力骨干

这是OneDrive的灵魂所在。整个解码器的核心注意力机制，完全沿用预训练VLM的因果自注意力（Causal Self-Attention）。所有Token（图像、检测、车道、规划、文本）都处于同一个因果掩码下。这意味着：

一个规划Token可以关注它之前的所有图像Token和感知Token，从而基于全面的场景信息做决策。
一个文本Token可以关注它之前的所有Token（包括规划结果），从而生成基于驾驶决策的解释。
最重要的：预训练VLM中已经学会的、如何建立视觉-语言关联的注意力权重和模式，被最大程度地保留和复用。论文中的诊断实验（见表1）也证实了，预训练的注意力权重具有极强的跨任务迁移能力，而只为文本生成优化的前馈网络（FFN）权重则迁移性较差。

为了增强对3D空间的建模能力，OneDrive在图像Token和结构化查询Token上引入了额外的3D位置编码（源自PETR、StreamPETR等工作），与原始的RoPE位置编码相加。这使得模型不仅能理解Token在序列中的顺序，还能理解它们在物理3D空间中的位置关系，对于自动驾驶任务至关重要。

2.2.2 任务特定的增强模块

在共享注意力骨干的基础上，OneDrive在浅层为结构化任务（感知、规划）添加了最小的、针对性的改动：

查询间自注意力（Query Self-Attention）：因果注意力要求序列顺序，这对于需要全局交互的并行感知（如判断两个检测框是否重叠）并不理想。因此，OneDrive在混合解码层中，额外引入了一个仅作用于结构化查询Token（Q_det, Q_lane, Q_plan）之间的双向自注意力模块。这个模块允许所有查询Token之间自由地交换信息，实现高效的并行推理，同时完全不干扰主干中的因果注意力。
任务特定前馈网络（Task-Specific FFN）：如前所述，预训练的FFN是为语言建模设计的，直接用于回归3D框坐标或轨迹点效果不佳。因此，OneDrive为检测、车道线、规划这三类查询Token分别配备了独立的前馈网络，用来进行任务所需的非线性特征变换。文本Token则继续使用预训练的FFN。

实操心得：这种“注意力共享，FFN特化”的设计哲学非常实用。它抓住了Transformer的核心——注意力机制负责建立关系，而FFN负责特征变换。关系建模（什么和什么相关）的能力是通用的，可以从预训练中迁移；而特征变换（把抽象关系变成具体的框坐标）则需要针对具体任务从头学习或微调。这好比一个经验丰富的指挥官（共享注意力）能看懂战场全局并指出关键关联，但具体的炮兵计算弹道（检测FFN）、工兵绘制地图（车道FFN）、参谋部制定行军路线（规划FFN）需要各自的专业工具。

2.3 训练策略：分阶段解锁能力

直接端到端训练如此复杂的多任务模型是困难的。OneDrive采用了三阶段渐进式训练策略，这在实际复现中至关重要：

第一阶段：感知-语言预训练
- 操作：冻结视觉编码器（ViT）。只使用图像Token、检测/车道查询Token和文本Token。训练混合解码器中的因果注意力（微调）、语言模型部分（通常用LoRA等参数高效方法适配）、以及为感知任务新引入的查询自注意力和任务特定FFN。
- 目标：让模型学会在视觉上下文中，同时完成物体检测/车道线识别和基本的语言描述（例如，“图中有一辆车”）。此阶段确立了视觉-感知-语言的基本关联。
第二阶段：规划适配
- 操作：引入规划查询Token Q_plan。冻结第一阶段训练好的感知相关模块（检测/车道FFN等）。训练规划查询、规划FFN和规划MLP头，同时继续用LoRA适配语言模型部分。
- 目标：在已经具备感知能力的基础上，让模型学会基于视觉和感知信息，生成合理的未来轨迹。此时规划任务可以“看到”并利用初步的感知结果。
第三阶段：联合微调
- 操作：解冻所有模块，包括视觉编码器。使用完整的损失函数（感知损失 L_perc + 规划损失 L_plan + 文本损失 L_text）进行端到端联合优化。
- 目标：让视觉编码器、共享注意力、以及各任务特定模块之间进行深度协同和调整，达到全局最优。论文中的消融实验（表8）证明，这种分阶段策略比直接端到端训练效果更好，感知预训练为规划提供了良好的初始化。

注意事项：在联合训练时，不同损失之间的权重平衡（λ_perc, λ_plan）是关键超参数。论文中通过网格搜索发现，对于nuScenes数据集，规划损失权重 λ_plan = 1.0 时能取得感知与规划的最佳平衡（见表6）。权重过高会导致规划任务“霸占”模型容量，损害感知精度；权重过低则规划性能提升不足。

3. 关键实现细节与实操解析

理解了核心思想后，我们深入到实现层面，看看如何把一个先进的论文想法落地成可运行的代码。这里会结合论文和常见的工程实践进行补充。

3.1 模型架构搭建

假设我们以 InternVL3-1B 这个预训练VLM作为基础模型进行构建。

PYTHON

import torch

import torch.nn as nn

from transformers import AutoModel, AutoConfig

class OneDriveModel(nn.Module):

def __init__(self, vl_model_name='OpenGVLab/InternVL3-1B',

num_det_queries=100, num_lane_queries=50, plan_horizon=6):

super().__init__()

# 1. 加载预训练的VLM骨干（包含ViT编码器和LLM解码器）

self.vl_model = AutoModel.from_pretrained(vl_model_name)

config = AutoConfig.from_pretrained(vl_model_name)

self.hidden_size = config.hidden_size # 例如 1024

# 2. 初始化结构化查询Token（可学习参数）

self.det_queries = nn.Parameter(torch.randn(1, num_det_queries, self.hidden_size))

self.lane_queries = nn.Parameter(torch.randn(1, num_lane_queries, self.hidden_size))

# 规划查询：每个时间步一个，加上一个ego状态token

self.plan_queries = nn.Parameter(torch.randn(1, plan_horizon + 1, self.hidden_size))

# 3. 任务特定的前馈网络（FFN）

# 使用简单的MLP，输入输出维度相同

self.det_ffn = nn.Sequential(

nn.Linear(self.hidden_size, self.hidden_size * 4),

nn.GELU(),

nn.Linear(self.hidden_size * 4, self.hidden_size)

)

self.lane_ffn = nn.Sequential(...) # 结构类似

self.plan_ffn = nn.Sequential(...) # 结构类似

# 文本部分沿用预训练模型的FFN，通过LoRA适配

# 4. 查询间自注意力模块（仅用于结构化查询）

self.query_self_attn = nn.MultiheadAttention(embed_dim=self.hidden_size, num_heads=16, batch_first=True)

# 5. 输出头（MLP）

self.det_head = nn.Linear(self.hidden_size, 8) # 例如: [x,y,z,w,l,h,theta,cls]

self.lane_head = nn.Linear(self.hidden_size, lane_points*2) # 车道点坐标

self.plan_head = nn.Linear(self.hidden_size, 2) # 轨迹点 (x, y)

# 文本生成头使用预训练模型的lm_head

# 6. 3D位置编码器（参考PETR/StreamPETR）

self.pos_encoder_3d = PositionEmbedding3D(hidden_dim=self.hidden_size)

def forward(self, images, text_input_ids, ego_status):

"""

images: [B, N_cams, C, H, W]

text_input_ids: [B, L_text]

ego_status: [B, D_ego]

"""

batch_size = images.shape[0]

# A. 视觉编码

# 将多视角图像拼接或分别编码，得到视觉token X_img

# 这里简化处理，实际需按InternVL的方式处理多图

visual_tokens = self.encode_images(images) # [B, N_img_tokens, D]

# B. 构建统一序列

# 扩展查询token到batch维度

det_q = self.det_queries.expand(batch_size, -1, -1)

lane_q = self.lane_queries.expand(batch_size, -1, -1)

plan_q = self.plan_queries.expand(batch_size, -1, -1)

# 将ego状态拼接到规划查询前

ego_embed = self.ego_embedding(ego_status).unsqueeze(1) # [B, 1, D]

plan_q = torch.cat([ego_embed, plan_q], dim=1)

# 获取文本token嵌入

text_embeds = self.vl_model.get_input_embeddings()(text_input_ids)

# 关键步骤：拼接成统一序列 Z

# 顺序: [视觉, 检测查询, 车道查询, 规划查询, 文本]

unified_sequence = torch.cat([visual_tokens, det_q, lane_q, plan_q, text_embeds], dim=1)

# 序列长度: L_total = L_img + L_det + L_lane + L_plan + L_text

# C. 添加3D位置编码（仅对视觉和结构化查询）

# 为视觉token和查询token计算3D空间位置

img_3d_pos = self.pos_encoder_3d.get_img_pos(images, ...)

det_3d_pos = self.pos_encoder_3d.get_query_pos('det', ...)

# ... 类似地获取lane和plan的3D位置编码

# 将3D位置编码加到对应的token上（在RoPE之后）

# D. 通过混合解码层

# 假设我们只修改前L_mixed层为混合层

decoder_output = unified_sequence

for idx, layer in enumerate(self.vl_model.decoder.layers):

# 原始因果注意力计算

decoder_output = layer.attention(decoder_output, ...) # 包含RoPE和3D位置编码

# 在浅层混合层中，对结构化查询部分进行额外处理

if idx < self.num_mixed_layers:

# 1. 提取结构化查询部分

struct_queries = decoder_output[:, L_img:L_img+L_det+L_lane+L_plan, :]

# 2. 应用查询间自注意力（双向）

struct_queries = self.query_self_attn(struct_queries, struct_queries, struct_queries)[0]

# 3. 应用任务特定FFN

det_part = struct_queries[:, :L_det, :]

lane_part = struct_queries[:, L_det:L_det+L_lane, :]

plan_part = struct_queries[:, L_det+L_lane:, :]

det_part = self.det_ffn(det_part)

lane_part = self.lane_ffn(lane_part)

plan_part = self.plan_ffn(plan_part)

# 将处理后的部分放回

struct_queries_processed = torch.cat([det_part, lane_part, plan_part], dim=1)

decoder_output = torch.cat([

decoder_output[:, :L_img, :],

struct_queries_processed,

decoder_output[:, L_img+L_det+L_lane+L_plan:, :]

], dim=1)

# 后续层（如果是原始FFN，文本部分用原始的，结构化部分用恒等映射或跳过）

# 实际实现中，需要更精细地控制不同部分的FFN路径

decoder_output = layer.feed_forward(decoder_output) # 这里需要重写，以路由到不同的FFN

# E. 从解码器输出中提取对应部分，并过任务头

final_det_tokens = decoder_output[:, L_img:L_img+L_det, :]

final_lane_tokens = decoder_output[:, L_img+L_det:L_img+L_det+L_lane, :]

final_plan_tokens = decoder_output[:, L_img+L_det+L_lane:L_img+L_det+L_lane+L_plan, :]

final_text_tokens = decoder_output[:, L_img+L_det+L_lane+L_plan:, :]

det_output = self.det_head(final_det_tokens)

lane_output = self.lane_head(final_lane_tokens)

plan_output = self.plan_head(final_plan_tokens)

# 文本输出使用预训练模型的lm_head

text_logits = self.vl_model.lm_head(final_text_tokens)

return det_output, lane_output, plan_output, text_logits

关键细节提醒：以上代码是一个高度简化的概念性示例。实际实现中，需要严格处理注意力掩码（确保因果性），精确实现3D位置编码与RoPE的结合，并妥善处理解码器中不同部分的前馈网络路由。最复杂的地方在于修改预训练Transformer解码器的前向传播逻辑，通常需要继承并重写其层模块。

3.2 数据准备与预处理

OneDrive在nuScenes和NAVSIM数据集上进行训练和评估。对于希望复现的研究者或工程师，数据流程是关键。

nuScenes数据：
- 核心：6个环视相机图像（关键帧）、3D激光雷达点云（用于生成真值，但训练时仅用图像）、高精地图、物体3D框标注、自车轨迹。
- 预处理：
  - 图像：按照InternVL等VLM的要求进行预处理（如调整分辨率、归一化）。通常需要将6张图像拼接或分别编码。
  - 感知真值：将3D检测框和车道线（可从OpenLaneV2获取）转化为模型需要的形式。对于DETR风格的检测，需要为每个真实物体分配一个查询，计算匈牙利匹配损失。
  - 规划真值：未来轨迹（通常未来3-6秒，采样频率10Hz）。需要将轨迹坐标归一化到自车坐标系下。
  - 文本数据：如果使用OmniDrive扩展的QA数据，需要将问题和答案转换为token序列。
NAVSIM数据：
- 更侧重于闭环规划评估，数据来源于nuPlan。需要处理复杂的交互场景和密集的轨迹序列。
- 预处理重点在于轨迹序列的提取和场景上下文（如交通规则、红绿灯状态）的编码，这些可能作为额外的输入或条件。
Token序列构造：
- 这是数据加载器的核心功能。对于每一个训练样本，需要动态地构建出那个统一的Token序列 [X_img, Q_det, Q_lane, Q_plan, X_text]。
- 其中，Q_det, Q_lane, Q_plan 是可学习的模型参数，在训练初期是随机初始化的。数据加载器不需要提供它们的内容，只需要提供它们的数量和顺序信息，以及对应的真值标签用于计算损失。

3.3 损失函数设计

多任务学习成功与否，很大程度上取决于损失函数的平衡。OneDrive的总体损失是加权和： L_total = λ_perc * L_perc + λ_plan * L_plan + λ_text * L_text

感知损失 L_perc：
- 3D检测损失：通常采用DETR系列的集合预测损失。包括：
  - 分类损失：Focal Loss或交叉熵，用于判断查询是否匹配到物体以及物体类别。
  - 框回归损失：L1损失和GIoU损失，用于回归3D框的中心点(x,y,z)、尺寸(w,l,h)、朝向(θ)。
- 车道线损失：对于每个车道线查询，输出一系列2D点坐标。可以使用点集的L1损失或Chamfer Distance。
规划损失 L_plan：
- L2位移误差：预测轨迹点与真值轨迹点之间的平均欧氏距离。这是最直接的精度指标。
- 碰撞损失：鼓励预测轨迹与感知到的障碍物（或其他智能体）保持安全距离。可以通过计算轨迹点与最近障碍物的距离，并施加一个惩罚项（如hinge loss）来实现。
- 舒适度损失：对轨迹的加速度、加加速度（jerk）进行正则化，使轨迹更平滑。
文本损失 L_text：
- 标准的自回归语言建模损失，即下一个token的交叉熵损失。对于VLM，这通常是在大规模图文数据上预训练时的主要目标。在OneDrive中，保留文本损失起到了正则化作用，防止共享的因果注意力在优化感知和规划任务时，过度偏离其预训练时学到的良好语义空间。

实操心得：深度监督：论文中提到，他们在规划任务上也采用了深度监督（Deep Supervision）。这意味着不仅仅在解码器的最后一层计算规划损失，而是在多个中间层（特别是那些输出结构化查询的混合层）都添加辅助的规划损失。这样做有助于梯度更好地传播，加速训练，并提升最终性能。这是一个非常有效的技巧，在实现时需要在多个层提取规划查询的中间特征并分别计算损失。

4. 实验分析与性能解读

论文在nuScenes（开环）和NAVSIM（闭环）两个权威基准上进行了全面评估，结果令人印象深刻。我们来深入解读这些数字背后的含义。

4.1 开环规划性能（nuScenes）

开环评估是在已知历史状态的情况下，预测未来轨迹，并与真实轨迹比较，不执行动作影响环境。

方法类别	方法	平均L2误差 (m) ↓	平均碰撞率 (%) ↓	核心特点
基于文本的模型	SOLVE-VLM	0.28	0.20	思维链，自回归文本输出轨迹
	OmniDrive	0.33	0.30	级联架构，大语言模型规划
基于动作的模型	VAD-Base	0.37	0.33	经典向量化端到端模型
	BEV-Planner	0.35	0.34	BEV感知+规划
	OneDrive	0.28	0.18	统一解码器，共享注意力

结果分析：

精度领先：OneDrive取得了所有基于动作的模型中最好的平均L2误差（0.28m）和最低的碰撞率（0.18%）。甚至与需要复杂思维链的基于文本的模型（如SOLVE-VLM）性能相当，但后者是通过将轨迹编码成文本来生成，延迟高且不可控。
安全性突出：0.18%的碰撞率显著低于其他同类型模型（如ColaVLA的0.23%，SOLVE-E2E的0.30%）。这表明统一架构下，规划模块能更有效地利用感知信息（检测到的障碍物）来规避碰撞，实现了更好的任务协同。
效率优势：如表7所示，OneDrive的推理延迟（513ms）显著低于同样非自回归的强基线ColaVLA（727ms）。这得益于其无需运行完整LLM进行自回归生成，也无需复杂的自定义注意力掩码，可以充分利用标准的Transformer优化（如FlashAttention）。

4.2 闭环规划性能（NAVSIM）

闭环评估更接近真实场景，模型输出的轨迹会被送入模拟器控制车辆，评估其在实际交互中的长期表现（安全性、合规性、舒适度等），使用PDMS综合评分。

方法	PDMS分数 ↑	说明
Query Decoder Baseline	85.0	使用ReCogDrive的查询解码器作为基线
ReCogDrive (SFT)	86.5	强大的VLA模型，监督微调
OneDrive	86.8	本文方法
DiffusionDrive	88.1	基于扩散模型的SOTA方法（使用激光雷达）

结果分析：

有效提升：相比基础的查询解码器基线（85.0），OneDrive（86.8）获得了近2个点的提升，这直接证明了统一解码器设计比传统的、分离的查询解码器更有效。
竞争力：与同样基于VLM监督微调的ReCogDrive（86.5）相比，OneDrive略有优势。考虑到OneDrive是纯视觉输入，而一些更高分的方法（如DiffusionDrive）使用了激光雷达，这个成绩非常有竞争力。
延迟优势再现：在NAVSIM上，OneDrive的延迟（156ms）比ReCogDrive（263ms）降低了约40%，再次验证了其高效性。这对于实时自动驾驶系统至关重要。

4.3 消融实验的深入洞察

论文中的消融实验回答了几个关键的设计选择问题：

文本监督的作用（表5）：在联合训练中保留文本损失，即使不评估文本任务，也能小幅提升感知（NDS/mAP）和规划（碰撞率）性能。这证实了我们的猜想：文本损失起到了正则化作用，帮助共享的因果注意力模块保持在预训练学到的、良好的优化轨迹上，防止其在适应结构化任务时发生灾难性遗忘或漂移。
规划损失权重 λ_plan（表6）：这是一个需要仔细调优的超参数。实验表明，λ_plan=1.0 时取得最佳平衡。权重过低（0.25）规划任务学习不充分；权重过高（2.0）则会损害感知性能并导致规划不稳定（碰撞率飙升）。在多任务学习中，损失权重的网格搜索是必不可少的步骤。
训练策略（表8）：三阶段训练（感知预训练 -> 规划适配 -> 联合微调）显著优于直接端到端训练。感知预训练阶段为模型提供了良好的场景理解基础，使得后续的规划适配更快、更稳。最终的联合微调让感知和规划相互促进，达到最佳性能。
Token序列顺序（表9）：实验对比了 车道->检测->规划 和 检测->车道->规划 两种顺序。结果表明，检测->车道->规划 的顺序 consistently 更优。一个可能的解释是，车辆检测（动态障碍物）对于安全规划是最高优先级的信息，将其放在更靠近视觉源的位置，能让规划查询更早、更直接地接触到最关键的安全信息。

5. 复现难点、常见问题与避坑指南

尽管论文思路清晰，但真正动手复现OneDrive这样的复杂系统，会遇到不少坑。这里结合我的经验，梳理出几个关键难点和解决方案。

5.1 预训练模型集成与修改

难点：如何在不破坏预训练VLM（如InternVL）原有结构的前提下，插入自定义的查询Token和混合解码层？

问题：直接修改 transformers 库中模型定义可能很复杂，且容易破坏其内部逻辑（如缓存、梯度检查点）。
解决方案：
1. 继承与重写：创建自定义模型类，继承自预训练模型类。然后重写 __init__ 方法以添加新的模块（查询参数、任务FFN等），并重写 forward 方法以实现新的前向传播逻辑。
2. 钩子（Hooks）：对于在特定层后插入操作（如查询自注意力），可以使用PyTorch的 register_forward_hook。但这种方法在复杂控制流下可能难以调试。
3. 使用模型库的适配接口：一些先进的库（如Hugging Face的 PEFT 对于LoRA）提供了非侵入式修改模型的方法。但对于添加全新的Token和注意力模块，可能仍需深度定制。
- 实操建议：从一个小型、结构类似的预训练模型（如GPT-2）开始，实现一个简化版的OneDrive原型，验证统一序列和混合层的基本可行性，再迁移到大型VLM上。

5.2 内存与计算效率

难点：统一的Token序列非常长（图像Token数千个 + 查询Token数百个 + 文本Token），导致注意力矩阵巨大，显存爆炸。

问题：序列长度 L 的注意力计算复杂度是 O(L^2)，直接计算不可行。
解决方案：
1. 利用因果注意力的稀疏性：虽然序列长，但因果注意力掩码意味着每个Token只关注前面的Token。然而，对于图像Token，它们之间通常是全连接的（在VLM中，图像Token内部可能使用非因果注意力）。需要仔细检查并实现正确的注意力掩码。
2. FlashAttention：必须使用。FlashAttention通过IO感知的算法，在保持精确度的同时，大幅降低显存占用并提升速度。确保你的PyTorch/CUDA环境支持FlashAttention。
3. 梯度检查点：在训练时，对Transformer层使用梯度检查点，用时间换空间，可以处理更长的序列。
4. 序列长度优化：对图像Token进行适度的下采样或池化，在不过度损失信息的前提下减少 L_img。论文中也提到，VLM的视觉编码器通常会进行下采样，这是性能瓶颈之一。

5.3 训练不稳定与发散

难点：多任务、多阶段训练容易不稳定，特别是感知和规划的损失尺度差异大。

问题：规划损失（L2误差，单位米）和检测损失（分类概率、框的归一化坐标）数值范围不同，梯度幅度差异巨大，导致其中一个任务主导训练，另一个学不到东西。
解决方案：
1. 自动损失平衡：不要固定 λ 值。可以尝试 GradNorm 或 Uncertainty Weighting 等方法，让模型动态调整各任务损失的权重，使它们的梯度幅度大致相等。
2. 损失缩放：手动对规划损失进行适当的放大或缩小，使其与感知损失处于同一数量级。这需要多次实验观察损失曲线。
3. 梯度裁剪：这是稳定Transformer训练的标配。设置一个全局梯度范数阈值（如1.0或5.0）。
4. 学习率热身与调度：使用线性热身（Warmup）和余弦退火（Cosine Decay）调度器。对于三阶段训练，每个阶段开始时可能都需要一个小的热身过程。
5. 仔细的初始化：新添加的任务特定FFN层，使用较小的标准差（如0.02）进行正态分布初始化，避免初始输出过大扰乱预训练主干。

5.4 评估与调试

难点：端到端模型评估流程复杂，错误来源难以定位。

问题：规划效果差，可能是感知不准，也可能是规划模块本身不行，或者是两者之间的信息传递有问题。
解决方案：
1. 分阶段验证：严格遵循论文的三阶段训练。在第一阶段结束后，单独评估感知任务（在nuScenes val集上计算mAP/NDS）和文本生成质量（人工检查或BLEU等指标）。确保感知基础是牢固的。
2. 可视化，可视化，再可视化：这是最重要的调试工具。
  - 感知可视化：将预测的3D框投影到图像和BEV图上，与真值对比。
  - 规划可视化：在BEV图中绘制预测轨迹、真值轨迹以及感知到的障碍物。观察碰撞是否发生在误检或漏检的障碍物上。
  - 注意力可视化：可视化规划查询Token对图像Token和检测查询Token的注意力权重。看它是否关注了正确的区域（如前方车辆、路口）。
3. 简化场景测试：先在极简的仿真环境或数据子集（如只有直道、少量车辆的场景）上跑通全流程，再逐步增加复杂度。

OneDrive的工作为端到端自动驾驶提供了一条新颖且强大的技术路径。它挑战了“异构任务必须异构解码”的固有思维，通过巧妙的Token序列设计和混合解码层，在预训练VLM的坚实基础上，构建了一个高效、统一、高性能的驾驶大脑。虽然复现之路充满挑战，需要对Transformer、多任务学习、自动驾驶有深入的理解和扎实的工程能力，但其展现出的潜力无疑值得深入探索。对于研究者而言，这是一个富含宝藏的方向；对于工程师而言，这或许是未来构建更简洁、更强大自动驾驶系统的一个蓝本。