Qwen -Drive 到底是什么：4B 级 VLM 如何成为驾驶策略底座
如果你准备把 Qwen-Drive 接入一个驾驶研究服务，最先要决定的接口可能很小：服务返回一条轨迹，还是一组候选？假设同事顺手用了 result.trajectory，界面画出一条五秒路线，接入就算完成了吗？
公开源码里，这个单数属性只有一行：return self.trajectories[0]。它取出第一条采样结果，没有在这里评价其余候选，更没有把"第一条"认证成"最合适的一条"。这处细节，比"4B 模型 会开车"的描述更能帮助工程师判断它承担了什么工作：Qwen-Drive 的规划路径生成未来自车轨迹；候选怎样进入下游，仍然需要一份明确的接入安排。1
沿这个返回值向前看，可以看清共享 视觉语言 主干、驾驶训练、连续轨迹专家和输入协议各自的作用。本文回答一个问题：接入 Qwen-Drive 时，应该把它当作什么组件，在哪个输出位置划清边界？最后形成的是一份待执行的输入---轨迹---下游接入记录。本文核对固定源码和官方论文，没有加载模型、取得 GPU 性能或运行车辆与仿真。
返回的是候选轨迹，第一条不是评选结果
固定官方原像素举证；范围为已核入口与论文报告，没有模型或车辆实测。
官方 QwenDriveOutput 把 trajectories 定义为 [num_samples, num_future_points, 3]。默认配置有 50 个未来点，每点为 (x, y, heading)。设置 num_samples=6，表示六条各有 50 点的候选，不是六辆车，也不是六个时间段。num_samples 默认是一；候选数来自调用参数，不是模型名里隐含的固定数量。12
这些点在当前时刻的自车坐标系里：x 向前、y 向左，位置单位是米；heading 是相对当前自车朝向的角度，正值表示向左，单位是弧度。输出为 10 Hz 的五秒未来，时间网格从 0.1 秒到 5.0 秒。每一行是相对同一个当前原点的位姿，不是上一行到下一行的位移增量。将它误当成增量再累加，会改变整条路线；把弧度当成角度，也会让下游读到另一种转向。34
模型内部的轨迹经过归一化，公开规划包装层在返回前调用反归一化。因此，消费 result.trajectories 时，不能不分层次地再乘一次尺度。内部网络输入的数字与公开输出的数字不是同一接口。这个区别不要求接入者重写采样器，却要求服务清楚标注自己接在哪一层。14
再回到单数属性：它只做索引零。若请求六条后只保存 trajectory，另外五条会在服务边界消失；下游也看不到它们之间的差异。若研究目标只是一条固定样本基线，预先声明始终取第零条完全可以，成本也更清楚。但若产品声称"生成多条并选择最佳"，还需要真实存在的选择机制及其依据。不能把数组顺序当作置信度排名。
如果要单独重放第几条候选，还应保存这次调用的基础 seed 与候选索引。固定公开接口说明，样本 k 使用 seed+k；只保存一张路线图，便无法回到同一次采样条件。这个安排描述源码的采样约定，不能据此承诺跨硬件或后端的逐像素、逐数值一致。1
同样，10 Hz 只说明未来点相隔 0.1 秒，并不说明服务每秒完成十次规划。一次请求的准备、视觉语言计算、轨迹生成与返回耗时，本轮都没有测量。轨迹的物理时间与服务的墙钟时间必须分开，否则接入方会从一个数据字段推导出并不存在的实时性能承诺。
三项能力共享主干，规划没有先读一张 BEV 图
作者结构解释与待执行接入方案；未运行模型、选择器、控制器或闭环。
官方 README 将 Qwen3.5 -4B 作为共享 VLM，也就是视觉语言模型；外接 BEV 感知头与 Planning Expert。BEV 是鸟瞰视角下的场景表示。感知头负责三维目标检测、语义占用预测和鸟瞰地图分割；原有语言解码器处理视觉问答；规划专家负责未来自车轨迹。这里的"4B"描述共享主干的型号，不能当作所有外接模块合计参数量、显存或运行成本。5
这组能力很容易被画成 相机 → VLM → BEV → 轨迹。但已核的规划调用不是这样：_plan_from_cache 把主干计算出的场景表示，以及历史位姿、速度、加速度、导航和车辆状态传给规划专家，再将结果转回物理量。该调用没有先消费检测框、占用栅格或 地图 分割结果。BEV 路径与规划路径共享主干，并不等于前者的输出是后者必经的中间件。1
这个观察会改变服务拆分。若当前目标只是复现公开规划接口，先单独上线完整 BEV 服务并不会自动补齐规划所需条件。若研究者想用显式占用或地图去检查候选，那是可以另行研究的新增连接，需要写清坐标转换、时间对应与判断规则；它不能因为架构图里有感知头，就被视为现成能力。
三条路径的输入也不完全相同。规划参考协议使用多视角的时间序列和自车历史；感知文档说明其发布推理是单帧多 相机 ，并涉及标定；generate_text 则只看到调用者传入的图像和问题，不自动拿到规划用的历史运动与导航。用一张前视照片得到正确红灯回答，证明了这次问答的输出；它没有替代完整规划输入。67
因此，接入时要先选任务和入口。需要的是问答，就返回问答；需要的是轨迹，就准备规划场景并加载规划专家。共享权重提供了联系，但不保证任意一次请求都同时完成三项任务，也不能由"共享"直接推出三项任务的总耗时等于一项任务。
一次规划请求，首先是一组有时间与方向的条件
固定官方原像素举证；范围为已核入口与论文报告，没有模型或车辆实测。
默认参考场景有前、左前、右前三路相机，每路四个时刻，依次为当前之前的 1.5、1.0、0.5 秒和当前。输入按相机分组：先放前视四帧，再放左前四帧，最后右前四帧。十二张图不是可以随意打乱的图片集合，视角标签和时间顺序是模型消费的条件。83
自车历史走另一条更密的时间网格：16 个 10 Hz 位姿点覆盖过去 1.5 秒，最后一行是当前 (0,0,0)，另外提供对应速度和加速度。图像的四个时刻与历史的十六行各有职责，不应为了凑相同长度而相互复制。文档还规定了场景文件中的图像尺寸与预处理；替换分辨率是输入配置变化，不能只看到画面仍可辨认就称为同一测试条件。3
一个没有加载模型就能发现的接入错误，是导航的两种编码。整数 nav_command 中，0 是直行、1 是左转、2 是右转；四维 driving_command 的顺序却是左转、直行、右转、未知。直行应对应整数 0 与 [0,1,0,0]，不能把整数位置直接用作四维数组的索引。它们表达同一个任务方向，但不是同一套编码。83
源码把当前速度、加速度和四维命令依次拼成八个状态数，再交给专家。假如影像中车辆正行驶，接入层却把当前速度和历史都填成零，模型收到的就是互相不一致的条件；返回形状仍可能正常。此时先修改 提示词 或者更换模型，都没有解决结构化输入的错误。
把单帧复制成四帧，或者把前视复制成三路，同样只补齐了数量，没有补出历史运动或侧向视野。这些是根据输入语义提出的故障情形，本文没有执行它们并统计轨迹退化。接入前能做的是显式标记缺失，确认原始数据是否满足参考协议。若任务只有单图问答需求，直接用问答路径会更简单；若必须研究轨迹，就应把缺失条件作为待解决适配项。
保留 VLM 架构，与不做驾驶训练是两回事
固定论文 v1 忠实选段与作者训练分工图；专家模式核对官方文档，未复现训练或运行模型、仿真及车辆。
理解组件角色，还要知道能力是在哪些训练里形成的。论文 v1 的配方有明确的更新分工：第一阶段固定视觉编码器与 VLM，只训练新加的 BEV 感知头；第二阶段联合更新感知头、视觉编码器与 VLM，混合感知和视觉语言样本。驾驶监督用于领域能力，通用视觉语言样本用于帮助保留原有能力。这是作者报告的训练方案，本轮没有独立复现。9
第三阶段重新固定视觉编码器与 VLM，只训练规划专家，用未来轨迹作为监督。训练混合带文字规划理由和不带理由的条件，但这一阶段没有文本生成目标。第四阶段继续固定共享主干，在任务奖励上优化规划专家，得到 RL 版本。SFT 与 RL 因而是规划专家不同训练状态的选项，不能理解为一次规划必须串行调用的两个决策者。95
这也解释了"架构保留"应如何读：层与拓扑沿用基座，不代表发布权重与原始通用模型相同；某阶段冻结，不代表全部阶段从未更新。直接拿普通 Qwen3.5-4B 的权重接上一个随机动作头，没有因此复现训练后的 Qwen-Drive。
对于正在集成的人，最小有效做法是记录共享主干、专家目录、代码版本与运行模式的组合。官方 cookbook 说明 SFT 专家支持直接规划与 reasoning 规划；RL 专家的奖励训练使用 reasoning rollout，并建议相应模式。加载不同专家却不记录模式，得到的结果即便都叫 Qwen-Drive，也不是可直接归因的同一配置。7
这里无须把所有训练数据集、全部榜单和损失函数搬进接入文档。当前要确认的是发布组件之间的配套关系，以及能力不能归给未经驾驶训练的裸基座。研究目标若只是问答，不必为展示多一条路线而加载专家；研究目标若是轨迹，问答流畅也不能代替轨迹专家和状态输入。
从一条候选，到下游真正消费的对象
作者结构解释与待执行接入方案；未运行模型、选择器、控制器或闭环。
规划器生成了未来自车位置，不等于预测了整个环境如何响应这些位置。已核公开入口没有在每条候选后返回一组其他车辆反应或任意动作条件下的未来视频。它在本文语境里是轨迹策略组件；若另外组合 世界模型 、模拟器或几何评价器，应单独标明新增模块及其待验证效果，不能只因都涉及"未来"就认为接口已经相同。
轨迹也不是油门、制动与方向盘转角。现有下游若消费另一坐标系、另一频率或者执行控制量，还需要明确的适配。即使都叫"轨迹"，双方也可能对第一个时刻、heading 参考方向和位置是否为增量有不同约定。五十行三列对得上，并不能让这些约定自动一致。
候选选择是另一项独立工作。需要多条候选时，应保留全部数组和真实选择规则；没有选择器时，可以固定取样本零并如实说明。不能等看过答案或未来真值后挑出最顺眼的一条，再将它称为上线服务能够做出的选择。本篇不评选算法优劣，只要求服务输出的含义与实际计算一致。
一次公开接口研究可以先停在这里：为一份真实场景准备输入，核对参考调用的完整输出，再交给一个定义清楚的离线下游。控制和闭环效果需要后续真实工作，本篇没有将它们填成已完成。这样划界的价值，是把下一次异常定位到可检查的位置：数据时间、导航编码、专家与模式、坐标解释，或者候选选择，而不是统一归结为"模型不够聪明"。
保留一份输入到下游的接入记录
作者结构解释与待执行接入方案；未运行模型、选择器、控制器或闭环。
下面是作者建议的单次接入记录，全部属于待执行设计，没有模型输出与测得耗时。它的作用是让调用者知道自己究竟验证到了哪一层。
| 接入位置 | 本次需要留下什么 | 当前证据状态 |
|---|---|---|
| 版本与任务 | 固定代码提交、主干与专家版本、规划模式 | 代码与官方文档已核；具体运行组合待选 |
| 场景输入 | 三路四时刻的视角顺序、图像尺寸、时间戳及历史状态来源 | 参考协议已核；真实样本待准备 |
| 方向条件 | 直行的 nav_command=0 与 0,1,0,0 配对，或对应转向编码 | 双编码已静态核对；模型行为未测 |
| 完整输出 | trajectoriesN,50,3，候选数、米与弧度、当前自车坐标、0.1--5.0 秒 | 默认接口已核；实际数组未生成 |
| 下游使用 | 消费者需要的坐标与频率、是否保留全部候选、选择依据 | 本次没有实现消费者或选择器 |
| 执行证据 | 请求总耗时与分段耗时、失败状态、后续离线或闭环评价 | 未运行，不填性能与能力数值 |
若第一阶段只做单样本接口检查，可以直接指定 num_samples=1，把问题收窄到"这份输入是否经正确路径得到一条按约定解释的轨迹"。需要研究多样性时再增加候选，并将保存与选择一起纳入目标。一个清楚的单样本记录，比一个只剩最佳截图的六候选展示更容易复核。
至此，Qwen-Drive 的组件角色便具体了：经过驾驶监督适配的共享 VLM，为问答、显式感知和连续轨迹专家提供基础；公开规划路径交付有坐标与时间语义的候选。工程师下一步要接的是这一真实输出，以及它尚未承担的下游工作。trajectory 的那行索引值得保留在记录旁边，因为它提醒我们，拿到一条路线与完成一次选择之间，还隔着实际实现。
来源与版本
核对日期为 2026-10-17，官方 main 固定为 28091c1532e869bc7aee91fc0aef6b3e6fd0b2e0，论文为 arXiv:2609.00111v1。输入协议、返回结构与调用顺序来自固定推理代码和文档；训练分工是论文报告；接入故障情形与记录是作者推导和待执行方案。没有下载权重、执行 GPU 推理、仿真、车辆或性能测试。
-
官方规划封装与返回对象，
QwenDriveOutput、_plan_from_cache、generate_trajectory、plan_from_inputs。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ -
官方技术报告 v1，训练配方，训练各阶段的更新与固定分工。 ↩︎ ↩︎