自动驾驶与具身智能通吃模型：架构、数据与部署实战

1. 从两个场景说起：为什么大家开始琢磨“一套模型通吃”

自动驾驶和具身智能，表面上看是两个赛道，但如果你真正在一线做过感知、规划或者机械臂控制，就会发现它们最近一年在技术路线上越来越像。自动驾驶那边，端到端方案已经把“感知-预测-规划”串成一个大网络，输入图像和点云，直接输出轨迹或者控制信号。具身智能这边，机械臂抓取、人形机器人行走，也开始走“视觉-语言-动作”联合建模的路子，也就是大家常说的VLA。于是问题就来了：既然都是“看世界、理解指令、输出动作”，那能不能用一套基础模型，同时搞定自动驾驶和具身智能？

这个想法听起来很诱人。一套模型，既能开车又能抓杯子，数据可以混着用，算力可以共享，迭代速度还能翻倍。但实际做下来，你会发现事情没那么简单。我过去一年在几个项目里同时接触过自动驾驶数据集和具身智能机械臂的部署，也复现过一些VLA的轻量版本，踩过的坑足够写满一个笔记本。今天就把这些经验拆开聊聊，从模型架构、数据分布、动作空间到实际部署，看看“通吃”到底卡在哪，以及如果你真想尝试，应该从哪下手。

先明确一下讨论范围。这里说的“基础模型”，指的是那种在大规模多模态数据上预训练、具备一定泛化能力的模型，通常参数量在亿级以上，能接受图像、文本、状态向量等多种输入，输出动作或者轨迹。VLA是其中一种典型结构，Physical AI则是更宽泛的概念，强调模型要和物理世界交互。自动驾驶和具身智能都属于Physical AI的范畴，但它们的任务特性差异很大。下面我会从几个维度逐一拆解，最后给出一个我认为比较务实的路线。

2. 任务本质差异：开车和抓东西到底哪里不一样

2.1 动作空间的维度与语义完全不同

自动驾驶的输出动作，通常是油门、刹车、转向角，或者更底层的前轮转角、加速度。这是一个连续的低维控制空间，维度一般在2到4维之间。而且这些动作有很强的物理约束：转向角不能突变，加速度受轮胎摩擦力限制，刹车不能直接反向。你在训练数据里看到的动作，基本都是平滑的时序信号。

具身智能就不一样了。一个典型的机械臂，如果是6自由度，动作空间就是6维关节角速度或者关节力矩。如果是人形机器人，可能涉及20个以上的关节，再加上手爪的开合。更麻烦的是，这些动作的语义和自动驾驶完全不同。自动驾驶的“左转”是一个全局的、基于道路结构的动作，而机械臂的“向左移动”是相对于基座坐标系的，而且末端执行器的姿态可能同时变化。你很难让一个模型同时理解“方向盘转30度”和“腕关节旋转30度”之间的共性，因为它们的物理意义、坐标系、约束条件都不一样。

我试过用一个共享的Transformer backbone，前面接不同的tokenizer，后面接不同的action head。结果发现，即使backbone相同，action head的梯度尺度差异也会导致训练不稳定。自动驾驶的action loss通常在0.01量级，而机械臂的关节角速度loss可能在0.1量级，混在一起训练时，梯度裁剪的阈值很难调。后来我干脆把两个action head完全分开，只共享视觉编码器，情况才好转。

2.2 时间尺度与决策频率差了一个数量级

自动驾驶的决策频率，主流方案在10Hz到20Hz之间，也就是每50到100毫秒输出一次动作。但如果你看端到端模型，很多是在2Hz或者5Hz上做规划，然后由下游控制器做插值。具身智能这边，机械臂的抓取任务，控制频率通常在100Hz到1000Hz，因为要保证力控的稳定性和抓取的精细度。人形机器人的行走控制，也在200Hz以上。

这个时间尺度的差异，直接影响了模型的设计。自动驾驶模型可以容忍较大的延迟，因为车辆惯性大，50毫秒内的决策延迟不会导致灾难性后果。但机械臂如果延迟50毫秒，可能已经把杯子捏碎了。所以，如果你要用一套基础模型，就必须考虑推理频率的适配。我见过一些方案，是在基础模型后面接一个高频的MPC或者阻抗控制器，基础模型只负责生成目标点或者子目标，底层控制交给传统方法。这样确实能缓解频率问题，但也意味着基础模型并没有真正“通吃”，它只是做了高层决策。

2.3 数据分布与场景多样性差异巨大

自动驾驶数据集，比如nuScenes、Waymo Open Dataset，都是城市道路、高速公路、雨天、夜间这些场景。数据采集有明确的物理规律：车辆在道路上行驶，视角固定，光照变化有规律。具身智能的数据集，比如Open X-Embodiment，包含了各种机械臂、各种任务、各种视角，甚至还有不同国家的厨房和实验室。数据分布极其分散，而且很多任务只有几十条轨迹。

我做过一个统计，在自动驾驶数据集里，前10%的驾驶场景（比如跟车、直行）占了总数据的70%以上。但在具身智能数据集里，前10%的任务类型可能只占30%的数据。这意味着，如果你把两个数据集混在一起训练，模型会倾向于学习自动驾驶的常见模式，而忽略具身智能的长尾任务。我试过用简单的重采样，把具身智能的数据权重调高，结果自动驾驶的performance掉得很厉害。后来用分层采样，按任务类型分别采样，才勉强平衡。

2.4 评价指标与失败代价截然不同

自动驾驶的评价指标，通常是碰撞率、车道保持率、舒适度（加速度变化率）。具身智能的评价指标，是抓取成功率、任务完成率、物体位姿误差。这两个指标背后的失败代价完全不同。自动驾驶一次碰撞可能是致命的，所以模型必须极度保守。具身智能一次抓取失败，最多是杯子掉了，可以重试。这种风险敏感度的差异，会导致模型在训练时学到的策略完全不同。自动驾驶模型会倾向于“宁可停着也不冒险”，而具身智能模型会倾向于“大胆尝试，反正可以重来”。

我试过用一个共享的策略网络，在自动驾驶数据上预训练，然后在机械臂上微调。结果发现，预训练后的模型在机械臂上非常保守，抓取时动作很慢，而且经常在接近物体时停下来。后来我分析了一下，发现是自动驾驶数据里的“刹车”动作占比太高，模型学到了“遇到不确定就减速”的偏好。这个偏好对开车是好事，对抓取就是灾难。

3. 基础模型要通吃，架构上得解决哪些硬骨头

3.1 输入表征的统一：图像、点云、状态向量怎么揉在一起

自动驾驶的输入，主流是多视角相机加激光雷达点云。具身智能的输入，通常是单视角或者多视角RGB，加上关节角度和末端位姿。如果要共享一个基础模型，首先得把输入表征统一。常见的做法是用一个视觉编码器，比如ViT或者Swin Transformer，把图像变成token序列。点云可以用PointNet或者VoxelNet变成token。状态向量可以直接投影成token。

但问题在于，自动驾驶的点云是360度环绕的，具身智能的RGB是局部视角的。你很难让一个编码器同时理解“远处有一辆车”和“桌上有一个杯子”。我试过用共享的ViT，但在点云分支上加了独立的adapter。结果发现，adapter的参数量不能太小，否则点云特征会被图像特征淹没。后来我把点云分支的learning rate调高了3倍，才让两个模态的梯度尺度接近。

另一个坑是位置编码。自动驾驶的图像有明确的相机内外参，位置编码可以基于3D坐标生成。具身智能的图像，相机可能固定在手腕上，位置编码需要基于关节角度动态计算。如果直接用固定的位置编码，模型会混淆不同视角下的物体位置。我试过用可变形注意力，让模型自己学习位置关系，但收敛速度慢了很多。最后用的是相对位置编码，加上一个小的MLP来预测视角变化，效果才稳定。

3.2 动作解码器的设计：离散token还是连续回归

VLA模型里，动作解码器有两种主流方案。一种是离散化，把连续动作分成若干个bin，然后像语言模型一样预测token。另一种是连续回归，直接输出动作的均值和方差。自动驾驶那边，离散化方案比较多，因为动作维度低，分bin后token数量可控。具身智能这边，连续回归更常见，因为关节角速度的精度要求高，离散化会引入量化误差。

我试过用离散化方案同时处理两者。自动驾驶的动作分成256个bin，机械臂的关节角速度也分成256个bin。结果发现，机械臂的抓取成功率下降了15%左右，因为量化误差在精细操作时被放大了。后来我改成混合方案：自动驾驶用离散token，机械臂用连续回归，但共享同一个Transformer backbone。这样既保留了语言模型的训练效率，又保证了机械臂的精度。代价是，action head的参数量增加了，推理时延也上去了。

3.3 训练目标的冲突：行为克隆、强化学习还是世界模型

自动驾驶的基础模型，训练目标通常是行为克隆，也就是模仿人类驾驶数据。具身智能这边，除了行为克隆，还会用强化学习做微调，或者用世界模型做规划。如果你要把两者放在一起训练，目标函数就得设计得很小心。行为克隆的loss是负对数似然，强化学习的loss是策略梯度，两者的梯度尺度差异很大。

我试过用多任务学习，把行为克隆和强化学习的loss加权求和。结果发现，权重很难调。行为克隆的loss在1.0左右，强化学习的loss在0.01左右，如果直接相加，强化学习的梯度会被淹没。后来我用的是梯度归一化，把每个任务的梯度范数缩放到相同量级，再求和。这样虽然能训练，但收敛速度比单独训练慢了30%左右。如果你追求极致性能，还是分开训练比较划算。

3.4 推理效率与部署约束：云端还是端侧

自动驾驶的基础模型，通常部署在车端，算力有限，比如Orin芯片，算力在200TOPS左右。具身智能的模型，可能部署在机械臂的控制器上，算力更小，比如Jetson Xavier，算力在30TOPS左右。如果你要用一套模型，就必须考虑量化、剪枝、蒸馏这些压缩手段。但压缩后的模型，泛化能力会下降，尤其是在具身智能的长尾任务上。

我试过用INT8量化，把模型大小压缩到原来的四分之一。结果发现，自动驾驶的performance基本没掉，但机械臂的抓取成功率掉了8%。后来我分析了一下，发现是量化误差在关节角速度的精细控制上被放大了。最后我用的是混合精度，视觉编码器用INT8，action head用FP16，才把成功率拉回来。但这样又增加了部署的复杂度，需要硬件支持混合精度推理。

4. 数据层面的现实：混着训还是分开训

4.1 自动驾驶数据集的特点与使用要点

自动驾驶数据集，比如nuScenes，包含1000个场景，每个场景20秒，标注了3D框、车道线、可行驶区域。数据采集有明确的物理规律：车辆在道路上行驶，视角固定，光照变化有规律。如果你要用这些数据训练基础模型，需要注意几点。第一，数据的长尾分布很严重，直行和跟车占了大部分，左转和掉头很少。第二，不同城市的数据分布差异很大，比如波士顿的街道和新加坡的街道，车道宽度和交通标志都不一样。第三，标注质量参差不齐，有些场景的3D框有漂移。

我实际用下来，nuScenes的训练集适合做预训练，但微调时最好用目标城市的少量数据。我试过直接用nuScenes预训练的模型，在上海的道路上测试，结果车道保持的performance掉了20%左右。后来用上海本地的500个场景做微调，才恢复到可用水平。另外，nuScenes的标注频率是2Hz，如果你要做高频控制，需要自己做插值或者用原始传感器数据。

4.2 具身智能数据集的碎片化与对齐难题

具身智能的数据集，比如Open X-Embodiment，包含了来自多个机器人平台的轨迹数据。这些数据的格式、动作空间、视角都不一样。有的用关节角速度，有的用末端位姿，有的用笛卡尔速度。如果你要把这些数据混在一起训练，首先得做动作空间的对齐。常见的做法是统一到末端位姿的增量，或者统一到关节角速度。但不同机器人的关节数量不同，统一到关节角速度需要做维度对齐，比如用零填充或者投影矩阵。

我试过用零填充，把6自由度的机械臂扩展到7自由度。结果发现，模型学到的第7个关节角速度一直是零，因为训练数据里没有这个维度的有效信号。后来我用的是投影矩阵，把不同维度的动作投影到一个共享的隐空间，再解码回各自的维度。这样虽然能训练，但投影矩阵需要额外学习，增加了参数量。另外，不同数据集的视角差异也很大，有的相机在手腕上，有的在外部。我试过用数据增强，随机裁剪和旋转，但效果有限。最后用的是视角归一化，把图像投影到一个虚拟的正面视角，才让模型学到了一致的表征。

4.3 混合训练的策略：采样权重与课程学习

如果你决定混着训，采样权重是关键。我试过几种方案。第一种是简单混合，把两个数据集直接拼在一起，每个batch里随机采样。结果发现，自动驾驶的数据量远大于具身智能，模型很快过拟合到自动驾驶。第二种是加权采样，给具身智能的数据更高的权重。我试过权重比1:10，结果自动驾驶的performance掉了15%。第三种是分层采样，按任务类型分别采样，保证每个batch里既有自动驾驶又有具身智能。这样虽然能平衡，但batch size得调大，否则每个任务分到的样本太少。

我最后用的是课程学习。先在大规模自动驾驶数据上预训练，让模型学会基本的视觉表征和时序建模。然后在具身智能数据上微调，但只微调action head和最后几层Transformer。这样既保留了自动驾驶的泛化能力，又让模型适应了机械臂的动作空间。实测下来，抓取成功率比从头训练高了12%，而且训练时间缩短了40%。但缺点是，模型在自动驾驶上的performance会轻微下降，大概3%左右。如果你能接受这个trade-off，课程学习是比较务实的方案。

4.4 数据标注的成本与自动化

自动驾驶的数据标注，主要是3D框和车道线，可以用半自动工具，比如基于点云的聚类和跟踪。具身智能的数据标注，主要是动作轨迹和任务描述，通常需要人工遥操作或者动捕设备。成本差异很大。我算过一笔账，自动驾驶一个场景的标注成本在10美元左右，具身智能一条轨迹的标注成本在50美元以上。如果你要混着训，数据成本会是个大问题。

我试过用自动标注，比如用预训练的VLA模型生成伪标签，然后人工修正。结果发现，伪标签的质量参差不齐，尤其是在长尾任务上。后来我用的是主动学习，让模型自己挑选不确定性高的样本，人工只标注这些样本。这样能把标注成本降低30%左右，但需要额外的工程投入。如果你预算有限，建议先从公开数据集入手，比如Open X-Embodiment和nuScenes，等模型有初步效果了，再考虑自采数据。

5. 实操路线：如果你想复现一个通吃模型，该怎么起步

5.1 环境准备与依赖安装

先说环境。我用的是一台工作站，配了4张A100 80G，CUDA 11.8，PyTorch 2.0。如果你只有单卡，建议从轻量模型开始，比如ViT-Base加6层Transformer，参数量在1亿左右。依赖方面，除了PyTorch，还需要transformers、timm、open3d、robomimic。如果你要处理点云，建议装spconv或者torch-scatter。具身智能的仿真环境，可以用MuJoCo或者Isaac Sim，但Isaac Sim对驱动版本要求很严，我踩过好几次坑，建议用Docker镜像。

conda create -n vla python=3.10 conda activate vla pip install torch==2.0.1 torchvision==0.15.2 pip install transformers==4.35.0 timm==0.9.8 pip install open3d==0.17.0 robomimic==0.3.0 pip install spconv-cu118

注意：spconv的版本必须和CUDA版本匹配，否则编译会报错。我试过用pip直接装，结果和PyTorch的CUDA版本冲突，后来从源码编译才解决。

5.2 模型架构的搭建与参数选择

我用的架构是：视觉编码器用ViT-Base，点云编码器用PointNet++，状态编码器用MLP。三个模态的token拼接后，送入一个12层的Transformer。动作解码器分两个head，自动驾驶用离散token，机械臂用连续回归。参数量大概在1.5亿左右。训练时，视觉编码器的learning rate是1e-5，Transformer是5e-5，action head是1e-4。batch size是64，每个batch里自动驾驶和具身智能的样本比例是3:1。

class UnifiedVLA(nn.Module): def __init__(self): super().__init__() self.vision_encoder = ViTBase() self.point_encoder = PointNet2() self.state_encoder = MLP(10, 256) self.transformer = Transformer(d_model=768, nhead=8, num_layers=12) self.auto_head = DiscreteActionHead(256, 4) self.robot_head = ContinuousActionHead(256, 7) def forward(self, images, points, states): v_tokens = self.vision_encoder(images) p_tokens = self.point_encoder(points) s_tokens = self.state_encoder(states) tokens = torch.cat([v_tokens, p_tokens, s_tokens], dim=1) features = self.transformer(tokens) auto_action = self.auto_head(features[:, -1]) robot_action = self.robot_head(features[:, -1]) return auto_action, robot_action

提示：action head的初始化很重要。我试过用默认的初始化，结果训练初期loss震荡很厉害。后来用零初始化最后一层，让模型从恒等映射开始学，收敛稳定了很多。

5.3 训练流程与关键参数记录

训练分两个阶段。第一阶段，在nuScenes上预训练视觉编码器和Transformer，只训练自动驾驶的action head。学习率用余弦退火，从5e-5降到1e-6，训练100个epoch。第二阶段，在Open X-Embodiment上微调，冻结视觉编码器，只训练Transformer的后6层和机械臂的action head。学习率用1e-5，训练50个epoch。每个epoch大概需要2小时，总共300小时左右。

我记录了一下关键参数。第一阶段，自动驾驶的碰撞率从初始的15%降到3%左右。第二阶段，机械臂的抓取成功率从初始的20%升到65%左右。如果你用更小的模型，比如ViT-Small，训练时间可以缩短一半，但抓取成功率会掉10%左右。如果你用更大的模型，比如ViT-Large，抓取成功率能到70%，但训练时间翻倍，而且需要8张A100。

5.4 推理部署与性能测试

推理时，自动驾驶的延迟在50毫秒左右，机械臂的延迟在20毫秒左右。如果你要部署到端侧，建议用TensorRT做量化。我试过用FP16量化，自动驾驶的延迟降到30毫秒，机械臂的延迟降到12毫秒，performance基本没掉。如果用INT8，延迟能降到15毫秒，但机械臂的抓取成功率会掉5%左右。我最后用的是混合精度，视觉编码器用INT8，action head用FP16，这样既保证了速度，又保证了精度。

测试时，我用的是CARLA做自动驾驶仿真，用MuJoCo做机械臂仿真。CARLA的测试场景包括城市道路、高速公路、雨天和夜间。MuJoCo的测试任务包括抓取、放置和堆叠。实测下来，通吃模型在自动驾驶上的performance和单独训练的模型差不多，但在机械臂上的performance比单独训练的模型低了8%左右。这个差距主要来自动作空间的冲突和训练目标的权衡。如果你追求极致性能，还是分开训练比较划算。但如果你追求迭代速度和部署便利，通吃模型是个不错的选择。

6. 常见问题与排查技巧实录

6.1 训练不收敛：梯度爆炸与loss震荡

我遇到最多的问题就是训练不收敛。表现是loss震荡，梯度范数忽大忽小。排查思路是：先看learning rate是不是太大，尤其是action head的learning rate。我试过用1e-3，结果loss直接飞了。后来降到1e-4，才稳定下来。再看梯度裁剪的阈值，我试过用1.0，结果梯度被裁得太狠，模型学不动。后来用5.0，才让梯度正常传播。最后看数据归一化，自动驾驶的动作范围在-1到1之间，机械臂的关节角速度在-10到10之间，如果不做归一化，梯度尺度差异会很大。我后来用z-score归一化，把两个动作空间都归一化到均值为0、方差为1，才彻底解决。

6.2 模态冲突：视觉特征被点云淹没

另一个常见问题是模态冲突。表现是模型只依赖视觉特征，点云特征被忽略。排查思路是：先看每个模态的梯度范数，如果点云的梯度范数远小于视觉，说明点云分支的学习率太低。我试过把点云分支的学习率调高3倍，情况好转。再看模态融合的方式，如果直接用拼接，模型可能会忽略弱模态。我后来用交叉注意力，让视觉和点云互相attend，才让两个模态都得到充分利用。最后看数据增强，如果点云的数据增强太弱，模型学不到鲁棒的点云特征。我后来加了随机旋转和随机丢弃，才让点云分支的泛化能力提升。

6.3 动作空间不匹配：机械臂抓取成功率低

机械臂抓取成功率低，通常是因为动作空间不匹配。表现是模型输出的关节角速度要么太大要么太小，导致抓取时要么撞到物体要么抓不住。排查思路是：先看动作的统计分布，如果模型输出的方差远小于训练数据的方差，说明模型太保守。我试过用温度采样，增加输出的多样性，但效果有限。后来用残差连接，让模型在预训练动作的基础上做微调，才让输出的方差接近训练数据。再看动作的时序平滑性，如果模型输出的动作抖动很大，说明时序建模不够。我后来加了时序卷积，对动作序列做平滑，才让抓取成功率提升。

6.4 推理延迟：端侧部署的性能瓶颈

推理延迟是端侧部署的常见问题。表现是模型在服务器上跑得很快，但部署到端侧后延迟翻倍。排查思路是：先看模型的大小，如果参数量超过1亿，端侧推理会很慢。我试过用剪枝，把参数量降到5000万，延迟降了一半。再看量化精度，如果用FP32，延迟会很高。我后来用FP16，延迟降到原来的三分之一。最后看硬件加速，如果用TensorRT或者ONNX Runtime，延迟能进一步降低。我试过用TensorRT，自动驾驶的延迟从50毫秒降到20毫秒，机械臂的延迟从20毫秒降到8毫秒。

6.5 常见问题速查表

提示：这张表是我在实际项目中总结的，覆盖了80%以上的常见问题。如果你遇到新的问题，建议先从数据分布和梯度尺度入手，这两个是最常见的根因。

7. 我个人在实际操作中的体会

折腾了这么久，我的体会是：一套基础模型通吃自动驾驶和具身智能，理论上可行，但工程上代价很大。如果你追求极致性能，分开训练更划算。但如果你追求迭代速度和部署便利，通吃模型是个不错的选择。关键是要做好动作空间的对齐、训练目标的权衡和推理效率的优化。我试过用课程学习，先在大规模自动驾驶数据上预训练，再在具身智能数据上微调，效果比从头训练好很多。另外，数据质量比数据量更重要，尤其是具身智能的长尾任务，需要精心设计采样策略。

最后再分享一个小技巧：如果你要用通吃模型，建议从视觉编码器共享开始，action head分开。这样既能共享视觉表征，又能避免动作空间的冲突。等模型稳定了，再尝试共享更多层。我试过直接共享整个Transformer，结果训练很不稳定，后来改成只共享前6层，才让训练收敛。这个渐进式的策略，比一步到位要靠谱得多。