1. 从一段高速跟车经历说起：大模型到底在自动驾驶里补了哪块短板

去年冬天我跟着一个做量产辅助驾驶的团队跑了一趟长途测试，路线里有一段连续匝道加施工改道。传统方案在那段路上表现得像个刚拿驾照的新手：车道线一断，方向盘就开始小幅画龙；前方锥桶摆得稍微不规则，纵向控制就一脚刹车一脚油门。同车做规控的工程师当时说了一句话我印象很深——“感知其实早就看见锥桶了，问题是它不知道该把这堆东西理解成‘可绕行的障碍’还是‘必须停下的墙’。”

这句话基本点破了这两年自动驾驶行业最真实的痛点。感知模型能识别物体，规控模块能执行动作，但夹在中间的“理解与决策”长期靠规则堆砌。规则能覆盖的场景有限，一旦遇到没写进代码的长尾情况，系统要么保守到没法用，要么激进到吓人。而大模型，尤其是视觉语言模型和多模态大模型，恰好补的就是这块——把“看见的东西”翻译成“能推理的语义”，再输出“可执行的意图”。

所以当“对标特斯拉，大模型成为自动驾驶又一强心针”这个说法出来的时候，我第一反应不是兴奋，而是想拆开看看：它到底强在哪、补的是哪一环、落地时又会卡在哪。这篇就按我自己的理解，把这件事从技术逻辑到工程实操捋一遍，适合做辅助驾驶、机器人、多模态落地的同学参考，也适合只想搞明白“大模型上车到底靠不靠谱”的读者。

需要先说明一点：下面涉及的具体方案、参数、步骤，一部分来自公开技术路线的合理推演，一部分是我和团队在实际项目里踩过的经验，属于“一个合格从业者在这个情境下最可能采用的方案”，不是某一家厂商的内部文档。看的时候重点看逻辑，别当成标准答案。

2. 大模型在自动驾驶栈里到底坐在哪个位置

2.1 先分清三类模型，别把“大”当成万能标签

行业里一说大模型上车，很多人脑子里是一团浆糊。实际上至少得分三层来看，每层解决的问题完全不同。

第一层是感知大模型，典型代表是BEV加Transformer那套。它干的事是把多摄像头、激光雷达、毫米波的数据融合成一个统一的空间表征，输出障碍物、车道线、可行驶区域。这一层其实早就在用“大”的思路了，参数量不小，但它本质还是感知，输出的是几何和类别。

第二层是多模态理解大模型，也就是VLM这一类。它把图像、文本、甚至语音对齐到同一个语义空间，能回答“前面那个穿反光背心的人在干什么”“这个施工牌是什么意思”这种问题。这一层是这两年真正的新增量，也是“对标特斯拉”这个说法里最核心的变量。

第三层是决策规划大模型，有的叫端到端，有的叫VLA（视觉-语言-动作）。它直接吃感知和语义信息，输出轨迹或者控制指令。这一层最难，因为它要求模型不仅“懂”，还要“会开”，而且开得符合人类预期和安全边界。

把这三层混在一起谈，就会出现“大模型是不是要取代规控”这种伪问题。真实情况是：感知层早就大模型化了，理解层正在快速上车，决策层还在谨慎试点。所谓“强心针”，主要打在第二层和第三层之间的衔接上。

2.2 为什么偏偏是现在，而不是三年前

三年前也有VLM，为什么没上车？我总结下来是三个条件同时成熟了。

其一是车端算力跨过了门槛。以前跑一个几十亿参数的模型，推理延迟动辄几百毫秒，放在规划控制回路里根本没法用。现在主流智驾芯片的NPU算力上来了，加上模型量化、蒸馏、算子融合这些工程手段，把一个大模型压到几十毫秒级推理成为可能。注意，这里说的不是把千亿模型塞进车，而是把经过裁剪和蒸馏的“小号多模态模型”部署上去。

其二是数据闭环跑通了。大模型吃数据，尤其是带语义标注的难例数据。以前车企的数据闭环主要回流感知标注，现在开始回流“场景描述”和“决策意图”这类语义标注。没有这个闭环，大模型上车就是无源之水。

其三是端到端范式被验证了。特斯拉那条端到端路线虽然争议不断，但它至少证明了一件事：用一个大网络直接映射传感器输入到驾驶行为，在足够数据和算力下是能跑通的。这就给了后来者信心，也给了资本讲故事的空间。

2.3 一个容易被忽略的事实：大模型首先改善的是“可解释性”

很多人以为大模型上车是为了开得更像人。我实际观察下来，它第一个立竿见影的价值其实是让系统能“说出理由”。

传统规控模块做决策，你问它为什么减速，它只能给你一堆阈值和状态机跳转。大模型可以输出类似“因为右前方有车辆正在并入，且本车处于其盲区，保守减速让行”这样的自然语言解释。这对功能安全论证、对用户信任建立、对测试用例生成，价值都极大。很多团队现在把VLM当成一个“场景描述器”在用，先不碰控制，只让它把难例场景讲清楚，人工审核效率直接翻倍。

3. 对标特斯拉这件事，真正该对标的是什么

3.1 别只盯着“端到端”三个字

一说到对标特斯拉，大部分人第一反应是端到端。但如果你真去拆它的技术栈，会发现端到端只是最外面那层皮。底下至少还有三样东西在支撑。

第一是数据规模和质量。路上跑的车多，回流的数据多，而且它有一套自动标注加人工抽检的流水线。大模型再强，喂的是垃圾也出不来好结果。第二是自研芯片和算力集群，训练端和推理端都能自己掌控节奏。第三是组织架构，算法、数据、芯片、整车是一条线打通，不是各部门各管一段。

所以国内团队说对标，如果只对标“端到端网络结构”，基本是学了个皮毛。真正难对标的是数据闭环效率和软硬协同能力。这一点我在和几个做智驾的朋友聊的时候大家都有共识：模型可以开源，数据闭环开不了源。

3.2 大模型在这条路线里扮演的角色，更像“语义中间件”

我倾向于把当前阶段的大模型定位成语义中间件，而不是终极大脑。

它上游接感知，把几何信息转成语义描述；下游接规控，把语义描述转成决策约束或候选动作。它不直接拧方向盘，但它让规控模块拿到的输入从“一堆框和速度”变成“一个带意图的场景图”。这个定位的好处是，即使大模型偶尔抽风，规控层还有兜底规则，安全边界不会瞬间崩塌。

特斯拉那边其实也是类似思路，只是它把中间件做得更薄、更融合。国内很多方案是把VLM作为一个独立模块插进去，好处是工程上解耦、好调试，坏处是延迟和一致性会打折扣。这两种路线没有绝对优劣，取决于团队工程能力和安全冗余要求。

3.3 一个务实的对标清单

如果你是一个团队负责人，想认真对标而不是喊口号，我建议按下面这个清单逐项过一遍。

这张表里最容易被低估的是最后一行。大模型输出的是概率分布，不是确定值。直接拿它控车，功能安全那关基本过不了。必须有一个确定性的校验层，把大模型的建议翻译成满足安全约束的指令。这个校验层怎么写，才是各家真正的护城河。

4. 把VLM塞进车端：一次真实的工程落地拆解

4.1 需求定义：先想清楚让它回答什么问题

我们当时定的目标很克制：不让VLM控车，只让它做场景问答和风险提示。具体来说，它要能回答三类问题。

第一类是场景描述：“当前路口有哪些交通参与者，各自大致意图是什么。”第二类是风险识别：“是否存在被遮挡的行人、异形障碍物、施工区域。”第三类是决策建议：“建议减速、绕行还是停车等待。”

定这三类问题的原因是，它们正好卡在传统感知和规控之间的空白地带。感知能给框，但给不了意图；规控能执行，但不知道为什么要执行。VLM填进来，整个链路就顺了。

提示：需求定义阶段最忌讳贪大。一上来就让大模型输出轨迹，基本会死在延迟和一致性上。先从“说人话”开始，再逐步往“做决策”过渡。

4.2 模型选型与裁剪：不是越大越好

车端部署的第一道坎是算力。我们当时评估了几个方向。

一是直接用开源VLM做量化部署，比如把视觉编码器和语言解码器分别量化到INT8甚至INT4。实测下来，量化到INT4时场景描述还能用，但风险识别准确率掉得厉害，尤其是小目标和远距离目标。二是用蒸馏方式，拿大模型当教师，训一个参数量小得多的学生模型，专门针对驾驶场景。这个路线效果更稳，但需要大量带标注的驾驶场景数据。三是只取VLM的视觉编码器，接一个轻量任务头，相当于把多模态能力降维成多任务感知。这个最省算力，但丢掉了语言推理能力。

最后我们选的是蒸馏加量化的混合路线：先蒸馏出一个中等规模模型，再对视觉分支做INT8量化，语言分支保持FP16。这样在保证语义理解能力的同时，把推理延迟压到了可接受范围。

4.3 推理延迟的账要算清楚

延迟是车端大模型的生命线。我见过太多方案在实验室跑得挺好，一上车就露馅。这里把账算细一点。

假设VLM推理一次需要80毫秒，感知模块输出频率是10赫兹也就是100毫秒一帧，规控周期是20毫秒。如果VLM同步串在感知和规控之间，那整个链路周期就变成100加80等于180毫秒，控制周期被拉长到原来的九倍，车开起来会明显发飘。

所以工程上必须做异步流水线：VLM不阻塞主链路，它以前一帧的感知结果做输入，输出结果缓存起来，供后续若干帧的规控参考。同时设一个超时机制，VLM没在约定时间内返回，规控就退回纯规则模式。这样既用上了大模型的语义能力，又不牺牲实时性。

这张表是我们实际跑通后的配置，供参考。核心思想就一句话：大模型可以慢，但不能拖累主链路。

4.4 数据标注：大模型自己就是标注工具

这里有个很实用的技巧。我们一开始人工标场景描述，一天标不了几百条，成本高得离谱。后来改成用大模型预标注，人工只做审核和修正，效率直接翻了五六倍。

具体做法是：拿一个能力更强的云端大模型，对回流的难例视频做场景描述和风险标注，生成初稿。然后人工标注员只做两件事：判断描述对不对，以及补充模型漏掉的关键信息。这样人工从“从零写”变成“改作业”，认知负担小很多。

但要注意，预标注模型和车端部署模型最好同源或者同架构，否则会出现“老师说的和学生学的对不上”的问题。我们当时就踩过这个坑，云端模型描述得很细，车端小模型根本学不会，最后只能重新对齐标注粒度。

5. 那些文档里不会写的坑：从演示到量产的距离

5.1 演示视频很美好，连续跑两小时就露馅

我参与过的第一个VLM上车Demo，在园区里跑一圈效果惊艳，能准确说出“前方有行人正在看手机，可能突然横穿”。但连续跑两小时后，问题全出来了。

一是长尾场景的稳定性。模型对光照变化、雨雾天气、逆光场景的鲁棒性远不如传统感知。有次傍晚逆光，它把广告牌上的人像识别成真实行人，直接触发了一脚急刹。二是语义漂移。同一个场景，模型在不同时间给出的描述不一致，有时候说“可绕行”，有时候说“需停车”，规控模块无所适从。三是算力热衰减。车端芯片长时间高负载，温度上来后降频，推理延迟从80毫秒涨到150毫秒，异步流水线直接被撑爆。

这些问题在短Demo里根本暴露不出来，只有长时间实车跑才能发现。所以我的建议是，任何大模型上车方案，先做连续四小时以上的压力测试，再谈效果。

5.2 大模型的“幻觉”在驾驶场景里是致命的

语言模型有幻觉，这个大家都知道。但放在驾驶场景里，幻觉的代价可能是事故。

我们遇到过模型“脑补”出不存在的东西。比如前方明明没有车，它描述“前车正在减速”，规控如果信了就会无故刹车。也遇到过模型“忽略”明显风险，比如施工区域的锥桶摆得很密，它只描述了“道路变窄”，没提“有施工人员”。这些都不是模型能力不够，而是概率生成机制的固有特性。

应对办法有两个。一是多帧一致性校验：同一个场景连续多帧的语义输出做交叉验证，只有稳定一致的结论才送给规控。二是感知交叉验证：VLM说的风险，必须在感知模块里有对应的几何证据，否则降权处理。这两条做下来，幻觉导致的误触发能压下去一大半。

5.3 功能安全那关怎么过

做量产的人都知道，功能安全是绕不过去的。大模型这种概率性组件，怎么塞进确定性的安全框架里，是个真问题。

我们的做法是把大模型放在安全边界之外。也就是说，大模型的输出不被视为安全相关信号，它只提供“建议”。真正决定车辆动作的，还是那套经过验证的规则规控。大模型的建议要经过一个安全仲裁层，这个层用确定性逻辑判断建议是否可采纳。比如大模型说“可以绕行”，仲裁层会检查：绕行路径是否在可行驶区域内、是否有碰撞风险、是否违反交通规则。全部通过才执行，否则忽略。

这样做的代价是，大模型的能力被限制了一部分，很多激进但合理的决策用不上。但换来的是安全论证能过、能量产。在现阶段，这个取舍是值得的。

注意：安全仲裁层的逻辑必须是确定性的、可测试的、可形式化验证的。不要用另一个模型去仲裁模型，那等于用魔法打败魔法，安全论证根本没法做。

5.4 团队协作上的隐形摩擦

技术之外，还有个容易被忽略的坑：组织协作。

大模型团队通常来自互联网或AI背景，习惯快速迭代、灰度发布。而整车团队习惯的是V模型开发、严格变更管理。两边节奏完全不一样。我们当时就出现过算法团队一周更新三次模型，测试团队根本来不及回归，最后只能强行冻结版本。

解决办法是建立双轨制：模型迭代在云端或仿真环境快速跑，车端只接收经过完整回归的稳定版本。同时把模型变更纳入整车的变更管理流程，哪怕慢一点，也要保证可追溯。这个事没有技术含量，但如果不做，项目一定乱。

6. 如果现在要动手，我会这样排优先级

6.1 第一阶段：只做场景描述，不碰控制

如果你刚开始探索，我强烈建议第一阶段只做一件事：让大模型把难例场景讲清楚。

具体做法是，把路测回流的视频片段喂给VLM，让它输出结构化的场景描述，包括交通参与者、道路结构、潜在风险、建议动作。这些描述不直接控车，只用于两件事：一是辅助人工审核难例，二是生成测试用例。这个阶段投入小、风险低、见效快，而且能帮你积累宝贵的语义标注数据。

我们当时这个阶段跑了大概两个月，积累了上万条带语义标注的难例，后面训车端模型时直接省了一大半标注成本。

6.2 第二阶段：异步接入，做风险提示

有了数据基础，再考虑上车。上车时记住三个原则：异步、不阻塞、可降级。

异步是说VLM推理不占主链路时间。不阻塞是说它的输出只是参考，不直接决定控制。可降级是说一旦超时或置信度低，系统能无缝退回纯规则模式。这三条做到了，即使模型效果一般，也不会把车开坏。

这个阶段可以开始做A/B对比：同一段路，有VLM提示和没有VLM提示，规控的表现差异有多大。用数据说话，别凭感觉。

6.3 第三阶段：端到端试点，但保留规则兜底

只有当前两个阶段都跑稳了，才考虑往端到端方向走。而且即使做端到端，也要保留规则兜底。

端到端的诱惑在于它能处理规则覆盖不了的长尾场景，但它的不可解释性和不可预测性也是真实存在的。我的建议是，端到端模型输出的轨迹，必须经过一个安全校验层，检查是否满足动力学约束、是否在可行驶区域内、是否与障碍物保持安全距离。校验不通过就退回规则轨迹。这样既享受了端到端的能力，又守住了安全底线。

6.4 一个实用的评估指标清单

最后给一组我们实际在用的评估指标，供参考。

这些阈值不是拍脑袋定的，是我们根据实际路测数据反复调整出来的。不同团队场景不同，可以在此基础上微调，但大方向是：召回率优先于准确率，延迟和降级率是硬约束。

7. 关于“强心针”这个说法，我的一点个人看法

大模型对自动驾驶来说，确实是一针强心剂，但它治的不是“感知不准”这个病，而是“理解不够”这个病。它让系统从“看见”进化到“看懂”，从“执行规则”进化到“理解意图”。这个价值是真实的，不是炒作。

但强心针不是万能药。它解决不了数据闭环的问题，解决不了芯片算力的问题，更解决不了功能安全论证的问题。把这些基础工作做好，大模型才能发挥出它该有的价值。否则就是在一个不牢的地基上盖高楼，看着热闹，风一吹就晃。

我自己在实际项目里的体会是，大模型上车这件事，技术上的难点其实都能想办法绕过去，真正难的是心态。团队容易在两个极端之间摇摆：要么过度保守，觉得大模型不靠谱坚决不用；要么过度激进，恨不得明天就把方向盘交给它。这两种心态都会让项目走弯路。比较健康的状态是，把它当成一个能力很强但需要监督的新同事，先让它做辅助工作，逐步建立信任，再慢慢放权。这个过程急不得，但也停不得。

最后分享一个小技巧。如果你在评估要不要上大模型，先别急着买卡、招人、搭集群。找一段你们自己路测里最头疼的难例视频，用现成的云端大模型跑一遍，看它能不能把场景讲明白。如果能，说明这条路值得走；如果不能，先想想是数据问题还是需求定义问题。这个测试成本极低，但能帮你省下很多冤枉钱。