自动驾驶基础模型综述：BEV、端到端与世界模型的工程落地

做自动驾驶这行久了，会发现一个挺有意思的变化：三四年前团队内部评审，吵的是"这个模块换个 backbone 能不能涨两个点"；现在评审，吵的是"我们还要不要保留这么多模块"。把这个问题推到台面上的，就是基础模型在自动驾驶里的全面渗透。所谓 "A Survey for Foundation Models in Autonomous Driving"，翻成大白话就是——把自动驾驶基础模型这一整套东西系统捋一遍：用大规模预训练的通用模型去做感知、预测、规划、仿真和数据生产，到底走到了哪一步，哪些是真能用，哪些还停留在论文的漂亮曲线上。

这类综述的价值不在于教你某个网络结构怎么改，而在于帮你判断技术栈的组织方式要不要重构。它适合三类人看：刚进这个方向、想快速建立全局地图的新人；正在做模块化方案、纠结要不要转端到端的工程同学；以及要拍板技术路线的负责人。我自己的体会是，读完一遍综述能省下至少两个月的盲目试错，但综述里没写的那部分——工程落地时的取舍细节——才是最贵的。

1. 先把"基础模型"这四个字掰开：它到底要解决什么问题

1.1 模块化流水线卡在哪一步

传统自动驾驶软件栈是"感知→预测→规划→控制"的四段式，每一段再往下拆成检测、跟踪、车道线、occupancy、行为预测、轨迹生成。这套架构统治了十几年，不是因为优雅，而是因为它可调试、可分工、可归责——出了事故能定位到具体模块。

但它的三个硬伤在数据量上来之后越来越刺眼。第一是接口处的信息塌缩：感知模块输出的是几十个 3D 框和类别标签，而原始传感器里其实有大量没被表达出来的信息，比如物体的材质、姿态细节、被遮挡部分的推测，这些东西在"框"这个接口上全丢了，下游想用也用不到。第二是误差累积与责任模糊：感知漏检一个小目标，预测模块拿着不完整的输入照样输出轨迹，规划再基于这条轨迹做决策，最后错误被放大，但复盘时谁也说不清是哪个环节的锅。第三是长尾场景的边际成本极高：每遇到一类新场景（异形车辆、临时施工、极端光照），都要走一遍"发现问题→采数据→标注→重训→回归"的完整流程，周期以月计。

基础模型的切入方式很直接：用海量、弱标注甚至无标注的数据先预训练一个通用表征，让模型自己学会"世界大概长什么样"，再往下游任务上微调，甚至干脆一个模型端到端输出轨迹。它想解决的核心矛盾是——标注数据的增长速度，永远追不上场景的多样性。

1.2 综述里反复出现的四个落点

我把这类综述里提到的应用场景归了归类，基本落在四个位置，理解这四个位置，整篇文章的骨架就清楚了。

看得出一条规律：离方向盘越远，基础模型落地越快。数据生产和人机交互这两块，已经在不少团队里跑起来了；真正上车控车的那部分，卡在算力、时延和安全验证上。这个梯度判断很重要，能帮你避免"看到一个惊艳 demo 就以为明年能量产"的误判。

1.3 读这类综述的三条主线

综述动辄几十页上百篇引用，硬啃会迷失。我建议带着三条主线去读。第一条是表征主线：从图像特征到 BEV 网格、再到稀疏 query、再到 token 序列，表征形式决定了后面能接什么任务、能融什么模态。第二条是数据主线：预训练语料从哪来、标注怎么降本、长尾怎么覆盖，这条线决定了方案能不能规模化。第三条是评测主线：离线指标和在线表现之间的鸿沟怎么填，闭环测试怎么做，这条线决定了你敢不敢把东西放上路。

顺带说一句读综述的方法：先看它的分类图和时间轴，把术语对齐；再挑两三个你最关心的方向精读引用；最后一定要去看那些"Limitations"和"Open Challenges"段落——那才是真正值钱的部分，因为作者在这里承认了自己也没搞定的事。

2. 整体方案怎么搭：从数据到车端的一条完整链路

2.1 数据层：语料构成比模型结构更决定上限

我见过太多团队在模型结构上反复折腾，却对数据配比很随意。实际经验是，基础模型的效果差异，七成来自数据和训练策略，三成来自结构。自动驾驶的预训练语料是个多模态大杂烩：多路相机视频（前视、环视、侧后视，通常 6 到 12 路）、激光雷达点云、毫米波雷达回波、GNSS/IMU 位姿、车辆总线信号（速度、转角、油门刹车）、驾驶员接管事件，再加上语音指令和自然语言描述。

自动标注流水线是这条链路上的性价比之王。常见做法是离线用一个大模型（多模态融合、多帧时序、高分辨率输入）跑伪标签，人工只做抽检和难例复核，把人力从"逐帧画框"转到"判断对错"。某团队做过统计，3D 框的人工标注成本能压到原来的三到四成，前提是伪标签质量过关——一旦大模型的系统性偏差被灌进训练集，学生会把老师的错误学得更牢，这叫确认偏差放大，后面很难纠。

注意：自动标注一定要保留"来源标记"，即每条伪标签记录由哪个模型版本、什么置信度生成。后期出问题回溯时，这个字段能救命。

数据配比上，除了常规的场景均衡（白天/夜间/雨雾、城市/高速/园区），还要专门做长尾重采样。我的做法是给每段数据打上场景标签，训练时按"逆频率"加权，稀有场景采样权重放大 3 到 10 倍，同时设上限防止某一类过拟合。隐私处理别忘掉：人脸和车牌必须脱敏，这类处理要在入库阶段就完成，别等到训练前临时补。

2.2 模型层：骨干、表征、任务头的三段组合

模型层的设计可以拆成三个可独立替换的部件。骨干负责从原始传感器提特征，图像侧现在主流是 ViT 系列或卷积与注意力的混合结构，点云侧是稀疏卷积或体素化的 Transformer。表征是中间表示，决定了多模态怎么融合：BEV 网格把一切拍平到俯视图，直观但分辨率受限；稀疏 query 用一组可学习的向量去"查询"特征，灵活但训练更挑技巧；纯 token 序列最通用，代价是计算量随分辨率平方增长。

任务头则是挂在表征上的若干小分支，检测、分割、occupancy、轨迹预测各一个。基础模型思路上，这里的关键选择是"共享多少"。共享得多，多任务互相正则、参数效率高；共享得少，各任务互不干扰、调起来省心。我的经验是前期共享骨干、分离任务头，等训练稳定、数据量上来之后再逐步加深共享，别一上来就追求极致共享，否则一个任务崩了会拖垮全部。

时序融合是另一个容易被低估的点。单帧模型在遮挡和远距离上表现很差，加入 3 到 5 帧的历史队列，配合隐状态传递，遮挡场景的召回能有明显提升。代价是内存占用和推理时延上升，所以要配合关键帧策略（比如每 2 到 3 帧做一次重计算）。

2.3 训练层：预训练、微调、蒸馏的三段式

预训练目标的选择直接决定学到什么。常见的有四类：掩码重建（遮住一部分输入让模型补全，逼它学结构）、对比学习（拉近同一场景不同视角的表征）、时序预测（用过去预测未来帧或未来表征）、图文对齐（把图像区域和自然语言描述对齐，为后续的语言交互打基础）。实践中往往混着用，权重需要调，我一般让掩码重建占大头，因为它最稳定、最不容易训崩。

微调阶段有个绕不开的取舍：全参微调效果好但显存吃紧、容易过拟合小数据集；参数高效微调（如低秩适配）省资源、多任务切换方便，但在域差距大的时候上限偏低。我的建议是先在目标域上做一轮轻量适配探路，看指标天花板在哪，再决定要不要全参。

蒸馏是把大模型能力搬到车端的必经之路。教师模型可以是多模态融合的大网络，学生模型是车端能跑的小网络，除了输出层对齐，中间层特征也应该对齐，效果比只对齐 logits 好不少。

2.4 部署层：算力预算倒推模型设计

这一步经常被放到最后才想，其实是应该最先算的。假设控制频率 10Hz，单帧总预算 100ms，其中感知与规划共享 60 到 70ms，剩下留给其他任务和安全冗余。倒推回来，模型前向的计算量就得压在某个上限内。

部署时的三板斧：量化（把权重和激活压到 8 位甚至更低，注意敏感层保留高精度）、算子融合与图优化（减少访存次数，端到端往往能省 20% 到 30% 时延）、内存带宽优化（很多模型不是算不动，是数据搬不动）。这里有个反直觉的观察：车端推理的瓶颈经常不在算力峰值，而在内存带宽和调度开销，所以模型参数量小但访存密集的结构，未必比大而规整的结构跑得快。

3. 四条主流范式逐个拆：BEV、端到端、视觉语言模型、世界模型

3.1 BEV 统一表征：为什么它成了默认起点

BEV（鸟瞰图）表征的逻辑很朴素：既然规划控制是在俯视平面上做决策，那就把感知的输出也统一到这个平面上，让下游拿到的输入和它要决策的空间一致。这样多相机、激光雷达、毫米波的数据都能投到同一个网格里融合，时序对齐也方便。

实现上有两条路。一条是显式深度估计：先预测每个像素的深度分布，再按深度把特征"泼"到 BEV 网格上，物理意义清楚，但深度估计误差会直接传导。另一条是隐式查询：用一组可学习的 BEV 查询向量，通过注意力机制从多视角特征里主动抽取信息，不显式建模深度，效果通常更好，代价是可解释性差一些。

参数上要注意网格分辨率的取舍。200×200 的网格配 0.5 米分辨率覆盖 100 米见方，对小目标友好但计算量大；128×128 覆盖同样范围分辨率降到 0.78 米，远处的行人和锥桶就容易糊在一起。我的经验是城市低速场景用高分辨率、高速场景用低分辨率，或者做多尺度网格。

3.2 端到端：把模块间的信息损失补回来

端到端的核心主张是——既然模块接口会丢信息，那就取消接口，让一个网络直接从传感器输入映射到轨迹输出。它最大的吸引力在于联合优化：感知的错误可以被规划的目标函数直接惩罚，模型会自动学会"哪些感知细节对最终决策重要"，而不是被动地追求检测指标。

但端到端不是银弹，坑很实在。可解释性下降是最直接的，出了问题是黑箱，很难向安全评审解释"为什么打了这把方向"。训练信号稀疏也是问题：一帧只有一个轨迹标签，梯度信息量远小于逐像素的检测监督。常见的缓解办法是加辅助任务（中间加检测头、occupancy 头、深度头做多任务监督），相当于给主干网络多接几根"营养管"。

还有个工程上的现实问题：端到端模型的回归目标通常是未来几秒的轨迹点，这些点在空间上的分布很不均衡（大多数时候车是直行的），直接回归会偏向均值。用 anchors 或者离散化到一组候选轨迹再做分类，稳定性会好很多。

3.3 视觉语言模型上车：能做什么、不能做什么

视觉语言模型在车上的价值，我认为被两拨人同时误判了。一拨人觉得它能直接开车，另一拨人觉得它就是个噱头。实际情况在中间：它在语义理解和长尾解释上很强，在精确几何和实时控制上很弱。

能做的事情列一列：把驾驶员的自然语言指令翻译成可执行的偏好（"前面这段开慢点""尽量走左边车道"）；对场景做开放词汇的描述和检索（"找出所有施工围挡的片段"），这对数据挖掘价值巨大；给决策结果生成人类能懂的解释，辅助安全评审和用户信任建立；以及在仿真里当"场景导演"，批量生成带语义标签的测试用例。

不能做的事情也得说清楚：不要指望它输出厘米级精度的 3D 位置，它的空间定位能力天然不足；不要把它放进 10Hz 的实时控制回路，几十亿参数的模型在当前车端算力下跑不动；更不要让它直接输出控制量，缺乏可验证的安全边界。

3.4 世界模型与生成式仿真：解决长尾的另一种思路

长尾场景的困难在于"采不到、标不起、测不全"。世界模型的思路是：让模型学会预测"如果我这么做，世界会怎么变"，从而在离线环境里生成大量可控的、带真值的场景。这在两个地方特别有用——一是生成极端场景（把白天的高速片段改造成暴雨夜间，把正常行驶改造成前车突然掉落货物），二是闭环仿真（让被测模型在生成的场景里跑，评估它的反应）。

技术上主要靠扩散模型或自回归的视频预测模型。难点在于真实性与可控性的矛盾：生成的东西越真实，往往越难精确控制；越想控制某个物体的位置，画面就越假。目前的实用做法是混合渲染——几何和动态物体用传统图形管线精确控制，材质、光照、天气用生成模型补，两者拼接。这个方向的评测标准也还没统一，怎么证明"生成的场景是合理的"，业界还在摸索。

3.5 四条路线的横向对比

4. 动手：搭一个最小可跑的基础模型实验

4.1 环境与显存估算

假设你手上有 8 张 80GB 的卡，想跑一个 BEV 感知的预训练加微调实验。先算 token 数量，这决定了显存和算力的基本盘。6 路相机，输入分辨率 900×1600，patch 大小取 32，那么每路图像的 patch 数是 (900/32)×(1600/32)≈28×50=1400，6 路合计 8400 个 token。如果用 patch 16，token 数直接变成 33600，显存需求约涨 4 倍——这就是为什么实际工程里很少用 patch 16 做多相机高分辨率输入。

按 8400 token、隐藏维度 768、12 层来估算，单样本的激活值大约在几个 GB 量级，配合梯度检查点（用计算时间换显存），单卡 batch size 2 到 4 是可行的。如果不确定，最简单的办法是先跑一个 batch size 1 的 forward，看显存占用，再按线性外推。

环境准备上，CUDA 版本、深度学习框架、分布式训练库三者的版本对齐是最常见的坑。我的习惯是先在一张卡上把单机脚本跑通、loss 能降，再上分布式，别一上来就多机多卡，出问题根本分不清是代码错还是通信错。

4.2 训练配置与关键参数

给一套我常用的起步配置，不是最优但稳：

optimizer: AdamW learning_rate: 1.0e-4 # 预训练 lr_backbone: 5.0e-5 # 骨干用更小学习率，防止破坏预训练权重 weight_decay: 0.05 scheduler: cosine warmup_steps: 2000 # 约占总步数 5% batch_size_per_gpu: 2 grad_accumulation: 4 # 等效 batch 64 precision: bf16 # 比 fp16 稳定，不容易出 NaN grad_checkpoint: true max_epochs: 24

几个参数背后的逻辑值得说。学习率上，骨干小于头部，是因为骨干通常加载了预训练权重，用大学习率会把有用的表征冲掉，这叫灾难性遗忘。warmup 长度不能太短，注意力模块在训练初期梯度方差大，直接上高学习率容易发散。bf16 比 fp16 稳，是因为它的指数位宽更大，不容易在梯度很小时下溢成零。

4.3 评测与消融：别只看一个数

评测要分三层。感知层看检测的平均精度、召回，特别是小目标和远距离目标的分项指标；预测层看轨迹的位移误差和碰撞率；闭环层看接管次数、通行效率、舒适度（加速度和 jerk 的分布）。

消融实验我一般按这个顺序做，因为每一步的收益递减是有规律的：先加时序融合（收益最大），再加多任务辅助监督，再加数据增强和长尾重采样，最后调模型宽度和深度。很多团队一上来就调结构，其实前两步的收益就占了大半。

提示：消融实验一定要固定随机种子跑多次取均值，单次结果的波动有时比消融项的收益还大，很容易得出错误结论。

4.4 车端部署验证

实验室指标好看，上了车就崩，这个落差我见过太多次。部署验证要关注四件事：时延分布（不只看平均，看 99 分位）、内存峰值（不能只看稳态占用）、数值一致性（量化后输出和浮点版本的偏差是否在容忍范围内）、降级策略（模型超时了怎么办，必须有保底方案）。

量化验证有个实用技巧：准备一组覆盖边界情况的校准数据（强光、暗光、雨雾、密集车流），逐层比对量化前后的输出差异，找出误差最大的层单独处理（保留高精度或换量化策略）。整网一刀切量化，往往就是那两三层拖垮了整体表现。

5. 常见问题与排查实录

5.1 训练不收敛或指标剧烈震荡

这是最高频的问题，原因通常排得出来。第一嫌疑是数据：检查标注框有没有越界、类别是否均衡、有没有坏样本（全黑帧、损坏的压缩包）。第二是学习率与 batch 的匹配：batch 变大而学习率没跟上，或者反过来，都会导致震荡，经验规则是学习率随 batch 线性缩放，但这个规则在超大 batch 时不成立，要换成平方根缩放。

第三是损失函数权重失衡：多任务训练时，分类损失和回归损失的量级可能差两个数量级，梯度被大的那项主导。解决办法是动态调整权重或者用不确定性加权。第四是归一化层的统计量问题：小 batch 时批归一化的统计不准，换成层归一化或者分组归一化会稳很多。

5.2 仿真指标漂亮，实车表现拉胯

这个落差有个专门的名字叫域差距。来源有三类。传感器域：仿真里的图像太干净，没有镜头污渍、运动模糊、卷帘效应、曝光过冲。行为域：仿真里的其他车辆太守规矩，不会加塞、不会犹豫。分布域：训练集里某些场景比例过高，模型在这些场景上过拟合。

排查方法我常用分层评测：把验证集按场景标签切片，看哪一类的指标掉得最厉害，那里就是域差距的重灾区。补救靠数据增广（模拟污渍、模糊、噪声）和真实数据回灌，别指望改模型结构能解决。

5.3 推理时延超标

先做时延分解，别猜。用工具把推理拆成算子级别，通常会发现时延集中在几个点上：注意力计算的序列长度过长、大矩阵乘的内存带宽打满、有一些低效算子（比如自定义的循环实现、频繁的 host-device 拷贝）。

对策按性价比排：减少 token 数（降分辨率、增大 patch、稀疏化注意力）通常收益最大；然后是算子融合和量化；再是模型剪枝和蒸馏。有一个容易忽略的点是预处理，图像解码和归一化如果放在 CPU 上做，很容易成为瓶颈，挪到 GPU 上能省不少。

5.4 长尾场景覆盖率上不去

覆盖率上不去，往往不是模型问题，是数据发现问题。常规的随机采样只能采到常见场景，长尾得主动找。方法有几种：用当前模型的不确定性做主动学习（挑置信度低的片段）、用语义检索找特定场景（用文本描述去查视频库）、用聚类找离群样本、以及分析接管事件的共现模式。

还有个思路是生成补足：真实数据采不到的（比如极端天气的组合、罕见车型），用生成模型合成一部分，但要严格控制合成数据的比例，我一般不超过总数据的两成，多了会让模型对合成的伪影过拟合。

5.5 问题速查表

6. 团队该怎么选：不同资源条件下的取舍建议

6.1 三档资源的现实路径

资源有限（十几张卡、小团队）：别去做通用基础模型，那是无底洞。聚焦在数据生产这一侧——用现成的开源模型做自动标注和场景检索，把标注成本打下来，这是投入产出比最高的地方。模型侧只在单个任务上做预训练加微调，比如专注提升夜间行人检测，做深做透。

资源中等（几十张卡、有稳定数据来源）：可以做 BEV 表征的统一和多任务共享，把感知的几个任务合并到一个骨干上，配合时序融合。同时搭建闭环评测的基础设施，这个能力一旦建起来，后面所有迭代都受益。

资源充足（上百张卡、有完整数据闭环）：可以尝试端到端和世界模型仿真，但要接受一个现实——这两条路在短期内很难带来可量化的量产收益，更多是战略卡位和技术储备。做的时候一定要设好阶段性的验证指标，别陷入"再训一版就好了"的循环。

6.2 我踩过的几个坑

第一个坑是过早追求统一架构。我们曾经想把感知、预测、规划全部塞进一个模型，结果调试成本爆炸，一个问题出现后要在十几个任务头之间来回排查。后来退回"共享骨干、分离头部"的折中方案，迭代速度立刻回来了。基础模型的思路是对的，但工程上要控制爆炸半径。

第二个坑是迷信大模型带来的自动提升。参数量翻倍，指标不一定涨，反而可能因为过拟合和训练不充分而下降。真正决定效果的是数据质量、训练时长和评测体系，参数量只是必要条件。我现在的习惯是先把小模型训到收敛、调到极致，把它当成基线，再评估大模型能带来多少增量。

第三个坑是评测体系滞后于模型迭代。模型一周一版，评测集却是半年前建的，结果就是模型在刷旧题，实车表现毫无进步。评测集也要持续更新，定期注入新采集的难例，保持"考卷"的难度。

最后一个经验是关于人的：基础模型这个方向，算法和工程的分界线越来越模糊。一个人既要懂训练技巧，又要懂量化和算子优化，还要能看懂数据分布。团队配置上，与其堆很多只懂调参的人，不如配两三个能把整条链路打通的"全栈型"选手，效率差距非常明显。这个领域变化太快，今天的最优解明年可能就过时了，唯一稳定的是对数据、对评测、对工程约束的判断力——这些才是不会贬值的东西。