最近，自动驾驶与大模型结合的节奏明显加快。通义千问这边直接放出了面向自动驾驶的统一大模型，核心动作是把 3D 感知、VQA 与规划三个能力一起集成进预训练 VLM。对做端到端自动驾驶、多模态大模型和视觉感知的开发者来说，这条技术路线值得从头到尾认真梳理一遍。本文不追热点，只做技术拆解：这个概念到底解决什么问题？架构上怎么组织？数据怎么准备？代码怎么写？落地部署有哪些坑？
这篇文章适合三类读者。第一类是自动驾驶算法工程师，想了解统一大模型和传统模块化方案的差异，以及自己的项目可以从哪里切入。第二类是多模态、大模型方向的开发者，想弄明白 3D 感知如何接入视觉语言模型，而不是停留在“看图说话”的层面。第三类是准备入门自动驾驶 AI 的学生，需要一条清晰、可执行的学习路线。
读完这篇文章，你应该能理解 VLM 自动驾驶模型的整体架构，能看懂 3D 感知、VQA、规划三个任务如何共享一个模型主干，并且能拿到一套最小可运行的 PyTorch 实现框架，知道评测指标怎么组织、常见问题怎么排查。
1. 背景与核心概念
1.1 为什么自动驾驶开始拥抱大模型
传统自动驾驶算法的主流做法是模块化流水线，链路大致是：感知、预测、规划、控制。感知模块负责检测车辆、行人、车道线、红绿灯；预测模块负责估计其他交通参与者的意图；规划模块基于上游结果生成一条安全轨迹；最后交给控制模块执行。
这种模块化方案的好处很明显：每个模块可以独立开发、单独测试、单独替换，团队协作边界清晰。但它的缺点在复杂场景下也非常突出。
第一，模块之间存在信息损耗。感知模块输出的是抽象的检测框、类别和速度，而不是原始场景的整体语义。预测模块拿不到感知模块丢掉的信息，规划模块又拿不到预测模块没表达出来的交互关系。每一层抽象都在减少信息量，最终规划模块很难做出全局最优决策。
第二，标注成本高。每个模块都需要独立的数据标注，感知需要 3D 框，预测需要轨迹意图，规划需要专家轨迹，每个任务的标注规范还不一样。维护三套数据管道既贵又慢。
第三，误差累积。感知漏检一个目标，后面的预测和规划基本都会出错；感知框抖动一下，规划轨迹也可能跟着抖动。端到端方案正是冲着这三个痛点去的，而大模型的出现，让端到端方案第一次拥有了“常识推理”能力。
通义千问这次推出的自动驾驶统一大模型，典型的特征是“一个底座，三个任务”：用同一个预训练 VLM 作为底座，把 3D 感知、视觉问答和规划都挂在上面。这意味着模型看到场景之后，先感知、再理解、最后规划，整个链路是共享特征的，不再是三套独立系统。
1.2 三个关键词：3D 感知、VQA、VLM
在继续往下看之前，先明确三个基本概念，后面所有内容都围绕它们展开。
3D 感知，是指让模型在三维空间里理解周围环境。输入是多视角摄像头图像或者激光雷达点云，输出包括目标的 3D 框（中心点坐标、长宽高、朝向角）、类别、速度等属性。3D 感知与 2D 感知最大的区别是它带深度信息，车辆在物理世界里的位置、尺寸、朝向都是明确的，这部分信息是规划和决策最需要的基础。
VQA，即 Visual Question Answering，视觉问答。给定一张或一组图像，模型需要回答关于图像内容的问题。普通的 VQA 用在通用图像上，比如“图里有什么颜色的花”。到了自动驾驶场景，VQA 的问题就变成“前方那辆白色轿车是否在减速”“左前方车辆下一步会不会变道”这类和驾驶决策强相关的问题。
VLM，即 Vision-Language Model，视觉语言模型。它同时具备图像理解能力和语言生成能力，典型结构是“视觉编码器 + 语言模型”。输入可以是图像、文本或两者的组合，输出则是文本或者进一步接出的任务结果。
把这几个概念连起来看，统一大模型做的事情就是：先用 3D 感知能力理解三维场景，再用 VQA 接口完成场景推理，最后把推理结果交给规划头生成轨迹。三个能力不再是三个模型，而是同一个 VLM 内部的三个输出分支。
1.3 “统一大模型”到底在解决什么问题
一个很自然的疑问是：既然 3D 感知、VQA、规划都能单独做，也都能做得不错，为什么一定要“统一”？
这里的关键在于，独立模型的组合存在三个根本性缺陷。
第一个缺陷是特征不一致。感知网络输出的特征向量和规划网络需要的特征向量，通常不在同一个语义空间。想要让感知结果真正指导规划，必须设计额外的特征适配层，而适配层本身又会引入新的误差来源。
第二个缺陷是联合优化困难。在传统流水线里，感知的误差会原样传给规划，但规划产生的损失无法反向传播回去修正感知。这意味着感知模块永远不知道它的输出对最终轨迹产生了多大影响。
第三个缺陷是可解释性差。传统端到端方案是一个黑盒，输入图像直接输出轨迹，中间没有一段“人类能看懂”的推理过程。出了问题，工程师只能翻网络中间特征，定位成本极高。
统一大模型把三个任务放进一个共享主干之后，感知结果能直接作为 VQA 推理的“事实依据”，VQA 推理结果又能直接作为规划的条件，三个任务互相提供监督信号，整个系统也因为有语言输出而变成了可以阅读、可以追问、可以审计的模型。这就是统一方案最核心的价值。
2. 技术架构拆解
2.1 整体设计：共享主干 + 多任务头
先看一个抽象的架构描述：
输入（多视角相机图像 + 可选激光雷达点云） ↓ 视觉编码器 → 特征 Token ↓ 大语言模型主干（场景理解、常识推理、上下文记忆） ↓ 3D感知解码头 VQA文本解码头 规划轨迹解码头 ↓ ↓ ↓ 3D框/属性 自然语言回答 未来轨迹点这个架构最关键的地方在于三个任务头共用同一个视觉语言主干。不管是输出 3D 框、自然语言还是轨迹，它们的特征来源都是同一份场景表示，而不是各自独立的卷积网络。
这样做有一个很重要的工程收益：优化目标可以互相传导。当模型回答“前车在减速”时，它不是先有一个独立的检测结果，再把这个结果拼进文本；而是 VQA 输出直接利用了感知任务训练出来的空间特征。反过来，规划头也会利用 VQA 推理得到的语义信息，比如“前车意图变道”这个结论会直接影响轨迹生成。
2.2 3D 感知如何与语言模型对齐
把 3D 感知接入语言模型，最大的挑战是“空间概念”和“文本概念”的对齐。语言模型操作的是离散 token，3D 感知操作的是连续的、带几何含义的空间特征。这两者不能直接相加。
目前主流做法有两类。
第一类是 BEV 特征投影。先把多视角图像通过视角变换映射到鸟瞰视角，得到 BEV 特征图，然后把 BEV 特征展开成 token 序列，送入语言模型。这种方式的好处是保留了空间的几何一致性，模型在 BEV 坐标系下更容易理解“左前方”“30 米外”这类空间指令。
第二类是稀疏查询方式。语言模型内部本身就有大量可学习的 query，可以让这些 query 变成 3D 空间的“锚点”。每一个 query 负责从图像特征中采样某个空间位置的区域特征，再与文本 token 拼接，一起进入 transformer 层做交互。
无论哪一类，最后都需要一个投影层，把空间特征维度映射到语言模型的隐藏维度。投影层通常是几层 MLP，在整个训练过程中和主模型一起更新。
对齐质量直接影响统一模型的性能。常见的现象是：模型文本回答很流畅，但回答内容对应的空间位置是错的。这种情况大多是空间特征和文本特征没有真正对齐，需要检查投影层的设计以及训练数据里 QA 问题和 3D 目标的绑定关系。
2.3 VQA 是推理接口，不是聊天功能
一提到视觉问答，很容易理解成“看图聊天”。在自动驾驶统一大模型里，VQA 的定位完全不同，它更像是一个结构化的推理接口。
它有两个核心作用。
第一个作用是提供可解释的中间监督。模型在做决策之前，先回答一系列和场景有关的问题，相当于把规划的依据用自然语言写出来。比如模型先答出“前方 30 米处有行人横穿马路”，然后规划头才生成减速避让的轨迹。这个“先答后规划”的机制，让工程师可以通过 VQA 的答案判断模型是否真的理解了场景，而不是盲目相信最终轨迹。
第二个作用是统一任务输入输出格式。指令可以被书写成文本：“前方交通灯是什么状态？”“给出未来 5 秒的避让轨迹。”模型在文本指令的驱动下，既输出理解结果，也输出规划结果。这种统一格式还带来一个附加好处：模型天然具备多任务泛化能力，新的任务只要能用文本描述，就能通过指令微调快速接入，不用重新设计网络结构。
但这里要注意，VQA 问题不能是“为了问而问”。每个问题必须绑定到具体的场景目标和时间戳。否则模型学会了语言常识，却没有学会“看场景回答问题”，这在自动驾驶场景里是极其危险的。
2.4 规划头如何利用统一特征
规划模块在传统方案中一般是独立的行为决策和轨迹规划算法，输入是感知目标列表和高精地图，输出是轨迹。在统一大模型里，规划头变成了一个条件生成器。
规划头的输入不再是手工拼接的特征，而是共享主干输出的统一特征，同时叠加 VQA 推理结果的语义特征。规划过程可以设计成自回归式：模型预测下一个轨迹点时，会把之前的轨迹点作为条件，逐步生成完整轨迹。
这样设计有几个实际收益。首先，规划轨迹天然会感知到检测到的障碍物位置，因为感知头的特征就在同一个特征空间里。其次，规划能利用语言推理结果，比如 VQA 模型判断“前方货车可能右转”，规划头就会自动倾向于生成向左绕行的轨迹。最后，规划和感知共享梯度，感知任务学到的空间信息会通过反向传播改善规划效果，规划产生的误差也能约束感知特征的质量。
当然，统一特征也意味着风险集中。如果共享主干输出错误，三个任务会同时出错；如果 VQA 推理错了，规划也会跟着错。所以后面章节我会专门讲安全冗余设计。
3. 数据、训练与评测体系
3.1 公开数据集与任务格式
想做自动驾驶 VLM 实验，第一步是组织数据。当前公开数据集里比较常用的是 nuScenes、Waymo Open Dataset 等。这类数据集通常提供多视角相机图像、激光雷达点云、3D 目标框标注以及自车轨迹。
但在统一大模型场景下，只有 3D 框还不够，还需要额外的 VQA 标注。学术社区目前生成 QA 对的方式有两类：一类是人工标注，质量高，但成本也高；另一类是用语言模型自动生成候选问题答案对，再由人工抽查修正。
一条有效的 QA 样本通常长成下面这样：
{ "scene_token": "scene_000012", "timestamp": 3.2, "question": "前方那辆白色轿车正在减速，它下一步最可能做什么？", "answer": "前方轿车正在减速，且左侧车道有空间，它可能准备变道。", "target_object_id": "predict_001234" }这里最容易被忽略的是target_object_id和timestamp字段。QA 必须能对应到具体的 3D 目标，也必须能对应到具体的时刻。如果问题问的是“前方车辆”，但模型看到的其实是 3 秒前的场景，训练出来的模型在真实道路上就会“时空错乱”。
规划任务同样需要标注轨迹。公数据集里自车轨迹通常来自高精定位系统，可以直接用来做模仿学习，也就是让模型输出的轨迹尽量贴近真实驾驶轨迹。
3.2 训练阶段的划分
把三类任务一次性端到端地训练，是一种理想状态，现实中很难直接收敛。工程上普遍采用分阶段策略，通常分三个阶段。
第一阶段是视觉语言预训练。目的不是让模型学会自动驾驶，而是让视觉编码器和语言模型具备基础的对齐能力，模型得先能“看图说话”，才能进一步“看图开车”。
第二阶段是领域感知预训练。用自动驾驶公开数据训练 3D 感知能力，让模型学会检测三维目标、预测目标属性。这个阶段通常不需要语言任务参与，或者只保留轻量的语言监督。
第三阶段是多任务指令微调。把 3D 感知、VQA、规划三个任务统一到指令格式里，一起做微调。这个阶段的任务是让模型学会“根据不同的指令，切换到不同的输出头”。
前两个阶段如果做不好，直接到第三阶段，很容易出现灾难性遗忘。模型学了一堆驾驶问答，却忘记了基础的检测能力，最终表现就是 VQA 答得头头是道，但 3D 框输出完全不可用。
3.3 损失函数与评测指标
统一模型的训练损失是三个任务的加权和，形式可以写成：
L = λ1 * L_det + λ2 * L_text + λ3 * L_planL_det：3D 检测损失，包括 3D 框回归损失和分类损失，通常使用 Smooth L1 和 Focal Loss 的组合。L_text：VQA 文本生成损失，一般是语言模型的交叉熵损失。L_plan：规划轨迹损失，常见的有模仿学习里的 L2 损失，也可以加入碰撞惩罚项。
评测指标也应该按任务分别设计。3D 感知常用 mAP（mean Average Precision），计算的是 3D 检测框与真值框的交并比（IoU）。VQA 部分可以用回答准确率、BLEU、ROUGE 等文本指标，但更推荐以人工评估为主，小规模随机抽样，因为自动驾驶 QA 的答案往往不是唯一的。规划部分最常用的是 ADE（Average Displacement Error，平均位移误差）和 FDE（Final Displacement Error，最终位移误差），分别衡量整条轨迹和终点位置与真值轨迹的平均偏移。
注意，规划指标只能反映“像不像真值轨迹”，不能反映“安不安全”。如果真值轨迹本身存在争议，或者数据集里的真值轨迹不是最优轨迹，规划的指标再好看也不代表能安全落地。后续评估一定要补充碰撞检测、急转弯次数、舒适度这类安全性和体验指标。
4. 最小可运行实现
接下来给出一套最小可运行的实现思路。下面的代码基于 PyTorch，重点演示“共享主干 + 多任务头”的模型组织方式。为了控制篇幅，我对模型组件做了大幅简化：视觉编码器用普通 CNN 代替，文本解码器用 GRU 代替，真实项目中这两部分都应该替换为预训练 VLM。代码的意义在于让你看清楚任务如何组织，而不是让你直接拿去商用量产。
4.1 环境与项目结构
建议环境如下：
- Python 3.10 及以上
- PyTorch 2.0 及以上
- transformers（可选，用于加载预训练视觉编码器或语言模型）
安装依赖：
pip install torch torchvision transformers项目结构按下面的方式组织：
driving_vlm/ ├── model.py # 统一模型定义 ├── dataset.py # 数据读取与预处理 ├── train.py # 训练入口 ├── evaluate.py # 评测入口 └── config.yaml # 资源配置4.2 模型定义
# 文件路径：driving_vlm/model.py import torch import torch.nn as nn class UnifiedDrivingVLM(nn.Module): """ 一个简化的自动驾驶统一大模型。 真实项目中，vision_encoder 可替换为 CLIP、Qwen-VL 等预训练视觉编码器， text_decoder 可替换为 Qwen、LLaMA 等大语言模型。 这里为了展示结构，使用简单 CNN 和 GRU 作为示意。 """ def __init__(self, num_queries=200, hidden_dim=512, future_steps=6): super().__init__() # 视觉编码器：将多视角图像编码成特征向量 self.vision_encoder = nn.Sequential( nn.Conv2d(3, 64, kernel_size=3, stride=2), nn.ReLU(), nn.Conv2d(64, 128, kernel_size=3, stride=2), nn.ReLU(), nn.AdaptiveAvgPool2d((8, 8)), ) self.bev_proj = nn.Linear(128 * 8 * 8, hidden_dim) # 3D 感知解码头：预测 num_queries 个目标的 3D 框 self.perception_queries = nn.Parameter(torch.randn(num_queries, hidden_dim)) self.perception_head = nn.Linear(hidden_dim, 9) # 8维框属性 + 1维类别 # 语言解码器：简化版 GRU self.language_token_embed = nn.Embedding(10000, hidden_dim) self.language_decoder = nn.GRU(hidden_dim, hidden_dim, batch_first=True) # 规划头：预测未来 future_steps 个轨迹点 self.plan_head = nn.Sequential( nn.Linear(hidden_dim, 128), nn.ReLU(), nn.Linear(128, future_steps * 2), ) def forward(self, images, text_tokens=None): """ images: (B, N, 3, H, W)，N 为视角数量 text_tokens: (B, L)，语言指令 token，可为空 """ B, N, C, H, W = images.shape # 1. 多视角图像编码 feats = self.vision_encoder(images.view(B * N, C, H, W)) feats = feats.view(B, N, -1) feats = feats.mean(dim=1) # 简单平均融合各视角 shared_feat = self.bev_proj(feats) # (B, hidden_dim) # 2. 3D感知分支 perception_feat = shared_feat.unsqueeze(1) + self.perception_queries.unsqueeze(0) perception_out = self.perception_head(perception_feat) # (B, num_queries, 9) # 3. VQA文本分支 if text_tokens is not None: text_emb = self.language_token_embed(text_tokens) lang_feat, _ = self.language_decoder(text_emb) lang_feat = lang_feat[:, -1, :] # 取最后一个时间步 else: lang_feat = shared_feat # 4. 规划分支 plan_input = shared_feat + lang_feat plan_out = self.plan_head(plan_input) # (B, future_steps * 2) plan_out = plan_out.view(B, -1, 2) return perception_out, plan_out代码说明：
perception_queries是一组可学习的空间锚点，每个 query 会从共享特征中聚合信息，最终预测一个候选目标的 3D 框。这和 DETR 系列检测头的思路一致。- 文本分支在
text_tokens为 None 时只依赖视觉特征。实际训练时，如果目标是联合优化 VQA 和规划，建议始终传入文本 token。 - 规划头最终的输出形状是
(B, future_steps, 2)，最后一维表示 x、y 坐标。真实项目中还需要把坐标映射回全局坐标系或车辆坐标系。
4.3 数据管道与训练脚本
# 文件路径：driving_vlm/dataset.py import json import torch from torch.utils.data import Dataset class DrivingVQADataset(Dataset): """读取组织好的自动驾驶 VQA 数据。""" def __init__(self, annotation_file, data_root): with open(annotation_file, "r", encoding="utf-8") as f: self.data = json.load(f) self.data_root = data_root def __len__(self): return len(self.data) def __getitem__(self, index): sample = self.data[index] # sample 结构见前文 JSON 示例 question_text = sample["question"] answer_text = sample["answer"] # 真实场景中，这里需要根据 scene_token 和 timestamp 读取图像并做预处理 images = torch.randn(6, 3, 224, 224) # 示意：6 视角图像 trajectory = torch.randn(6, 2) # 示意：未来 6 个轨迹点 return { "images": images, "question_text": question_text, "answer_text": answer_text, "trajectory": trajectory, }# 文件路径：driving_vlm/train.py import torch import torch.nn as nn from torch.utils.data import DataLoader from dataset import DrivingVQADataset from model import UnifiedDrivingVLM def train_one_epoch(model, dataloader, optimizer, device): model.train() total_loss = 0.0 for batch in dataloader: images = batch["images"].to(device) trajectory = batch["trajectory"].to(device) # 当前简化示例不训练文本生成，loss 只包含检测和规划 perception_out, plan_out = model(images, text_tokens=None) # 规划损失：L2 plan_loss = nn.functional.mse_loss(plan_out, trajectory) # 检测损失：示意，实际需按 3D 框格式计算 det_loss = perception_out[:, :, :].abs().mean() loss = plan_loss + 0.5 * det_loss optimizer.zero_grad() loss.backward() optimizer.step() total_loss += loss.item() return total_loss / len(dataloader) if __name__ == "__main__": device = "cuda" if torch.cuda.is_available() else "cpu" dataset = DrivingVQADataset("annotations.json", "./data") loader = DataLoader(dataset, batch_size=2, shuffle=True) model = UnifiedDrivingVLM().to(device) optimizer = torch.optim.AdamW(model.parameters(), lr=1e-4) for epoch in range(10): loss = train_one_epoch(model, loader, optimizer, device) print(f"epoch {epoch}, loss {loss:.4f}")这个训练脚本只展示了流程骨架。实际项目里还需要加入文本生成的交叉熵损失、3D 框的真实匹配策略，以及训练过程中的学习率调度、梯度裁剪等常规操作。
4.4 评测脚本
# 文件路径：driving_vlm/evaluate.py import torch from model import UnifiedDrivingVLM def mean_displacement_error(pred, target): """计算平均位移误差（ADE），单位与输入坐标一致。""" return torch.mean(torch.norm(pred - target, dim=-1)) def final_displacement_error(pred, target): """计算最终位移误差（FDE）。""" return torch.norm(pred[:, -1, :] - target[:, -1, :], dim=-1).mean() if __name__ == "__main__": model = UnifiedDrivingVLM() model.eval() with torch.no_grad(): images = torch.randn(1, 6, 3, 224, 224) pred_traj, _ = model(images, text_tokens=None) gt_traj = torch.randn(1, 6, 2) ade = mean_displacement_error(pred_traj, gt_traj) fde = final_displacement_error(pred_traj, gt_traj) print(f"ADE: {ade.item():.3f} m") print(f"FDE: {fde.item():.3f} m")评测脚本里只实现了 ADE 和 FDE 两个轨迹指标。真实项目还需要补充 3D 检测的 mAP、VQA 的准确率、轨迹碰撞率等多维度指标。
5. 常见问题与排查思路
统一大模型在开发过程中会遇到很多问题，下面把高频问题整理成一张表，方便排查时对照。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 多任务训练时 loss 震荡不收敛 | 三个任务的损失量纲差异太大，权重设置不合理 | 先固定检测和规划损失，逐步加入文本损失；或对每项 loss 做归一化处理 |
| 3D 感知结果与语言回答不一致 | 视觉特征和文本特征没有完成对齐 | 检查投影层设计，确认感知任务和 VQA 任务是否在同一个主干上联合训练 |
| 规划轨迹与障碍物碰撞 | 规划头只是回归轨迹，没有真正利用感知约束 | 把感知头的特征显式送入规划头，或在规划损失里加入碰撞惩罚项 |
| 显存不足 OOM | 多视角图像加大语言模型同时前向，显存占用过高 | 使用梯度累积、混合精度训练、减小 batch size，或冻结图像编码器 |
| VQA 答非所问 | 问题模板和真实场景不一致，或 QA 标注与 3D 目标时间戳没对齐 | 检查训练集 QA 与场景标注的一致性，增加真实场景问题比例 |
| 微调后基础检测能力退化 | 灾难性遗忘 | 降低领域微调学习率，保留少量通用数据集混合训练，或使用 LoRA 等参数高效微调方式 |
| 规划指标很好但实际体验差 | ADE/FDE 只能衡量与真值轨迹的相似度，不能衡量安全性 | 增加碰撞检测、急弯、舒适度等额外指标，结合仿真闭环评测 |
如果训练一开始 loss 就出现 NaN，优先检查数据里是否有空图像、异常坐标和 NaN 标签。统一模型的输入链路长，数据问题的定位成本比单任务模型高很多，数据清洗可以在前期省下大量排查时间。
6. 最佳实践与工程建议
6.1 数据质量是第一优先级
统一大模型对数据质量极其敏感。同一个场景里，如果 3D 框标注的时间戳和 QA 答案描述的内容差了一帧，模型就会学到错误的对齐关系。每个 QA 问题必须能对应到具体目标，并且和 3D 标注使用同一套坐标系、同一个时间戳体系。
如果团队没有足够的人工标注能力，优先保 3D 标注质量，QA 对可以用语言模型生成后再人工抽查。反过来，如果 QA 标注很规范，但 3D 框标注质量低，模型就会“回答得很有条理，但空间位置全是错的”。这两种情况都意味着后面要返工。
6.2 多任务训练的权重策略
三个任务的 loss 量纲完全不同：检测 loss 可能是平滑 L1 数值，文本 loss 是交叉熵，规划 loss 是 L2 位移误差。直接放到一起优化，大概率出现某一项一骑绝尘、其余项被无视的情况。
实践中有两个方向可选。一是使用不确定性加权，让模型自动学习每个任务的重要性；二是先固定检测和规划两个任务，等模型稳定后再加入文本任务。无论选哪个，都要记录每个任务单独的 loss 曲线，而不是只盯着总 loss。某个任务的 loss 突然上升，通常不是那个任务本身的问题，而是共享主干的特征被其他任务“带偏”了。
6.3 安全边界与部署形态
自动驾驶是安全关键系统。统一大模型再强大，现阶段也不应该作为唯一的决策来源。工程上更稳妥的做法是“大模型做理解、规则层做兜底”。
具体来说，可以保留一套独立的安全校验模块。大模型规划出轨迹之后，校验模块会对轨迹做碰撞检测、限速检查和最小风险操作判断。一旦发现轨迹异常，就切换到独立的规则规划器，而不是依赖大模型自己纠正。
部署形态上，大模型通常先部署在云端，负责复杂场景的远程判断和高价值场景的数据回流；车端则部署经过蒸馏和量化的小模型，保证实时性和确定性。云端判断结果可以再用于迭代车端模型，形成一个数据闭环。
6.4 日志、版本与可复现性
统一模型工程的复现成本比单任务模型高得多。建议从第一天就建立完整的版本管理体系，包括代码版本、数据集版本、模型权重版本和评测脚本版本四部分。
日志方面，每个测试场景至少保留四类信息：原始图像、3D 感知输出、VQA 文本输出、规划轨迹。这四类信息缺一不可。遇到线上问题，工程师应该能根据场景 ID 重新回放整个推理过程，而不是只看一个最终轨迹 CSV。
另外要注意数据授权边界。使用 nuScenes 等公开数据集时遵守对应 license，内部私有数据不能随意对外发布，更不能用未授权的数据训练后对外宣称能力。安全合规是技术工作之外不可逾越的底线。
7. 总结与下一步学习路线
7.1 本文核心要点
现在回看本文开头的问题，你可以有一个比较完整的答案了。统一大模型之所以值得关注，是因为它把传统流水线中的三个独立任务整合进了一个共享主干：3D 感知提供了空间事实，VQA 提供了可解释的推理过程，规划头则在这个统一特征空间里生成轨迹。三者互相补充，也互相约束。
架构上，3D 感知和语言模型通过 BEV 投影或稀疏查询完成特征对齐，VQA 作为推理接口提供中间监督，规划头作为条件生成器输出轨迹。数据上，QA 标注必须与 3D 目标、时间戳严格对齐。训练上，建议分阶段进行，最后再统一做多任务指令微调。工程上，数据质量、任务权重、安全冗余、日志体系四件事，优先级高于任何花哨的模型结构改动。
7.2 接下来怎么学
对这个方向感兴趣的开发者，下一步可以按这样的顺序推进。
第一，先把 VLM 基础打牢。通义千问系列中的多模态模型是很好的学习对象，理解它的视觉编码器、语言模型和投影层如何拼接，再回去看自动驾驶 VLM 的论文会有一种豁然开朗的感觉。
第二，跑通一个公开数据集的 3D 检测基线。nuScenes 是目前生态最完整的自动驾驶数据集之一，先跑通官方 baseline，再在此基础上做改造。
第三，构造自己的 QA 数据，完成指令微调。可以先不做规划，只做“检测 + VQA”双任务，验证特征对齐是否有效。
第四，把规划头接进去，做三任务联合训练。这个阶段会出现很多本文第 5 节提到的问题，每解决一个，你对模型的理解都会更深一层。
最后提醒一句：这类方案演进很快，文章里的代码是为了讲清原理而简化的教学示例。实际项目请以官方发布的技术文档、模型权重和工具链为准，并根据自己的硬件、数据和合规要求调整。
如果本文对你有帮助，可以先收藏备用，后面实践到某个环节卡住时再回来对照排查思路，应该能找到对应的解决方向。
