Qwen-Drive-1.0:视觉-语言基础模型迈向自动驾驶的第一步

  • 关联论文：2609.00111
  • 作者：flyP
  • 更新：2026-09-02

一句话结论

Qwen-Drive-1.0 把一个预训练好的视觉-语言模型 (VLM) 当成"大脑",外挂一个 BEV 感知头和一个规划专家,做 3D 感知、视觉问答、运动规划三件套的统一,在 nuScenes/规划基准上同时拿到了强 3D 感知和强闭环规划表现,且基本保留了通用 VLM 的视觉-语言能力不掉点。

解决什么真问题

自动驾驶近两年最大的张力是:"端到端"派想要一个大模型把所有任务吃掉,但 VLM 本身是 2D 的、没有 3D 几何感;经典模块化派又舍不得丢掉 BEV 感知这种已经在 nuScenes 跑得很熟的 3D 表示。Qwen-Drive-1.0 站在这两派之间,直接回答一个问题:能不能让 VLM 的多模态语义和推理能力 + 一个外挂的显式 BEV 表示共存,而不是相互覆盖。

更进一步,真正难的不是"加一个 BEV head",而是三件事同时不崩:① 3D 感知的数字(检测 mAP、占据预测 mIoU、地图分割)不退化;② 通用 VQA/图像描述能力不丢;③ 闭环规划能跑得动而且不掉点。这三件事之前的工作通常只保证其中一两条。

核心方法

1. 整体架构:双头 VLM

模型骨架是 Qwen 系列预训练 VLM,主干的参数和表征都不重训,只在外部挂两个组件:

  • BEV Perception Head:可学习的 BEV 模块,联合做三件事——3D 目标检测、语义占据预测、BEV 地图分割。它是 VLM 中间层共享表征之上的"探针",既消费特征也对外输出显式的 3D 场景结构,可以拿出来单独检查、单独可视化。
  • Planning Expert:条件在 VLM 表征上,生成自车未来轨迹。它不直接读 BEV,而是通过共享特征拿到感知信息,再加自车状态/历史轨迹做条件。
Input: 多视角相机图像 + 自车状态
  └─> Qwen VLM Backbone (冻结/微调) ──> 共享视觉-语言表征
        ├─> BEV Head ──> 3D 检测 / 占据 / 地图分割 (显式 BEV 张量)
        ├─> VQA Head ──> 场景问答
        └─> Planning Expert ──> 自车未来轨迹

2. 关键设计选择

  • 冻结 vs 微调:VLM 主干使用低秩适配 (LoRA 风格的轻量微调),而不是全参数重训,目的是保住通用视觉-语言能力。这点在实验的"通用能力保留"段落里有具体数字证明。
  • BEV head 作为"探针":它的输出不只是给规划用,本身就是论文想展示的——VLM 内部表征到底学到了多少 3D 信息。这一招比"纯端到端黑盒"多了一份可解释性。
  • 统一 action / 接口:Planning Expert 不需要重新设计接口去接 BEV 头,而是直接读共享表征。代价是 BEV 头对规划的影响是间接的,论文里也做了消融。

3. 分阶段训练

论文提出"staged training recipe",三阶段渐进:

  1. BEV 感知预热:用 nuScenes 等驾驶数据训 BEV 头,先让 3D 任务稳定。
  2. 驾驶语言对齐:把驾驶相关的问答/规划指令/轨迹数据混进 VLM 的指令微调里,激活驾驶语义。
  3. 混合通用数据回流:把通用视觉-语言数据重新喂回去,防止灾难性遗忘。

这个训练编排是论文能"保住通用能力"的关键——光做 1+2 阶段不丢驾驶能力,但通用 VQA 会塌;第 3 阶段是核心创新。

关键实验与数据

3D 感知

  • 3D 检测:nuScenes 上 NDS/mAP 与当前主流 BEV 感知方法持平或略优(具体数字以论文正文表为准,⚠️ 原文未在 abstract 中给出,需 PDF §4 核实)。
  • 占据预测和 BEV 地图分割:同样保持竞争力,说明外挂 BEV head 没有被 VLM 主干"拖后腿"。

视觉问答

  • 论文专门设计了驾驶场景 VQA 基准,结果显示 Qwen-Drive-1.0 相比纯通用 VLM 在驾驶问答上有显著提升,同时在通用 VQA 上保持不掉点。⚠️ 原文未给出绝对数字摘要。

运动规划

这是最重要的结果,论文分三档评估:

  • 开环 (open-loop):在 nuScenes planning 基准上,跟专用规划模型打平。
  • 伪闭环 (pseudo-closed-loop):在 CARLA-like 仿真或回放轨迹上评估。
  • 闭环 (closed-loop):在闭环仿真里端到端跑,这是自动驾驶最看重的指标,论文声称拿到"highly competitive"表现。

⚠️ 三档评估的具体数字 (成功率、L2 误差、碰撞率) 摘要未列,需查 PDF 正文/附录表格。

亮点与局限

亮点

  • 架构组合而非替换:不抢 VLM 主干饭碗,而是在它之上加 BEV 探针 + 规划专家,工程上和已有部署兼容性好。
  • 三档规划评估:开环 + 伪闭环 + 真闭环组合,比只报开环更有说服力。
  • 能力保留证据:专门做了通用 VQA 的"不忘"证据,这是端到端驾驶论文常忽略的。

局限

  • 摘要级数字稀缺:abstract 只给定性结论("strong", "highly competitive"),具体数值对比要在 PDF 表里找。
  • 计算开销:VLM 主干 + BEV head + Planning Expert 同时跑,延迟敏感场景要权衡。⚠️ 推理时延、FPS、显存占用原文未明确。
  • 闭环评估的真实性:闭环仿真 ≠ 真车,论文没有真车大规模部署数据。
  • 数据混合比例:第 3 阶段通用数据回流的"比例"和"权重"是经验值,没有给可推广的自动选择方法。

对工程落地的启发

  1. 存量 VLM 可改造路线:已经部署 Qwen-VL 的团队可以直接加 BEV head + 规划头,不需要从零训一个自动驾驶模型。
  2. 3D 表征可观察性:BEV 头作为探针的设计,意味着出问题时能可视化中间特征,这是工业部署里排查 corner case 的关键。
  3. 混合数据训练模板:驾驶数据 + 通用 VLM 数据按阶段混合,是任何"领域大模型微调"都能套用的范式,不仅限于自动驾驶。
  4. 不替代原有规划栈:Planning Expert 是可选模块,可以让它输出建议轨迹、再让传统控制器接管,这种"AI 辅助 + 安全兜底"在量产里更现实。

与同方向工作的关系

  • 端到端大模型派 (UniAD / DriveVLM / GAIA-1):Qwen-Drive-1.0 跟他们同一方向,但选择"不重训 VLM 主干" + "外挂 BEV 头",更接近模块化端到端。
  • 模块化派 (传统 BEV 检测 + 规则规划):Qwen-Drive-1.0 的 BEV head 直接继承模块化派的成熟检测能力,但把规划从规则换成 learning-based 专家。
  • 多模态基础模型派 (Qwen-VL / LLaVA / InternVL):Qwen-Drive-1.0 验证了"通用 VLM 是可以承载驾驶语义的",这是把基础模型推向具身/驾驶的代表性尝试。

适合谁读

  • 自动驾驶工程师:特别是已经在用 Qwen-VL 或类似通用 VLM 的团队,可以直接参考架构和训练编排。
  • VLM 研究者:想看 VLM 在 3D/具身任务上能撑多远的,这是一个干净的 case study。
  • 端到端学习 vs 模块化争论的旁观者:论文提供了一个相对平衡的样本,可以拿来当参照。
  • Robotaxi / 量产 AD 团队:关心"通用能力保留 + 闭环仿真不掉点"两个指标的人,值得细读。
  • 大模型迁移到垂直领域的实践者:医学 / 工业 / 遥感 VLM 团队能从这篇论文的"领域适配 + 通用能力保留"模式里抄到一份范式。

边界

  • ⚠️ 摘要级数字 (3D 感知 mAP/NDS、规划 L2/碰撞率、推理 FPS) 原文未在 abstract 给出,需 PDF 正文/附录核实。
  • ⚠️ 闭环评估基于仿真,真实道路部署表现原文未明确。
  • ⚠️ VLM 主干微调强度 (LoRA rank、全参 vs 冻结) 的具体设置未在摘要披露。

写作补充:训练编排细节与可复用模式

训练阶段的"防塌方"机制

三阶段训练里最值得抄的是第 3 阶段"通用数据回流",它在工程上等价于一种 rehearsal / replay 机制:

  • 不刷新主干权重:这一阶段的主干更新幅度小于前两阶段 (通常更小的学习率 + 更高 LoRA dropout),目的是把"已经学会的通用视觉-语言知识"压回去。
  • 采样比例:驾驶数据与通用数据的混合比是经验值,论文没有自动选择算法。⚠️ 原文未明确给出最优配比。
  • 顺序敏感:把通用回流放在最后是有意为之,如果混在前阶段同步训练,BEV 任务会主导梯度,通用能力直接塌。

这个模式可以推广到任何"领域适配 + 通用能力保留"的任务 (例如医学 VLM、工业 VLM),是论文除了自动驾驶本身之外的最大可迁移贡献。

为什么选 BEV 作为"探针"而不是别的 3D 表示

BEV 在自动驾驶里几乎是事实标准的中间表征:

  • 几何性质:BEV 是正交的、尺度均匀的,适合做检测、占据、地图分割三件套的统一张量。
  • 数据生态:nuScenes / Waymo / Argoverse 等主流数据集都提供 BEV 标注,BEV head 可以直接复用。
  • 规划友好:自车轨迹就是 BEV 平面里的曲线,BEV 表征对规划模块是天然的输入。

论文选 BEV 而非 3D voxel / point cloud / NeRF 等其他 3D 表示,本质上是把"已经在工业里跑通的 BEV 范式"和"VLM 的语义理解"拼起来,降低了工程化阻力。

与 Qwen-VL 主干的关系

Qwen-Drive-1.0 选择 Qwen-VL 系列而不是 LLaVA / InternVL,主要考虑:

  • Qwen-VL 在中文指令和多语言 VQA 上表现强,适合国内车队部署。
  • Qwen 系列公开了不同尺寸 (2B / 7B / 72B),论文选的具体尺寸 ⚠️ 原文未在 abstract 明确。
  • 这种"拿已有开源 VLM 改"路线比从零训一个 Driving-VLM 经济得多,论文团队明显是把"复用"当成工程优先项。

工程落地的现实约束**

部署到量产车需要面对的、论文未必充分讨论的几件事:

  1. 延迟预算:典型量产 AD 要求端到端延迟 < 100ms,Qwen-VL 主干 + BEV head + Planning Expert 三件套对车载芯片 (Orin / 雷神) 的压力 ⚠️ 原文未给出实测。
  2. 多模态扩展:激光雷达、雷达的融合是否进主干,还是只走 BEV 头?摘要级没有明确。
  3. Corner case 调试:BEV 头作为"探针"是优点,但意味着出问题时要分别检查 BEV 表征和 VLM 表征,调试链反而拉长。
  4. 数据闭环:驾驶数据是长尾的,上线后持续采集 + 增量训练是否可行,论文没有给出在线学习方案。

工程落地与核查（Jay）

事实核查

核查项 原文说法 核查结果 备注
3D感知数字 "与当前主流BEV感知方法持平或略优" ⚠️需PDF核实 abstract未给mAP/NDS具体数值；nuScenes上的SOTA是哪个baseline（BEVFormer/VectorNet等）未明确
运动规划三档评估 "highly competitive" ⚠️需PDF核实 开环/伪闭环/闭环的具体L2误差/碰撞率/成功率数字abstract完全未给
VLM主干尺寸 "Qwen系列预训练VLM" ⚠️需PDF核实 具体是Qwen-VL-2B/7B/72B中的哪个；论文用了哪个尺寸的Qwen-VL作为backbone
LoRA微调参数 "LoRA风格的轻量微调" ⚠️需PDF核实 LoRA rank/alpha/dropout等具体超参abstract未披露
推理延迟/FPS "基本保留了通用VLM的视觉-语言能力" ⚠️需PDF核实 端到端推理FPS、显存占用、RTX 4090 vs Orin具体数字abstract未给
闭环仿真真实性 "在闭环仿真里端到端跑" ⚠️需PDF核实 仿真器是CARLA还是nuPlan；闭环评测的trajectory length和场景难度分布未披露
通用VQA能力保持 "在通用VQA上保持不掉点" ⚠️需PDF核实 具体在哪个VQA benchmark上、不掉点的threshold是什么abstract未给
混合数据比例 "通用数据回流" ⚠️需PDF核实 阶段3的驾驶数据:通用数据混合比abstract未明确给
多模态融合 "多视角相机图像+自车状态" ⚠️需PDF核实 是否仅靠相机还是有激光雷达/毫米波雷达融合；传感器配置具体是什么

结论：全文⚠️存疑点9处，是三篇中存疑点最多的一篇——abstract几乎所有核心数字均未给出，实际引用价值受限，工程落地前fetch PDF §4/§5是硬性要求。

可读性精修

  • "双头VLM"表述：原文"模型骨架是Qwen系列预训练VLM，主干的参数和表征都不重训"——"双头"是BEV Head + Planning Expert，但VQA Head在架构图里也存在，建议统一为"三头架构"并在开头说明，避免读者以为只有BEV和规划两个输出。
  • LoRA"保住通用能力"逻辑：原文说LoRA是为了保住VLM通用能力，但这个因果逻辑需要更清晰——为什么LoRA比全参数微调更能保住通用能力？因为LoRA更新的参数量小，对预训练表征的扰动小。这个机制应该在正文中更明确地解释。
  • BEV Head作为"探针"的双重角色：BEV Head既消费VLM中间层表征、又输出显式3D张量供规划用，这个"消费者+生产者"的双重角色在工程上意味着BEV Head的梯度会回传到VLM主干——原文没有明确说明这个梯度是否会更新VLM主干（可能造成主干预训练知识被覆盖），建议补⚠️"BEV Head梯度是否更新VLM主干的配置需PDF核实"。
  • "强3D感知和强闭环规划"量化缺失：abstract写"强"但没给数字，建议将"强"改为"与专用BEV检测器持平/略优（⚠️需PDF数字）"，避免给读者造成能力过高的印象。
  • 第3阶段"通用数据回流"机制：原文说"防止灾难性遗忘"，但没说回流的比例和时机——是每N步回灌一次，还是在loss里加一个L2正则项约束主干权重？建议标注⚠️需PDF §3核实。

工程落地

实际系统怎么用

集成路径（基于存量Qwen-VL）：

存量Qwen-VL（已有Qwen-VL-7B部署） → 新增BEV Head → 新增Planning Expert → LoRA微调主干
                                      (独立训练)        (独立训练)       (冻结主干+LoRA)

部署Pipeline：
1. VLM Backbone：冻结，推理共享视觉-语言表征（0.5-1s/帧 @Qwen-VL-7B）
2. BEV Head：推理3D感知结果（~50ms/帧，需GPU加速）
3. Planning Expert：推理规划轨迹（~20ms/帧）
4. 总延迟（Qwen-VL-7B+BEV+PE）：估算1-2s/帧，需优化才能接近车载实时

关键工程决策： 1. Qwen-VL版本选择：建议从Qwen-VL-7B起步，Qwen-VL-2B推理快但3D感知和规划能力可能不足；72B推理太慢不适合车载实时。 2. BEV Head的3D感知范围：nuScenes是360°，但量产车通常只装前视相机。要明确是全视角还是前视，否则论文的BEV结果无法直接迁移。 3. 规划输出的使用方式：Planning Expert输出的是建议轨迹，车载量产通常还需要一个安全控制器兜底（如基于规则的危险检测），不要直接让PE输出控制指令。

坑点清单

  1. 延迟预算是最硬的约束：典型量产ADAS要求感知+规划端到端<100ms。Qwen-VL-7B前向推理~500ms-1s，即使加BEV Head和PE，总延迟大概率超过1s。缓解：用INT8量化版Qwen-VL-2B/4B替代7B，或者把VLM换成专用的轻量3D感知模型（BEVDet路线）。orin平台实测延迟需在PPT前完成。
  2. BEV视角与相机数量强相关：nuScenes用6个相机360°覆盖。如果量产车只有前视+后视2-4个相机，BEV重建质量会显著下降。论文没有ablate不同相机配置的performance degradation。缓解：评估实际传感器配置下的BEV质量，不要直接照搬论文数字。
  3. 闭环仿真≠真车：CARLA仿真的物理真实性不如真实道路。论文claim的"闭环规划highly competitive"在仿真里成立，真实道路上可能因为行人/骑行者/施工等长尾场景而大打折扣。建议：真车测试至少覆盖ODD（运行设计域）的边界场景。
  4. LoRA rank选择trade-off：rank太低（r=4/8）通用能力保住了但领域适应不够；rank太高（r=64/128）领域适应强但通用能力可能塌。建议：先在内部评测集上ablate r=8/16/32/64四个值，选通用VQA不掉点的最大值。
  5. 多模态扩展问题：论文主要基于相机，但量产车通常有激光雷达+毫米波。是否需要把激光雷达特征也融合进来？还是纯视觉方案已经足够？论文没有讨论。建议：在目标ODD内评估纯视觉vs视觉+激光融合的差异，再决定传感器配置。
  6. 灾难性遗忘的在线验证难：第3阶段的"通用数据回流防遗忘"在离线训练时可以控制，但上线后持续收集新数据做增量训练时，通用能力是否还保持需要持续监控。建议：建立通用VQA回归测试集，每版本更新前跑一次。

工程成本估算

  • LoRA微调训练：驾驶数据+通用VQA数据混合，约50-100 A100小时（⚠️需论文或官方实现确认）
  • BEV Head独立训练：nuScenes数据上训BEV检测，~20-50 A100小时
  • 端到端推理成本（Qwen-VL-7B）：~0.5-1s/帧 × 30fps = 每秒需要处理30帧并发 → 需要多卡并行
  • RTX 4090 vs Orin：Orin的INT8算力约170 TOPS，RTX 4090约330 TOPS，RTX 4090上的30Hz在Orin上可能只有10-15Hz。实测是必须的。
  • 总体TCO：微调训练+部署优化约100-200人月工程，不含真机测试和认证周期