★ FEATURED ARTICLE 最近总有人问我一句话你们做自动驾驶那套基础模型能不能直接搬过去做具身智能问的人多了我意识到这不是个别人的想法而是行业里普遍存在的期待——一套模型通吃自动驾驶和机器人操作省数据、省算力、省人力听起来确实诱人。但每次听到这个问题我都忍不住先反问一句你说的“通吃”是指用同一套权重跑两个任务还是指用同一套架构和训练管线适配两个场景这两种理解难度差了十倍不止。先说结论目前没有任何公开的、可验证的基础模型能在自动驾驶和具身智能这两件事上端到端通吃而且我认为短期内也不会出现。但这个结论并不悲观因为“不能通吃”不代表“不能共享”恰恰相反这两条赛道在数据表征、世界模型、仿真迁移等层面有大量可以复用的技术底座。这篇文章我想拆开来讲清楚为什么大家会产生“通吃”的念头技术上卡在哪几个关键环节以及现实中更值得走的路径是什么。内容偏工程实践很多细节是从我实际的跑实验、调模型、修bug经历里捞出来的希望能帮在这个路口徘徊的团队省点试错成本。1. “通吃”的诱惑从自动驾驶到具身智能的逻辑链条1.1 技术外溢的必然性数据、架构与人才的三重驱动“一套模型通吃”这种想法不是凭空冒出来的它有非常现实的技术外溢背景。过去五年自动驾驶在环境感知、端到端规划、仿真闭环这些环节积累了大量的技术资产而具身智能恰好也需要这些能力——机械臂要理解场景得先看懂物体在三维空间里的位置机器人要在家庭或工厂环境里移动需要做和车辆类似的避障决策。这种能力需求上的高度重叠让很多人自然产生了一个推断既然两者都依赖视觉语言模型做感知理解都依赖世界模型做状态预测干脆做一个统一模型岂不美哉。资本和人才流向也在强化这个推断。自动驾驶融资进入冷静期之后一批原本做感知、仿真的工程师转投具身智能赛道他们带过去的不仅是代码库还有一整套“用大模型解决感知规划问题”的思维范式。我认识好几个团队做具身智能时直接套用了自动驾驶的BEV感知架构再叠加一个语言指令接口效果居然还不错——这反过来又给“通吃论”添了一把火。但这里有个关键区分共享技术栈和共享模型权重完全是两码事。你可以用同一套Transformer训练管线、同一套点云处理流程、甚至同一个基础设施平台去支撑两个项目这没问题。但要让一个模型在给车规划变道的同时还在脑海里计算机械臂抓取一个玻璃杯的接触力这属于模型容量和任务耦合的问题远不是“共享技术栈”能cover住的。1.2 “基础模型”的三个层次别把三件事混为一谈讨论“通吃”之前我建议先把“基础模型”这个词拆成三个层次否则对话没法进行。第一层是架构基础模型指代同一个骨干网络backbone比如用ViT做视觉编码器无论是给自动驾驶看路况还是给机械臂看桌面都用同一个编码器抽取特征。第二层是预训练基础模型指在一批大规模混合数据上做预训练然后下游任务微调同一个初始权重。第三层是部署态通用模型指同一个权重文件直接跑多种任务不做任何微调或只挂轻量适配器。这三层难度是递进的。架构共享现在就能做成本极低预训练共享已经有些团队在尝试需要仔细平衡驾驶数据和操作数据但可行部署态通用模型我认为在当前的算力和数据条件下硬凑只会两头不讨好。很多时候大家争论“能不能通吃”其实是在不同层次上自说自话——说的是一回事想的是另一回事。先把层次厘清再谈技术方案争论就能减少大半。1.3 仿真与数据侧的共同语言从欧卡2到开源社区还有一个被低估的共性层在数据侧。相关热词里的“欧卡2自动驾驶”很多人不了解它其实是个特别有意思的现象——欧洲卡车模拟器欧卡2虽然是个游戏但它的道路拓扑、交通流动态、天气切换都有较高的物理和规则保真度不少自动驾驶团队拿它做数据扩充和模型鲁棒性测试。这件事给我最大的启发不是“游戏数据能用于驾驶”而是“仿真环境和真实任务之间存在一个可以迁移的中间表征层”。具身智能社区也在做同样的事比如xbotics这类开源社区已经在生态层面沟通自动驾驶和机器人的数据标准。我实际体验下来的结论是如果两边的数据都转成统一的token序列格式那同一个预训练模型确实可以在“表征层面”共享权重。但注意这里共享的是编码器往前的部分解码器和任务头还是各做各的。所以数据侧虽然成了打通两边的桥梁但桥面之下任务侧的隔阂依然深厚。2. 拆开看本质驾驶任务与操作任务到底差在哪里2.1 任务空间差异从“不接触”到“必须接触”要理解为什么部署态通吃这么难得先看清楚自动驾驶和具身智能在任务空间上的本质差异。自动驾驶的核心是非接触式控制——车辆在地面移动绝大多数动作是通过转向、油门、刹车来实现的车辆与物体之间要么保持距离要么以非接触的方式通过。即便遇到紧急情况自动驾驶系统也几乎不会做“推开障碍物”这类动作它的任务是预测和规避而不是干预和操作。具身智能恰恰相反它的核心能力恰恰是接触式操作——机械臂要握住、提起、旋转、推开、按压物体每一件事都依赖准确的力量控制、摩擦估算和接触状态切换。你让一个自动驾驶模型去规划变道它只需要输出一条平滑的轨迹你让同一个模型去规划“把杯子拿起来放在托盘里”它得同时考虑末端执行器的抓取位姿、夹爪闭合力学模型、以及被抓物体被破坏的阈值——这已经完全超出了防碰撞轨迹规划的范畴。这个差异会直接渗透到模型架构的底层。自动驾驶的主流方案输出的是轨迹点或速度指令参数空间基本在几十维以内机器人操作则要输出末端位姿序列、关节力矩、有时候还要输出接触力反馈具有明显的多模态控制特征。让一个模型同时输出这两类完全不同量纲的指令架构上不是不能做而是需要加一大批任务特定的接口和正则项加完之后你发现这个模型已经不是一个模型了而是一个插着好几个不同脑袋的共享躯干。2.2 数据格式与token流物体级与实体级的落差自动驾驶数据集里最常见的佛像是物体框、车道线、轨迹预测标签一切都被简化成“物体级object-level”的抽象。物体框很好用因为车、人、路障这些都在道路平面上运动一个二维框加一个速度向量基本够用。具身智能数据集完全不是这个路数“xbotics具身智能机械臂”这种场景里的数据粗粒度的物体框根本不够你需要像素级分割、深度图、法向量、抓取点标注甚至物体内部材质的信息——这是“实体级entity-level”的颗粒度需求。在落地模型的时候颗粒度差异会变成一个很痛苦的工程问题。我们曾经尝试把一套自动驾驶的BEV感知模型直接用在桌面机器人的场景理解上跑出来的识别精度其实不差但下游仍然无法完成抓取——因为BEV特征天然对“高度”信息的表征是压缩过的而机械臂规划最看重的恰恰是垂直方向上的几何信息。最后我们不得不给模型加了一个额外的点云编码分支这等于给“共享”打了个补丁效率远远低于直接在具身数据上训一个新的感知头。更麻烦的是token流的结构差异。现在做多模态大模型大家都喜欢用token统一一切。自动驾驶这边业界探索的Scene/Motion2Token方案把场景和运动信息都token化形成所谓的token flow这个思路在驾驶域内是自洽的——场景小、结构清晰、实体有限。但到了具身智能token要描述的东西数量级不同而且要描述接触力学和物理状态转移这些信息很难在离散token里不丢精度地编码。强行统一token的结果是自动驾驶这边跑得欢具身智能这边要么token数量爆炸要么接触信息被严重量化损失。2.3 交互对象与语义复杂度从交通规则到人的意图再往深一层看两个领域对“智能”的定义也不太一样。自动驾驶面对的世界虽然复杂但语义规则是高度结构化的——红绿灯的含义是全局约定好的车道线的语义是标准化的行人的意图虽然不确定但运动模式有统计规律可循。这意味着自动驾驶模型可以大量依赖“地图语义交通规则嵌入”来降低不确定性很多方案里把静态车道图编码进embedding就构成模型的一条主要先验路径。具身智能面对的是高度非结构化的开放世界。同样是“把杯子拿给我”这个指令在厨房、办公室、车间三个环境下杯子的位置、周边的障碍物、可用的抓取策略完全不同更要命的是物理世界不存在“全局约定好的规则”你对一个物体的力学理解稍有偏差任务就直接失败。这种高语义不确定性不只在感知层还深入到规划和执行层。有人可能觉得可以用语言模型来统一这种语义理解让两者都变成“多模态指令跟随”。但我实际测试的经验是语言大模型确实能统一指令侧的表达形式却统一不了物理侧的dynamics。你的模型可以说得头头是道但真正输出关节力矩控制机器臂去抓一个易碎物体时语言知识帮不了什么忙——这件事必须靠真实物理交互数据的学习才能做到。3. 世界模型能否一鱼两吃关键技术拆解与算力真相3.1 “世界模型”不只是预测场景重建与行为预测的分野世界模型是当前自动驾驶和具身智能都在押注的技术方向也是“通吃论”最后的大本营。主张通吃的人会说既然自动驾驶的世界模型能预测车辆周围未来几秒的场景演变具身智能也能用同样的模型预测机械臂操作后物体的状态变化这不就统一了吗这话说的理论逻辑没错但落地的难度在于“世界”的定义不同。自动驾驶的世界模型本质上是场景重建行为预测的组合它要重建的是道路拓扑和交通参与者的运动状态要预测的是红绿灯切换、前车刹车、行人横穿这一类宏观行为很多方案用5D flow三维空间加时间加流场来表示这个动态世界这个表示对驾驶任务来说是恰到好处的。然而在机械臂操作系统里需要预测的是橡胶球的形变、纸杯的滑移、软体物体在夹爪压力下的状态变化这属于物理接触动力学的范畴复杂度比驾驶场景的行为预测高了好几个数量级。我见过有人试图在这两个方向共用一个预训练的世界模型做法是先在驾驶数据上做自监督再在操作数据上微调。结果很有意思微调之后驾驶域性能掉10%操作域性能也达不到直训的水平。后来排查发现问题出在预测loss的设计上——驾驶场景的loss偏重轨迹预测和occupancy预测优化方向与操作领域的接触状态预测存在根本冲突。强行共享权重等同于拿一个学了中国象棋的模型去学国际象棋虽然棋盘画得很像棋子的走法完全不同。3.2 自回归生成loss与动作token设计共享架构的真实上限从实现层面看世界模型要让两个领域共用最关键的技术点是动作token的设计。自动驾驶的动作token相对简单——受到“minimal speed commands”最小速度指令思路的影响不少团队把动作输出降维成极低的指令空间只输出几个离散的加速度和转向档位剩下的交给底层控制器去平滑。这也是为什么在很多自动驾驶数据集评测里模型看起来简单利落、指标漂亮。但具身智能的动作token要复杂得多。一个机械臂的动作通常包含末端位置、姿态、开合状态、速度和力控信号如果考虑灵巧手自由度更加爆炸。硬要用一套离散动作token同时覆盖“方向盘转角”和“关节力矩”结果就是自动驾驶这边动作空间浪费、具身智能这边动作空间不足。有人说可以把动作空间统一到一个高维连续空间理论上成立但训练难度会呈指数级上升。我统计过一个小规模的对比实验分别用同一个8卡训练管线训练两个模型一个专用自动驾驶一个专用机械臂抓取再训练一个混合模型同时学两个任务。混合模型的收敛速度比专用模型慢了约60%而在线性能只有专用模型的75%左右——但它的参数量只节省了不到18%。这个效率差距足以劝退大多数工程团队因为省下来的那点内存和显存根本抵不过训一个弱智模型带来的损失。3.3 mAP52.7的陷阱离线指标无法覆盖闭环评测聊到技术挑战就不能不提评测机制。很多团队被“通吃”说服是因为在离线公共数据集上看到了漂亮数字——比如某个混合模型在驾驶感知任务上达到了mAP52.7在机器人物体识别上也表现不俗于是得出“通吃可行”的结论。我劝大家看到这种数字时先冷静一下mAP这类基于感知框的离线指标衡量的是“模型能不能认出场景中的物体”但它衡量不了“模型能不能在闭环环境中完成一连串决策动作”。做完技术拆解我倾向于一个更冷静的判断端到端共享模型在可见未来只能存在于“认知侧”感知、理解、常识推理而“物理侧”运动控制、接触操作、动力学预测必须依赖专用模型除非长期坚持这个常识型路径规划否则终究会被落地场景的现实打回来。这话不好听但跑过产线、跑过路测的人应该懂我在说什么。4. 现实路径一套基础模型加多套任务的工程化落地4.1 共享预训练到底共享什么不共享什么既然部署态通吃不现实那退一步的共享预训练值不值得做我的答案是值得但要像做菜一样分清主料和辅料。可以共享的是感知编码器——视觉、语言、点云这些跨任务通用的特征提取模块不建议共享的是规划解码器和控制输出头——这两者恰恰是任务差异最集中的地方把它们锁死在同一个模型里等于逼一个厨师同时做川菜和粤菜还只给一把勺子。实操层面我建议采用“一个底座两个分支三层释放”的结构。底座是共享的多模态编码器在大量混合数据上预训练两个分支一个是自动驾驶输出头输出轨迹、速度指令一个是操作输出头输出位姿、力控信号三层释放指在部署时底座和分支按需冻结或微调——固定场景用冻结推理数据漂移大时只解冻部分参数做轻量微调。这种设计的好处是模型文件只有一个但内部模块按需优化既保住了共享的参数量优势又留住了任务特化的精确度。4.2 接口标准化把多模态处理做成“shared user interface”这个架构里最考验设计功力的是任务分支和共享底座之间的接口。打个不恰当的比方一个好的接口应当像一个“shared user interface”——用户下游任务不关心底座内部的实现细节只需要通过一套标准化的API拿到想要的特征即可。驾驶任务可能需要的是“场景级特征物体级状态”操作任务可能需要的是“实体级特征空间几何信息”这两者都可以通过同一套接口语言描述但内部特征抽取深度可以不同。我在工程实现中比较青睐的做法是引入Scene/Motion2Token类似的token flow作为接口标准。感知底座输出一个统一的、带空间和时间语义的token序列下游任务各自按需从序列里采样、聚合、解码。这个方案的好处是接口们与具体任务解耦底层架构升级不会引发下游地震坏处是token流的定义和压缩比需要反复调搞不好就会成为性能瓶颈。我亲眼见过一个团队在token流表示上磨了半年最终靠着一个更精细的时空特征对齐方案才跑通。4.3 仿真数据迁移的真实作用先别急着上真机真车数据层面欧卡2这类游戏仿真器给了我们一个非常重要的启发仿真与真实之间的鸿沟可以用共享表示来缩小但完全消除是不现实的。对具身智能团队来说类似xbotics开源社区提供的仿真环境价值不只是帮你白嫖数据而是让你在真实设备烧钱之前先低成本验证“策略的泛化边界”。同样的道理反过来也适用自动驾驶团队如果先在一个高保真仿真器里验证新版模型在数据分布外的表现往往能省下几个月路测返工的成本。但这里有个必须警惕的坑仿真迁移不能把“仿真里work”当成“真实中一定work”。我做自动驾驶评测时踩过的坑是模型在仿真环境下表现极佳一到真实道路就被各种低概率事件击穿。这类问题的根源在于仿真器里的传感器噪声模型和真实硬件存在系统性偏差解决方式只能是分级验证——先在仿真里做大数据量筛选再在真实环境里做小数据量精修。别指望有一套通吃的仿真到真实验证管线那比通用模型还遥远。4.4 从共享到协同两个团队跑一套代码库的协作实战现实中如果一个团队既要交付自动驾驶项目又要交付机械臂项目最现实的方案不是合并模型而是合并基建。我跟一个朋友的公司交流过他们的实操两条业务线共用一套数据管理平台、一套分布式训练框架、一套评测底座但模型权重和实验计划完全分开管理。这样做的好处是训练基础设施的投入double省散伙风险也低——任何一个任务出问题不会拖垮另一条线。实际操作中我强烈建议两件事。第一共享代码库里所有涉及任务特定逻辑的部分必须用插件化接口隔离绝不允许自动驾驶的代码直接调用机械臂的控制器接口否则第三周开始就会出现互相踩脚的情况。第二两条线共用一套CI/CD训练流水线但模型发布权限必须分开否则一个任务升级导致另一个任务回归那种锅谁都不愿背。5. 实操中的血泪经验训练、评测与团队协作5.1 训练节奏设计混合数据调度远比模型架构重要很多团队拿到一个混合模型方案第一反应是去调模型架构但我实际经验是混合数据调度对最终效果的影响通常比架构改动来得更明显。驾驶数据和操作数据的样本量级、难易程度、信息密度完全不一样放在同一个采样器里均匀采样几乎没有好结果。我们最后摸索出来的一套方法是“动态比例采样”训练初期让驾驶数据占大头因为场景状态空间更规整学得快中期逐渐增大操作数据比例引入物理接触带来的复杂特征后期两者交替峰值逼迫模型不断切换特征空间反而能增强共享层的鲁棒性。配套的做法是分阶段冻结与解冻。初期整体训练中期冻结解码器单独训两层任务头后期解冻共享编码器的浅层做精调。这个节奏用的是“先学通用再学专精最后微调底层”的思路踩坑之后发现它也能帮助感知底座学习到兼顾两个域的通用表示而不是被某个任务“带偏”。5.2 评测体系陷阱排查别把A/B测试做成焦虑测试混合模型的评测比单任务模型难得多最容易出现的情况是“各项离线指标都涨闭环一测就崩”。我在实操过程中确定的排查流程如下先做一个基线模型的两次独立评测确认指标波动范围再测混合模型在单任务上的指标看是否显著低于基线最后做跨任务对抗性评测——拿自动驾驶的难例去测机械臂分支拿抓取的奇葩场景去测驾驶分支。这个对抗性评测启动很慢但真的能暴露不少共享特征层互相干扰的问题。还建议加一个“紧急回滚”机制。混合模型训练过程中经常出现的情况是中段表现优异后段突然开始蹦极这通常源于某个任务的数据被另一个任务的数据“淹没”。我们每次跑混合训练都强制存下中间checkpoint并且每周挑一个checkpoint做一次全量闭环评测——这个机制看着笨实际拯救过我们至少两次发布周期。5.3 团队协作模式不要让一个模型背两个KPI最后讲一个最容易忽略的坑组织架构问题。搞混合模型生命周期评估建议始终先回答几个基础问题——你的交付物到底是什么是必须现网两个场景都成功的统一交付还是允许两条线各自精调后续发布我发现当两个业务线同时考核一个混合模型的时候很容易出现“都没人愿意让步”的僵局自动驾驶团队不敢改共享层担心影响路测表现机械臂团队不敢动解码器怕抓取又翻车。最后整个模型进入“谁也动不了”的冻结状态。实操中比较好的做法是设立一个独立的“底座团队”专门负责共享层和对齐层的质量它的KPI不是单任务性能而是“底座在两边做回归时都不产生显著掉点”。这个团队负责维护共享层接口和预训练节奏两个业务团队则在这个底座之上独立迭代任务头。这个角色划分听上去简单但很多团队做不到最后都死在了“谁都有权改共享层”的混乱协作里。写到这儿把我看下来的一点个人体会放最后。想清楚这个问题其实不在于纠结“一套模型彻底通吃”这个宏大命题而在于想明白你到底要节省什么成本。如果目标是省训练算力那共享底座加特化分支是比较明确的路线如果目标是省人员开支和运维成本那反而要慎重因为混合模型的调试复杂度通常会把省下来的那点人力和算力再吃回去。我个人的建议是先别急着追求“同一个权重干两件事”而是先让两个团队用同一套代码栈、同一个数据管线、同一套评测框架跑起来——这种基建层面的“通吃”性价比远高于模型层面的“通吃”。等底座和接口稳定下来如果你还真的需要跨领域的统一部署再逐步把共享层扩大这条路走起来会顺得多。当前阶段拿“通吃”当方向感是可以的拿它当交付标准则大可不必。真干过两个领域的人都知道通用是理想适配才是日常。
阅读完成 · 觉得有帮助？
