视觉语言模型在自动驾驶上火了但坦白说圈子里不少讨论都跑偏了——大家拼命往模型里塞各种问答数据好像让模型多看几张图、多答几个问题车就能开稳。Qwen-Drive-1.0这个方向反而点破了关键通用视觉语言模型走向自动驾驶缺的根本不是更多问答而是一层能被检查、能被验证、能和下游规控闭环的3D与轨迹接口。我在自动驾驶行业摸爬滚打了这么多年从传统感知到端到端模型都做过看到这个思路时确实有点共鸣。今天想从实际工程角度聊聊为什么接口比问答更重要3D接口和轨迹接口到底该怎么设计以及落地时有哪些躲不开的坑。1. 视觉语言模型上车为什么大家一拥而上却容易跑偏1.1 从“看图说话”到“看路开车”VLM到底强在哪先理清一个概念。视觉语言模型VLM本质上是一个多模态模型它把图像编码器和语言模型粘在一起——图像进来先经过视觉编码器变成特征再交给语言模型去理解、推理、生成回答。过去几年火起来的大模型本质上都是在“预测下一个token”但加上视觉编码器之后模型就多了一双眼睛能看到真实世界的图像、点云、视频然后基于这些视觉信息做语义层面的推理。在自动驾驶场景里VLM的优势是显而易见的。传统感知模型可以检测出“前方有一辆白色轿车”但很难理解“前面那辆车打了右转向灯旁边车道还有空隙它很可能要向右变道”。这种对交通参与者意图、场景上下文、罕见状况的综合理解恰好是VLM最擅长的事情。模型能看图说话、能做常识推理这就让自动驾驶系统具备了处理长尾场景的潜力——比如路边摆放的临时施工牌、前车掉落物、交警手势这些都是规则引擎很难预先穷举的情况。1.2 纯问答路线的三大局限很多团队做VLM上车走的是“多模态问答”的路线喂一张前向摄像头图像让模型用自然语言描述场景或者回答“前方是否可以变道”“有没有危险”。一开始效果看起来不错demo视频也很惊艳但只要往量产方向细想就会发现纯问答路线有三个硬伤。第一个硬伤是信息瓶颈。自然语言是一个高度压缩的离散符号系统你说“前方有一辆车离我们很近”这句话丢失了大量信息——车在哪个车道、横向距离多少、纵向距离多少、相对速度是多少、它的朝向角如何语言可以描述定性的趋势但无法输出定量的、毫秒级精确的几何信息。第二个硬伤是不可验证性。大模型天生会幻觉让它描述一个没有行人的画面它也可能煞有介事地告诉你“右前方有一个行人正在横穿马路”。如果这个描述直接送去规划模块那就成了事故源头。语言输出的东西不是结构化数据没法做传统的阈值判断、协方差校验、真值比对可靠性完全无从谈起。第三个硬伤是和下游脱节。规划控制模块要的不是句子是障碍物在自车坐标系下的坐标、多边形轮廓、速度矢量或者是未来几秒内自车的期望轨迹。你给规划器一段文字“请减速并向右避让”规划器根本没法直接用。中间还得翻译而翻译的过程就会损失信息、引入错误。所以结论就出来了通用视觉语言模型想做自动驾驶关键不是让模型“会说话”而是给模型加一层“手脚”——把语义理解翻译成几何与轨迹的接口。这个接口必须是显式的、可检查的、能对接传统自动驾驶技术栈的。Qwen-Drive-1.0提出的方向就是在视觉语言模型之上构建3D接口和轨迹接口让模型不仅“看懂”了路还能把看懂的东西落到物理世界的坐标和路径上去。2. 3D接口让模型真正站在物理空间里思考2.1 为什么要显式的3D表达而不是2D框加文字如果VLM只输出2D检测框和自然语言描述它在物理世界里根本无法闭环控制。2D检测框是图像平面上的像素坐标它不包含深度信息也不包含物体在自车坐标系下的真实位置。摄像头图像本身就是透视投影的产物——一个近距离的小物体和一个远距离的大物体在图像上可能占相同大小的面积。举一个我实测中遇到的例子。前向摄像头检测到一个“疑似障碍物”的2D框它既可能是一辆距离5米的电瓶车也可能是一辆距离50米的大货车。如果没有深度估计和3D定位这个感知结果对规划模块来说几乎没有价值——因为不知道障碍物到底在哪里、什么时候会撞上。所以3D接口的第一层含义就是要让模型输出物体在自车坐标系下的3D位置、尺寸、朝向甚至是占据栅格或密集深度。这样才能和传统感知链路——比如激光雷达点云、毫米波雷达检测结果——做融合、交叉验证。自动驾驶是一个对精度有极高要求的系统厘米级的误差在高速场景下会被放大成致命的碰撞风险。VLM的输出必须落在3D空间里才算真正和下游打通。2.2 Qwen-Drive-1.0中3D接口的实现路径从行业里公开的技术趋势和我个人的工程经验来看给VLM加3D接口有一套比较成熟的路径Qwen-Drive-1.0大概率也是沿着类似方向走的。基础方案是在视觉编码器后面加一个3D感知分支用查询query机制去解码BEV鸟瞰视角特征或者3D空间特征而不是让模型直接生成文本。具体来说可以设计一组“3D锚点查询”——每个查询对应三维空间中的一个位置或区域——让模型在这些锚点上输出目标的类别、尺寸、朝向和速度。这样就把VLM的视觉理解能力嫁接到了一个结构化的几何输出上。更进一步可以用3D高斯泼溅或神经辐射场类的技术来建模场景。3D高斯泼溅这几年很火它本质上是把连续场景表达成一组可微分的3D高斯分布能够从多个视角的图像中重建场景的几何和外观。好处在于它天然支持多视角一致性还能渲染出任意视角的图像。对自动驾驶来说这意味着模型可以不只理解“当前这一帧图像”而是在一个统一的3D场景表征里理解整个周围的动态环境。Qwen-Drive-1.0如果想把通用视觉理解能力真正用起来这样一个3D场景表征层几乎是必需品。实际落地的时候还要考虑传感器配置。纯视觉方案能输出3D但直接测距精度不够尤其是夜间、逆光、雨雪天气。所以量产车上一般会做激光雷达和摄像头的多模态融合——激光雷达提供精确的几何骨架摄像头提供丰富的语义纹理再把两者通过3D接口合并成统一的传感器表征喂给VLM。这里的关键是“显式”两个字3D接口不应该隐藏在模型的黑盒子里而是应该能导出成清晰的坐标、帧、类别、置信度让人能看、能查、能校验。2.3 设计3D接口时最容易出错的几个细节我在实际工程中踩过不少坑这里挑几个关键细节说。首先是坐标系。自动驾驶里至少有四套坐标系——图像像素系、相机系、车体系、世界系。3D接口必须明确约定输出落在哪个坐标系里。我见过有团队让模型直接回归图像坐标结果在弯道上车辆位置和人眼看到的画面完全对不上。正确的做法是统一到自车后轴中心的车辆坐标系输出X为纵向、Y为横向或相反单位统一用米角度用弧度。其次是时间同步。相机和激光雷达的采集时刻如果不同步哪怕只差几十毫秒在车辆高速行驶时都会产生显著的位移误差。一辆以30米/秒行驶的车50毫秒的时间差就意味着1.5米的定位误差这在高速汇入场景中是致命的。接3D接口时必须做传感器的时间戳对齐必要时做运动补偿Motion Compensation。第三是输出格式的可检查性。3D接口最好同时输出三样东西数值结果、结构化语义标签、可视化渲染图。比如模型输出“前方50米处有一辆白色SUV速度约10米/秒”除了保存结构化数据外还应该把3D框/占据栅格直接渲染到图像和BEV图上让测试人员一眼就能看出模型是否理解错了场景。没有可视化检查工具3D接口就是不可调试的黑盒几千小时的测试数据也会因为无法快速排查而大打折扣。注意3D接口本质上是一个转换层——它把VLM的语义推理能力“翻译”成物理可度量的几何信号。做这个转换层时优先保证输入的传感器数据经过时间同步和内外参标定否则任何基于几何的下游任务都会是空中楼阁。3. 轨迹接口不只说“前方有危险”而是给出一条能落地的路3.1 从语义理解到自车轨迹预测3D接口解决的是“世界是什么样”的问题轨迹接口则要回答“我该怎么走”。这也是Qwen-Drive-1.0这个思路里最核心的一环。传统自动驾驶的规控模块需要的是若干条候选轨迹每条轨迹由一系列时空路径点组成。规划器再通过代价函数来选择最优的一条。VLM要融入这个链路就不能只输出“应该向左避让”这种语义级别的建议而必须直接生成稠密的轨迹序列——包括未来5到10秒内每隔0.1到0.2秒的自车位置、速度、加速度、曲率等信息。轨迹接口的意义在于它把VLM的语言推理能力和底层的运动学约束、动力学约束、安全约束彻底打通了。举个例子模型通过语义理解判断“前方有事故需要变道到左车道”那么轨迹接口就需要输出一条在横向上平滑换道、在纵向上适度减速的候选轨迹。这条轨迹必须满足车辆运动学约束——比如最大转向角、最大横向加速度——不是随便画一条曲线就能执行的。3.2 轨迹接口的典型结构从实现角度讲我一般会把轨迹接口分成两个层次意图层和曲线层。意图层负责输出驾驶意图比如“保持车道”“向右变道”“靠边停车”“减速通过”。这可以由VLM的语义推理头直接输出对应一个离散的意图类别。曲线层负责输出具体的时空轨迹以多条候选轨迹的集合形式给出并附上置信度分数和约束标记。代码层面一个简化的轨迹输出结构可以做成这样dataclass class TrajectoryCandidate: # 轨迹未来时间点单位秒 time_s: List[float] # 自车坐标系下纵向位置序列单位米 x_m: List[float] # 自车坐标系下横向位置序列单位米 y_m: List[float] # 每个轨迹点的期望车速单位米/秒 v_mps: List[float] # 每个轨迹点的曲率单位1/米 curvature: List[float] # 意图标签如 left_lane_change, keep_lane intention: str # 模型置信度范围 0~1 confidence: float # 安全约束标记如 passive_safety, comfort_constraint constraints: List[str]把轨迹设计成多条候选的方式最重要的原因是给下游规划器留出仲裁空间。VLM不是全知全能的它可能对场景的理解有偏差但如果同时给出“保持车道”和“向左变道”两条轨迹下游规划器再叠加基于规则的安全校验、驾驶员习惯模型、舒适度评估就能在最后一步把住安全关。这个设计理念和传统规划模块的“多候选代价函数仲裁”是一致的本质上是用冗余换安全。3.3 轨迹与规划的闭环可检查接口的安全兜底轨迹接口还承担着一个任务让系统可以被人检查和干预。我见过太多端到端模型输入图像直接输出方向盘转角。这种方案的问题在于一旦模型在复杂路口表现异常工程师根本没法判断——到底是模型对场景的理解错了还是轨迹生成错了还是映射到控制指令的时候错了整个系统像个熔岩灯内部永远在变化出了问题你无法定位。Qwen-Drive-1.0的思路是把这个流程拆开保留可检查的中间结果。视觉语言模型输出3D障碍物结果再生成语义级的驾驶意图和轨迹候选最后由下游的规则规划器或安全层做校验。哪一层出了问题都能通过中间接口快速定位。某段轨迹的曲率突变、某个障碍物的3D框和真值偏差过大都能单独排查。我在实际测试中比较关注三个轨迹指标碰撞率生成的轨迹是否和障碍物相交、乘坐舒适度横向加速度和纵向冲击度是否超标、以及与规则规划器的轨迹离散度如果VLM输出和传统规划器输出差距过大说明模型对场景的理解可能有问题。这三个指标可以做成实时监控只要任何一项超出阈值就自动降级到保守策略——减速、靠边、请求接管。这比让模型直接“盲操”要稳健得多。注意接口层才是安全的核心不是模型本身。VLM的推理能力再强也可能在某些罕见场景下出错但只要接口层的校验和降级机制够扎实模型犯点小错并不会酿成灾难。反过来再强的模型只要直接输出方向盘指令一旦出问题就是不可回退的。4. 评测与数据没有可检查的接口就没有可靠的自动驾驶测试4.1 场景库评价从ISO 34505说起聊到评测就绕不开自动驾驶测试场景的标准文件。ISO 34505:2025《自动驾驶测试场景评价与用例测试生成》是国内和国际自动驾驶测试领域都会参考的框架性文件。ISO 34505的核心思想是把自动驾驶测试场景拆分成功能场景、逻辑场景、具体场景三个层次来管理——功能场景描述“发生了什么”的抽象场景逻辑场景给出参数空间比如车速范围、障碍物距离范围具体场景则是一组可执行的具体参数组合。VLM落地的测试完全可以借鉴这套框架。比如要让模型处理“前车急刹”场景先定义功能场景前车在自车前方行驶以一定减速度减速至停车再定义逻辑场景前车初速度30至60km/h自车车距10至30米减速度4至8m/s²最后用参数采样方法在逻辑场景的参数空间里生成成百上千条具体测试用例。有了ISO 34505这种结构化的场景定义方式可检查的3D与轨迹接口的价值就体现出来了——对场景库里的每一帧数据模型输出的3D检测框、轨迹预测值都可以和真值做量化对比测试人员可以逐帧检查失败案例。如果没有结构化接口大模型在这种评测框架下根本无从评估。4.2 数据集与数据闭环光靠公开数据集跑不通现在很多团队拿公开数据集比如nuScenes、Waymo Open Dataset来训练VLM的自动驾驶能力。这些数据集有传感器数据、3D标注、地图信息质量确实不错但直接用于训练一套面向自动驾驶的VLM远远不够。第一个问题在于数据多样性和场景覆盖。公开数据集里的天气、时段、城市分布相对平均但真实自动驾驶最怕的恰恰是极端天气、夜间暗光、施工改道、事故现场这类长尾场景。公开数据集里这些场景非常稀疏模型学了等于没学。第二个问题是标注粒度和接口不匹配。VLM要学的是“从语义到3D到轨迹”的完整映射而公开数据集往往只有感知标注缺少驾驶行为标签和轨迹真值更缺少“文字问答几何标注轨迹标注”对齐的多模态数据。所以真正做项目时我一般建议走数据闭环路线在道路上运行的测试车持续把corner case数据回传到云端云端触发自动标注管线——3D框自动跟踪、轨迹自动拟合、场景文字描述自动生成。再经过人工抽检后变成下一轮模型训练的增量数据。数据闭环这件事听上去容易做起来是个系统工程牵扯到数据筛选、自动标注、人工复审、版本管理一整套流程。但想达到量产级的性能这条路是绕不开的。4.3 评测链路分模块评测加端到端闭环评测评测VLM在自动驾驶上的表现我建议分两层。第一层是分模块评测。感知层面重点看3D目标检测的AP值、BEV下的定位误差预测层面重点看轨迹未来5秒内的ADE平均位移误差和FDE最终位移误差语义层面看意图分类的准确率、场景描述的语义相似度。每一个模块都有中间接口可以汇报指标哪根短板一眼就看到。第二层是端到端闭环评测。在仿真环境里把模型接入完整的规控链路记录安全性指标、任务完成率、平均接管里程。仿真评测的好处是可以低成本跑几千万公里的虚拟里程快速暴露边界问题。但仿真再逼真也有domain gap最终还得靠实际道路测试来收尾。我在项目里经常用一张汇总表来跟踪模型的评测进度给读者参考评测维度关键指标参考目标值评测方式3D感知精度BEV下的3D框mAP高离线数据集评测轨迹预测精度ADE / FDE越低越好离线数据集评测意图分类准确率变道/保持/停车等意图准确率高离线数据集评测端到端安全性每万公里接管次数极低仿真道路实测接口可检查性中间结果可视化抽检通过率 99%人工抽检注意最后一项“接口可检查性”往往不在常规评测清单里但我认为它是最重要的。自动驾驶是安全攸关系统再好的数据指标如果没有经过逐帧视觉检查确认都有可能存在系统性的理解误区——比如模型对某些罕见标志牌视而不见但数据集里恰好这类样本偏少指标完全暴露不了问题。5. 工程落地中的常见问题与排查实录5.1 相机和激光雷达时间不同步导致的3D漂移我参与的项目里第一次把VLM的3D接口接到实车数据上跑出来的BEV可视化结果明显“重影”——物体的3D框和点云轮廓是错位的车明明是直线行驶框却像在左右摇晃。排查过程从标定参数开始先确认相机内参、外参没有问题然后检查是时间同步问题——对比每帧图像和点云的时间戳发现两者相差大概80毫秒。车辆在40km/h行驶时80毫秒意味着前进将近0.9米这就解释了3D框为何前后偏移。解决方案不复杂对点云做线性插值运动补偿把所有传感器数据统一到同一个参考时刻或者在硬件层面用触发线把相机曝光时刻和激光雷达扫描时刻对齐。从那以后我养成一个习惯任何多传感器融合项目的第一道验收标准就是看时间戳对齐误差这个不达标后边做得再好也没用。5.2 VLM轨迹输出抖动如何做时序平滑VLM输出的轨迹容易出现帧间抖动——上一帧说“保持车道稳定直行”下一帧轨迹候选却往右偏了30厘米再下一帧又偏回来。原因在于模型对每一帧图像独立作预测单帧的语义理解会受光照、遮挡、视角变化的影响输出的轨迹自然不够稳定。我试过几种方案最终觉得效果最好的是“预测滤波”让VLM在输出轨迹的同时给出轨迹的时间序列特征然后在时间上做一次平滑。类似卡尔曼滤波的思路把当前帧的预测和上一帧的历史轨迹做加权融合。另外一点经验是把轨迹接口和意图解耦意图信号做滞后平滑比如连续3帧都是“向左变道”才执行变道而几何轨迹做逐点滤波。这样模型偶尔对某帧画面“多想了”也不至于让车辆猛地抖一下。5.3 模型幻觉和规则兜底怎么防止VLM一本正经地胡说八道VLM还有一个绕不开的问题是幻觉场景里明明没有行人模型却煞有介事地预测“行人横穿”。放到自动驾驶里这种幻觉如果直接送给轨迹生成模块可能会触发毫无理由的急刹车。我的经验是一定要在轨迹接口之后加一层独立的规则安全层。这个安全层不依赖VLM的语义推理而是用传统的几何和运动学方法检查候选轨迹是否真的会碰撞障碍物。如果VLM说“前方有行人”但传感器和3D检测都没有对应的障碍物证据安全层可以直接驳回这条轨迹。反过来如果VLM漏检了一个真实存在的障碍物但3D检测模块检测到了安全层也能兜底。这套设计并不复杂但它把“模型自信”和“实际安全”分开不会因为模型的一次幻觉就产生灾难性后果。5.4 算力受限VLM很难原封不动跑在量产芯片上最后说部署。VLM模型动辄几十亿参数而量产车规级芯片的算力通常有限还要给感知、规划、控制其他模块留余量。直接在车上跑原版大模型基本不现实。我走通的一条路径是“云-端分离加模型蒸馏”云端跑大参数VLM用于数据标注、难例挖掘、离线评估车端部署一个经过蒸馏和量化的小型化模型保留3D接口和轨迹接口的关键能力把算力消耗压到可控范围。任务级蒸馏比输出级蒸馏实用得多——不是让车端模型复现云端模型的每一个词而是让车端模型学会在相同场景下输出一致的3D检测结果和轨迹分布。牺牲一点多样性换来的是可部署性。结尾我一直在想为什么很多团队做VLM自动驾驶做到最后demo惊艳却迟迟无法量产落地。看了Qwen-Drive-1.0的方向后我更加确信——问题不在模型的推理能力而在于缺少一层能被检查、能被验证、能和下游控制的接口。做模型的觉得我输出文字就够智能了做规控的却在想这堆文字到底该怎么用。3D与轨迹接口就是这两个世界之间的“翻译官”。根据我个人的项目经验如果你也想让视觉语言模型在自动驾驶上真正落地建议别急着堆问答数据。先想清楚三件事模型的输出能不能量化为自车坐标系下的3D几何能不能生成满足车辆运动学约束的轨迹候选这些中间结果能不能被工程师逐帧可视化检查把这三点打通模型离上路就不远了。反过来这三个问题没想清楚堆再多问答也只是让模型变成一个更聪明的“副驾驶解说员”而不是真正握着方向盘的老司机。