先说一个我自己的阅读习惯拿到一篇自动驾驶领域的英文综述我不会从头到尾顺着读而是先翻到它的分类图和挑战章节看看作者把哪些工作塞进了同一个抽屉。这篇关于自动驾驶基础模型的综述我前后读了三遍第一遍读分类第二遍读训练范式第三遍专门盯着它讲落地约束和评测的那几节。原因很简单基础模型这个词在过去两年被用得太松了感知大模型、视觉语言模型、世界模型、端到端驾驶模型全都被叫做基础模型但它们在车上的位置、训练方式、失效模式完全不是一回事。这篇综述的价值就在于它试图给这团乱麻建立一套坐标系。如果你是从业者或者正在做自动驾驶相关的课题、准备入行这篇文章会帮你把基础模型这个模糊概念拆成可讨论、可比较、可落地的东西。我下面做的不是逐句翻译而是把它当成一份技术地图来解读中间穿插我自己在数据链路和闭环验证上踩过的一些坑。1. 从一堆专用小模型到一个通用底座自动驾驶为什么盯上基础模型1.1 传统模块化流水线到底卡在哪要理解综述为什么值得读得先回忆一下自动驾驶过去十年的主流架构。感知、定位、预测、规划、控制五个模块串成一条流水线每个模块有自己的输入输出契约各自训各自的模型。这套东西不是不好它能上车、能过测试、能定位问题工程上非常友好。但它有三个结构性瓶颈而且这三个瓶颈互相咬合很难单独修。第一个是误差累积与接口信息丢失。感知模块输出的是框、是类别、是速度这些结构化结果把原始像素里大量有用的信息压掉了。一个行人回头看了一眼一个前车刹车灯闪了一下一个骑行者身体重心偏移这些信号在框类别速度的表示里基本消失。预测模块拿到的已经是被压缩过的世界它只能在有限信息上做推断一旦感知在某个边缘场景出错后面所有模块都在错误前提上工作没有任何回退余地。第二个是标注成本与场景覆盖的矛盾。模块化架构下每个模块都需要自己的标注感知要框和分割预测要轨迹规划要专家驾驶行为。这些标注各自独立无法复用而且越是长尾场景越难标。行业里有个公开的共识剩下的那百分之几极端场景需要的投入可能超过前面百分之九十。靠人工标注去填这个坑边际成本高到不可持续。第三个是优化目标不一致。感知模块优化的是检测精度预测模块优化的是轨迹误差规划模块优化的是舒适性和安全性每个模块都把自己那一段做到局部最优但全局最优并不等于局部最优之和。一个检测精度极高的感知模型可能输出抖动很大的轨迹序列反而让规划模块难受。这种目标错配在模块化架构里几乎无法根治。1.2 基础模型带来的三样东西以及它的代价综述里把基础模型的吸引力归纳得很清楚我按自己的理解重新组织一下。它给自动驾驶带来的核心是三件事规模法则带来的能力涌现、跨任务的知识迁移、语言与常识先验的引入。规模法则这件事做视觉的人应该都有体感。同一个架构参数量和数据量上去之后不只是精度涨几个点而是开始出现一些训练时没专门教过的能力比如对遮挡的鲁棒推断、对罕见物体的零样本识别。这对自动驾驶意义很大因为长尾场景本质上就是训练时没见过而规模法则恰好是缓解没见过问题的一条现实路径。跨任务迁移的价值在于统一表示。一个在多模态数据上预训练过的主干它的中间表示同时包含几何信息、语义信息、运动信息感知、预测、规划可以共享这套表示接口不再是把世界压成框而是保留高维特征下游任务各取所需。这也是端到端方案在架构上更优雅的根本原因。语言先验这一块很多人第一反应是开车要语言干嘛。但实际用起来会发现语言模型带来的不只是听懂指令更重要的是世界知识和推理链条。比如遇到一个从没见过的施工场景语言模型可以基于施工现场通常有锥桶、有临时围挡、有工人这类常识做推断而纯视觉模型只能依赖它见过的像素分布。这种常识补位在长尾场景里非常关键。但代价同样明确而且综述里没有回避。算力需求上了一个数量级车端算力预算本来就紧张一个几十亿参数的模型想实时跑必须做大量压缩。可解释性下降端到端模型输出的是轨迹中间为什么这么决策很难给出让人信服的解释这在功能安全审查里是硬伤。数据闭环变复杂传统流水线哪个模块出问题就补哪个模块的数据基础模型出了问题是整条链路的问题定位难度陡增。这三条代价基本决定了后面所有工程取舍的方向。维度模块化流水线基础模型路线信息损失接口处强压缩高维信息丢失高维特征贯穿保留更多细节标注依赖每模块独立标注不可复用预训练可复用下游标注需求降低优化目标局部最优全局次优端到端联合优化目标一致可解释性强每步可查弱决策链路不透明算力占用相对可控可分模块部署显著上升需压缩与调度问题定位容易按模块排查困难需全链路归因2. 综述那张分类图拆开看基础模型在车上的四种落位方式2.1 按模态切分视觉主干、语言模型、多模态融合综述的分类体系第一层是按模态走的这个切法很实用因为它直接对应了工程上的选型决策。视觉主干这一类本质是把图像和点云统一到一个表示空间里常见做法是通过查询机制把多视角图像投影到统一的三维空间形成稠密的场景表示。这类模型的优势是几何精度高、实时性好缺点是缺乏语义推理能力遇到需要理解意图的场景就吃力。语言模型这一类在车上通常不直接控制车辆而是作为决策解释器和指令接口。用户说前面那个路口右转注意别压线这句话要拆成目标点、约束条件、行为偏好再喂给规划模块。语言模型在这里承担的是语义解析和常识补全它的价值不在于开车而在于把人类意图翻译成机器能执行的约束。多模态融合这一类是目前最热的方向通常是把视觉特征和语言特征对齐到同一个空间让模型既能看又能说。这种架构的好处是可以用语言描述来监督视觉理解比如用前方有车辆正在并线这类文本去对齐对应的视觉片段相当于用廉价的语言标注替代昂贵的几何标注。综述里对这一类的篇幅给得最多也侧面说明了学术界的重心所在。2.2 按任务切分感知、预测规划、数据生成三条线第二层分类按任务走我把它归纳成三条线。第一条是感知基础模型包括三维检测、占用栅格预测、语义分割、车道线理解。这类模型的共同点是需要处理稠密的空域信息输出的是场景的结构化描述。第二条是预测与规划基础模型输入是场景表示加自车状态输出是未来轨迹或者决策序列。第三条容易被忽略但极其重要是数据生成与仿真基础模型包括神经渲染、视频生成、场景重建它不直接上车但决定了前两条线的数据供给质量。这个三分法我觉得比按模态分更有工程指导意义因为三条线的评测方式、数据要求、部署位置完全不同。感知模型要在车端实时跑规划模型要在车端低延迟跑数据生成模型则在云端离线跑算力约束差了三个数量级。很多团队在选型时把这三条线混在一起讨论结果是用云端的思路去设计车端模型最后发现根本压不下来。综述里把这三条线分开讲这个结构安排本身就值得学习。2.3 分类不是目的找到接口才是我读完分类章节最大的感受是分类图好看但真正难的是接口设计。一个视觉主干怎么把特征交给规划模型交什么、交多少维、要不要离散化、要不要加中间监督这些细节在综述里通常一笔带过但在工程里决定了成败。举个具体的例子。如果感知主干输出的是稠密的鸟瞰图特征规划模型直接在这张特征图上做查询好处是信息无损坏处是特征维度太高规划模型的注意力机制会被大量无关区域稀释训练很难收敛。实践中常见的折中是加一层轻量的特征压缩把稠密特征聚合成一组稀疏的查询向量每个向量对应一个潜在的目标或者一个区域。这个压缩层的设计直接决定了端到端模型能不能训起来。所以在看这类综述的时候我的建议是不要只记分类而是去追每个分类下面那篇代表工作是怎么定义输入输出接口的。接口定得好模型能力才能传导下去接口定得糙再大的主干也是白搭。3. 训练链路的实操拆解预训练、微调、对齐三段怎么排3.1 预训练阶段的数据配比比模型结构更影响结果综述里讲训练范式的那一节我建议反复看。基础模型的训练通常分三段大规模预训练、任务微调、偏好对齐。第一段决定能力上限第二段决定任务适配度第三段决定行为风格。预训练阶段最关键的其实不是模型多大而是数据配比。自动驾驶的数据来源非常杂真实路采数据、仿真合成数据、公开数据集、网络视频、图文对。这几类数据的分布差异巨大混合比例稍有偏差模型就会偏向某一类。我见过一个比较典型的问题合成数据比例过高时模型在真实场景下的光照鲁棒性明显下降因为合成数据的光照模型太理想化反过来真实数据比例过高、合成数据太少模型对罕见场景的覆盖又不够。一个相对稳妥的做法是分阶段配比。早期用大比例的真实数据和图文对打底建立通用的视觉语义能力中期逐步提高仿真数据和长尾场景的比例针对性补短板后期用高质量的精标数据做收尾。这个思路在综述里对应的是课程学习的思想虽然论文里表述得比较抽象但落到工程上就是一张配比表。数据配比这件事没有标准答案只有针对具体场景反复试出来的经验值。提示预训练阶段不要过早引入强任务监督。很多团队急着让模型学会输出轨迹在预训练阶段就混入大量轨迹标注结果模型的通用表示能力反而被任务信号带偏后面微调时泛化性很差。3.2 微调阶段的冻结策略与任务头设计微调阶段的分歧主要在冻结多少层。全量微调效果通常最好但显存和训练成本高而且小数据集上容易过拟合把预训练学到的通用能力冲掉。冻结主干只训任务头成本低、稳定但适配深度不够遇到和预训练分布差异大的场景效果有限。我自己的经验是分层设置学习率主干用极小学习率中间层中等任务头正常。这样既保留了通用表示又给了任务适配的空间。另外一个小技巧是在微调初期冻结主干若干轮先让任务头收敛到一个合理起点再解冻主干联合训练这样能避免训练初期任务头的随机梯度把主干带偏。这个技巧在综述里没写但在我经手的几个项目里都验证过有效。任务头的设计要看任务性质。感知类任务头通常是稠密预测需要保持空间分辨率用轻量的卷积或者上采样结构规划类任务头通常是序列生成用查询机制或者自回归解码更合适。这里有个常见误区就是把感知任务头直接套用到规划任务上结果规划输出抖动严重因为稠密预测结构对时序一致性没有约束。规划头必须显式建模时序否则输出不可用。3.3 对齐阶段的驾驶偏好怎么定义才不自相矛盾偏好对齐这一段是综述里讨论最少的但对实际体验影响最大。语言模型的对齐目标是有用、诚实、无害自动驾驶的对齐目标是安全、舒适、高效、符合交规这几个目标之间本身就有张力。安全和高效经常冲突舒适和交规有时也冲突比如为了避让而急刹安全上正确舒适上很差。工程上的处理方式一般是用分层约束加权重打分。硬约束是不可违反的比如不碰撞、不越实线软约束是加权优化的比如加速度变化率、跟车距离、通行效率。对齐阶段的训练目标就是让模型的输出分布尽量落在硬约束内同时在软约束上取得好的加权分数。这里有个很现实的坑如果只用规则生成的偏好对做对齐模型学到的是规则的近似遇到规则没覆盖的场景就退化。更稳的做法是混入人类驾驶数据做正样本用模型的失败案例做负样本让偏好信号既有规则的一致性又有人类行为的自然性。综述里提到用人类反馈做对齐但具体怎么构造偏好对、怎么控制正负样本比例这些细节才是真正决定效果的地方。4. 世界模型与闭环仿真综述里最容易被低估的一章4.1 仿真数据质量决定了基础模型的能力上限很多人读综述会跳过仿真那一章觉得那是工具链的事不是模型的事。这个判断我觉得是错的。基础模型的能力上限很大程度上被数据分布决定而真实路采数据的分布是极度偏斜的绝大多数是直道、晴天、畅通路况真正难的长尾场景占比极低。靠真实数据去覆盖长尾成本高到不现实所以仿真承担了扩增长尾的责任。仿真数据的问题在于真实性。传统仿真靠手工建模场景几何准确但渲染失真纹理、光照、材质都不真实模型在这种数据上训出来迁移到实车会掉点。神经渲染这类方法的价值就在这里它用真实数据学习场景的辐射场表示再重新渲染出新视角、新光照、新天气既保留了真实感又能可控地生成变化。综述里把这部分归到数据生成基础模型我觉得这个归类很准确因为它本质上也是一个在大规模数据上预训练、然后做条件生成的模型。4.2 视频生成在闭环里的真实定位视频生成模型这两年被大量讨论很多说法是可以生成任意驾驶场景。我实际用过之后的判断是它在闭环仿真里有价值但不能当万能药。它的强项是生成合理的未来演化比如给定当前帧生成未来几秒的场景变化这对训练预测模型、做闭环回放很有用。它的弱项是几何一致性和物理合理性生成的多视角视频经常在视角之间对不齐生成的车辆运动也可能违反动力学约束。如果直接拿这种数据训练规划模型模型会学到物理上不可能的行为模式。比较务实的定位是用视频生成做场景多样性扩增和感知鲁棒性训练用神经渲染做几何精确的闭环仿真两者分工。感知模型对几何精度的要求相对宽松多样性的收益更大规划模型对物理一致性要求高必须用几何可靠的仿真。这个分工在综述里没有明确写但从它引用的工作分布能看出来作者其实也是这个倾向。4.3 仿真到实车的分布偏移我踩过的一个坑说个具体的踩坑经历。早期我们做闭环验证仿真里的雨天场景是用参数化方式加的雨滴和反射视觉效果看着还行模型在仿真里的雨天表现也不错。结果实车一测雨天掉点非常严重。排查了很久才发现问题出在雨刮器上。真实雨天雨刮器会周期性扫过挡风玻璃造成周期性的视野遮挡和形变而仿真里完全没有建模这个因素。模型在仿真里学到的雨天是不含雨刮遮挡的雨天实车上遇到了就懵了。这个坑的启示是仿真的真实性不只是渲染质量还包括传感器物理特性和机构运动的建模。摄像头有滚动快门、有运动模糊、有镜头污渍激光雷达有雨雾衰减、有多回波这些因素在仿真里如果缺失训出来的模型就有系统性的盲区。综述里讨论仿真时更多聚焦在场景生成对传感器建模的篇幅不多这块我认为是它相对薄弱的环节读的时候需要自己补上。5. 上车部署的现实约束算力、时延与确定性5.1 车端算力预算怎么算先算清楚再谈模型综述里讲部署的那一节我觉得对工程团队最有参考价值。基础模型的参数规模动辄几十亿车端算力平台通常在几十到几百 TOPS 量级中间差着一到两个数量级。这个差距不是靠优化能完全抹平的必须做结构性取舍。算力预算的估算方法我习惯这么算先确定模型的峰值算力需求用参数量乘以每 token 或每像素的浮点运算次数再乘以帧率得到每秒的运算量。然后乘以安全余量系数一般取一点五到二倍因为实际部署时的调度开销、内存带宽瓶颈、算子实现效率都会吃掉理论算力。最后对比平台的可用算力差值就是必须压缩的量。举个粗算的例子。一个十亿参数的主干处理一张高分辨率多视角输入单帧的前向计算大概在几十 GFLOPs 量级按十帧每秒算就是几百 GFLOPs 每秒。如果平台的可用算力是一百 TOPS看起来绰绰有余但实际部署时内存带宽往往先成为瓶颈权重加载的时间可能比计算本身还长。所以算力预算不能只看峰值算力还要看内存带宽和缓存容量这两项经常是真正的限制因素。约束类型典型瓶颈表现常用缓解手段峰值算力大矩阵乘耗时超预算剪枝、低秩分解、算子融合内存带宽权重加载成为主要耗时量化、权重共享、片上缓存优化缓存容量中间激活无法全部驻留分块计算、激活重计算时延抖动最坏情况延迟不可控固定计算图、避免动态分支功耗与散热持续高负载触发降频动态调度、按场景切换模型规模5.2 量化与蒸馏的取舍精度掉在哪里要提前知道量化是最直接的压缩手段从浮点到定点位宽降下来算力和带宽都跟着降。但量化对不同类型的层影响差异很大。卷积层和全连接层对量化相对鲁棒注意力机制里的 softmax 和归一化层对量化非常敏感位宽降得太狠会出现明显的数值不稳定。我的做法是混合精度量化敏感层保持高精度其余层降到低精度。具体哪些层敏感不能靠猜要用校准数据跑一遍逐层敏感度分析看每一层量化后输出分布的偏移程度。这个过程比较繁琐但比训完之后发现精度崩了再回头查要省时间得多。蒸馏的思路是用大模型教小模型让小模型在输出分布上逼近大模型。这个方法的坑在于教师模型的错误会被学生继承。如果教师模型在某些场景下判断错误学生模型会把这些错误当成正确答案学过去。所以蒸馏前要先对教师模型做筛选把明显错误的样本剔除或者用多个教师做集成投票。综述里讲蒸馏时强调的是效率收益但实际工程里蒸馏的质量控制比蒸馏本身更花精力。5.3 功能安全与可解释性绕不过去的现实问题基础模型的不可解释性在功能安全审查里是实实在在的障碍。传统模块化架构可以逐模块做失效分析基础模型是一个黑箱输入图像输出轨迹中间发生了什么很难说清楚。工程上的应对方式通常是多层防护。第一层是模型内部加可解释的中间输出比如强制模型输出占用栅格、输出注意力热图、输出语义描述这些中间结果可以被独立校验。第二层是外部加规则兜底用一个轻量的规则系统监控模型输出一旦发现输出违反物理约束或者交规约束就接管控制。第三层是运行时的置信度估计模型对自己的输出给出置信度低置信度时降级到保守策略。这三层防护会增加系统复杂度但目前在可解释性没有根本突破的情况下这是比较务实的路径。综述里对这块讨论得比较克制更多是提出问题而不是给方案这也反映了学术界和工业界在这个问题上的分歧。6. 评测体系综述列出的指标哪些真能用6.1 开环评测和闭环评测之间的鸿沟综述的评测章节列了一大堆指标检测用的平均精度、预测用的位移误差、规划用的碰撞率这些指标各自在自己的任务里是合理的但拼在一起并不能反映真实的驾驶能力。核心问题在于开环评测和闭环评测的错位。开环评测是给定真实历史让模型预测未来然后和真实未来比误差。这个设定下模型不需要为自己的错误负责因为历史是真实的它只要在当前帧上拟合得好指标就好看。但实际驾驶是闭环的模型输出的动作会改变未来状态一个在开环里误差很小的模型闭环里可能因为一次小偏差导致状态偏离然后越偏越远。行业里越来越重视闭环评测但闭环评测的成本高、可复现性差。比较现实的做法是开环做快速迭代筛选闭环做关键节点验证。开环阶段用大量场景快速筛掉明显不行的方案闭环阶段用少量高价值场景做深度验证。这个流程在综述里没有明确写但从它引用的评测工作分布能看出来闭环评测的占比在明显上升。6.2 语言模型那套评测指标搬到驾驶任务上会失真多模态模型常用的评测指标比如视觉问答准确率、描述生成的 BLEU 类分数这些指标在驾驶任务上有明显的失真风险。原因很简单驾驶任务关心的不是描述得像不像而是决策对不对。一个模型可以准确地描述前方有行人正在横穿马路但决策上选择加速通过描述满分行为零分。反过来一个模型描述得含糊其辞但决策上稳稳刹停行为满分描述扣分。这两种情况在指标上是矛盾的说明描述类指标和驾驶能力之间没有强相关。更靠谱的评测方式是行为级评测直接看输出轨迹在各种场景下的安全性、舒适性、合规性。描述能力可以作为辅助诊断指标用来定位模型为什么做某个决策但不能作为主要评价标准。综述里提到这一点但没有展开我觉得这是读这篇综述时值得自己补一块的地方。7. 读这类综述的姿势以及我建议的动手路径综述这种东西读完很容易产生一种我都懂了的错觉但真正动手时会发现处处是坑。我的建议是不要只读要带着问题读。读分类章节时问自己我手上的场景适合哪一类读训练章节时问自己我的数据配比合理吗读部署章节时问自己我的算力预算够吗每读一节就在自己的项目上对一遍这样读一遍顶读三遍。动手路径上我建议从小规模的感知基础模型切入而不是一上来就搞端到端。原因很实际感知任务的评测指标清晰、数据容易获取、失败模式好定位适合建立对基础模型训练全流程的体感。等把预训练、微调、量化部署这一整条链路跑通了再去碰规划和对齐难度会低很多。还有一个容易被忽略的点是数据管线的建设要先行。基础模型的效果很大程度上取决于数据质量和配比如果数据管线还是一堆脚本拼凑训练过程会非常痛苦。我见过不少团队模型架构设计得很漂亮卡在数据加载和清洗上进度拖了几个月。所以如果让我重新排优先级我会把数据管线放在模型选型之前。最后分享一个读综述的小技巧把综述里引用的工作按时间排序看这个领域的热点是怎么迁移的。早期集中在感知中期转向多模态融合最近两年明显偏向世界模型和端到端。这个迁移轨迹本身就包含了大量信息它能告诉你哪些方向正在被验证、哪些方向还停留在概念阶段。我在判断一个技术方向值不值得投入时经常会用这个方法做交叉验证比看单篇论文的结论可靠得多。 
长河君 · 2026/10/27 3:47:44 · 阅读 1.2k 自动驾驶基础模型综述解读：分类、训练、部署与评测
先说一个我自己的阅读习惯拿到一篇自动驾驶领域的英文综述我不会从头到尾顺着读而是先翻到它的分类图和挑战章节看看作者把哪些工作塞进了同一个抽屉。这篇关于自动驾驶基础模型的综述我前后读了三遍第一遍读分类第二遍读训练范式第三遍专门盯着它讲落地约束和评测的那几节。原因很简单基础模型这个词在过去两年被用得太松了感知大模型、视觉语言模型、世界模型、端到端驾驶模型全都被叫做基础模型但它们在车上的位置、训练方式、失效模式完全不是一回事。这篇综述的价值就在于它试图给这团乱麻建立一套坐标系。如果你是从业者或者正在做自动驾驶相关的课题、准备入行这篇文章会帮你把基础模型这个模糊概念拆成可讨论、可比较、可落地的东西。我下面做的不是逐句翻译而是把它当成一份技术地图来解读中间穿插我自己在数据链路和闭环验证上踩过的一些坑。1. 从一堆专用小模型到一个通用底座自动驾驶为什么盯上基础模型1.1 传统模块化流水线到底卡在哪要理解综述为什么值得读得先回忆一下自动驾驶过去十年的主流架构。感知、定位、预测、规划、控制五个模块串成一条流水线每个模块有自己的输入输出契约各自训各自的模型。这套东西不是不好它能上车、能过测试、能定位问题工程上非常友好。但它有三个结构性瓶颈而且这三个瓶颈互相咬合很难单独修。第一个是误差累积与接口信息丢失。感知模块输出的是框、是类别、是速度这些结构化结果把原始像素里大量有用的信息压掉了。一个行人回头看了一眼一个前车刹车灯闪了一下一个骑行者身体重心偏移这些信号在框类别速度的表示里基本消失。预测模块拿到的已经是被压缩过的世界它只能在有限信息上做推断一旦感知在某个边缘场景出错后面所有模块都在错误前提上工作没有任何回退余地。第二个是标注成本与场景覆盖的矛盾。模块化架构下每个模块都需要自己的标注感知要框和分割预测要轨迹规划要专家驾驶行为。这些标注各自独立无法复用而且越是长尾场景越难标。行业里有个公开的共识剩下的那百分之几极端场景需要的投入可能超过前面百分之九十。靠人工标注去填这个坑边际成本高到不可持续。第三个是优化目标不一致。感知模块优化的是检测精度预测模块优化的是轨迹误差规划模块优化的是舒适性和安全性每个模块都把自己那一段做到局部最优但全局最优并不等于局部最优之和。一个检测精度极高的感知模型可能输出抖动很大的轨迹序列反而让规划模块难受。这种目标错配在模块化架构里几乎无法根治。1.2 基础模型带来的三样东西以及它的代价综述里把基础模型的吸引力归纳得很清楚我按自己的理解重新组织一下。它给自动驾驶带来的核心是三件事规模法则带来的能力涌现、跨任务的知识迁移、语言与常识先验的引入。规模法则这件事做视觉的人应该都有体感。同一个架构参数量和数据量上去之后不只是精度涨几个点而是开始出现一些训练时没专门教过的能力比如对遮挡的鲁棒推断、对罕见物体的零样本识别。这对自动驾驶意义很大因为长尾场景本质上就是训练时没见过而规模法则恰好是缓解没见过问题的一条现实路径。跨任务迁移的价值在于统一表示。一个在多模态数据上预训练过的主干它的中间表示同时包含几何信息、语义信息、运动信息感知、预测、规划可以共享这套表示接口不再是把世界压成框而是保留高维特征下游任务各取所需。这也是端到端方案在架构上更优雅的根本原因。语言先验这一块很多人第一反应是开车要语言干嘛。但实际用起来会发现语言模型带来的不只是听懂指令更重要的是世界知识和推理链条。比如遇到一个从没见过的施工场景语言模型可以基于施工现场通常有锥桶、有临时围挡、有工人这类常识做推断而纯视觉模型只能依赖它见过的像素分布。这种常识补位在长尾场景里非常关键。但代价同样明确而且综述里没有回避。算力需求上了一个数量级车端算力预算本来就紧张一个几十亿参数的模型想实时跑必须做大量压缩。可解释性下降端到端模型输出的是轨迹中间为什么这么决策很难给出让人信服的解释这在功能安全审查里是硬伤。数据闭环变复杂传统流水线哪个模块出问题就补哪个模块的数据基础模型出了问题是整条链路的问题定位难度陡增。这三条代价基本决定了后面所有工程取舍的方向。维度模块化流水线基础模型路线信息损失接口处强压缩高维信息丢失高维特征贯穿保留更多细节标注依赖每模块独立标注不可复用预训练可复用下游标注需求降低优化目标局部最优全局次优端到端联合优化目标一致可解释性强每步可查弱决策链路不透明算力占用相对可控可分模块部署显著上升需压缩与调度问题定位容易按模块排查困难需全链路归因2. 综述那张分类图拆开看基础模型在车上的四种落位方式2.1 按模态切分视觉主干、语言模型、多模态融合综述的分类体系第一层是按模态走的这个切法很实用因为它直接对应了工程上的选型决策。视觉主干这一类本质是把图像和点云统一到一个表示空间里常见做法是通过查询机制把多视角图像投影到统一的三维空间形成稠密的场景表示。这类模型的优势是几何精度高、实时性好缺点是缺乏语义推理能力遇到需要理解意图的场景就吃力。语言模型这一类在车上通常不直接控制车辆而是作为决策解释器和指令接口。用户说前面那个路口右转注意别压线这句话要拆成目标点、约束条件、行为偏好再喂给规划模块。语言模型在这里承担的是语义解析和常识补全它的价值不在于开车而在于把人类意图翻译成机器能执行的约束。多模态融合这一类是目前最热的方向通常是把视觉特征和语言特征对齐到同一个空间让模型既能看又能说。这种架构的好处是可以用语言描述来监督视觉理解比如用前方有车辆正在并线这类文本去对齐对应的视觉片段相当于用廉价的语言标注替代昂贵的几何标注。综述里对这一类的篇幅给得最多也侧面说明了学术界的重心所在。2.2 按任务切分感知、预测规划、数据生成三条线第二层分类按任务走我把它归纳成三条线。第一条是感知基础模型包括三维检测、占用栅格预测、语义分割、车道线理解。这类模型的共同点是需要处理稠密的空域信息输出的是场景的结构化描述。第二条是预测与规划基础模型输入是场景表示加自车状态输出是未来轨迹或者决策序列。第三条容易被忽略但极其重要是数据生成与仿真基础模型包括神经渲染、视频生成、场景重建它不直接上车但决定了前两条线的数据供给质量。这个三分法我觉得比按模态分更有工程指导意义因为三条线的评测方式、数据要求、部署位置完全不同。感知模型要在车端实时跑规划模型要在车端低延迟跑数据生成模型则在云端离线跑算力约束差了三个数量级。很多团队在选型时把这三条线混在一起讨论结果是用云端的思路去设计车端模型最后发现根本压不下来。综述里把这三条线分开讲这个结构安排本身就值得学习。2.3 分类不是目的找到接口才是我读完分类章节最大的感受是分类图好看但真正难的是接口设计。一个视觉主干怎么把特征交给规划模型交什么、交多少维、要不要离散化、要不要加中间监督这些细节在综述里通常一笔带过但在工程里决定了成败。举个具体的例子。如果感知主干输出的是稠密的鸟瞰图特征规划模型直接在这张特征图上做查询好处是信息无损坏处是特征维度太高规划模型的注意力机制会被大量无关区域稀释训练很难收敛。实践中常见的折中是加一层轻量的特征压缩把稠密特征聚合成一组稀疏的查询向量每个向量对应一个潜在的目标或者一个区域。这个压缩层的设计直接决定了端到端模型能不能训起来。所以在看这类综述的时候我的建议是不要只记分类而是去追每个分类下面那篇代表工作是怎么定义输入输出接口的。接口定得好模型能力才能传导下去接口定得糙再大的主干也是白搭。3. 训练链路的实操拆解预训练、微调、对齐三段怎么排3.1 预训练阶段的数据配比比模型结构更影响结果综述里讲训练范式的那一节我建议反复看。基础模型的训练通常分三段大规模预训练、任务微调、偏好对齐。第一段决定能力上限第二段决定任务适配度第三段决定行为风格。预训练阶段最关键的其实不是模型多大而是数据配比。自动驾驶的数据来源非常杂真实路采数据、仿真合成数据、公开数据集、网络视频、图文对。这几类数据的分布差异巨大混合比例稍有偏差模型就会偏向某一类。我见过一个比较典型的问题合成数据比例过高时模型在真实场景下的光照鲁棒性明显下降因为合成数据的光照模型太理想化反过来真实数据比例过高、合成数据太少模型对罕见场景的覆盖又不够。一个相对稳妥的做法是分阶段配比。早期用大比例的真实数据和图文对打底建立通用的视觉语义能力中期逐步提高仿真数据和长尾场景的比例针对性补短板后期用高质量的精标数据做收尾。这个思路在综述里对应的是课程学习的思想虽然论文里表述得比较抽象但落到工程上就是一张配比表。数据配比这件事没有标准答案只有针对具体场景反复试出来的经验值。提示预训练阶段不要过早引入强任务监督。很多团队急着让模型学会输出轨迹在预训练阶段就混入大量轨迹标注结果模型的通用表示能力反而被任务信号带偏后面微调时泛化性很差。3.2 微调阶段的冻结策略与任务头设计微调阶段的分歧主要在冻结多少层。全量微调效果通常最好但显存和训练成本高而且小数据集上容易过拟合把预训练学到的通用能力冲掉。冻结主干只训任务头成本低、稳定但适配深度不够遇到和预训练分布差异大的场景效果有限。我自己的经验是分层设置学习率主干用极小学习率中间层中等任务头正常。这样既保留了通用表示又给了任务适配的空间。另外一个小技巧是在微调初期冻结主干若干轮先让任务头收敛到一个合理起点再解冻主干联合训练这样能避免训练初期任务头的随机梯度把主干带偏。这个技巧在综述里没写但在我经手的几个项目里都验证过有效。任务头的设计要看任务性质。感知类任务头通常是稠密预测需要保持空间分辨率用轻量的卷积或者上采样结构规划类任务头通常是序列生成用查询机制或者自回归解码更合适。这里有个常见误区就是把感知任务头直接套用到规划任务上结果规划输出抖动严重因为稠密预测结构对时序一致性没有约束。规划头必须显式建模时序否则输出不可用。3.3 对齐阶段的驾驶偏好怎么定义才不自相矛盾偏好对齐这一段是综述里讨论最少的但对实际体验影响最大。语言模型的对齐目标是有用、诚实、无害自动驾驶的对齐目标是安全、舒适、高效、符合交规这几个目标之间本身就有张力。安全和高效经常冲突舒适和交规有时也冲突比如为了避让而急刹安全上正确舒适上很差。工程上的处理方式一般是用分层约束加权重打分。硬约束是不可违反的比如不碰撞、不越实线软约束是加权优化的比如加速度变化率、跟车距离、通行效率。对齐阶段的训练目标就是让模型的输出分布尽量落在硬约束内同时在软约束上取得好的加权分数。这里有个很现实的坑如果只用规则生成的偏好对做对齐模型学到的是规则的近似遇到规则没覆盖的场景就退化。更稳的做法是混入人类驾驶数据做正样本用模型的失败案例做负样本让偏好信号既有规则的一致性又有人类行为的自然性。综述里提到用人类反馈做对齐但具体怎么构造偏好对、怎么控制正负样本比例这些细节才是真正决定效果的地方。4. 世界模型与闭环仿真综述里最容易被低估的一章4.1 仿真数据质量决定了基础模型的能力上限很多人读综述会跳过仿真那一章觉得那是工具链的事不是模型的事。这个判断我觉得是错的。基础模型的能力上限很大程度上被数据分布决定而真实路采数据的分布是极度偏斜的绝大多数是直道、晴天、畅通路况真正难的长尾场景占比极低。靠真实数据去覆盖长尾成本高到不现实所以仿真承担了扩增长尾的责任。仿真数据的问题在于真实性。传统仿真靠手工建模场景几何准确但渲染失真纹理、光照、材质都不真实模型在这种数据上训出来迁移到实车会掉点。神经渲染这类方法的价值就在这里它用真实数据学习场景的辐射场表示再重新渲染出新视角、新光照、新天气既保留了真实感又能可控地生成变化。综述里把这部分归到数据生成基础模型我觉得这个归类很准确因为它本质上也是一个在大规模数据上预训练、然后做条件生成的模型。4.2 视频生成在闭环里的真实定位视频生成模型这两年被大量讨论很多说法是可以生成任意驾驶场景。我实际用过之后的判断是它在闭环仿真里有价值但不能当万能药。它的强项是生成合理的未来演化比如给定当前帧生成未来几秒的场景变化这对训练预测模型、做闭环回放很有用。它的弱项是几何一致性和物理合理性生成的多视角视频经常在视角之间对不齐生成的车辆运动也可能违反动力学约束。如果直接拿这种数据训练规划模型模型会学到物理上不可能的行为模式。比较务实的定位是用视频生成做场景多样性扩增和感知鲁棒性训练用神经渲染做几何精确的闭环仿真两者分工。感知模型对几何精度的要求相对宽松多样性的收益更大规划模型对物理一致性要求高必须用几何可靠的仿真。这个分工在综述里没有明确写但从它引用的工作分布能看出来作者其实也是这个倾向。4.3 仿真到实车的分布偏移我踩过的一个坑说个具体的踩坑经历。早期我们做闭环验证仿真里的雨天场景是用参数化方式加的雨滴和反射视觉效果看着还行模型在仿真里的雨天表现也不错。结果实车一测雨天掉点非常严重。排查了很久才发现问题出在雨刮器上。真实雨天雨刮器会周期性扫过挡风玻璃造成周期性的视野遮挡和形变而仿真里完全没有建模这个因素。模型在仿真里学到的雨天是不含雨刮遮挡的雨天实车上遇到了就懵了。这个坑的启示是仿真的真实性不只是渲染质量还包括传感器物理特性和机构运动的建模。摄像头有滚动快门、有运动模糊、有镜头污渍激光雷达有雨雾衰减、有多回波这些因素在仿真里如果缺失训出来的模型就有系统性的盲区。综述里讨论仿真时更多聚焦在场景生成对传感器建模的篇幅不多这块我认为是它相对薄弱的环节读的时候需要自己补上。5. 上车部署的现实约束算力、时延与确定性5.1 车端算力预算怎么算先算清楚再谈模型综述里讲部署的那一节我觉得对工程团队最有参考价值。基础模型的参数规模动辄几十亿车端算力平台通常在几十到几百 TOPS 量级中间差着一到两个数量级。这个差距不是靠优化能完全抹平的必须做结构性取舍。算力预算的估算方法我习惯这么算先确定模型的峰值算力需求用参数量乘以每 token 或每像素的浮点运算次数再乘以帧率得到每秒的运算量。然后乘以安全余量系数一般取一点五到二倍因为实际部署时的调度开销、内存带宽瓶颈、算子实现效率都会吃掉理论算力。最后对比平台的可用算力差值就是必须压缩的量。举个粗算的例子。一个十亿参数的主干处理一张高分辨率多视角输入单帧的前向计算大概在几十 GFLOPs 量级按十帧每秒算就是几百 GFLOPs 每秒。如果平台的可用算力是一百 TOPS看起来绰绰有余但实际部署时内存带宽往往先成为瓶颈权重加载的时间可能比计算本身还长。所以算力预算不能只看峰值算力还要看内存带宽和缓存容量这两项经常是真正的限制因素。约束类型典型瓶颈表现常用缓解手段峰值算力大矩阵乘耗时超预算剪枝、低秩分解、算子融合内存带宽权重加载成为主要耗时量化、权重共享、片上缓存优化缓存容量中间激活无法全部驻留分块计算、激活重计算时延抖动最坏情况延迟不可控固定计算图、避免动态分支功耗与散热持续高负载触发降频动态调度、按场景切换模型规模5.2 量化与蒸馏的取舍精度掉在哪里要提前知道量化是最直接的压缩手段从浮点到定点位宽降下来算力和带宽都跟着降。但量化对不同类型的层影响差异很大。卷积层和全连接层对量化相对鲁棒注意力机制里的 softmax 和归一化层对量化非常敏感位宽降得太狠会出现明显的数值不稳定。我的做法是混合精度量化敏感层保持高精度其余层降到低精度。具体哪些层敏感不能靠猜要用校准数据跑一遍逐层敏感度分析看每一层量化后输出分布的偏移程度。这个过程比较繁琐但比训完之后发现精度崩了再回头查要省时间得多。蒸馏的思路是用大模型教小模型让小模型在输出分布上逼近大模型。这个方法的坑在于教师模型的错误会被学生继承。如果教师模型在某些场景下判断错误学生模型会把这些错误当成正确答案学过去。所以蒸馏前要先对教师模型做筛选把明显错误的样本剔除或者用多个教师做集成投票。综述里讲蒸馏时强调的是效率收益但实际工程里蒸馏的质量控制比蒸馏本身更花精力。5.3 功能安全与可解释性绕不过去的现实问题基础模型的不可解释性在功能安全审查里是实实在在的障碍。传统模块化架构可以逐模块做失效分析基础模型是一个黑箱输入图像输出轨迹中间发生了什么很难说清楚。工程上的应对方式通常是多层防护。第一层是模型内部加可解释的中间输出比如强制模型输出占用栅格、输出注意力热图、输出语义描述这些中间结果可以被独立校验。第二层是外部加规则兜底用一个轻量的规则系统监控模型输出一旦发现输出违反物理约束或者交规约束就接管控制。第三层是运行时的置信度估计模型对自己的输出给出置信度低置信度时降级到保守策略。这三层防护会增加系统复杂度但目前在可解释性没有根本突破的情况下这是比较务实的路径。综述里对这块讨论得比较克制更多是提出问题而不是给方案这也反映了学术界和工业界在这个问题上的分歧。6. 评测体系综述列出的指标哪些真能用6.1 开环评测和闭环评测之间的鸿沟综述的评测章节列了一大堆指标检测用的平均精度、预测用的位移误差、规划用的碰撞率这些指标各自在自己的任务里是合理的但拼在一起并不能反映真实的驾驶能力。核心问题在于开环评测和闭环评测的错位。开环评测是给定真实历史让模型预测未来然后和真实未来比误差。这个设定下模型不需要为自己的错误负责因为历史是真实的它只要在当前帧上拟合得好指标就好看。但实际驾驶是闭环的模型输出的动作会改变未来状态一个在开环里误差很小的模型闭环里可能因为一次小偏差导致状态偏离然后越偏越远。行业里越来越重视闭环评测但闭环评测的成本高、可复现性差。比较现实的做法是开环做快速迭代筛选闭环做关键节点验证。开环阶段用大量场景快速筛掉明显不行的方案闭环阶段用少量高价值场景做深度验证。这个流程在综述里没有明确写但从它引用的评测工作分布能看出来闭环评测的占比在明显上升。6.2 语言模型那套评测指标搬到驾驶任务上会失真多模态模型常用的评测指标比如视觉问答准确率、描述生成的 BLEU 类分数这些指标在驾驶任务上有明显的失真风险。原因很简单驾驶任务关心的不是描述得像不像而是决策对不对。一个模型可以准确地描述前方有行人正在横穿马路但决策上选择加速通过描述满分行为零分。反过来一个模型描述得含糊其辞但决策上稳稳刹停行为满分描述扣分。这两种情况在指标上是矛盾的说明描述类指标和驾驶能力之间没有强相关。更靠谱的评测方式是行为级评测直接看输出轨迹在各种场景下的安全性、舒适性、合规性。描述能力可以作为辅助诊断指标用来定位模型为什么做某个决策但不能作为主要评价标准。综述里提到这一点但没有展开我觉得这是读这篇综述时值得自己补一块的地方。7. 读这类综述的姿势以及我建议的动手路径综述这种东西读完很容易产生一种我都懂了的错觉但真正动手时会发现处处是坑。我的建议是不要只读要带着问题读。读分类章节时问自己我手上的场景适合哪一类读训练章节时问自己我的数据配比合理吗读部署章节时问自己我的算力预算够吗每读一节就在自己的项目上对一遍这样读一遍顶读三遍。动手路径上我建议从小规模的感知基础模型切入而不是一上来就搞端到端。原因很实际感知任务的评测指标清晰、数据容易获取、失败模式好定位适合建立对基础模型训练全流程的体感。等把预训练、微调、量化部署这一整条链路跑通了再去碰规划和对齐难度会低很多。还有一个容易被忽略的点是数据管线的建设要先行。基础模型的效果很大程度上取决于数据质量和配比如果数据管线还是一堆脚本拼凑训练过程会非常痛苦。我见过不少团队模型架构设计得很漂亮卡在数据加载和清洗上进度拖了几个月。所以如果让我重新排优先级我会把数据管线放在模型选型之前。最后分享一个读综述的小技巧把综述里引用的工作按时间排序看这个领域的热点是怎么迁移的。早期集中在感知中期转向多模态融合最近两年明显偏向世界模型和端到端。这个迁移轨迹本身就包含了大量信息它能告诉你哪些方向正在被验证、哪些方向还停留在概念阶段。我在判断一个技术方向值不值得投入时经常会用这个方法做交叉验证比看单篇论文的结论可靠得多。