Qwen-Drive-1.0这个方向最近讨论度很高。它把通用视觉语言模型VLM拉进了自动驾驶的核心流程但真正让我觉得值得写一篇长文的不是它又刷了多少榜单而是它把问题定义换了一个能上车的视觉语言模型缺的不是更多问答能力而是可检查的3D与轨迹接口。如果你跟我一样过去两年既在追多模态大模型又没少被端到端自动驾驶的黑盒问题折磨那你应该能立刻get到这个变化的重量。以前我们看VLM自动驾驶的demo基本都是让模型对着一张路测图回答“前方有没有行人”“能不能变道”模型答得头头是道可一旦要把它接进真实规控管线马上发现无从下手输出的文字没有坐标、没有时间戳、没有可量化的置信度更没有可以被下游模块直接消费的结构化接口。Qwen-Drive-1.0想做的是另一件事让视觉语言模型不仅能“看懂”场景还能直接吐出任一步骤都能回放的3D感知结果和多模态轨迹预测结果。这篇文章就围绕这个点展开聊聊它为什么卡在“3D与轨迹接口”上以及我们做工程落地时该怎么理解、验证、使用这类接口。适合正在研究多模态大模型、端到端自动驾驶、数据闭环或者被“黑盒模型能否上车”这个问题困扰的同行一起讨论。1. 先聊清楚VLM上车为什么光会“答问题”远远不够1.1 Qwen-Drive-1.0在做什么先说结论Qwen-Drive-1.0不是又一个“看图说话”的驾驶问答模型而是把视觉语言理解与自动驾驶的结构化输出结合在了一起。它仍然保留了VLM的场景理解、常识推理、复杂指令跟随能力但更重要的是它在模型输出侧增加了可被自动驾驶系统直接读取的接口其中最关键的就是3D感知接口和轨迹预测接口。这么说可能有点抽象我拆开讲。视觉语言模型本质上是一个多模态Transformer输入是图像/视频加文本输出是文本这是大家熟悉的范式。但自动驾驶场景里文本输出只能用于人机交互、离线分析、知识问答它没有办法直接变成方向盘的转角、刹车踏板的力度。Qwen-Drive-1.0这类模型的设计思路是在VLM主干之上增加专门的输出头把“对场景的理解”转成“对驾驶有用的一系列数值和结构化数据”比如3D目标框、占用网格、未来轨迹点序列。这类设计在业界其实已经有一些探索比如把VLM当作“感知增强器”在传统规控管线上做辅助决策也有把大模型当成“端到端决策器”直接输出轨迹。Qwen-Drive-1.0更接近后者但它特别强调了一个词可检查inspectable。这意味着模型的每一项关键输出都能被开发人员“打开看一看”能回放、能验证、能干预而不是丢给你一个神经网络内部的隐向量。1.2 问答式VLM在真实驾驶场景里为什么不好使很多刚接触这个方向的同学会疑惑让模型多回答几个问题比如“前方是什么车”“这个路口能不能左转”难道不是也能辅助驾驶吗我的经验是这类“问答式”输出在真实驾驶任务中有三重结构性短板。第一没有几何信息。自然语言说“前方有一辆车”但规控模块需要知道这辆车在哪距离多远、横向偏移多少、朝向如何、速度多快。语言描述可以给出相对位置却给不出精确的几何参数。前方是一辆停在路边的车还是一辆正在汇入我车道的车对决策的影响完全不同只靠问答根本没法区分清楚。第二没有时序信息。自动驾驶是做预测和规划的模型需要回答的不是“此刻图里有什么”而是“接下来三到五秒会发生什么、我该怎么办”。单帧问答顶多描述当前场景无法给出未来轨迹。十字路口是直行还是左转、前车会不会急刹、行人会不会横穿这些决策不仅依赖当前帧更依赖对未来的估计。第三没有闭环接口。就算模型用自然语言说出了“应该减速”直接把这个文本发给下游控制器也是不可行的。真实自动驾驶系统有用例驱动的接口约定规划模块能消费的是轨迹点、速度曲线、目标框列表不是一句话。问答式输出只能做展示和人机交互无法参与实车闭环。这也是很多演示项目“看起来酷、用不起来”的根本原因。1.3 “可检查的3D与轨迹接口”到底指什么把这个问题想透之后你就能理解标题里那句判断的真正分量通用视觉语言模型走向自动驾驶缺的不是更多问答而是可检查的3D与轨迹接口。这里的“3D接口”指模型能输出带三维几何意义的感知结果比如3D目标框、BEV栅格、占用网格、深度估计等。有了这些输出系统才能在一个统一的三维空间里讨论“我”和“其他物体”的相对关系。光有2D检测框是远远不够的因为2D框没有深度无法知道前车距离是10米还是50米。“轨迹接口”指模型能输出未来一段时间内自车的行驶轨迹通常是一串带时间戳的waypoint也可能是多条候选轨迹和对应的置信度。轨迹接口是连接感知与决策的桥梁有了它下游控制模块才能执行“向左变道”“跟车减速”等具体操作。“可检查”要更细一层。它意味着每个输出都有明确坐标系、时间戳、物理单位可以回放到原始传感器数据上进行验证。3D框可以投影回图像里看对不对轨迹预测可以跟真实人类驾驶轨迹做对比还可以在仿真环境里闭环测试。这种“能验证、能调试、能干预”的特征是量产自动驾驶工程最看重的东西。2. 核心设计思路拆解从“图片文本”到“3D空间预测轨迹”2.1 3D感知分支怎么构建“带坐标的视觉”我见过不少团队尝试把VLM用于驾驶理解最常见的方式是把图像直接扔进Transformer让模型输出自然语言。这种路子对封闭数据集有效但一到开放道路就露馅根本原因是没有几何坐标系的概念。Qwen-Drive-1.0在架构上很关键的思路是在VLM主干之上接一个3D感知头。这个感知头会把多视角摄像机图像、自车姿态、可选的点云信息融合起来生成BEV鸟瞰图特征然后在这个特征基础上输出3D目标框列表和占用网格。BEV之所以重要是因为它把所有检测结果都投影到了自车坐标系下的一个水平平面上上游感知和下游规控能共用同一套空间语言。具体到输出项3D接口至少包括这几类目标类别、3D中心坐标通常以自车为原点x为前向y为左侧单位米、目标长宽高、朝向角yaw角、速度估计。此外很多方案还会输出带语义的占用栅格occupancy grid把可行驶区域、障碍物、未知区域都画到一个栅格上。这里有一个值得注意的技术细节为了得到高质量的BEV特征很多模型会用到3D卷积或者3D卷积自编码器这类结构。因为BEV特征本身是H×W×C的立体张量如果在空间维度上只用2D卷积很难捕捉物体遮挡、竖向上的结构信息。3D卷积自编码器可以学到一个紧凑的场景表示把多帧观测压缩成更容易被轨迹解码器使用的特征。2.2 轨迹接口为什么不是“输出一条线”那么简单很多非自动驾驶背景的人第一次听到“轨迹接口”会以为就是一个简单的坐标序列。实际远不是这么回事。一个合格的轨迹接口必须同时表达“我想怎么走”和“我有多确定”。Qwen-Drive-1.0这类模型在轨迹分支上通常输出多条候选轨迹每条轨迹由未来若干时刻的waypoint组成每个waypoint包含位置坐标、朝向、速度等。为什么要多条因为驾驶决策本身是多模态的同一个路口我可以直行也可以左转这是两种完全合法的行为。只给一条轨迹等于强行砍掉了决策的多样性遇到突发事件很难有备选方案。每条候选轨迹会带一个概率或分数表示模型认为这条轨迹的合理程度。更重要的一点是轨迹分支应该能让开发人员看到“模型是依据哪些场景特征做出这个判断的”。比如模型预测前车会减速那这个预测应该能追溯到前车的3D位置、相对速度、刹车灯状态等具体线索。这样一来轨迹输出就不再是黑盒里的一个向量而是一个可解释、可审计的决策结果。这也是我在实操中最看重的一点轨迹接口和自然语言解释最好同时给出且相互对齐。自然语言说“我要变道”轨迹接口就必须真的输出一条变道曲线两条输出不能打架。一旦语言描述和轨迹出现不一致测试阶段还能接受实车阶段就是安全风险。2.3 统一接口架构怎么把VLM“接进”自动驾驶系统模型设计得再好如果不能融入现有自动驾驶软件栈价值也大打折扣。这里说的软件栈通常包括感知perception、预测prediction、规划planning、控制control四个模块。Qwen-Drive-1.0给出的方案是把VLM的输出设计成下游模块可以直接消费的标准格式。3D感知接口对接的是传统的感知模块和Fusion模块轨迹接口对接的是规划和控制模块。换句话说它不是在旁边外挂一个“智能问答盒子”而是让自己成为新的感知与决策主干。我在工程实践里有一个很深的体会接口设计决定了模型能被工程接受的下限。如果接口是自定义的私有格式团队就得专门写一堆适配代码如果接口贴近行业通用标准例如类似Apollo、Autoware这类开源框架的消息格式那集成成本会低很多。Qwen-Drive-1.0至少在接口形态上走了对的方向3D输出与轨迹输出从数据结构上看都是可反序列化、可记录、可回放的。这对后续的数据闭环和测试验证非常友好。3. 实操落地视角数据、时间同步与仿真评测是三道硬门槛3.1 数据闭环里最容易被低估的事3D标注质量做这类模型数据质量几乎决定上限。我可以负责任地说绝大多数团队跑不通VLM自动驾驶不是模型实现不了而是数据准备阶段就垮了。训练3D感知分支和轨迹分支需要海量带精确3D标注的自动驾驶数据。传统自动驾驶数据集比如nuScenes、Waymo Open Dataset、Argoverse都提供了3D框、轨迹真值、传感器标定和时间戳信息是很好的训练底座。但对于VLM模型的特殊之处在于它还需要同时提供自然语言描述或问答标注这就是很多研究团队会用DriveLM、NuScenes-QA这类驾驶语言数据集的原因。真正容易踩坑的是3D标注噪声。自动驾驶数据集里远处小目标经常漏标遮挡严重的物体边界框不稳激光雷达盲区里的目标可能干脆没有标注。如果模型在全是漏标的区域被训练出来感知结果就会显得“有选择地失明”。我曾经在调试一个模型时发现它对右侧相邻车道的大货车检测极不稳定后来查数据才发现数据集中货车类别的3D框标注本身就前后不一致。这个问题不解决后面的轨迹预测再漂亮都白搭。3.2 时间同步3D感知和轨迹预测绕不开的坑说到做自动驾驶数据处理时间同步绝对是被新手忽略最多、却最容易引发诡异问题的一环。3D感知通常融合多路传感器摄像头、毫米波雷达、激光雷达。各路传感器采样频率不同延迟也不同如果时间戳没有对齐就会出现一个很尴尬的现象摄像头看到的是t时刻的场面激光雷达扫描的已经是t30ms的场面融合出的3D框在高速场景下直接“飘”出去。轨迹预测对时间同步更敏感模型要预测的是“当前时刻之后3秒”的轨迹如果当前时刻本身就不准那预测结果就成了“对错误时刻的准确预测”。实践中做时间同步最基本的是把毫米波雷达、激光雷达点云、图像都外推到统一时间戳通常以控制器或融合模块的主时钟为基准。更成熟的做法是引入协方差插值、动态延迟补偿在传感器驱动层面就算好每一帧数据的“有效时刻”。我还想提醒一点时间同步不只是传感器之间的事模型输出的轨迹时间戳也得和传感器时间基准对齐。如果模型输出的waypoint是基于“收到图像那一刻”的而下游规划模块计算时用的是“当前控制周期开始”的时刻两者之间差出几十毫秒到上百毫秒在高速变道场景就是半米到几米的偏差。3.3 模型的仿真与闭环评测该怎么做接口可检查的好处在测试阶段体现得最充分。我做这类模型验证时习惯分成两个阶段开环测试和闭环测试。开环测试阶段把测试数据跑一遍比较模型的3D检测与真值框的重合度比较轨迹预测与人类驾驶轨迹的误差。常用指标包括3D目标检测的mAP、平均位移误差ADE、最终位移误差FDE、碰撞率等。这些指标能快速暴露模型在感知和预测上的明显缺陷优点是快、可控、可复现。闭环测试阶段把轨迹接口插到仿真器里跑。常用的有CARLA这类高保真驾驶仿真器模型输出的3D感知结果作为仿真器的“虚拟传感器输入”或真值替换轨迹输出直接驱动虚拟车辆。重点观察模型在连续场景里能不能稳定行驶变道会不会压线、路口起步会不会犹豫、面对突然切入的车辆会不会急刹。开环我见过模型单帧指标很漂亮可一进闭环就频繁被后方来车逼停原因往往是轨迹多模态不够丰富只预测了“前车保持车道”这一种未来没有给“前车变道”留候选。仿真评测阶段最重要的一个原则是接口日志必须齐全。每个决策点对应的3D目标框、候选轨迹、最终选中的轨迹都要能逐帧回放。否则出了问题你想查是感知错了还是决策错了根本无从下手。4. 行业路线观察为什么“可检查接口”是量产的关键分水岭4.1 端到端与模块化之争接口是最大公约数自动驾驶行业这两年争论最多的话题之一就是端到端大模型方案和传统规则模块化方案到底谁更优。端到端方案的优势是决策流畅、系统简单、能学习复杂交互缺点是解释性差、安全验证难、遇到分布外场景没有兜底。模块化方案可控性强、容易验证但工程浩大、规则之间打架严重。Qwen-Drive-1.0走了一条很有意思的中间路线底层依然是VLM这种端到端的大模型表现形式但输出层固定为结构化接口。这种做法相当于把“模型内部的自由发挥”限制在了3D框和轨迹这个语义层保住了神经网络的模式识别能力又给了工程师一个可以介入、校验、监督的抓手。从我的实际经验来看这种“可控式端到端”是当前最有可能落地的方向。纯黑盒端到端安全评审委员会大概率一票否决纯规则系统又很难覆盖长尾场景。把大模型输出统一成可检查的结构化接口等于告诉所有利益相关方我在黑盒和透明之间找了个折中点你想看细节随时可以看你想干预随时可以接。4.2 周边技术生态3D高斯泼溅、占用网络和数据集进化可检查的3D接口能成为趋势离不开周边技术的共振。占用网格occupancy grid这几年已经成为自动驾驶感知的主流表示它把场景切分成均匀网格每个网格标注是否被占用、被什么东西占用。Qwen-Drive-1.0用BEV和体素化的思路本质上是同一套语言所以天然容易融合。另一个值得关注的是3D高斯泼溅。这个技术本来主要应用于三维重建和渲染现在也被一些团队用来表示动态场景。如果未来VLM可以用3D高斯泼溅生成可查询的场景表示那“3D接口”从技术形态上还会有一次升级模型输出的不再只是一个网格而是一个连续、可渲染、可动态更新的场景模型。这种表示比固定栅格更细腻也更适合做决策层的空间推理。我还想强调数据集进化的方向。现有的驾驶问答数据集比如DriveLM、NuScenes-QA主要提供图像问题的文本答案这对VLM的对话能力有帮助但对驾驶任务的直接帮助有限。下一阶段的驾驶语言数据集必须把自然语言问题和3D框、轨迹真值绑在一起甚至要做到“同一段数据既有问答标注又有轨迹标注”。模型才能真正学会把语言理解和结构化输出统一起来而不是两条腿走路。4.3 对研发团队的影响岗位和流程都会跟着变这个话题看起来偏管理但实际上对每个做技术的人都有影响。过去自动驾驶团队分工很清晰感知组交付目标框预测组交付轨迹规划组负责决策。VLM带着可检查接口进来之后这种边界会被打散。VLM团队和感知团队对接的是“3D接口的精度和召回”和预测团队对接的是“多模态轨迹的分布合理性”和规划团队对接的是“候选轨迹是否满足安全约束”。如果一个团队只把自己当成“做模型发论文的”不关心接口能不能被下游消费很快就会被替换掉。这也是我在带项目时反复强调的一点模型输出必须像API一样设计明确输入、输出、异常处理、版本兼容。4.4 它会不会替代传统规控模块很多人问既然VLM都能输出轨迹了那是不是传统规划控制模块就没用了我的看法是短中期内不会也不应该。轨迹接口提供的是“行为建议”不是“控制指令”。它缺少安全兜底没有碰撞检测和最小风险机动策略遇到完全超出训练分布的极端场景没有人敢把方向盘完全交给一个1050亿参数的大模型。更合理的做法是VLM输出多条候选轨迹和理由下层安全模块做碰撞检测、交规校验最后由仲裁模块决定执行哪一条或者是否转入安全停车。轨迹接口成了大模型和传统系统之间的“合同”“我给你的是一系列可选行为以及每个行为的依据你来兜底。”这种分工既保住了大模型的理解能力也保住了系统安全性的底线。5. 工程落地中的常见问题与避坑实录5.1 常见问题速查表问题现象常见原因排查建议3D框投影回图像对不上框在图像上大幅度偏移坐标系搞混模型输出在自车系投影时当成相机系统一坐标变换链路增加投影可视化工具轨迹预测在高速场景飘预测轨迹抖得厉害时间戳对齐误差大做时间同步校准检查各传感器延迟补偿自然语言说“要变道”轨迹却是直行语言解释与轨迹输出矛盾两个分支训练目标隔离增加语言和轨迹一致性约束做联合微调闭环仿真频繁急刹行驶体验差、撞车概率高轨迹多模态不够只给出单一预测增加候选轨迹数量强制覆盖不同驾驶意图感知漏检远处小目标3D框召回率低数据集标注漏标长尾样本不足做难例挖掘补充小目标数据集这张表里的问题我在不同项目里至少都撞到过一遍。尤其是第一行“坐标系搞混”听起来很基础但在实际开发中极其常见。相机坐标系、激光雷达坐标系、自车坐标系、世界坐标系每经过一次变换都可能引入一次手误没有可视化的投影校样这类错误能潜伏很久。5.2 我判断一个“可检查接口”是否合格的三个标准面对任何一个宣称支持3D或轨迹输出的VLM模型我拿到手的第一步不是跑榜而是先看三个基本问题。标准一每个输出都能对应回输入空间。3D框能不能投影回原始图像占用网格能不能和激光雷达点云叠加显示如果能说明系统在空间上是可验证的如果不能那么这个接口的可检查性就是纸上谈兵。标准二每个输出都有明确的物理单位。位置是米速度是米/秒朝向是弧度或角度时间戳是哪一时刻。很多模型论文只给一个坐标数组根本不标注单位这种接口在工程上几乎不可用。没有物理单位的输出连安全评审的门槛都迈不过去。标准三每个输出都有明确坐标系定义和时间戳。我在实际集成时吃过一次大亏模型输出的轨迹点看着完整后来才发现它用的是“接收图像时的自车坐标系”而不是“当前时刻的自车坐标系”在一段高速变道场景里直接偏出去两米。这个教训让我后来对所有接口都强制要求坐标系和时间戳必须在消息结构里显式声明。5.3 给正在做相关工作的工程师几条经验第一句话先跑通一条最小路径再去追求模型大小。选一段简单的结构化道路场景用现有数据集训练一个能输出3D框和轨迹的小模型先把接口整条链路跑通再谈增加参数量。第二句话把自然语言当作解释层别当作控制层。语言输出适合做人机交互、离线分析、系统诊断但它不应该成为唯一决策来源。控制层面必须依赖结构化接口否则没有任何安全机制能兜底。第三句话做数据闭环时把模型的“不确定帧”捞出来人工复核。模型在哪帧轨迹出现明显偏离、在哪帧3D检测漏报这些就是数据闭环最值得回传的数据。回传后重新标注、增量训练比一股脑堆数据效率高得多。第四句话不要忽略低算力设备上的实时性。模型设计的再花哨上不了车也没有意义。Qwen-Drive-1.0这类视觉语言模型普遍参数规模不小真正用起来还需要考虑量化、剪枝、计算图优化以及和车端芯片的适配。我在实测中发现接口设计如果能做成计算友好的形式比如提前把3D检测和轨迹预测分成不同频率执行实时性压力会小很多。5.4 从研究到产品的后续扩展空间如果你读到这里想沿着这个方向继续做点什么我个人觉得有四个可以深挖的点。一是把轨迹接口和自然语言解释做更深度的对齐让模型不仅“会开车”还能“会解释为什么这么开车”。二是在3D接口里引入更稠密的场景表示比如体素占用加上语义类别让模型对复杂城市障碍物有更细粒度的理解。三是做多传感器时间同步与建模的联合优化把时间同步从“预处理环节”变成“可学习的环节”。四是构建更高质量的驾驶语言轨迹联合数据集这件事单独作为工程课题都有很大的价值。我个人的体会是这几年从大语言模型火到多模态大模型再到VLM上车技术迭代很快很多团队容易陷入“追着参数和榜单跑”的惯性。但自动驾驶这个领域真正的护城河不是模型能答多少问题而是整个系统在复杂危险的世界里亏多少分可控。Qwen-Drive-1.0把“可检查的3D与轨迹接口”放到了台面上等于给了所有做落地的人一个信号大模型要上车先得让系统看见它、验证它、管住它。接口的可检查性不是学术洁癖是工程底线。