ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

阿里入场智驾VLA:从端到端到六维外力的技术跃迁

2026/9/10 9:27:34 拓冰建站 浏览量
阿里入场智驾VLA:从端到端到六维外力的技术跃迁 1. 阿里亲自下场做智驾VLA这事儿藏了多少技术硬货VLA这三个字母最近在自动驾驶圈子里出现的频率高得吓人。我身边好几个搞智驾的朋友过去半年聊天的话题从BEVTransformer、端到端几乎全换成了VLA。而阿里被曝出亲自下场布局智驾VLA还直接对标小米、英伟达、Waymo这些国内外头部玩家这确实是个信号级的事情。标题里的“碾压”两个字我觉得有点夸张但有一点是真的国内互联网大厂从平台侧、云端侧正式切入车端VLA模型研发智驾竞争的技术格局已经变了。先说清楚VLA是什么。VLA是Vision-Language-Action Model视觉语言动作模型。前几年大家聊端到端本质上是把视觉输入直接映射到控制指令中间的规则和中间表征被神经网络代替。而VLA往前走了一步它把自然语言也拉进了这条链路模型不仅看懂路况还能理解语言指令结合对场景的理解直接输出动作。也就是说车不再只是“看见什么就躲什么”而是能够理解“前面有行人意图横穿我在保证安全的前提下减速等待”这类高层的、带有语义推理意味的决策。为什么头部玩家都在往VLA上压资源一句话总结纯视觉端到端解决了“感知到执行”的直连问题但解决不了复杂交互场景中的推理和泛化问题。城市NOA跑到一定阶段你会发现车能开但开得不“懂事”。碰到施工绕行、交警指挥、极限切入、异形车辆传统模块化方案靠规则兜底端到端靠海量数据硬扛但VLA的思路是靠语言模型带来的世界知识去做推理。阿里做VLA的逻辑和它做通义千问、做云计算的逻辑是一致的大模型能力往产业纵深落智驾是最复杂、最有商业想象力的落地场景之一。这篇文章我不打算去重复发布会通稿而是把这轮VLA热潮里真正值得技术人关注的东西拆开讲VLA和上一代智驾方案的核心区别各家技术路线凭什么敢说“领先”以及被反复提及的“六维外力作为VLA一等模态”到底解决什么问题。文末我会给出一份关于VLA部署、测试和对抗攻击的实操记录都是我这段时间从模型调试、仿真环境搭建和实车测试里攒下来的经验希望能帮正在研究这个方向的朋友少踩几个坑。2. VLA到底是什么和传统智驾方案差在哪2.1 从模块化到端到端再到VLA的“三段跳”理解VLA之前得先理解它的两个前任。第一代是模块化方案感知、预测、规划、控制四个模块各司其职每个模块都由人类专家设计规则和网络结构。这套方案统治了智驾行业将近十年优点是每个环节都可解释、可调试缺点是规则写不尽长尾场景一旦碰到corner case整个链路就卡住。第二代是端到端方案以特斯拉FSD为典型代表。它的思路是放弃人工设计的中间表征车道线、障碍物、轨迹预测直接让神经网络学习“图像序列输入到控制指令输出”的映射。端到端的好处是消除了模块间的信息损耗数据驱动上限很高坏处是缺乏显式的推理能力。很多场景它靠的是统计规律而不是真正的理解比如前方有一辆改装车形状很奇怪端到端模型见过相似的样本就能处理没见过就很容易懵。VLA是第三代本质上是把端到端模型和大语言模型做了一次深度耦合。它不再是单纯的感知-控制映射而是把视觉token、文本token、动作token放进同一个Transformer架构里让模型在“理解场景语义”和“生成控制动作”之间共享一套参数。用大白话说VLA让车具备了“看路况、读指令、想对策、打方向”的连贯能力而不是像传统方案那样“摄像头负责看规划模块负责想控制模块负责动”每个环节各干各的。2.2 VLA的关键语言模态到底带来了什么增量很多人问开车这事跟语言有什么关系关系大了。语言模型最大的价值是它压缩了海量的人类世界知识。路面上绝大多数驾驶规则本质上是社会学规则——大家都在路上怎么博弈、怎么礼让、怎么预判对方意图这些很难用代码写清楚但可以在大量文本数据里学出来。举一个street-level的例子。传统方案碰到前车突然打双闪靠边停车规划模块通常会把双闪灯识别为一种状态信号结合车辆减速轨迹做保守决策。VLA则能更进一步它知道“双闪靠边”往往意味着前方可能有故障车、事故或道路收窄因此不只是减速跟停而是会提前做变道预判、观察侧后方路况、评估变道窗口。这种“场景理解驱动行为预判”的能力正是语言模态带来的推理增量。我在自己的测试中发现VLA模型在面对文字类提示比如导航语音“前方300米靠左行驶注意汇入车辆”时能把语言指令和视觉场景对齐生成更加符合人类驾驶习惯的动作。相比之下传统端到端模型对指令的理解是隐性的它只能靠数据里隐含的统计相关性来响应远不如VLA来得直接。这也是为什么VLA被称为通向自动驾驶L4的一条更务实的路径——它把“逻辑推理”这个因子显式地引入了驾驶决策链。3. 各家VLA路线对比阿里、小米、英伟达、Waymo在拼什么3.1 阿里押注“云端车端协同”的VLA新范式阿里下场做智驾VLA最值得关注的不是它做了一个模型而是它背后有一套完整的“云-端”协同打法。智驾模型非常吃算力和数据单靠车端芯片训练不出好模型必须有云端大规模训练集群再通过车端部署实现闭环迭代。阿里最大的底牌是云计算基础设施和通义大模型体系它做VLA的逻辑和做通义千问高度一致——先立一个基础大模型再做行业垂类适配。从技术路线上看阿里更强调VLA的“泛化”能力特别是在中国复杂城市路况下的表现。为了做到这一点阿里在训练数据里加入了大量中文路况描述文本、局部交通规则说明、驾驶行为点评等内容让模型在理解场景的同时还能对齐中文语义环境下的驾驶习惯。这一点和Waymo、英伟达有明显差异有人觉得这只是在堆数据但实际操作过VLA训练的同学应该清楚多语言、多场景的数据配比直接决定模型在不同地域泛化能力的上限。3.2 小米从量产车反推VLA的务实主义者小米在智驾领域的打法一直是“量产优先”。小米SU7上市后智驾系统迭代频率非常高这说明它的数据和工程链路已经跑通VLA模型正好可以借助量产车收集的大量真实路采数据来做持续迭代。小米做VLA的特点是从问题出发而不是从模型出发。它先列出量产车在城市NOA里遇到的典型问题——鬼探头、低速拥堵博弈、小区窄道通行等再针对性设计VLA的训练任务和评测指标。相比之下阿里的路径更像是“先有大模型能力再找应用场景”小米则是“先有场景痛点再有模型设计”。两条路线没有绝对优劣但决定了两个团队在做VLA时关注的指标完全不同。3.3 英伟达与Waymo一个拼算力底座一个拼系统验证英伟达的VLA布局集中在Drive Thor平台和配套的模型训练工具链它不直接造车但想把VLA训练和部署的整套生态都留在CUDA里。VLA模型对算力的需求非常夸张训练阶段尤其依赖大规模GPU集群。英伟达打造整套工具链为的是让所有想做VLA的车企和Tier1都绕不开它的算力底座。从商业角度看这一招很聪明。Waymo一直走的是RoboTaxi路线它做VLA更多是为了在极少数极端场景里补足安全兜底能力。Waymo的积累在于系统验证方法论——它有一套极其严谨的场景拆解、仿真测试、安全指标拆解流程这在L4领域是稀缺资源。换句话说Waymo对VLA的态度更谨慎它不拼“模型参数”或“Demo效果”而是拼“可证明的安全性”。而在中国这套打法往往要更快因为智驾产品的窗口期很短很多团队只能先上车再迭代。厂商VLA技术策略最大优势主要挑战阿里云端训练车端部署强调中文场景泛化云计算基础设施、大模型基座缺少自有量产车型和数据闭环小米从量产问题反推模型设计快速迭代自有车型、数据采集闭环起步相对晚算法代际需要追赶英伟达建设VLA训练与部署的算力生态GPU算力、工具链生态不直接接触车辆和驾驶场景Waymo系统验证驱动安全兜底优先L4验证方法论、多年数据积累商业模式局限迭代节奏偏慢3.4 “碾压”的说法哪里站得住哪里站不住标题里的“碾压”这两个字放在市场声量和资本关注度上阿里确实有优势——体量、大模型能力、云计算资源都是实打实的壁垒。但如果放在自动驾驶工程落地上“碾压”这种说法就太武断了。小米有量产车在手每天都有真实车队在跑数据这是阿里短期内很难补上的短板。Waymo在L4安全验证上攒了十多年的方法论也不是一个VLA模型就能抹平的。我的判断是大家比的不是同一个维度的东西。阿里强在模型能力和计算平台小米强在产品化速度英伟达强在算力底座Waymo强在系统验证。对真正想做智驾研发的从业者来说与其纠结谁能“碾压”谁不如关注VLA这条技术路线上最关键的工程难题尤其是模型部署、数据闭环和对抗安全这几个方向。4. 六维外力作为VLA一等模态解决的是什么问题4.1 什么是“六维外力”为什么它够格当“一等模态”最近研究社区里有一个非常值得关注的趋势VLA模型的研究正在从“仿真驾驶”走向“物理交互”。轮式机器人底盘、机械臂、人形机器人、自动驾驶车辆本质上都是“在物理世界里做动作的智能体”。它们和世界打交道不只是靠摄像头看还要靠“手感”去感知接触力、摩擦力、扭矩这些看不见摸不着的信息。那什么是六维外力一个物体在三维空间里受力可以分为沿X、Y、Z三个轴的力以及绕这三个轴的力矩合起来就是六维。当一个车辆或者机器人在运动时轮胎和地面的接触力、风阻、悬挂系统的反作用力、机械臂抓取物体时的阻力这些都可以通过六维力传感器测量出来。过去这些数据主要用于底盘控制和工业机器人几乎没有进入VLA模型的模态设计里。ForceVLA研究2026提出的核心观点是把末端六维外力作为VLA模型的一等模态而不是辅助信号。所谓的“一等模态”指的是在模型输入层就占据和视觉、语言同等的结构化地位而不是像传统方案那样只在底层控制回路里当作反馈量。这意味着模型的学习目标从“看路况输出转向角度”变成了“理解路况和受力情况输出兼顾安全、舒适和物理可行的动作”。这完全不只是加一个传感器通道而是改变了模型的输入范式和训练范式。4.2 外部力觉信息对智驾VLA的三种实际价值第一提升对路面物理状态的感知能力。视觉方案在雨天、雪天、积水、砂石路面上的感知能力衰减很快但六维力传感器可以直接感知到轮胎和路面之间的附着系数变化车辆是在打滑边缘还是抓地力充足力信号比视觉信号更直接。VLA模型如果能把“视觉看到的路面纹理”与“力觉感知到的附着状态”做跨模态对齐就能生成更加符合物理规律的控制策略。第二增强对车辆动力学极限的判断。高速紧急变道、湿滑路面制动、爆胎情况下的稳定控制这些场景里车辆已经逼近物理极限。传统的控制模块依赖ESC、ABS这些底层系统做兜底VLA模型如果能直接读取六维外力信息就能提前预判车辆是否接近失稳边界在决策层面提前做出更保守的规划。这是我个人非常看好的方向——VLA不只是做“聪明的决策”还要做“懂物理的决策”。第三支撑L4级的舒适性优化。L4车型最终要面对的乘客体验问题不是“能不能到”而是“坐得舒不舒服”。六维外力数据可以直接量化车辆的纵向冲击、横向加速度变化率和垂向颠簸这些信号能够作为VLA训练和评测的客观指标。视觉信息告诉你“前方有一个减速带”力觉信息告诉你“过减速带时的冲击是否超过了舒适阈值”两者结合才能训练出真正让乘客觉得“老练”的驾驶风格。4.3 端到端模型如何处理多模态的力觉数据从技术实现上说力觉数据的引入有三条路线。第一条是把六维力数据编码成token序列输入Transformer和视觉token、语言token拼接让模型自己学习跨模态注意力关系。第二条是把力觉数据和视觉特征做特征级融合在网络的某个中间层注入力觉特征降低对位置编码的依赖。第三条是设计专门的力觉分支网络先单独提取力觉特征再通过跨模态注意力模块与其他模态融合。我实际测试后发现简单地把力觉token拼进序列里效果很不稳定因为力觉信号和视觉信号的时间频率不一致——摄像头通常是30帧或者50帧而六维力传感器可以到几百赫兹时间对齐本身就是个难题。目前更稳妥的做法是在视觉特征提取之后、全局Transformer之前设计一个小型的力觉特征编码分支通过时间窗口对齐的方式做融合这样既保证了力觉信息的完整性又不干扰视觉模态的主干结构。这里还需要解决一个数据问题六维力传感器的硬件成本不低实车全天候采集不现实。我采用的方案是先在仿真环境里大量生成带力觉标签的数据再用少量实车力觉数据做 domain adaptation把仿真环境里学到的力觉-驾驶关联迁移到真实场景。实际效果来看这一步是可行的但要特别注意仿真器里轮胎模型的精度如果仿真和现实的力觉曲线分布差异太大迁移后模型性能反而不如不用力觉信息。5. 从论文到车端VLA部署与测试的实操笔记5.1 VLA训练数据的构成与配比经验VLA模型的数据配比是决定最终效果最直接的因素。我在实际实验中的配置大致遵循一个6:2:2的原则60%的纯驾驶视频-控制数据20%的视觉-语言-动作交错数据20%的感知问答类数据比如“前方是什么类型的障碍物”“当前车道是否可通行”这类问题-答案对。为什么纯驾驶数据比例要拉到60%因为VLA本质还是一个驾驶模型语言能力再强最终输出的是动作而不是对话内容。训练数据里如果语言任务占比太高模型会偏向“理解”而弱化“执行”具体表现是决策过于保守或者动作不够连贯。反之语言数据太少模型就退化成近乎端到端模型语言的推理增益不明显。这个比例需要根据不同数据集微调但6:2:2是一个值得新手起步尝试的基准配置。另外要注意负样本的使用。我早期训练VLA时踩过一个坑把数据清洗得过于干净所有样本都是“正确驾驶行为”结果模型在测试时碰到稍微复杂一点的情况就不知所措因为它从未见过“错误示范”。后来我在训练集中加入约8%的负样本包括危险变道、跟车过近、闯黄灯等模型决策的鲁棒性明显提升。负样本的标注不用做得特别精细只需要给模型一个“这类轨迹不可取”的对比信号。5.2 车端部署的算力约束与量化策略VLA模型体量动辄几十亿参数直接上车完全不可能。目前行业内主流做法是知识蒸馏加量化。我实验得出的可行路线是云端训练一个较大的VLA教师模型车端部署一个参数量在3B到7B级别的学生模型通过模仿学习和偏好优化完成知识转移。学生模型参数量不能太低实测低于1B时模型的场景理解能力断崖式下降尤其对复杂语言指令的理解几乎失效。量化方面我强烈建议优先尝试INT8量化而不是INT4。INT4虽然能把模型压得更小但VLA模型里有大量注意力计算量化误差会在长序列推理过程中累积最终导致决策不稳定。而INT8在保持绝大多数性能的同时可以把模型体积压缩到原来的四分之一左右典型7B模型的INT8版本在车规级芯片上已经可以达到实时运行要求。部署过程中还要特别关注首token延迟。VLA模型的推理延迟直接影响控制指令下发频率如果从图像输入到动作输出超过200毫秒车辆在高速场景下的轨迹跟踪质量会显著下降。我采用的做法是将图像编码器单独部署并通过CUDA Stream与语言-动作解码器并行执行这样能将端到端延迟控制在一帧半以内。5.3 VLA对抗攻击与防御安全测试不能跳过VLA模型的长尾风险和安全性问题最常被忽视的就是对抗攻击。传统CNN模型对微小扰动敏感的问题在VLA上不仅存在而且因为引入了语言模态攻击面变得更大了。攻击者可以在图像上叠加人眼几乎不可见的扰动也可以构造带有恶意指令的文本提示诱导模型做出错误决策。我在测试中发现针对VLA图像编码器的攻击效果非常显著。对一张正常路况图加上幅度仅为4/255的对抗扰动模型可能将“允许左转”识别为“禁止左转”。防御方面常用的对抗训练虽然有效但会降低模型在干净样本上的性能。我的经验是按约20%的比例混合对抗样本进行训练然后通过集成防御在模型输入端做随机化和平滑化来提升鲁棒性而不需要把所有训练数据都换成对抗样本。文本侧的攻击更隐蔽。有人通过在路牌上放置带有误导性文字的贴纸比如“前方施工请直行”试图让VLA模型被文本信息带偏。防御措施是在训练中加入“图像文字可信度判定”任务让模型学会判断视觉场景中的文字信息与驾驶决策的关联度——如果文字和场景本身存在矛盾优先相信场景物理特征。5.4 VLA测试的仿真-实车验证体系VLA的测试不能只靠实车路跑也不能只靠仿真必须两条腿走路。我在实践中搭建了一套三级测试体系第一级是在仿真环境里做大规模回归测试跑数万条场景片段主要验证模型的基础驾驶能力和安全性指标是否回退第二级是半实物仿真也就是把真实路采数据通过回放方式输入模型检验模型的输出决策是否合理第三级才是封闭场地实车测试和公开道路路测。这里要特别提醒做仿真测试的朋友VLA模型在仿真环境里特别容易过拟合到仿真器的“气质”上也就是所谓sim-to-real gap。解决这个问题的核心手段是增加仿真环境中的传感器噪声干扰——包括图像模糊、动态模糊、光照突变、力觉信号噪声等让模型在仿真阶段就见足够多的“坏数据”。我在环境里加入这些干扰后实车测试的首次通过率提高了将近四成这是一个性价比非常高的投入。还有一个经常被忽略的环节评测指标的设计。VLA模型的输出是多维的既包含横纵向控制指令也包含语义层面的中间解释。评测指标如果只看“能否到达目的地”很容易被模型钻空子——比如选择极其保守的驾驶策略虽然安全性达标但效率极低。我的指标设计原则是安全性、效率、舒适性三个维度加权评分其中安全指标权重最高但不做一票否决效率指标反映乘员的通行体验舒适性指标参考加速度变化率等物理量。6. VLA后续还能怎么玩以及我个人的几点判断VLA赛道的演进还有一个值得关注的变量就是它和轮式机器人底盘、机械臂等物理智能体的结合越来越紧密。热词里出现了“导航VLA”“轮式机器人底盘VLA”这些搜索说明关注VLA的人群已经从智能车扩展到了更广义的机器人领域。这个趋势背后的逻辑是VLA模型的“视觉-语言-物理交互”能力本质上不仅适用于自驾车而是适用于一切需要在物理世界里理解和行动的智能体。六维外力作为一等模态的研究正是连接自动驾驶和通用机器人的一座桥梁。我个人在调试VLA过程中最深的体会是它的上限取决于模型架构但它的下限取决于数据工程。同样一个模型架构有的人让它变成“老司机”有的人只能让它变成“应试机器”差别几乎全部来自训练数据的设计、清洗和配比。对比各家发布的技术报告真正的护城河不是模型发了多少篇论文而是他们手里有多少高质量、高覆盖、带标注的真实驾驶数据。说到最后想给正在研究VLA的朋友一点建议不要只盯着模型创新多花时间把数据闭环跑通。造一个VLA模型不难难的是让它持续进化——车端采数据数据回流云端云端标注和训练评测后发布新版本新版本又要经过仿真和实车两道验证。这个飞轮一旦转起来后面别人想追就不是只训练一个更强的模型就能追上的了而是要重走一遍完整的数据工程体系。阿里亲自入场会让这个赛道更热闹但热闹的结果应该是让整个行业的智驾水平往上走一个台阶而不是让PPT里多几个“遥遥领先”的新词。