★ FEATURED ARTICLE 最近一次技术评审会上一个问题把我问住了你们还在用“BEVTransformer”那条老技术栈下一代方案准备怎么走我顺手指了指屏幕上的VLA2.0发布会回放忽然意识到2025年的智驾竞争已经不再是感知精度从95%提到98%的竞赛而是谁先把语言模型的语义理解能力真正塞进“方向盘”后面。今天这篇内容就是想把VLA2.0拆成能看得懂的块讲清楚它到底是什么、怎么训练的、为什么说它会改变行业打法和评价标准也给还在观望的算法团队一个判断坐标。先说明一下我不会逐条念技术新闻而是按一个从业者的视角去拆。适合三类人看正在做智驾方案选型的工程师、负责产品定义的产品经理、以及想看明白“端到端之后下一代是什么”的行业分析师。如果你对神经网络在车上跑的算力边界还不熟也可以先看第3章和第5章那两章会把约束条件讲得比较细。1. VLA为什么会成为下一个技术拐点三代技术栈的演进逻辑1.1 模块化时代的“规则之美”与天花板十年前做L2级辅助驾驶主流方案是模块化流水线摄像头完成目标检测雷达负责测距然后一个独立的预测模块估计障碍物轨迹最后规划模块生成路径。每个模块各司其职出现问题时可以单独回溯这是它最大的优点也是它在复杂场景里逐渐力不从心的根源。模块化方案的核心问题是“信息在传递中不断打折”。感知模块输出的是目标框和语义标签比如“前方有一个行人”但行人的意图、姿态、周围车辆的让行关系在这个接口里基本丢掉了。规划模块拿到的是一个高度抽象的结果就好比两个同事协作A告诉B的永远只是“那张表格在第几个文件夹”而不是表格内容本身。所以到了城市道路这种长尾场景密集的地方模块化方案需要维护的规则越来越多加塞怎么判断、电瓶车意图怎么建模、临时施工桩桶怎么绕。每接一个新城市几乎都要靠规则工程师去“补丁式”适配。行业里甚至有个玩笑说模块化方案的代码量不是写出来的是“堆”出来的。1.2 端到端解决了什么又留下了什么端到端方案把整条链路压成了一个网络。传感器原始数据进去轨迹和决策直接出来中间没有一个显式接口。这让“信息无损传递”第一次成为可能也让系统具备了从海量数据里学习驾驶行为的能力不再依赖于人类工程师总结规则。但端到端也有一个非常现实的问题它是个黑盒。你只知道它输出了“左转”但很难拆解它为什么判断左转。遇到一个模糊路口的失败案例工程师想去定位是视觉注意力偏了、还是历史轨迹记忆错了往往只能在数据堆里反复试错。更麻烦的是端到端模型对“常识”是缺失的。它可以拟合出非常像人的驾驶轨迹但遇到没有见过的新牌面、新标志、新的施工围挡它并不知道“这个圆角矩形大概率是临时路障”这类基本物理常识。语言模型天然具备的一部分世界知识正好可以补上这一块。1.3 VLA把语言模型带进驾驶场景从“看见”到“理解”VLA全称是Vision-Language-Action也就是“视觉-语言-动作”。它在端到端模型的基础上引入了一个文本表征空间作为“推理中间层”。传感器采集的图像、点云、导航信息先被编码成视觉token随后和文本指令、地图语义一起送入一个类似大语言模型的Transformer主干在语言空间里完成对场景的“理解”最后解码成驾驶动作序列。最关键的差别在于VLA不只是“看见物体”而是把场景描述成了语言可操作的形式。举个例子模型看到前面有一辆公交车打着双闪停在路上传统感知模块只能输出“静态障碍物”VLA可以从语义层面推理出“这辆车可能在上下客后方的电瓶车大概率会绕行我应该预留横向空间”。这就是VLA2.0这一代产品被行业高看一眼的原因。它不再是一个单纯的感知或规划升级而是从架构上让车辆具备了“用语言思考驾驶”的能力。我们后面会详细拆这里先记住一句话VLA的意义不在于更大的模型、更多的参数而在于把“理解”和“行动”放进了同一个优化空间。2. 拆开VLA2.0的引擎盖视觉token、语言接口与动作解码如何协同2.1 输入侧多模态输入的统一序列化VLA2.0在输入端的核心处理是把摄像头图像、毫米波雷达点云、导航地图信息、高精语义地图、甚至语音指令全部统一转换成一个token序列。这个思路跟多模态大模型很像但落到车上更复杂因为车端的传感器源更多、频率不同、时序也不同。摄像头通常给的是1920×1080甚至更高分辨率的多路画面直接丢进Transformer会非常浪费算力。VLA2.0的典型做法是先做尺度归一化和Patch化把图像切成一堆小块再通过视觉编码器变成维度统一的视觉token。为了控制token总量往往还会做一个重要区域感知的裁剪策略驾驶员注意区域、路口区域给更高分辨率两侧和后视以低分辨率兜底这样在算力固定的情况下能提升有效感知质量。我见过一个有意思的工程细节某VLA方案在输入序列里额外加了一个“传感器健康状态token”哪个摄像头被泥水遮挡、哪个雷达出现故障都会作为一个可学习的标记拼进序列。这个标记虽然没有直接影响轨迹输出但在训练时会引导模型学会“当某个输入源异常时主动降级”而不是硬着头皮用坏数据推理。车载并行机制不能完全照搬云端大模型的“稀疏注意力”因为车端的硬件资源和功耗限制更严格。比较务实的做法是分两个阶段先用一个轻量级全局编码器快速扫描整幅画面生成场景级粗粒度token再用一个局部Transformer对粗粒度的重点区域做细粒度推理。这样既保留了全局上下文又控制了单帧计算量。2.2 语言侧常识与逻辑推理如何参与驾驶决策语言接口是VLA2.0里最容易被低估的部分。很多人以为池子里塞一个BERT一样的文本编码器就行实际上它承担了两个任务第一把高精地图语义和导航指令转成向量第二在推理过程中充当“驾驶常识”的锚点。什么叫“充当锚点”举个具体场景主路右侧有一排护栏护栏外是一条辅路导航提示“前方500米右转”。传统端到端模型靠大量数据学习“护栏尽头那个缺口可以转进去”。VLA2.0则可以在语言空间里生成类似“右转需要跨越当前车道、留意护栏缺口旁的自行车、并线距离不足时降低车速”这样的语义表示。这个语义表示不一定是人能读懂的完整句子它更像是一组在语言空间里正交分布的向量把“转弯时机”“目标车道”“风险对象”这些维度解耦开。解耦带来的直接好处是当某个维度的信息有误时模型可以针对这个维度做attention mask的修正而不是把整条推理路径推翻重来。VLA2.0相较VLA1.0的一大提升就是语言接口不再只是一个“场景分类器”而是真正参与到了时序推理里。它会把过去几秒内的语言化事件例如“前车切入”“路口车道线消失”缓存到一个短期记忆队列里再与当前帧的视觉token做跨模态注意力。这跟人开车很像——我们看到前车打灯的同时脑子里还在保留“它刚才在左侧车道”的短期记忆而不是只看当前这一帧。2.3 输出侧轨迹规划与接管请求的分层落盘VLA2.0的输出也不是直接吐出一个方向盘转角就完了。实际落地时输出侧会拆成多层首先是若干个候选轨迹点序列每个轨迹点带置信度其次是一个行为标签比如“变道”“跟车”“刹停”最后还有一个接管风险评估分数用来判断模型自己是否已经开始“心虚”。这种分层输出最大的价值是给了下层的车辆控制模块一个“对齐窗口”。轨迹序列负责给出目标路径行为标签负责解释轨迹语义接管分则用来控制责任转移的时机。如果接管分突然飙升系统会在保持当前安全轨迹的同时提前降低车速给驾驶员留出反应时间。我见过不少团队在这个位置踩坑他们只关注轨迹输出是否平滑忽略了轨迹置信度与接管分的联合阈值设计。结果就是车辆在难以决策的工况下要么过于自信地继续向前开要么过于频繁地退出。VLA2.0之所以被反复强调“安全边界”很大一部分原因就是它在输出层做了显式的风险量化而不是让下游模块自己去猜。另外输出侧的轨迹长度和采样频率也值得注意。城区工况速度低、场景密轨迹时间窗一般给4到5秒采样频率在0.2秒左右高速场景则会拉长到8秒以上采样间隔也能放宽。超参数直接决定解码器的参数量和计算开销这块内容官方通常不会讲得太细但对自研团队来说是很关键的设计决策。2.4 VLA1.0到VLA2.0真正的架构升级在哪里很多文章在聊VLA2.0时都会反复提“参数翻了X倍”“训练数据涨到了多少个视频片段”。这些数字可以作为宣传点但从架构角度看真正的升级在三个方面。第一时序建模深度加深了。VLA1.0基本还停留在“当前帧前后各一帧”的三帧输入模式VLA2.0则引入了真正意义上可学习的记忆模块具备了跨5到10秒的时序上下文。这个跨度让它能理解“前车因为前方施工反复点刹”这种过程性事件而不是只看到当前瞬间的动作。第二输出从“一条路径”进化成“一组带语义标签的路径”。VLA1.0更像是一个连续的控制函数VLA2.0则把“换道”“借道”“绕行”等行为模式变成了显式的离散语义要素。离散和连续在训练上的区别很大离散语义可以直接做监督学习也可以做基于语言反馈的强化学习而连续控制函数很难引入语言奖励。第三它在多模态融合的层级上做了变化。VLA1.0更多是“图像编码器文本编码器拼接后一起过Transformer”拼接感很强VLA2.0更倾向于在编码阶段就用跨模态注意力做融合文本和视觉的信息在很早的层就开始互相调制。这有点像一个团队从“两个部门分别干活最后汇总”改成了“跨部门混编作战”效率提升是结构性的而不是靠堆叠参数量。3. 训练与数据工程VLA2.0最容易被低估的工程量3.1 三类数据来源的配比逻辑VLA2.0的训练数据来源大致可以分为三类真实路采数据、仿真引擎生成数据、以及基于真实数据重放与增强的合成数据。每家车企在这三类上的配比不一样但方向非常一致大家都在想办法把“高质量真实数据”的利用率拉到极致同时用仿真补齐长尾。真实路采数据永远是最有价值的它包含真实的传感器噪声、真实的车流交互、真实的天气光照。但真实数据的痛点也明显难标注、难筛选、难以获得极端场景。很多团队在初期以为“数据越多越好”结果把几千小时的路采数据漫无目的地丢进训练池发现训练效率极低还占用了大量算力。仿真数据的好处是可以精确构建各种边缘场景比如“行人从大货车车头突然出现”“前车掉落货物后的紧急避让”。仿真数据不好的是“分布偏差”问题如果仿真器的物理精度、渲染风格和真实传感器差异太大模型在仿真里学到的特征在实车上可能完全不work。所以现在主流的做法是“重放扰动”把真实路采数据作为模板加上光照、天气、遮挡等扰动生成变体既保留了真实传感器特性又扩大了样本覆盖。根据我看到的一些公开技术分享头部玩家在路采、仿真、重放增强上的配比大概在5:2:3。这个比例不是绝对的但它体现了一个基本原则仿真数据可以多但必须和真实数据混合训练否则模型对仿真的过度拟合会直接影响上线表现。对中小团队来说与其砸重金买仿真平台不如先把自己已有的真实数据管理好、标注好把重放增强的流程跑通效果往往提升更明显。3.2 三阶段训练策略预训练、指令微调、对齐校准VLA2.0的训练流程已经越来越像大语言模型的三阶段范式只是每一阶段的视频数据占比更高。第一阶段的预训练目标是让模型建立“视觉场景-语言描述-驾驶动作”之间的基础映射。这个阶段不需要太精细的标注主要用大量“视频片段对应的粗略驾驶动作”做自监督或弱监督学习。预训练的任务可以设计成“给定一段前向视频预测驾驶员的方向盘操作”让模型先学会理解时间序列里最基本的因果。第二阶段的指令微调是VLA2.0真正区别于传统端到端的地方。这里会把驾驶任务包装成带指令的问题比如“在保持安全的前提下超越前方慢车”然后让模型根据指令输出对应的轨迹。为了让模型学会区分指令中的重要约束训练数据里会有意识地加入“禁止变道”“优先保证舒适性”“需要尽快通过路口”这类不同性质的指令让模型在语言空间里建立约束的排序关系。第三阶段是对齐校准它借鉴了大模型里的“人类反馈强化学习”思路。采集大量“模型输出轨迹-安全员对该轨迹的评分”作为反馈信号通过强化学习微调策略让模型的输出更符合人类驾驶员的偏好。注意这里的评分不能只看是否安全还需要考虑舒适度、效率、规则的平衡。这个阶段有一个工程细节特别值得注意反馈数据需要做非常严格的一致性校验。如果两个安全员对同一个场景的评分差异过大这条数据对模型的负面影响会非常大。所以我在实际项目里会要求标注平台记录每个安全员的历史偏好像做人岗匹配一样做“人-场景”匹配偏好高度一致的人才被分配到同一类场景的评分任务里。3.3 车端算力约束模型多大才装得进量产车说到训练就绕不开车端推理的算力约束。VLA2.0这种把语言模型和视觉模型耦合在一起的架构参数量动辄几十亿到上百亿。一辆量产车上的计算平台功耗和散热都受严格限制不可能像云端那样随随便便跑满几千瓦的GPU集群。目前车端比较主流的高算力平台能提供的神经网络算力大概在几百TOPS的量级但VLA模型的实际有效计算面也就是在推理时可以并行利用的算力通常比理论峰值低很多。Transformer的自注意力计算涉及大量的内存访问TOPS高并不直接等于推理速度快内存带宽反而经常成为瓶颈。所以VLA2.0在实际部署时普遍采用“模型蒸馏”策略云端训练一个很大的教师模型再蒸馏出一个小几倍的学生模型放到车上。蒸馏后的学生模型精度通常会有折损但换取的是推理延迟从几百毫秒降到了几十毫秒这对自动驾驶来说是生死线。蒸馏之外另一个常见的工程手段是“token剪枝”。车端推理时不是每一帧的每一个视觉token都有用例如等红灯时道路两侧的静态建筑信息几乎没有决策价值模型可以通过一个轻量级门控模块来动态决定哪些token可以跳过。这个思路听起来很优雅但实际调优难度不小因为门控模块本身也会犯错一旦把关键token剪掉了后续决策就会出问题。我的建议是初期还是老老实实跑全集token先保证安全再考虑动态剪枝优化。4. 行业影响评估VLA2.0会把智驾竞争引向哪里4.1 对整车产品规划的冲击从功能堆叠到“驾驶人格”VLA2.0发布后行业里讨论最多的问题其实是如果新的技术范式成立那么过去几年各家做的“开城”和“功能堆叠”策略是不是都要重新审视过去一个智驾系统好不好用主要看它开通了多少城市、覆盖了多少条道路、能不能处理掉头、无保护左转、窄路会车这些复杂功能。这些指标背后是大量的规则适配和地图适配本质上是一种“工程量竞赛”。VLA2.0把语言推理能力引入之后系统的泛化能力显著增强不再需要每个城市都去做“特殊规则适配”这会让头部车企在功能开放速度上的差距急剧拉开。“驾驶人格”这个概念正在被越来越多的产品经理提起。传统端到端模型学习到的是一种平均化的驾驶风格而VLA2.0因为有了语言接口理论上可以通过一个非常轻量的方式去调节驾驶风格在指令输入侧加入“更激进”或“更舒适”的文本描述再用少量数据对齐微调就能让同一套模型表现出差异化风格。对整车厂来说这意味着智驾不再是一个配置参数而是一个可以向用户宣传的“灵魂属性”。4.2 对供应商格局的影响算法、芯片、数据三方重新分蛋糕VLA2.0对供应商格局的冲击主要体现在“垂直整合”与“分工边界”的重划上。第一是芯片厂的压力。VLA模型对内存带宽、异构计算调度能力的要求远高于传统CNN那些只擅长做矩阵乘法的车规级AI芯片很快就会在跑VLA模型时显得力不从心。芯片公司如果还想在智驾市场里站住脚就需要把更多的精力投入到Transformer加速、稀疏计算支持、以及异构核之间的数据带宽优化上而不是继续堆算力峰值。第二是图商和导航服务商的位置变化。VLA2.0对高精地图的依赖没有消失但对地图表达的形态要求变了。传统的高精地图更像一套静态CAD图纸VLA2.0更希望地图以“语义化的行车指引”形式存在比如“下一个路口有三个车道左转道在最左侧注意该路口有非机动车混行”。这意味着图商的核心能力从“精度测绘”转向“语义提取”行业门槛和商业模式都会随之变化。第三是算法团队的门槛。过去做智驾方案核心能力是感知算法优化VLA2.0时代核心能力变成了大模型训练、数据闭环、强化学习对齐。这三样东西的经验积累曲线非常陡峭中间断层的小供应商如果不能快速补齐训练能力很可能会逐渐被市场和车企边缘化。4.3 对评价指标的改变开城数、接管率之外的新尺度行业对智驾系统的评价指标也在被VLA2.0一点点撬动。过去我们习惯用“百公里接管数”“城市覆盖数”“复杂功能通过率”去衡量一个系统的水平这些指标本质上都是对“工程覆盖”的评价。VLA2.0真正想证明的是“认知泛化能力”。这很难用传统指标衡量。比如一个系统从没去过某个四线城市它第一次出现在未知道路上的表现这个叫“零样本泛化”现有的开城数指标完全无法体现。越来越多的技术团队开始引入类似大模型评测体系中的Benchmark用一组覆盖“常识理解”“状态记忆”“危险推理”等维度的标准场景集来考察一个智驾系统而不再只是统计它在某个特定城市里跑了多少公里没接管。乐观地讲这个转变对未来更客观但也要泼一盆冷水。任何新指标都会带来新的“刷分行为”厂商很可能会针对Benchmark里的场景做针对性优化。VLA2.0要做成真正可靠的技术底座最终还得靠真实道路的长期泛化检验而不是某一场评测的分数。5. 冷静评估VLA2.0没那么神话落地挑战很具体5.1 算力悖论云端千亿级模型与车端低功耗平台之间的落差我见过不少团队被发布会上的模型规模和跑分震撼回到实验室一评估冷静下来的速度也很快。VLA2.0在云端跑出惊艳效果的模型和车端能量产的模型至少差着几十倍的算力鸿沟。算力悖论的核心在于“训练时的大规模”和“推理时的高效性”之间存在结构性矛盾。大模型很喜欢用稀疏注意力、专家混合这些机制来提升训练效果但这些机制在车端落地时往往因为内存访问模式不规则、动态路由难调度导致推理效率远低于预期。所以车端VLA模型的架构选择从一开始就要受到“能否高效部署”的约束而不能等到模型训完再考虑压缩。我自己的经验是在VLA2.0项目立项时就应该把“部署约束”写进模型设计的需求文档里比如输入图像分辨率上限、Transformer层数上限、注意力头数上限、最大token长度、目标推理延迟。模型设计师和芯片工程师从一开始就在同一张参数表上对话而不是各干各的这会省掉后面大量的返工。5.2 幻觉与安全语言模型一本正经地胡说八道怎么办语言模型最常见的缺陷是“幻觉”它会用流畅的表述编造一个不存在的事实。驾驶系统如果出现幻觉后果是毁灭性的。VLA2.0在架构上引入了语言推理就等于把幻觉问题一并带进了驾驶决策。具体来说VLA2.0的幻觉风险主要有两类。第一类是场景幻觉也就是模型把视觉信息错误翻译成了语义信息比如把路面上的一块影子误认为“前方深坑”并据此规划了一条不必要的绕行路线。第二类是知识幻觉模型基于训练数据里学到的“常识”给出判断但实际上这个判断在当前场景中不成立比如在尚未开放的道路上根据旧地图信息推断“前方有交叉路口”。应对幻觉没有那么万能的方案工程上比较有效的是“冗余校验”和“跨模态投票”。冗余校验指的是用传统的感知规则模块作为“监护者”当VLA模型输出的轨迹与规则模块预期相差太大时触发人工审查或降级接管。跨模态投票则是让相机、雷达、语言语义三个来源独立给出“前方是否有障碍物”的判断至少两个来源一致时才采纳。这一块我必须说明目前的做法本质上都是“用外部约束减弱内部风险”而不是彻底消除内部风险。VLA2.0真正成熟还需要在模型自身的“不确定度估计”上做更多工作让系统清楚地知道自己不知道而不是为了流畅输出而强行编造。5.3 数据不足的中小玩家先做小规模场景验证别急着全栈切换最后想聊聊中小团队和准入门槛。VLA2.0的研发成本、数据成本、算力成本都极高很多人担心这是不是意味着智驾领域接下来只有头部玩家能玩了。我的看法是VLA2.0作为一种通用能力最终大概率会以平台化、开源化的方式下沉。中小团队最务实的路径不是从零训练一个完整的VLA2.0而是在成熟的基础模型之上专注于某个细分场景的微调。比如矿区无人运输、园区物流接驳、特定港口的自动驾驶这些场景的传感器配置相对固定环境变化有限训练数据的获取成本也低得多。具体落地时可以用一套开源的视觉-语言基础模型做底座再采集自己场景里的路采数据做二次微调。微调的数据量不需要很大几万条高质量场景片段就能看到明显效果。等这个细分场景跑通了再去扩展新的场景比一开始就想着做全场景通用VLA靠谱得多。我见过一个团队就是从“停车场跨层巡航”这个功能开始小步快跑地把VLA的“语言导航”能力落地到低速场景半年之后才把能力扩展到公开道路。这个节奏看起来慢但每一步都有真实用户反馈和数据积累。回到那个评审会上的问题。我的判断是VLA2.0不是智驾技术演进的终点但一定是“语言理解与驾驶控制融合”这条路上一个绕不开的坐标。现在讨论这个问题最重要的不是跟风急着换架构而是先把自家的数据规模、算力储备和场景目标盘清楚再决定是全面拥抱还是在某个细分领域先试着啃一小口。就我个人经验来说那些在项目启动时就把“车端能跑多大模型”和“数据从哪里来”想清楚的团队往往比单纯追热点的团队走得更远、更稳。希望这篇拆解对正在做技术规划的你有点帮助也欢迎手里有VLA实车数据的朋友来评论区交流一下真实体验。
阅读完成 · 觉得有帮助？
