预约这两个字在自动驾驶圈一挂出来马上就有人开始讨论MindVLA-o1新一代VLA自动驾驶大模型真的来了。说实话我第一眼看到这个命名注意力完全被o1后缀吸引住了。VLA已经是当下自动驾驶和具身智能领域最热的技术路线之一如果它再叠加上o1这种指向推理、慢思考的标签背后意味着什么很值得认真掰扯一下。这篇文章不吹不黑只把MindVLA-o1当成行业方向的代表性样本从一个长期做自动驾驶算法和端到端模型落地的人的角度拆一拆VLA的原理架构、训练数据、评测体系、部署工程以及我在实际项目里踩过的一些坑。无论你是做智驾算法、端侧推理部署还是搞数据闭环这篇文章应该都能给你一些可用的东西。1. VLA到底在卷什么从听懂话到边听边动1.1 传统端到端和VLA的差别在哪先捋一下技术演进不然很多新来的朋友容易晕。早期自动驾驶是典型的模块化方案感知模块识别车、人、车道线预测模块估计他们下一步往哪走规划模块生成一条轨迹控制模块去执行。这套链路在L2级辅助驾驶上已经非常成熟但每个模块各自为政上游识别错了下游改不了误差一路累积到最后的控制指令可能早就偏了。后来大家开始做端到端把感知到规划压进一个神经网络输入多路摄像头图像直接输出未来轨迹。好处是信息无损传递从图像到轨迹是一条大路走到底。但纯轨迹式的端到端有个硬伤它不理解语言。模型看到前方有斑马线礼让行人这种交通语义时没有显式的推理空间碰到没见过的场景就只能硬猜。这也是很多端到端系统在长尾场景里表现不稳定的原因之一。VLA就不是这个思路了它的全称是Vision-Language-Action Model视觉-语言-动作模型。输入既有摄像头图像也有文字指令/系统提示词模型内部先做语义理解再输出底层控制动作。你可以把它想象成开车时副驾驶上坐了一个既能认路、又能理解交规、还能直接动手打方向盘的老司机。VLA把看路、思考、操作一口气全包了不再分感知和决策两大块。MindVLA-o1这个名字里的VLA瞄准的正是这个方向。1.2 o1后缀意味着会思考的驾驶员再说o1。做过大模型的朋友都知道o1风格的模型最核心的能力是推理扩展在给出最终答案之前先内部生成思维链把问题拆成几步来想。笛卡尔有句名言我思故我在搁到自动驾驶上就是先想再开。传统自动驾驶模型一般是快思考摄像头画面进来GPU算一下马上给出方向盘转角。这种反应速度很快但没有三思而后行的过程。比如遇到一个停在路肩打着双闪的车辆模型能不能先想一想它会不会突然左转我会不会离它太近要不要提前减点速这在大模型术语里就是chain-of-thought。MindVLA-o1的想法很直接把o1式推理能力塞进驾驶模型里让驾驶决策不再是输入图像直接吐动作的黑盒而是先做场景编剧推理再输出控制策略。它内部可能会生成类似前方有静止车辆疑似紧急停车我应当适度减速并向左偏移避让这样的隐式推理过程再来决定油门、刹车和转向量。这个思路对长尾场景特别有价值因为在真实道路上安全驾驶本来就是一个不断假设、不断验证、留出安全余量的过程。1.3 决策延迟32.8毫秒怎么理解MindVLA-o1相关讨论里有一个很具体的数据决策延迟32.8毫秒。很多非工程背景的朋友可能没概念我来算笔账。假设车辆以60km/h行驶换算一下就是16.7米/秒。32.8毫秒的决策延迟意味着从传感器信号进入模型到产生动作车辆只会前进大约0.55米。如果车速拉到80km/h也就是22.2米/秒这段延迟里车辆前进约0.73米。对比传统模块化方案动辄100毫秒以上的决策链路或者在车端跑大语言模型那种动辄一两秒的响应时间这个数字已经非常能打了。这里必须澄清一下所谓决策延迟指的是端到端模型一次完整推理的耗时从图像/指令进去到控制器拿到目标方向盘角度和期望加速度。不包含底盘执行器的响应时间也不包括摄像头曝光和传输延迟。能压到32.8毫秒说明推理引擎做过大量工程优化这在后面我会专门展开讲。2. MindVLA-o1的设计思路与技术拆解2.1 整体架构视觉编码器加LLM骨干加动作头说实话VLA类模型的架构大同小异MindVLA-o1大概率也逃不出这个框架只是每个模块的工程选型很考究。我按自己熟悉的方案拆一下。第一部分是视觉编码器。原始的多路相机图像会先被编码成语义Token。现在主流的选择是ViT或者类CLIP的视觉主干后面再接时序建模的模块。这部分负责把像素变成模型能理解的语义符号相当于眼睛。有些做法会额外引入BEV特征做融合方便模型理解空间位置关系。第二部分是大语言模型骨干这是VLA的大脑。它接收视觉Token、历史动作Token、以及文本系统提示词/用户指令。系统提示词里可以附加导航信息、天气状况、驾驶风格偏好等。LLM骨干的作用是场景理解、多模态对齐和推理它决定了整个模型的聪明程度。MindVLA-o1如果有o1式推理能力逻辑就藏在这一层。第三部分是动作头。LLM骨干输出的隐含表示不是直接的物理控制量还需要一个动作解码器将它映射到方向盘转角、油门/刹车开度。这里有一个工程上非常重要的选择到底用离散动作Token还是连续动作回归。早期很多VLA模型会把控制动作离散成Token直接让模型按照预测下一个token的方式去生成动作。好处是实现简单跟语言模型共用训练范式但坏处也明显真实驾驶控制是连续光滑的离散Token会让动作产生阶梯状抖动角度看是一抽一抽的。机器人领域现在更倾向用扩散式动作头Diffusion Policy / Flow Matching把动作生成当成一个去噪过程在连续空间里预测整段动作序列。这样输出天然平滑配合LLM的语义理解又能保证控制精度。我猜MindVLA-o1的动作头大概率也是这个路线因为我对标过几个开源方案扩散动作头在横向控制和跟车舒适性上确实比纯离散Token更好调。2.2 训练分两步走先教常识再教驾驶习惯VLA不是一上来就拿驾驶数据硬训的。它跟大模型一样遵循预训练加微调的思路只不过预训练的内容更加混合。第一步是预训练对齐。用无标注或者弱标注的互联网视频、图片语料、以及大量人类驾驶数据训练模型完成看图说话和基础动作模仿。这一步的目的是让模型具备世界常识知道红绿灯是红绿黄三色知道行人是两条腿走路的知道大货车转弯半径大。这些常识很难从驾驶日志里学来必须从大规模图文语料里灌输。第二步是端到端微调。把真实驾驶场景数据拿出来教模型在这个场景下老司机会怎么操作。这一步核心是模仿学习但MindVLA-o1这种带o1调性的模型还会加一步类似强化学习的后训练让模型在仿真环境里自己开不断试错用奖励函数告诉它这样开安全、舒适、高效逐渐逼近老司机的操作风格。我在实际项目里体会最深的一点是第二阶段的数据质量比数量更关键。哪怕只有几万段高质量、经过挑拣的老司机驾驶数据效果也远比海量普通数据好。因为普通数据里大量是匀速跟车、直道巡航这种背景板对模型能力提升几乎没帮助真正有价值的是那百分之几的高难度交互场景。2.3 决策延迟32.8毫秒背后的工程优化清单怎么能把一个大模型压到32.8毫秒的决策延迟这不是单纯买块好GPU就行的事。按我自己的部署经验至少要在以下几个地方下功夫。第一模型量化。FP16转INT8几乎是必备操作性能敏感位置甚至可以做INT4混合量化。驾驶模型对量化误差的容忍度比语言模型低关键层比如动作头最好保留FP16其余注意力层用INT8。这个取舍需要反复暴力测试不是一次性跑通就完事。第二缓存机制。自动驾驶场景里相邻两帧图像高度相似LLM推理时大量的历史注意力可以缓存起来类似大模型推理里的KV Cache。这样下一帧决策时不需要重新计算整段长上下文只处理新进来的视觉Token能省掉一大半计算开销。这也是VLA能跑出30毫秒级延迟的关键原因之一。第三投机采样。用一个轻量草稿模型先产出候选推理Token再由大模型一次性验证。如果草稿模型预测对了大模型的计算量能大幅下降。在决策链路中这个技巧可以把推理延迟再压低20%到30%。第四专用推理引擎。PyTorch自带的eager模式在车端基本不可用至少得换TensorRT或TVM这类静态图优化推理引擎配合张量并行和算子融合。我见过太多团队在车规芯片上跑PyTorch模型然后抱怨延迟跑不下来其实问题根本不在于模型太大而在于推理引擎压根没有针对硬件优化。说实话能交出32.8毫秒这个数字说明他们在系统层面下了狠功夫。对于正在做VLA落地的团队这个指标可以作为参考基准线。3. 训练数据的细糠仿真和真车数据怎么喂给大模型3.1 真实数据采集与标注到底有多麻烦大模型是吃数据长大的VLA也不例外。但自动驾驶真实数据的采集和标注比做ChatGPT的数据清洗麻烦一个数量级。首先车端采集回来的原数据不能直接用。多路摄像头、激光雷达、毫米波雷达、IMU、GPS这些传感器必须先做严格的时间同步与空间标定。摄像头要标内参外参雷达和视觉要标联合外参稍有偏差模型学到的图像和动作对应关系就是扭曲的。这一关我亲眼见过不少团队栽过跟头拿着一批没有严格同步的数据去训练训练损失怎么都降不下去。其次VLA需要语言标注这是传统自动驾驶数据集没有的东西。除了基本的场景标签、物体框你还需要给每一段驾驶视频配上自然语言描述这是十字路口左转前方有行人横穿我减速让行。这种描述性标注的成本比目标检测框标注高得多。一个中型规模的数据集做下来标注费用轻松达到几百万级别这还是用半自动化标注工具辅助之后的价格。最后是长尾场景挖掘。别指望模型凭空学会没见过的险情你得从海量数据里把稀有场景捞出来。常见办法是跑规则或者小模型在云端批量扫日志把高曲率转弯、近距离切入、恶劣天气这类片段找出来送进训练集。只有不断补充长尾模型在真实道路上的表现才稳。3.2 仿真数据用游戏引擎当驾校教练真实数据又贵又难采集仿真数据就成了VLA训练里绕不开的一环。仿真环境最大的好处是可以自由重复生成危险场景你可以让前车在1秒内切入可以让行人从盲区猛地窜出来可以在模拟器里把天气调到暴雨或者雾霾。这些场景在真实路测中可遇不可求在仿真器里是复制粘贴一样的标准操作。有一个很有意思的现象是连玩家社区都在干这件事。网上有人做过在《欧洲卡车模拟2》里实现智能车道保持的自动驾驶插件利用游戏里丰富的道路场景和车辆AI生成驾驶数据训练出来的模型还真能完成高速车道居中。这个思路跟工业界用游戏引擎做数据采集本质相同先录制屏幕画面和方向盘/油门操作真值再把它们配对成训练样本。游戏引擎里的物理模型虽然跟真车有差距但用来跑模型架构验证、数据管线验证完全足够了。工业界用仿真器还要多做一步域迁移。游戏画面的纹理、光照、材质跟真实世界有差异直接拿仿真数据训练出来的模型到了真实摄像头画面里往往表现掉一截。解决思路有三个方向一是域随机化在仿真器里随机改变光照贴图和材质逼着模型学语义而不是学画风二是用图像风格迁移把真实场景风格搬到仿真图上三是分层训练用仿真数据做预训练再用真实驾驶数据做端到端微调仿真数据负责打底子真实数据负责精修。3.3 数据闭环让模型越开越聪明VLA这类系统真正可怕的地方不是单次训练而是数据闭环带来的持续迭代能力。也就是说车量产上路之后每辆车的影子模式都在不断收集疑难场景日志回传后自动切分、清洗、标注再流进训练集新模型修复旧问题后再通过OTA发布。这个循环每转一圈模型能力就往上拱一截。这里要重点提醒一句很多团队数据闭环的瓶颈不在车端存储而在难例怎么定义。如果靠人工刷数据效率太低。现在主流的做法是先用便宜的小模型或者规则引擎做第一道拣选判断场景有没有让驾驶系统处于高风险状态然后再进人工精标。自动拣选这一环做到位了数据闭环才能真正转起来。MindVLA-o1如果按这个体系去做它用自然语言推理输出的特性反而成了优势可以让模型对难例自动生成决策理由用来辅助筛选和回放省下大量人工标注负担。这是我个人觉得比较有价值的设计方向。4. 评测指标不能只盯着NDA和接管率4.1 传统自动驾驶指标为什么不够用很多自动驾驶团队做评测第一反应是看NDA也就是每千公里被动脱离平均值中文圈习惯叫百公里接管次数。这个指标直观但它有一个致命问题司机个体差异太大。同一个系统激进型测试员可能百公里接管0.3次保守型测试员可能就0.8次你很难说这个差异是系统不行还是司机太谨慎。还有个问题是应试驾驶。如果团队考核指标只压在接管率上就会出现一个很有意思的现象模型决策时宁可多刹车、慢起步把所有风险场景都极端保守化接管率自然是零但乘坐体验极差后排乘客能晕车。这种模型在榜单指标上好看实际一点都不能用。所以做VLA评测一定要搭多维度评价体系把安全、舒适、效率分开来打分。4.2 MindVLA-o1这种模型该怎么评测我自己的经验是VLA模型的评测至少要分三层。第一层是场景库压测。整理一套标准化的典型场景库里面包含鬼探头、加塞切入、停走车流、十字路口盲区、夜间逆光、雨雾天气等等。每个场景都设定好客观指标比如最近距离、TTC碰撞时间、横纵向加加速度。模型跑完这些场景得分排名一目了然。场景库的价值在于可复现同一个场景今天跑和明天跑结论一致。第二层是闭环仿真连续评测。单个场景压测不够还要把模型放进连贯通畅的仿真路网看它能不能连续开几小时不出事。这里重点看的已经不是会不会碰撞这种底线问题而是交互质量它变道是不是果断跟车距离是不是合适被加塞之后是不是能平复心态。语言能力也在这一层发挥作用让模型输出每次变道/制动的决策理由然后把这些理由主观评分。这一招是传统端到端模型做不到的也是o1型VLA独特的评测维度。第三层才是真实路测。在封闭场地先跑完所有高危场景再上开放道路。路测时除了客观指标还要让多位不同驾驶风格的测试员做双盲打分避免单一个人的主观偏好污染结论。4.3 安全冗余大模型再强也要留兜底无论VLA模型表现多好我都不建议在量产车上做纯模型裸奔式决策。你至少得留三层保险。第一层是决策合理性监控。用一个轻量级规则引擎或者小模型实时检查大模型的输出如果输出的转角/加速度超出合理包络或者帧间动作跳变过大就触发降级。这很像大模型落地里的安全护栏。第二层是底层AEB自动紧急制动这类独立安全系统。它们不依赖感知大模型只靠雷达和视觉对目标物做碰撞判断触发条件极端保守。这层是最后的物理兜底。第三层是远程云代驾或者道路救援兜底。当模型在陌生场景连续输出低置信度决策时主动向云端坐席求助由人类远程接管。把这三层加上VLA系统才能算是可以谈量产规格的。我个人一直跟团队讲一句话VLA负责开得聪明规则和安全系统负责开得安全。两者不是替代关系是互相兜底的关系。5. 复现与工程化踩坑实录5.1 在小算力平台上复现VLA的几个老大难先说一个让人头大的现实VLA模型参数量动辄几十亿训练要用几十张H100/A100级别的卡个人开发者基本复现不了完整版。但这不等于没法玩LoRA这类高效微调技术在消费级显卡上确实能跑起来。我试过用一张RTX 4090对开源VLA基座做LoRA微调效果虽然跟云端全参训练没法比但用来验证方案、跑演示Demo完全够了。最容易踩的第一个坑是显存溢出。解决方案是梯度检查点、混合精度、FlashAttention三件套哪个都不能缺。第二个坑是动作头部分的学习率跟语言骨干不能统一我一般会把动作头设置成骨干的5到10倍否则模型会只更新语言层动作输出几乎不学。第三个坑是扩散动作头的采样种子没固定导致同一场景下每次输出的轨迹都不一样调debug的时候非常抓狂。这个问题的解法是固定随机种子并把采样步数压到20步以内。5.2 微调VLA时防不胜防的翻车现象第一个典型翻车是灾难性遗忘。我遇到过新版本模型在老场景上的表现明显退化跑了旧测试集才知道原来的左侧无保护转弯能力被新数据冲掉了。解决办法是把旧场景代表数据按一定比例混合进每个训练批次里比如保持3成旧数据、7成新数据的比例能有效抑制遗忘。第二个典型翻车是过拟合仿真数据。仿真环境里生成的极端场景样式比较单一模型容易把看到某种贴图纹理当成应该紧急刹车的信号。上了真车一看正常马路也频繁触发幽灵刹车。这个问题的根治方法还是域随机化训练时同步切换光照、天气贴图。第三个典型翻车是动作输出抖动。扩散模型天然带有随机性如果采样过程不稳定会在直线行驶时出现方向盘轻微左右晃。车身控制器看这个信号机械上很快就能感觉到画龙。解决要做两件事一是用动作平滑滤波比如二阶低通二是把扩散去噪的步数稍微调大牺牲一点点延迟换稳定性。这也是为什么延迟能压到32.8毫秒很不容易的原因越接近物理极限留给平滑的空间就越小。5.3 模型上车前的检查清单算法在云端表现好不代表能上车我自己每次送测前一晚都会过一遍部署清单这里也分享出来给你参考。延迟稳定性连续跑1000帧统计单帧推理延迟的P50、P99和最大值。如果最大值是平均值的3倍以上说明推理引擎存在严重抖动必须排查。车端系统不接受这种突发卡顿。功耗和温度车规芯片的散热条件比服务器差很多模型推理时芯片温度如果持续超标性能会大幅衰减。要在高温跑车满载压力测试确认长期稳定不掉帧。回退机制如果大模型输出连续异常比如动作头产生NaN、置信度过低、前视图像丢帧系统要能在毫秒级切到规则兜底。这个切换指令在测试前一定要模拟验证不能只存在于PPT交接文档里。帧间一致性自动驾驶控制是时序过程哪怕每帧延迟只有32.8毫秒帧与帧之间的决策也应该是连续演进的。把一个连续变道过程记录下来逐帧回放如果发现决策跳变要在动作头上加时间注意力或者历史状态缓存。6. 对行业的影响和我的实际感受6.1 自动驾驶大模型将重塑产业链MindVLA-o1这类系统的出现会让自动驾驶能力越来越依赖数据飞轮和算力基础设施而不只是传统的传感器和底盘调校。过去比拼的是毫米波雷达数量、摄像头像素、高精地图覆盖未来比拼的是云端数据中心、场景数据标注产能、模型迭代速度和车规推理芯片。这个变化对产业格局的影响非常直接自研大模型的车企将获得更强的迭代主动权而只做硬件集成的方案商日子会更难过。同时车规芯片的竞争重点也会从支持多少路摄像头转向能跑多大参数的模型、跑多快、功耗多低。我身边已经有不少硬件团队在跟芯片厂商对接时开口第一句不是问IO接口而是问算力能不能支持7B/13B大模型实时推理。6.2 哪些人应该重点关注这个方向如果你正在做智驾算法VLA就是你未来两三年的技术主线别只看传统感知规划了。如果你在做端侧部署和推理加速33毫秒级延迟的大模型车端推理方案是你简历上最值钱的一笔经验。如果你在做数据闭环和标注系统自然语言驾驶描述相关的标注和自动生成工具是明显的增量市场。哪怕是普通技术爱好者也值得留意这个方向。因为当会推理的自动驾驶大模型开始量产上车后你对车的能力预期、对智驾这个词的理解都会完全改变。6.3 个人实践心得这套方向我陆续折腾了小半年最大的体会是别一上来就追求复现完整版MindVLA-o1先把基础动作生成方案跑通比如扩散策略/ACT这类经典路线再去叠加大语言模型骨干最后才考虑o1式思维链推理。步子迈太大最容易在数据标注这一步就卡死。另一个心得是数据工程是整个VLA项目里最值钱的部分。模型结构只要从论文、开源仓库里抄几天就能跑通但一份高质量、带自然语言标注、时间对齐严谨的驾驶数据大概率要磨几周才能成型。谁先把这个环节做扎实谁就真正占了先机。很多团队模型效果不好根因真不在模型结构而是训练数据太糙。最后再分享一个小技巧在做强化学习微调阶段我很推荐整个团队一起看仿真回放。别只看终端指标曲线要看模型跑出来的驾驶轨迹和动作曲线人的直觉依然是发现异常行为最快的工具。我看过的异常里有七八成都是肉眼在看回放时先发现的指标层面反而毫无异常。这条经验可能比任何一项工程技巧都有用。我对MindVLA-o1后续能交出什么样的真实表现很期待我会持续关注它在数据、评测和实车表现上的动静。无论最终成绩如何这个方向本身已经把自动驾驶推进到了一个真正值得认真对待的阶段。
