这几年视觉语言模型火得不行但真把它用到自动驾驶上很多人第一步就卡住了模型确实能告诉你画面里“有一条路”“有一辆车”但说不清楚这条路离车几米、坡道有多陡、路口怎么延伸更别提让它直接给出一条能踩油门的轨迹。Qwen-Drive-1.0 这个项目想做的事情就是把视觉语言模型从“看图说话”推到“空间推理”这一步——让模型真正理解三维道路结构然后基于理解结果生成可执行的驾驶轨迹。换句话说不再让模型当讲解员而是让它当副驾驶。这篇内容适合三类人看一是做感知算法但想往多模态大模型方向靠的工程师二是做规划控制但苦于规则方案太脆、想试试数据驱动方案的同行三是对自动驾驶好奇、想搞懂“大模型怎么开车”的研究者。我会把整个项目的技术拆解、数据构建、模型改造、轨迹生成和实际踩坑都摊开讲尽量少讲空话多给能落地的思路。1. 为什么视觉语言模型必须“理解三维道路”1.1 从“认识图片”到“感知空间”的认知跨越先明确一个很容易被忽略的前提视觉语言模型本质上是一个“二维图像的语义解释器”。无论模型对图片里的红绿灯、行人、车道线识别得多准它面对的都是一个由像素构成的平面。平面图像天然缺失深度信息模型能告诉你“前方有障碍物”却不知道障碍物是3米外还是30米外能描述“道路向左弯曲”却算不出曲率半径是多少。自动驾驶真正需要的不是“描述”而是“度量”。车辆控制模块需要知道自车坐标系下的精确位置关系、道路边界的三维几何、可行驶区域的空间范围。因此让视觉语言模型理解三维道路本质上是在模型的感知链路里补充一个空间重建环节。你可以类比成一个近视的人摘掉眼镜看得到轮廓但看不清距离戴上眼镜之后他才能从“看到”变成“判断”进而决定要不要迈步。Qwen-Drive-1.0 的第一层设计目标就是给视觉语言模型戴上这副“空间眼镜”——让图像输入经过三维感知模块之后模型拿到的不再是原始像素而是带深度、带坐标的空间结构信息。1.2 项目要解决的核心矛盾传统自动驾驶的感知系统比如基于检测网络和分割网络擅长输出结构化目标但缺少语义理解和上下文推理能力。举个例子前方有个临时交通指示牌传统感知模型只能把它识别成“一个牌子”但无法结合周围施工区域的上下文判断“这里可能要改道”。反过来纯语言模型有语义能力但缺少实时空间感知。Qwen-Drive-1.0 把这两条路径拧在一起整体框架可以拆成两大块三维道路感知从多传感器输入中恢复道路的三维结构包括车道中心线、道路边界、可行驶区域、障碍物位置和运动状态。驾驶轨迹生成在感知结果的基础上结合驾驶意图比如“变道超车”“前方路口右转”生成一串符合车辆运动学约束的路径点序列交给下游控制器跟踪。这两件事单拆开都有成熟方案但把它们放进同一个可微分的视觉语言模型框架里难度就上来了。核心矛盾在于感知模块的坐标输出是连续值语言模型擅长的是离散token怎么设计接口让梯度流动、让模型既能读图又能写轨迹这是项目里最关键的工程决策点。后面我会专门展开。2. 三维道路数据的获取与标注方案2.1 多传感器数据采集与坐标对齐任何三维理解项目都绕不开数据。我们的第一版实验方案用的是标准多传感器套件前视/环视相机加激光雷达配合惯导系统提供自车姿态和轨迹。这套组合几乎覆盖了当前量产车和自动驾驶测试车的主流配置选它的原因也很直接相机提供丰富的语义纹理激光雷达提供高精度的深度真值惯导解决帧间坐标变化。数据采集阶段最容易被低估的是坐标对齐这件事。相机坐标系、雷达坐标系、自车坐标系之间的外参标定稍有偏差后续所有标注和训练都会跟着出问题。我建议在采集之前先做一次严格的外参校验并且在采集过程中定期抽检防止车辆震动导致标定参数漂移。坐标对齐的具体流程一般是通过离线标定工具获取相机到雷达的外参矩阵。将雷达点云投影到图像平面验证投影点与视觉边缘对齐。用惯导数据把每一帧的自车姿态统一到世界坐标系或局部平面坐标系下。对多帧数据进行时间同步确保图像和点云对应的是同一物理时刻。这一套流程做完才能得到一帧带有准确三维空间信息的样本后面所有的标注工程都建立在“坐标可信”这个大前提之上。2.2 三维标注与真值生成策略三维道路标注比二维检测框标注贵得多、也难得多。二维标注只需要框出一个矩形三维标注要给出目标的中心点、长宽高、朝向角还要标出车道线的空间位置和道路边界的三维曲线。对于一个真实路口一帧数据里可能涉及几十个动态目标、多条车道线、复杂的拓扑关系纯人工标注的成本会高到难以承担。我们的数据策略分三层来做第一层用激光雷达点云做自动化辅助标注。点云本身就是三维的聚类算法可以自动抽出物体的轮廓人工只需要确认类别和调整边界框。车道线和道路边界通过点云反射强度和高程变化自动提取初值。第二层用高精地图或采集车多次往返的融合结果生成稳定的道路骨架真值。这一招特别适合固定路线能把单帧不稳定的检测结果融合成准确的道路结构。第三层对难例场景做纯人工精修。遮挡严重的路口、异形车道、施工改道区域自动标注基本都会出错只能拉回标注平台手动调整。这个流程走下来我们大概1个标注人员一天可以完成过去3天的工作量但代价是需要额外写一套标注工具链。如果项目周期紧也可以直接采购第三方三维标注服务价格贵一些胜在省时间。2.3 任务是三维但输入可以“多模态”这里有一个容易被新手忽略的设计点虽然模型最终要理解三维道路但我们并没有只喂raw点云给语言模型而是把视觉输入组织成多模态组合。常用组合包括前视环视的相机图像提供语义细节。激光雷达投影生成的深度图或BEV鸟瞰图提供空间结构。自动标注模块输出的3D目标框叠加图让模型直接看到“哪里被识别成了障碍物”。输入通道越多模型学起来越容易但训练和推理的资源开销也越大。我的建议是前期宁可多给信息也不要让模型自己从零开始学深度估计。空间感知能力可以通过显式的三维特征注入来“教”给模型而不是靠它在大量数据里隐式悟出来。3. 模型架构改造从二维语义到三维空间的接口设计3.1 BEV鸟瞰视角分支与语言模型的融合方式这是整个项目技术含量最高的部分也是决定模型能不能“懂空间”的关键。视觉语言模型的标准结构是视觉编码器把图像变成特征序列语言模型通过交叉注意力读取这些视觉特征再生成文本。这个结构对二维任务是够用的但对三维任务有个致命问题二维图像特征里没有深度信息空间关系是纠缠在像素里的。解决方案是增加一条三维感知分支。常见做法是引入BEV特征编码器把多视角图像或者点云投影到统一的鸟瞰视角网格上每个网格位置就是物理世界中的一个真实坐标。Qwen-Drive-1.0 的做法类似——先生成BEV特征再把BEV特征和原始图像特征一起送给语言模型。这里有个工程细节BEV特征和文本token的维度不一致语言模型不能直接“读”BEV图。我们的处理方式是加一个轻量的空间特征投影模块把BEV特征压缩成固定长度的空间token拼进语言模型的输入序列里。你可以理解为给模型加了一种“空间语言”和文本语言并列模型需要同时理解这两种模态才能输出正确轨迹。3.2 坐标如何编码成模型能回归的目标模型理解空间还不够最终要输出轨迹这就面临连续数值和离散token的转换问题。轨迹点的坐标都是浮点数语言模型没办法直接生成浮点序列至少不能高精度地生成。我们试过几种方案效果差异很大方案做法优点缺点方案A直接回归文本数字让模型输出“x3.5,y4.2”这样的字符串实现简单符合语言模型本能精度差小数值回归非常不稳定方案B离散网格分类把坐标映射到最近的网格点模型只做分类稳定训练容易输出分辨率受限轨迹不平滑方案C目标点回归插值模型只预测几个关键目标点再用后处理插值兼顾稳定性和精度下游可优化需要额外的轨迹平滑模块最终我们采用方案C作为主路线。模型先预测未来3到5秒内的几个关键位置点输出时仍然通过离散化token来表示坐标但每个token不再是直接的数字而是经过归一化的相对坐标偏移量。归一化处理很关键把坐标范围缩到-1到1之间模型收敛速度会快很多。还记得第一次实验时我们直接让模型输出绝对坐标几千次的迭代loss都不降换上归一化相对偏移之后几个小时内就开始出形状了这是个相当典型的实操坑。3.3 从感知到轨迹的指令微调训练数据集和模型结构都定了接下来就是训练。训练分两阶段走第一阶段是感知预训练。在大规模三维标注数据上先让模型学会“看图回答空间问题”比如给定一张BEV图输出障碍物数量、车道数量、可行驶区域范围。这个阶段的目标不是生成轨迹而是建立图像特征和空间语义之间的映射。语言模型本来就有很好的语义理解能力只需要让它熟悉三维特征空间的表达方式。这个阶段可以借鉴常规视觉语言模型的训练经验复制海量图像文本对去微调空间感知头。第二阶段是轨迹微调。在感知稳定的基础上让模型看场景同时输入驾驶意图描述比如“保持当前车道直行”“向左侧变道”模型需要输出对应的未来轨迹点序列。这里对数据质量要求很高轨迹真值要么来自人类驾驶数据要么来自经过验证的规划器输出。我们用的是采集车上一位经验丰富的安全员驾驶数据配合离线质检过滤掉急刹车、蛇形等异常片段。训练资源方面整个项目在单卡上根本跑不动建议至少准备8卡以上的训练环境和充足的显存。视觉编码器部分冻结只训练空间投影模块和语言模型后半段的权重参数量大约只占全文的30%左右这样能把训练成本压低不少。4. 轨迹生成从模型输出到可执行轨迹的完整链路4.1 模型内部的轨迹生成流程推理阶段的流程是这样的输入一组环视图像和激光雷达点云加上一条文本指令“前方路口右转”。感知模块在后台生成三维目标的检测结果和可行驶区域的BEV表示。语言模型融合文本指令和空间token逐步生成未来3秒内的关键轨迹点。输出模块将离散token解码成归一化坐标再映射回自车坐标系。这个过程看起来简单但每一步都有细节。单说语言模型生成轨迹点时解码策略就有讲究。如果使用通用的自回归解码每一步的误差会累积第一步算偏一点、第二步更偏、最后轨迹完全飞掉。我们的解决办法是限制解码步长一次生成整条轨迹的全部关键点而不是逐点递归。轨迹点之间的位置约束在模型内部建模一次性输出显著降低了误差漂移。4.2 后处理让轨迹从“看起来像样”到“真的能开”模型输出的轨迹哪怕精度不错直接丢给底盘控制器也绝对不行。因为语言模型输出的轨迹天然缺少运动学约束连续性。车辆有最小转弯半径、有加速度限制、不能瞬移这些在模型训练时很难全部建模下来必须做后处理。我们的后处理管线包含四个步骤平滑滤波用滑动平均或样条拟合消除轨迹点抖动。运动学校验逐点检查曲率是否超过车辆最小转弯半径超限就强行修正。安全校验把轨迹与障碍物的三维框做碰撞检测有碰撞风险的片段直接裁剪或重规划。速度规划为轨迹附加上限速度曲线保证刹车距离在安全范围内。这个后处理环节也是整个系统最能兜底的地方。模型再怎么聪明也会偶发输出不合理轨迹规控模块的勒索性校验能把这类风险降下来。一个经常被问的问题是既然后处理能做这么多事为什么不完全依赖传统规划器答案在于模型的泛化能力。传统规划器在陌生场景需要依赖预设规则而模型能结合语义理解做出更柔性的决策比如看到施工绕行标识会主动规划绕行路线这种能力来自多模态大模型的灵魂所在——语义理解与推理。4.3 评估指标与实验效果对比评估轨迹生成质量我们主要盯着这几个指标指标解释我们的目标值ADE 平均位移误差预测轨迹点与真值轨迹每个点的平均距离小于0.8米FDE 末点误差预测终点与真值终点的距离小于1.5米碰撞率生成轨迹与障碍物发生碰撞的比例低于1%语义合理率人工判断轨迹是否符合驾驶常识的比例高于95%实验数据显示在标准场景下模型的FDE可以达到1.2米左右这已经接近端到端规划器加后处理方案的准确度但模型的语义理解能力给复杂场景带来了额外优势。有一次测试场景是前车遮挡下的小路口左转传统规则方案因为无法判断路口内部的潜在冲突选择了保守等待我们的模型结合对路口形态和周围车辆意图的推理生成了一个缓慢谨慎的左转轨迹。这类决策是让整个团队坚信这条技术路线值得继续深挖的直接原因。5. 实操中的踩坑记录与排错指南5.1 三个代价惨重的工程坑第一个坑是坐标系符号不统一。我们早期有一版数据部分标注组用的是相机坐标系另一部分用自车坐标系两个坐标系的正方向和原点都不同合并训练时模型指标完全崩盘。排查问题花了一周时间最后发现是标注工具配置写错了。这个问题的教训是项目启动前必须定义全局唯一的坐标系规范并且用自动化检查脚本对每帧数据进行坐标合理性验证。比如所有物体必须在自车前方一定范围内所有车道线不能出现在车身下方这种规则检查成本极低但非常有效。第二个坑是遮挡场景的标注质量。有一次一个路口场景有很多车辆排队目标互相遮挡严重。自动标注把被挡住的车辆漏了人工复核时又只看图像不看点云结果漏标目标直接被模型当成“行车空间可用”生成的轨迹就从那辆被挡住的车身上穿过去了。事后我们补了一批遮挡场景的专项数据并在训练时加入随机遮挡增强碰撞指标才有了明显改善。第三个坑是长场景推理误差累积。在连续驾驶实验中模型每帧生成轨迹但前一次轨迹的误差会带进下一帧的观测。跑了十几分钟之后轨迹明显向右偏移越偏越多。减少误差累积的方法是把上一帧的轨迹输出作为下一帧的空间token输入之一让模型意识到自己之前的动作形成闭环反馈。这个改动看起来很直白但对稳定性的提升非常明显。5.2 可视化调试工具是项目隐形功臣做三维感知项目最怕的不是模型不收敛而是模型收敛了但你看不懂它学到了什么。我们团队早早就搭了一个可视化调试平台每次训练迭代的中间结果都会实时展示BEV特征图、预测轨迹、三维障碍物框、障碍物速度向量叠加在同一张俯视图上。这个平台看起来没什么技术含量但实际排查问题的效率提升了几倍。举个例子模型某个版本总是对右侧来车反应迟钝。仅看指标数字只能发现碰撞率上升但打开可视化之后一眼就能看出模型生成的轨迹在时间维度上不够敏捷反应总是慢半拍。后来我们排查发现训练数据的采样频率和真实场景不一致时间步长设置有问题。这类问题单靠数值指标根本定位不了可视化真的是最直接的诊断工具。5.3 从仿真到实车的落差处理思路真实部署又是一个全新的挑战仿真里跑得好不等于路上跑得好。首当其冲的是推理延迟。语言模型推理相对较重哪怕是精简版本单帧推理也要上百毫秒。而轨迹规划环节通常需要闭环频率达到10赫兹以上这就需要我们在工程上做分层降频感知和语义推理以较低频率运行传统控制器在高频率下执行轨迹平滑跟踪。另一个落地的挑战是环境复杂度的分布变化。训练数据主要在晴天、标准城市道路采集一旦遇到暴雨或夜间场景模型的输入分布偏移明显指标下降很快。处理这个问题的思路不是无限加数据而是加一个基于不确定性的安全策略模型输出置信度低时自动降级为保守模式减少变道、降低车速把风险控制在可接受范围内。最后分享一点个人体会项目做到后期我越来越意识到这类技术能否真正落地往往不在模型本身多聪明而在数据、工程和系统设计是否稳固。视觉语言模型给自动驾驶带来了更强的语义推理和场景理解能力但基础的真实空间度量、运动学约束、安全校验依然是底盘工程的核心。几次踩坑下来我最深的感觉是模型的输出永远要当作“一个聪明但不够靠谱的建议”而不是可以直接执行的命令。你要做的是让它参与到决策和规划流程中去而不是让它主导整个系统。目前这个方向还可以继续往外延伸比如把历史多帧空间信息压缩成记忆模块让模型具备短时记忆或者引入人类驾驶偏好做个性化轨迹生成让自动驾驶的乘坐体验更接近真人司机。但说实话这些扩展的前提都是先把三维感知和轨迹生成的闭环做扎实。希望这篇拆解能给正在往这个方向探索的朋友一些真正有用的参考至少让你少走几个我已经帮你踩过的坑。