Qwen-Drive-1.0-4B：开源多模态模型统一自动驾驶感知、问答与规划-平芜编程栈

1. 从模块分立到三合一：Qwen-Drive-1.0-4B 想解决什么问题

1.1 传统流水线里感知、规划、问答为什么各干各的

做自动驾驶研发的人对这套流程再熟悉不过：环视相机图像进来，先走感知模块，输出3D检测框、车道线、可行驶区域；感知结果交给预测模块，预测周围目标未来几秒的轨迹；预测结果再给规划模块，规划模块在参考线、限速、碰撞约束下算出一条自车轨迹；最后轨迹交给控制模块去跟踪。整个链路像一条流水线，每个环节都是独立模型、独立数据集、独立标定。

这条流水线本身没毛病，工程上非常成熟，但它有几个从根上带来的问题。首先是错误传播：感知漏检了一个行人，预测模块根本看不到这个目标，规划模块自然也不会为它减速，等相机画面里行人已经近到能看清脸时，规则刹车已经来不及。其次是需要给每个模块单独维护一套标注规范和模型版本，感知模型换了版本，预测和规划里的参数可能全要跟着调。最麻烦的是跨模块接口的语义损耗——感知输出的检测框坐标、类别置信度，都是为“通用目标检测”设计的，到了规划模块真正需要知道的是“这个目标会不会突然横穿”，这种高层语义在低层几何表示里根本没被表达出来。

驾驶问答在传统架构里就更尴尬了。它不属于感知、规划、控制任何一个环节，通常被塞进一个独立的人机对话模块，用规则模板或者一个单独的NLP模型去处理。乘客问一句“前面路口能左转吗”，问答模块如果看不到感知结果，就只能靠经验数据库猜。一旦猜错，轻则被乘客吐槽，重则让驾驶员做出违规操作。

1.2 “统一”的真正含义是共享上下文，不是简单拼接口

Qwen-Drive-1.0-4B 这个开源模型的卖点，是把3D感知、驾驶问答、运动规划三件事塞进同一个模型。你可能觉得这是把三个模型拼成一个模型包，共享一套相机输入，最后分三路输出。实际操作里没那么简单——如果只是拼接口，三个任务各自为政的本质并没有变。

真正的统一，是把三个任务放在同一个特征空间里协同推理。模型不是先看到图像、做一次感知，再把感知结果文本化之后“告诉”规划模块；而是所有任务共享同一套视觉特征和世界模型理解。比如在处理“前方路口能否左转”这个问题时，模型参与推理的不只是语言token，还有当前环视图像里提取出来的空间特征、车流状态、路面标识信息。它回答的每个字都知道“我看到什么”，而不是像传统问答系统一样只检索知识库。

打个不太严谨的比方：传统流水线像接力赛，每一棒交接时都可能掉棒，交接界面就是信息损耗的根源；统一模型像一个全能选手同时参加三项比赛，她的每一次判断都基于同一双眼睛看到的东西，协调性天然更好。

1.3 4B规模的选择：为什么不是更大，也不是更小

现在通用大模型动辄几十B、几百B参数，Qwen-Drive-1.0-4B 把参数量定在4B，是一个很务实的工程取舍。

先说为什么不能太小。3D感知需要从环视图像里恢复空间位置、目标边界、相对速度，这需要视觉编码器有足够的表达容量；运动规划需要对场景做未来推演，需要序列建模能力；驾驶问答需要大模型预训练积累的常识基础。参数太小的模型，光是被这三个任务同时“挤占容量”，表现就会明显塌方。

再说为什么不用更大。参数越大，推理延迟和显存占用就越难看。4B模型在fp16权重下大约需要8~9GB显存，一张RTX 3090/Tesla T4级别的卡就能跑起来，推理一个规划步骤能控制在几十到几百毫秒级别，这对仿真测试、路测数据分析、准实时决策都是可以接受的范围。如果换成70B模型，想要跑到这样的时延，得上多卡集群加量化蒸馏，工程成本完全不是一个量级。

4B的本质是“把好钢用在刀刃上”：视觉编码器做重、语言模型主体做轻、任务头做精。这样在开源社区里，个人开发者用一张游戏显卡就能玩得起，小团队也能负担微调和部署的算力，这是模型能不能真正“活”在社区里的关键。

2. 模型内部怎么同时完成三件事：架构与数据流拆解

2.1 多模态输入对齐：环视图像、文本指令和历史轨迹的融合

Qwen-Drive-1.0-4B 的输入不是单一模态，而是三路信息：环视相机图像（通常是6路或8路鱼眼/广角相机）、自然语言指令（比如“向左变道”“停到前方空位”“描述当前路况”）、车辆历史状态（速度、转向角、上一帧轨迹）。这三路数据进入模型的方式不同。

图像先经过视觉编码器，把每一路图像切成patch并编码成视觉token。这一步是整个模型的算力大头，所以视觉编码器的选择很关键。为了把图像里的空间信息保留下来，很多类似方案会引入BEV（鸟瞰视角）投影模块或显式的空间位置编码，让模型知道某个patch对应的物体是在自车正前方还是左后方。没有这一步，模型看环视图像就会像人只盯着一个方向开车，左右后方的信息对不上位置。

文本指令不需要经过视觉编码器，走的是语言模型的embedding层。历史轨迹和速度这类时间序列信息，一般会被离散化成token，或者和文本指令拼接在一起放进prompt里。这里最需要关注的是对齐策略：视觉token、文本token在进入语言骨干网络之前，必须有统一的embedding维度，并且空间位置编码要加对地方。如果视觉token没有空间位置信息，模型能告诉你“前方有车”，但分不清车在哪个车道，规划任务基本没法用。

2.2 任务指令路由与多任务头设计

一个模型同时做三件事，需要在内部有任务路由机制。常见做法是在prompt层面做任务区分——系统提示词里明确“你现在要输出3D目标检测结果”“你现在要回答乘客问题”“你现在要生成规划轨迹”。指令不同，模型激活的推理路径和输出头也不同。

更工程化的实现是引入任务token。输入序列里插入一个特殊的任务标识符，模型最后一层根据这个token选择不同的解码头：

感知头：回归一组3D框参数，包括目标中心坐标、长宽高、朝向角、类别概率；
规划头：回归一条未来轨迹，即未来T个时间步的自车位置点；
语言头：走标准的语言模型词表解码，生成自然语言回答。

这三条输出路径不是完全独立的，它们在语言骨干网络的高层特征里共享了大量信息。感知头和规划头实际上只做轻量回归，真正理解场景的是中间的Qwen主体。这也是为什么这个模型能在4B参数量下把三个任务都做得能看——大部分参数被用来建场景理解和推理能力，输出只是最后一步的转写。

2.3 轨迹解码与自然语言生成的分工边界

需要重点提醒的是，运动规划的输出不是让模型“说”出一串坐标文字，而是经过专门的轨迹回归头直接输出数值。我之前见过一些demo把轨迹写成语言序列，让模型生成“[[1.2, 3.4], [2.1, 3.8], ...]”这种字符串，再在代码里解析成轨迹。这种做法在演示阶段看着挺酷，实际部署会让你崩溃——语言模型偶尔会生成格式混乱的括号或多余字符，解析失败一次，轨迹就断了。

规范的做法是模型主体输出的特征同时送给语言头和轨迹头，轨迹头做回归，语言头做生成，两条路并行、互不干扰。用户想看问答结果就从语言头取文本；控制模块要轨迹就从轨迹头取数值。这样两边都稳定，职责边界清晰。

从训练角度说，这种方式也更加友好。规划任务是回归损失（比如L1或平滑L1），感知任务是检测损失，问答任务是交叉熵损失，三个loss加权求和，一次反向传播同时更新整个模型。如果规划任务也要通过语言解码生成，梯度传递会变得复杂，训练效率和稳定性都会大打折扣。

3. 本地部署与首次推理实践：硬件、环境与跑通流程

3.1 硬件选型与量化方案取舍

先说结论：你不需要一台几十万的服务器来跑Qwen-Drive-1.0-4B，但要舒服地做实验，至少准备一张16GB显存的显卡。RTX 4090是首选，24GB显存能让你用bf16精度直接加载模型，还能留出足够空间给环视图像输入和中间特征。如果预算有限，RTX 4070 Ti Super或Tesla T4（16GB）也能跑，就是batch size和并发要压一压。

如果显存实在紧张，可以使用4-bit量化加载。Qwen系列对量化支持做得不错，4-bit下模型权重大概压缩到5~6GB。但我要提醒一个实测中容易踩的坑：量化对感知头和轨迹头的回归精度有明显影响，坐标输出会出现小幅抖动。跑演示demo完全够用，但如果你想用它做闭环控制或者数据标注，还是老老实实上bf16精度。量化和回归任务的兼容性，是这个模型部署时最容易被低估的问题。

3.2 推理脚本的核心步骤与参数设置

我把一次完整的推理流程拆成几步，逻辑是固定的：

加载tokenizer和模型。权重格式建议用HuggingFace Transformers兼容格式，也可以直接用ModelScope下载。用from_pretrained加载后，把模型转成bfloat16并放到GPU上。
处理输入。环视图像要按模型的预处理要求做尺寸缩放和归一化，通常是把多路相机图像拼成一个batch序列一起送进视觉编码器。文本prompt方面，建议严格按照模型发布的对话模板组装，不要自己发明格式，否则效果会有肉眼可见的退化。
区分任务模式。感知和问答走生成路径，规划走轨迹回归路径。问答模式下设置max_new_tokens=256，temperature=0.3，top_p=0.9；感知模式最好用贪心解码（do_sample=False）；规划模式也建议关闭采样，轨迹输出要的是稳定，不是随机性。
后处理。规划头输出的轨迹坐标要先映射回车辆坐标系，再做一次平滑处理。我习惯用移动平均或贝塞尔拟合，把轨迹上的毛刺去掉。别忘了检查加速度和转向速率是否超过车辆物理极限，这层约束不应该依赖模型自己遵守。

3.3 首次跑通后的检查清单

第一次跑通模型，不要急着欢呼，先按下面这个清单逐项确认，否则后面做实验容易数据全废：

图像尺寸和归一化参数：视觉编码器对输入分辨率很敏感，尺寸不对会直接报错或输出退化；
环视相机的排列顺序：6路图像必须以固定的空间顺序输入，顺序一乱，模型的空间认知就全错了，但表面看起来“好像能出结果”；
轨迹坐标系约定：模型输出的轨迹是前向x还是前向y，单位是米还是像素，这些细节必须在模型文档里确认清楚；
提示词模板：中文prompt最好和训练模板保持一致，尤其是系统提示词里对任务模式的描述；
时间戳记录：每帧图像的时间戳和轨迹输出的时间戳一定要带上，后面做仿真对比时，两个数据对不上会让人抓狂。

这个检查清单我踩过太多次坑了，尤其是坐标系约定，不同开源项目之间差异巨大，别想当然。

4. 实测中的亮点与失误场景：哪些能用，哪些要兜底

4.1 3D感知：环视目标一致性与小目标召回

我拿公开数据集和自采的园区道路数据分别测了Qwen-Drive-1.0-4B的3D感知效果。在标准数据集上，它对车辆、行人、骑行者的检测能力是能用的，尤其是对近处大目标的3D框定位精度，在开源同体量模型里属于第一梯队。这和它共享上下文的设计有关——模型在推理时不只是看单个视角的2D特征，而是能把环视信息融合起来判断目标的三维位置。

但小目标场景是真短板。距离超过50米的行人、被前方车辆遮挡一半的骑行者，召回率下降非常明显。这其实不能全怪模型，视觉编码器的分辨率就摆在那里，小目标在图像里只占十几个像素，再怎么融合注意力也难有奇效。另一个值得注意的问题是跨相机目标一致性：一辆车从前视相机视野开到右前相机视野时，模型输出的3D框能不能平稳过渡。实测中偶尔会出现目标ID跳变或框位置抖动，需要后面的跟踪模块来做平滑和关联。如果直接拿感知头输出的原始结果去做统计，数据会很脏。

4.2 驾驶问答：现场感知上下文比知识记忆可靠

驾驶问答是这个模型最有特色的部分。我实际试过几种问题类型，感受差异很大。

第一类是现场感知类问题，比如“当前车道是否可以掉头”“前方是不是人行横道”，模型因为能看到感知特征，回答得相当稳。它能结合路面标线、信号灯、周围车辆状态给出答案，不是瞎猜。第二类是规则常识类问题，比如“路口让行规则是什么”“发生轻微事故怎么处理”。这类问题训练语料里一定有，但模型偶尔会一本正经地给出不完整甚至错误的答案——这其实是所有语言模型的通病，不该对它抱有过高期望。

第三类是开放场景推测，比如“前车急刹，我下一步该怎么办”。这类问题模型能给出合理的建议，但很笼统，更像一个驾校教练在讲理论，而不是一个正在开车的司机在实操。说明它在运动规划上的推理能力还没有完全泛化到语言输出中。

我的建议是：驾驶问答可以做乘客交互和调试辅助工具，但要当成“辅助提示”，不要直接拿它生成的内容作为用户最终看到的唯一信息源，最好有规则层或人工审核兜底。

4.3 运动规划：防御性驾驶倾向与硬约束安全兜底

规划方面，我在录制的园区场景和白名单仿真的闭环测试里做了验证：常规跟车、车道保持、可控变道这些操作它都能完成，轨迹平滑度不错，乘员感好，没有那种一卡一顿的感觉。这得益于模型在训练时见过足够多的正常驾驶数据，模仿学习阶段学的就是人的平顺驾驶习惯。

但进入开放交互场景，问题就来了。模型生成的轨迹明显偏“防御性”：遇到旁边车道车辆准备并线时，它会倾向减速让行，而不是稍微提速或轻微转向把博弈空间占住。这在某些场景下是安全的选择，但在高峰路口、无保护左转这些需要主动博弈的场景里，会让通行效率变差，甚至导致卡死在路口。

更重要的一点是，不能把安全完全交给模型。我强烈建议在模型输出的轨迹后面再接一层硬约束检查：碰撞检测、加速度限制、转向角限制、参考线偏离限制。模型负责“开得聪明”，规则层负责“开得安全”。这两层配合，才能让模型真正走出demo。

5. 围绕开源基座做二次开发：微调、上车与社区贡献

5.1 数据组织与LoRA微调的实用建议

开源模型最大的价值是允许你针对自己的场景做微调。Qwen-Drive-1.0-4B的微调思路和一般LLM类似，但数据组织上有它自己的讲究。

感知数据方面，每条样本要包含环视图像和对应的3D标注（目标框+类别+相对位置），标注格式要转成模型感知头能理解的格式，不能直接用常见目标检测数据集的格式。我在实际做的时候发现，很多公开自动驾驶数据集的标注格式并不统一，需要写一个转换脚本统一到模型要求的schema，这一步的工作量比想象中大，但没法跳过。

规划数据的标签是未来N步的轨迹点序列。这里最需要注意的是坐标系和对齐：轨迹必须是相对于自车坐标系的，而不是世界坐标系，否则模型学不到相对驾驶行为；轨迹和输入图像的时间戳也要严格对齐，时间不对齐的样本会让模型学到错误映射，微调后反而变笨。

LoRA微调是成本最低的起步方式。4B模型用一张A100或者两块RTX 4090跑LoRA，通常几小时能看到初步效果。我建议先冻结视觉编码器，只微调语言骨干和任务头，这样显存压力小，收敛也快。等跑通了再逐步解冻视觉部分做联合微调，效果会更好，但训练成本明显上升。

5.2 封装成ROS/CyberRT节点时的时序对齐问题

如果要把模型接进车上的实时系统，最常见的做法是封装成一个ROS节点或CyberRT模块。模型推理在GPU上做，输入是环视相机话题和车辆状态话题，输出是轨迹话题和目标列表话题。听起来简单，真正麻烦的是时序对齐。

相机话题的帧率可能是10Hz或30Hz，模型推理一次可能要80~150毫秒，也就是说不是每一帧图像都能被推理到。如果你直接把“当前时刻接收到的图像”拿去推理，再把输出当作“当前时刻的规划结果”，就引入了推理延迟——模型看到的是80毫秒前的路况，但输出的轨迹却被当成现在的结果使用，这在高速场景下误差很大。

合理做法是记录图像的采集时间戳，推理完成后把输出轨迹的时间戳校正到图像采集时刻加推理时长，并在消息里显式带上这个时间信息。控制模块在消费轨迹时，要根据这个时间戳做补偿或丢弃过期结果。时序问题在仿真里不明显，一上实车就会被无限放大，这是从demo到产物之间最大的拦路虎。

5.3 开源协作的正确打开方式与许可证选择

最后聊点开源的“软技能”。现在大模型项目在GitHub、Gitee、ModelScope这些平台的活跃度很高，很多开发者都想参与贡献。

我个人的体会是：新手不要一上来就提大型PR。热门项目的维护者对陌生人的大PR是警惕的，因为大PR意味着review成本高、风险大。最顺利的参与路径是：先提Issue反馈使用中发现的bug，或者补充文档——尤其是中文文档的翻译和错误修正，这类贡献门槛低、容易被接受。等和maintainer有了交流基础之后，再提出小范围、明确目标的代码修改，通过率会高很多。

我在实际项目中尝到的甜头是：把Qwen-Drive的问答输出接到路测日志分析系统里，让模型对每一段路测数据自动生成“这段数据里有哪些风险场景”的文字摘要。以前工程师要花大量时间看视频回放找问题，现在模型能直接把图像特征转化为文字报告，定位问题的效率提升非常明显。这种用法可能不是模型设计者的初衷，但开源项目的价值就在这里——你永远可以在它的能力边界之外找到自己的切入口。

模型本身还在快速迭代，4B这个量级我相信不是终点，后面大概率会有更大体量、更强闭环能力的版本出来。但对我来说，Qwen-Drive-1.0-4B已经提供了一个足够好的起点：它让我能以可接受的成本，在一个开源基座里把感知、问答、规划串成一条链，并且清楚知道哪一环需要规则来兜底。这才是开源自动驾驶技术最吸引人的地方。