端到端与多模态大模型在智能驾驶中的落地实践与踩坑记录

1. 端到端与多模态大模型：到底在解决什么问题

搞智驾的这两年，最绕不开的一个词就是端到端，紧接着多模态大模型又把整个行业卷上了新高度。作为一线算法工程师，我完整经历了一个从规则模块到端到端、从单模态到多模态融合的过渡项目，今天把这些经验掏出来聊聊。这篇文章不是科普论文，更像是一份踩坑实录——从技术选型、数据回灌、模型微调到车载部署，把端到端与多模态大模型在智驾场景里的关键环节拆开揉碎，适合正在做智驾感知、决策规划或者想转行大模型落地的朋友参考。

先说结论：端到端解决了“模块间信息损耗”的根子问题，多模态大模型解决了“复杂场景语义理解”的上限问题，两者叠加，才真正打开了从L2到L2+/L3的体验门槛。但这个组合远没有PPT上那么光鲜，训练数据、算力、评测、部署，每一环都能劝退一支团队。

1.1 传统智驾的天花板在哪里

传统智能驾驶算法链路过长，感知、预测、规划、控制各自独立，像个流水线：感知模块输出目标框，预测模块猜测目标意图，规划模块基于规则或优化方法搜索轨迹，控制模块再去执行。这条链路的好处是可解释、每部分都好做单元测试，坏处也致命——前一级的误差会原封不动传给后一级，而且模块之间传递的“中间表征”往往是手工设计的，丢失了大量原始信息。

举个典型例子：路边停着一辆打着双闪的货车，后面还蹲着一个人。传统感知模块可能只给出一个“车辆”框和一个“行人”框，预测模块没法知道“这个人正在弯腰搬货，是否要突然窜出来”，规划模块只能保守刹车。而端到端模型如果能直接看到原始摄像头画面，它可以学习到“人蹲下、手触碰货物、身体重心在调整”这类像素级线索，输出更自然的减速或绕行动作，甚至不需要显式建模“意图”。

我在项目里复盘过不少Corner Case，最后发现80%的问题不是某个模块算法不够好，而是模块间接口丢失了关键语义。模块化路线并不是错，只是它到了需要精细理解场景的时候，天花板非常明显。

1.2 端到端的一次成型思想

端到端（End-to-End）并不是新概念，早年就有人用CNN直接输出方向盘角度，但真正掀起热潮是因为大模型时代的“规模化定律”被发现：只要数据够多、模型够大、训练足够充分，模型自己能涌现出复杂驾驶策略。

在智驾场景里，端到端通常有两种形态：一是“感知-规划”一体化，直接输入多传感器原始数据，输出轨迹或控制量；二是“多模态大模型+向量化场景理解”，先用视觉语言模型把场景转成结构化描述或Token，再交给决策网络。前者更像传统端到端的加强版，后者则是多模态大模型介入智驾的主流姿势。

从我试过的方案来看，真正能跑通的是第二种。纯端到端控制量输出对数据一致性和仿真环境要求极高，一旦训练集里有个别标注错误，模型就会学出神经质行为。而多模态大模型擅长的是“理解”，不是高频控制，让它负责场景风险评估、目标意图推理、罕见路况应对，把决策规划留给更轻量的模型或规则兜底，这套组合既稳又聪明。

1.3 多模态大模型为什么能上车

多模态大模型在智驾里能站稳脚跟，靠的是三个能力：跨模态对齐、常识推理、快速迁移。摄像头给图像，激光雷达给点云，导航给地图，多模态模型能把它们统一到同一个语义空间里，然后像人一样“看着画面联想常识”去判断路况。比如看到“前方一排锥桶、地面有箭头标记、施工围栏”，模型能综合这些信息判断出“此处正在施工，需要跟着箭头变道”，而不是像传统模型那样只把它们识别成独立物体。

另一个优势是迁移成本低。新的交通标识或者少见车型，传统的感知模型需要凑几千张图重新训，多模态大模型只需要构造几十条图文数据做一次轻量微调，就能在开放集上识别出来。这正好补上智驾长尾场景的痛点，也是我把它引入项目的最直接原因。

2. 从论文到代码：技术选型与工程落地路径

选定方向之后，就要面对一个很现实的问题：到底用什么模型、什么框架，怎么把这套东西从论文变成能跑的代码。这个阶段我踩的坑最多，写下来希望能帮大家少走弯路。

2.1 主流端到端框架与多模态模型盘点

目前公开可复现的智驾端到端方案不少，但多数停留在学术数据集（nuScenes、Waymo Open Dataset）上，离量产还有距离。工业界可以参考的思路有几种：UniAD把感知、预测、规划串成统一Transformer网络；VAD偏向向量化场景表示，轻量可控；SparseDrive用稀疏感知做端到端，更贴近工程效率。这些开源方案的共同点是都建立在BEV或稀疏查询之上，核心代码量不大，但复现需要扣很多细节。

多模态大模型这一层，开源生态已经非常成熟。视觉语言模型里，Qwen-VL、InternVL、LLaVA都是能直接下载权重跑推理的；如果要接入自动驾驶场景，一般会再拿一个开源基座做微调。我用的主力是Qwen-VL系列加BGE-M3做文本向量化，前者负责图像和文本联合理解，后者负责场景描述的语义检索和记忆回放。另外，如果要做开放词汇目标检测或细粒度视觉定位，Grounding-DINO和BADCLIP这类模型可以作为辅助模块。

表1是我在项目里做过的选型对比，供参考：

部署侧，LLaMA Factory是我目前用得最顺手的微调工具，它把LoRA、QLoRA、全参微调全部封装成了配置文件，对新人非常友好。推理部署我习惯用vLLM，吞吐量比原生Transformers高不少，配合Ollama做本地私有化部署，一套下来能把整个实验链路跑通。

2.2 数据闭环：从采集到标注的自洽链路

大模型时代，数据比模型更值钱。我接手项目前，团队的数据体系还是“采集一批、标注一批、训练一批”的离线模式，一个Corner Case从发现到回到模型可能隔了一两个月。后来我们搭了一套近乎实时的数据闭环：车端部署了规则加小模型的双触发器，遇到异常场景自动脱敏回传；云端做场景聚类和难度打分，优先筛选难例；再用多模态大模型做自动标签生成，人工只做抽检修正。

这套闭环里最耗费时间的不是模型训练，而是数据清洗。车端回传的数据经常是几秒到几十秒的连续片段，里面大量是冗余帧。如果用视频理解模型做一次过滤，按“画面变化幅度 + 目标类型出现频次 + 预测置信度”三个维度打分，能砍掉80%低价值数据。这里我强烈建议不要一上来就上多模态自动标注，先把“数据去重”和“场景切片”做扎实，否则后面微调时你会发现数据集里全是同一个路口的同一种情况，模型怎么调都过拟合。

2.3 动手搭一套多模态融合基线

纯讲概念太空，这里给出一个可执行的最小方案。我假设你已经有一台带24G显存的GPU（比如RTX 3090/4090），用开源数据集跑通流程。

第一步，搭多模态场景理解基线。下载Qwen-VL或InternVL的权重，准备好一批“图像+文本问答”数据。问题模板可以是“描述当前交通场景中的风险物体”“判断前车是否要切入本车道”“给出前方施工区域的绕行建议”。用LLaMA Factory的LoRA配置做微调，学习率设在1e-4到2e-4，批次大小根据显存调整，通常4到8就能稳定收敛。

第二步，把端到端决策网络接进来。用VAD或SparseDrive作为轨迹预测主干，把多模态模型输出的场景Token拼接到网络输入中。这里有个关键点：不是直接拿CLS Token用，而是要把多模态模型中间层的视觉特征投影到BEV空间，和激光雷达特征做加性融合或Cross-Attention融合。我试过直接把文本输出拼进去，效果很差，因为文本信息丢失了空间位置。

第三步，在开源数据集上做闭环评测。nuScenes提供完整的感知和规划标注，可以算规划误差、碰撞率、驾驶舒适度等指标。也可以自己搭一个简单的CARLA仿真环境，但注意仿真和真实差距较大，只能用来冒烟测试，不能替代真实路测。

这个基线跑通之后，你就有了一个“多模态理解 + 端到端决策”的可运行框架，后续所有优化都可以基于这个基线展开。

3. 实操手记：训练、微调与部署的硬核细节

框架选好只是开始，真正让人掉头发的是模型训练和部署。我在这里把大家最容易忽视的细节和踩过的坑摊开来说。

3.1 大模型微调的最小操作单位是什么

很多人问“多模态微调的最小微调单位是什么”，网上答案五花八门。从我实践来看，这个“单位”得看你站在哪个层面去理解：参数层面是LoRA Rank，数据层面是“一条完整的图文问答对”，训练层面是“一个Batch”。

参数层面，LoRA的Rank大小直接影响微调参数量和表达力。Rank取8到16就能适配绝大多数智驾场景，太大容易过拟合，太小学不到足够特征。我习惯在微调前先用几十条样本做一次“探针实验”，观察损失下降速度，如果Loss下降过快说明Rank可能偏大或学习率偏高，如果下降太慢则相反。

数据层面，最小单位不是一张图，而是一组“同一场景下的多视角问题回答”。多模态模型要看到连续帧或环绕视图才能理解空间关系，所以我会把一张图扩展成“环视6路摄像头 + 1个全局BEV图”的多图输入，对应的一组问答才算一条数据。这样标注成本高，但模型学到的空间理解能力会明显上一个台阶。

训练层面，Batch Size决定了梯度更新的稳定性。多模态大模型参数量大，视觉编码器和语言模型学习率要分开设置。我通常设置“视觉塔”的学习率为语言模型的一半，同时开启梯度裁剪，最大范数设为1.0，防止训练中期出现Loss炸掉。

3.2 用LLaMA Factory和Ollama跑通多模态流程

LLaMA Factory是我见过对大模型微调最友好的开源工具，它支持多种模型架构和微调策略，配置文件写清楚之后，一行命令就能启动训练。下面是一个我实际用过的多模态LoRA示例配置片段，关键参数都标了注释：

model_name_or_path: Qwen/Qwen-VL-Chat template: qwen_vl stage: sft finetuning_type: lora lora_rank: 8 lora_alpha: 16 learning_rate: 1.5e-4 num_train_epochs: 3.0 lr_scheduler_type: cosine warmup_ratio: 0.1 fp16: true per_device_train_batch_size: 2 gradient_accumulation_steps: 8 dataset: smart_driving_qa cutoff_len: 2048

这里gradient_accumulation_steps很重要。单卡Batch Size很小，但叠加梯度累积后等效Batch Size能到16，保证训练稳定。我踩过的坑是忘了调cutoff_len，结果长文本输入被截断，模型在测试时只要遇到长上下文场景就“失忆”。如果显存够，建议至少设到3072。

微调完成之后，导出的LoRA权重可以直接合并到基座模型里，然后转成Ollama支持的GGUF格式，本地起一个OpenAI兼容的服务。Ollama最大的优势是部署简单，命令拉取模型后直接对话，适合快速验证和演示。但要注意，Ollama的并发能力偏弱，只适合内部测试，量产车端推理还得走TensorRT或vLLM那条路。

3.3 GPU资源有限时的折中与提速

很多朋友私信问我，手里只有一两张显卡，能玩大模型吗？我的答案是能，但要会折中。QLoRA是最佳选择，它把基座模型量化到4-bit，只训练LoRA参数，显存占用能降低到原来的三分之一左右。我用RTX 3090跑Qwen-VL 7B，QLoRA微调显存峰值大概在14G，勉强能塞下。

如果连单卡24G都没有，还能不能用？可以，但要牺牲更多。比如用较小的模型底座，像InternVL2-1B或Qwen2-VL-2B，这类小模型在智驾特定任务上微调后同样能干活；或者用CPU加载7B的量化权重做纯推理，速度虽然只有每秒几Token，但用来离线批量清洗数据、生成伪标签是够的。

另一个提速思路是冻结视觉塔，只训练语言部分。视觉塔参数量大且预训练特征已经不错，在智驾场景里我们更需要的是“学会推理”，而不是“重新认图”。这个方法能让训练时间缩短40%左右，而且效果不会差太多。想更快的话，可以采用DeepSpeed ZeRO Stage 2开启CPU offload，把优化器状态放到内存里，把显存让给前向计算。

3.4 部署环节的显存与延迟博弈

部署是另一个战场。车端的硬件平台通常只有几十瓦功耗，和服务器完全是两个世界。多模态大模型动辄几十亿参数，直接端侧部署不现实，所以工程上有几种常见方案：模型压缩、蒸馏、量化，还有把复杂任务放到云端、轻量模型留在本地的混合架构。

我在项目里采用的是“车端小模型 + 云端大模型”的协同方案。车端跑一个3B左右的视觉语言模型，负责实时场景摘要和风险预警，网络好的时候再把高难度片段上传云端，让7B甚至13B的模型做深度分析。这样既保证实时性，又享受了大模型的推理能力。车端部署时，我用TensorRT把模型转为FP16和INT8两种引擎，精度损失在可接受范围，延迟从原来的120ms压到了40ms，总算达到了产品要求。

这里要特别强调，INT8量化前一定要做校准集，直接盲量化会把模型搞残。校准集应覆盖夜间、雨雾、强光、逆光等典型场景，至少1000张图，数量太少的话量化后精度掉得离谱。我一开始偷懒用了500张普通道路图片，结果模型在隧道场景里疯狂误报，排查了三天才发现是量化校准集分布不均衡。

4. 评测与落地中的那些坑

模型训好了，部署也通了，最后还有一关：你怎么证明它比原来的方案好？这可能是整个项目里最难的部分，因为端到端和多模态模型的表现很难用单一指标衡量，而且评测过程中的陷阱非常多。

4.1 端到端模型的评测指标怎么定

传统模块化方案有清晰的中间指标，比如检测mAP、跟踪MOTA、预测ADE/FDE，每个模块都能单独考核。端到端模型直接输出轨迹或决策，评测思路要改成“最终行车质量 + 安全 + 舒适 + 接管率”的组合。

我常用的指标包括：规划误差（L2误差，预测轨迹和真实轨迹的欧氏距离）、碰撞率（在仿真器里跑1000个场景，统计碰撞次数）、驾驶舒适度指标（加速度变化率、横向急动度）、人工接管率（真实路测中每千公里人工介入次数）。这几个指标要放在一起看，不能只看单一的L2误差，因为有可能模型为了让误差小，学会了“过度保守跟车”，虽然轨迹拟合得很好，但实际通勤效率极低。

还要注意端到端模型的“黑盒”特性。没有中间模块，出了事故很难定位是感知错了还是决策错了。我的做法是在模型中间加入几个辅助预测头，一边输出轨迹，一边输出“场景描述”和“风险目标定位”，虽然推理时会多花一点算力，但出了问题能回溯到底模型看到了什么、理解了什么，对量产安全审查至关重要。

4.2 多模态模型在Corner Case上的表现

多模态大模型最吸引人的就是对罕见场景的泛化能力，但实际开放道路测试中，它的表现非常波动。我总结下来，它在两类场景下特别亮眼：一是非常规交通参与者，比如牲畜、宠物、遗落物、新能源车的充电机器人；二是带有社会交互属性的场景，比如交警手势指挥、前车驾驶员把手伸出窗外、旁车开着双闪示意让行。

但它在纯几何感知场景下反而容易掉链子。比如雨天反光对车道线识别的干扰、隧道路口突然的明暗变化，这类问题视觉语言模型并没有图片分类或者纯感知大模型来得稳。所以我强烈建议多模态大模型做“高层理解”和“异常预警”，基础感知仍然交给专用模型，不要贪心让它什么都干。这里的原则是“模型各司其职，融合在逻辑层”。

4.3 常见问题与排查思路速查

最后把我踩过的坑整理成一张速查表，很多问题不是代码写错，而是数据或训练配置有隐性毛病。

另外提一个独家经验：多模态模型的Prompt风格一定要统一。同一个场景，“这辆车会怎么开”和“请你描述前方路况”会得到完全不同格式的回答，而后续接的决策模型对输入格式非常敏感。我在数据构建时强制用一套Prompt模板，并且在后处理阶段写了解析器，把模型输出规范化成“风险等级 + 目标列表 + 建议动作”三段式结构，工程上稳定了很多。

4.4 多模态微调与端到端协同的进阶心得

如果你已经跑通了基线，我建议再往“场景检索增强”方向走一步。车端遇到陌生场景时，可以先把当前帧的图像特征向量化，去检索云端的历史相似场景库，把相似场景的经验描述一起送给大模型。这种方法很像给模型加了一本“行车手册”，能明显提升极端场景下的决策质量。注意检索器我用的是BGE-M3，它能把图像描述文本和场景标签统一编码，在几千条经验库里检索耗时不到10毫秒，对整体流程几乎没有影响。

另外一个心得是，智驾大模型微调时不要贪多。一次只针对一类场景做增强，比如这一轮专门啃“无保护左转”，下一轮专门啃“斑马线人车混行”，每一轮迭代后做回放测试，防止灾难性遗忘。要是直接在混合大杂烩数据上一直训，模型会变得平庸，原先会的场景能力也会倒退。

最后再分享一个小技巧：训练时在数据里故意加入5%的负样本——也就是在正常场景下模型输出了错误驾驶建议的样本。这样微调出来的模型会变得不那么“自信”，在情况不明时会偏于保守，而自动驾驶最怕的就是“自信的错误”。这个做法听起来简单，但效果立竿见影，车端接管率至少下降了三成。