“端到端”大概是这两年自动驾驶圈子里被讨论最多、也最容易吵起来的概念。一边是特斯拉FSD V12带来的震撼效果一边是“黑盒”“不可控”的质疑声行业里对它既有期待也有焦虑。我自己的感受是很多人把端到端理解成“输入图像、输出方向盘转角”这个说法太粗略了真正落地的时候数据怎么组织、模型怎么训练、怎么去验证安全性、出了corner case怎么兜底每一步都有大量值得深挖的细节。这篇文章想把我对端到端算法的理解、实际跑实验时踩过的坑、以及对整个技术路线走向的判断系统整理一遍给同样在做自动驾驶算法或者准备切入这个方向的朋友们一个参考。1. 端到端算法到底是什么从“拼接”到“贯通”的范式转变1.1 传统模块化架构的困局过去十年自动驾驶的主流方案是模块化流水线感知、预测、规划、控制各管一段。感知模块负责把摄像头、激光雷达的数据变成障碍物边框、车道线、交通标志预测模块根据这些结果推算其他车未来几秒的运动轨迹规划模块再基于预测结果生成一条安全、平滑的轨迹最后控制模块去跟踪这条轨迹。这套架构的好处是每个模块都可以单独开发、单独测试、单独优化出了问题也能快速定位是感知漏检还是规划不合理。但做久了你会发现几个很难回避的问题。第一是信息损耗前一个模块输出的结构化结果会丢掉原始数据里的很多信息比如图像里一个被遮挡一半的行人姿态、路面上的细微纹理变化这些细节在传感器原始数据里明明存在但一旦被抽象成“一个3D框”就再也用不上了。第二是误差级联感知模块的漏检或者误检后续的预测和规划模块几乎没有纠错能力错误会一路传导下去。第三是模块间接口设计困难感知输出的“目标列表”到底应该包含哪些属性、预测模块输出的概率分布怎么传给规划器这些接口往往靠工程师手工设计很难做到最优。做规划的同事经常吐槽感知那边给过来的轨迹抖动一下规划就得重新优化半天。这种拆东墙补西墙的体验做过量产项目的应该都懂。1.2 端到端架构的核心思路端到端算法的思路很简单粗暴不再人为划分模块边界而是让一个大的神经网络直接学习“从传感器原始输入到驾驶决策”的映射关系。输入是图像、激光雷达点云、导航地图、车辆自身状态输出直接是轨迹点、方向盘转角、油门刹车开度或者更抽象一点的“驾驶意图”。这样做最大的优势是可微分的全局优化。整个系统是一个巨大的复合函数所有参数都可以通过损失函数反向传播端到端地更新中间不需要人为设计接口也不存在误差级联——因为整个系统是联合训练的模型会自己学会在感知不确时保守一点、在场景清晰时更果断一些。这种方式更接近人类驾驶的机制人类开车也不是先“识别出前方5米有一个行人”再做一串逻辑推理而是直接把视觉信息和操作经验融合在一起形成一种条件反射式的决策。当然这不是说端到端就没有感知和规划的区分了。更准确地说感知、预测、规划这些能力被压缩进了同一个网络的不同层和不同分支里它们共享特征、互相调制而不是各干各的。1.3 为什么前几年没火偏偏是现在端到端的概念早在上世纪80年代末就有学者拿ALVINN系统做过实验用单隐层神经网络把摄像头图像映射成转向角在卡内基梅隆大学旁边的公路上跑了几十公里。但那个时代算力撑不起大规模训练数据采集成本也高得离谱所以一直停留在实验室。真正让端到端成为行业主流话题是三件事同时发生的结果。一是Transformer和BEV感知的成熟。Vision Transformer让模型可以在图像空间做全局注意力BEV鸟瞰视角统一了多传感器特征表达这两个进展让端到端模型有了能够承载复杂驾驶场景的基础架构。二是数据闭环与仿真能力的积累。头部公司手里有数百万公里的真实路采数据再加上仿真引擎可以生成海量边缘场景端到端模型有了“喂饱”的土壤。三是大算力GPU集群的普及。训练一个端到端模型动辄需要几千张A100/H100同时跑很多天这在五六年前几乎是不可想象的资源量级。关于这个趋势我自己最深的体会是算力、数据、算法这三要素在端到端这个方向上终于形成了共振缺一个都转不起来。2. 核心技术栈与关键选型不是“一个大模型”就完事2.1 数据是第一生产力高质量数据集决定上限做端到端算法最核心的不是网络结构而是数据。模型结构大家抄来抄去差距很快就能抹平但数据质量、数据分布、数据闭环能力才是真正拉开差距的地方。一个可用的自动驾驶数据集通常包含以下几类信息多路摄像头图像前视、环视分辨率一般在2MP以上更高端的到8MP激光雷达点云如果传感器配置里有车辆自身的位姿、速度、加速度等状态信息高精度地图或导航地图信息人工标注的语义标签用于辅助损失或评测驾驶员操作记录在模仿学习方案中作为监督信号我在实际做数据清洗时踩过的一个坑是数据失衡。城市快速路的数据特别多但城中村窄路、施工改道路段的数据少得可怜。模型在这种不均衡数据上训练完日常场景表现很好一遇到窄路会车就“犯懵”。后来我们的做法是给不同场景类型设置采样权重并且用仿真工具专门补充难例数据才把问题压下去。另外数据的时空多样性也很重要。同一个路口在不同光照、天气、季节下的表现差异可能非常大。如果数据采集集中在某几个月模型就是对那个季节过拟合。有条件的话最好做跨地域、跨季节、跨时段的均衡采样这个对泛化能力的影响比调几个网络参数大得多。2.2 网络结构从CNN到Transformer再到BEV当前主流的端到端方案在感知骨干网络部分通常会选这三种之一纯CNN如ResNet、RegNet计算效率高、部署友好但感受野受限长距离依赖建模能力弱Vision TransformerViT全局建模能力强适合处理复杂交互场景但计算量偏大需要蒸馏或者裁剪才能上量产芯片CNNTransformer混合浅层用CNN提局部特征高层用Transformer做全局交互兼顾效率和效果目前很多落地项目采用这种方案在特征表达层面BEV空间基本成了共识。把多摄像头的图像特征通过几何投影和注意力机制统一到自车为中心的鸟瞰视角网格上再在这个统一空间里做目标检测、在线地图构建、占用网格预测。好处是不同模态的特征在同一个坐标系下对齐后续预测和规划分支可以直接在BEV特征上做不需要再来回切换坐标系。我个人的建议是如果团队是从零开始做不要一上来就上超大模型。先把一个中等规模的BEV感知模型跑通吃透数据流程和loss设计再逐步扩展到端到端的整体框架。直接套用几十亿参数的大模型光是调分布式训练和显存优化就能耗掉你一个月时间。2.3 规划控制部分当强化学习遇上传统优化端到端模型输出决策的方式也分好几个流派。一种是把规划模块也直接用神经网络替代输入BEV特征和历史轨迹输出未来几秒的轨迹点或控制量。这种方式“端到端”程度最彻底但可解释性和安全约束的嵌入比较困难。另一种是神经规划器与优化器结合神经网络负责生成候选轨迹或者给出一个较优的“初始解”传统优化器比如二次规划、模型预测控制再在这个基础上做平滑和安全校验。这种混合方式既享受了端到端特征提取的优势又保留了优化方法的约束能力是目前很多希望在量产上找到平衡点的公司选择的路线。在训练策略上模仿学习和强化学习都在被使用。模仿学习IL直接用人类驾驶数据做监督简单有效但受数据分布限制遇到没见过的场景容易手足无措。强化学习RL让智能体在仿真环境中试错理论上可以覆盖更多极端场景但奖励函数设计非常考验功力——你希望车开得快它就学会闯黄灯你希望车开得安全它就变成“乌龟车”不敢变道。后来很多人采用RLIL联合训练的方式先用模仿学习做预训练再用强化学习做微调效果比单用任何一种都好。另外提一句虽然现在大家都在谈神经网络规划但传统规划算法并没有被完全抛弃。像Dijkstra、A这类图搜索算法在全局路径规划中依然常用基于采样的RRT/RRT在复杂场景也有它的价值。端到端模型更像是一个“高效的通勤者”负责处理90%的常规场景传统算法则是那个“冷静的兜底者”在模型不确定或者安全校验不通过时接管。这两种角色不是对立关系而是互补关系。3. 从零跑通一个端到端训练流程实操记录与方法论3.1 数据闭环与训练流程设计我自己实际跑通一个端到端项目大致会分成五个阶段数据采集与预处理车端采集原始数据做时间对齐相机、lidar、IMU、CAN总线之间的时间戳同步非常关键差几十毫秒在高速场景就是一两米的偏差、传感器标定、地图匹配。数据量级从几百小时起步质量筛选要看光照、天气、遮挡程度。数据标注与挖掘人工标注目标框、车道线、可行驶区域等同时用规则和模型挖掘困难样本急刹车、近距离切入、交通参与者姿态异常等。这个过程很耗时建议优先保证难例数据的标注质量。模型训练输入通常是一个序列比如前后各1秒的帧数据采样频率10Hz左右输出是未来5~8秒的轨迹序列。训练分成两阶段先在大型通用数据集上做预训练比如在ImageNet或者某个大型BEV数据集上再在自采的驾驶数据集上微调。离线评测在独立测试集上计算各类指标包括感知类指标mAP、mOTA、轨迹类指标L2误差、碰撞率、不可行驶区域侵入率、舒适性指标加速度变化率、 jerk等。这里要注意一个经典陷阱模型在训练集所在城市测试效果很好换个城市或换个国家效果雪崩所以测试集的覆盖范围一定要多元化。闭环仿真验证把训练好的模型放进仿真环境中跑大量场景测试它的决策合理性。仿真的好处是可以批量验证边缘case缺点是仿真与真实之间存在sim-to-real gap仿真里表现好不代表真实世界一定行。我自己训练时的经验是loss的设计比网络结构更容易被低估。单纯用均方误差MSE去约束轨迹点模型倾向于输出“平均轨迹”会不自觉抹掉急转弯和紧急刹车这些动作导致驾驶风格极其保守。后来我们加入多模态轨迹分支每一模态负责一种驾驶风格再用一个概率头去选择最合理的模态效果明显改善。3.2 端到端模型训练中的参数细节举一个具体的训练配置例子方便你有个大致概念输入分辨率前视8MP图像缩放至1920×1080环视4路至1280×720时间序列长度10帧1秒采样间隔100ms特征图尺寸BEV网格自车为中心200m×100m分辨率0.5m视觉骨干ResNet-50或ViT-Small预训练权重从通用数据集加载轨迹模态数K3分别对应巡航、加速变道、减速避让损失函数分类损失选择哪个模态 回归损失每个模态下的轨迹点坐标 辅助感知损失分割/检测 正则化项优化器AdamW初始学习率5e-4cosine decayBatch size256分布式训练64卡A100约训练3万步训练时间约5~7天这些参数不一定适合所有项目核心是想让大家有个“量级感”。我之前见过一个团队batch size设太大导致模型严重过拟合到高密度车流场景后来缩减batch size并加大数据增强随机遮挡、色彩抖动、随机裁剪才缓解。3.3 评测体系ISO 34505带来的新思路2025年发布的ISO 34505《道路车辆——自动驾驶系统测试场景评价及测试用例生成》给自动驾驶测试场景的生成、评价和用例设计提供了国际标准框架。它的核心思路是不再只依赖人工设计测试用例而是通过系统性方法从真实事故库、自然驾驶数据库、边缘Case库中挖掘和组合测试场景并定义了一套评估场景质量、覆盖度和危险度的指标。对做端到端算法的团队来说这套标准很有参考价值。因为端到端模型最容易在“见过的场景”里表现好在“没见过但合理”的场景里出问题传统的固定功能测试很难覆盖这类盲区。ISO 34505提供的方法论让我重新审视评测体系建设与其撒胡椒面式地准备测试用例不如先做一个覆盖度分析识别场景空间里的“空白区”再有针对性地去仿真或实测中补充。顺着这个思路我们的测试流程做了一次调整模块级评测分别验证代码正确性、模型数值稳定性、极端输入下的鲁棒性系统级仿真评测包括IEC/ISO标准工况如切入切出、前车急停、行人横穿等也包括基于真实路采数据重建的场景回放实车路测在限定区域的开放测试场和指定道路上进行重点关注舒适性与安全兜底行为泛化性探针引入跨城市、跨季节、跨道路类型的分层采样测试验证模型在分布外场景的表现实话说ISO 34505的描述并不好“啃”很多术语比较抽象。我建议团队里最好有人先把标准消化透再对照现有测试流程做差异分析而不是全员硬啃。4. 落地过程中踩过的坑与争议直说是非曲直4.1 可解释性黑盒恐惧与可视化兜底端到端模型最被人诟病的一点就是不可解释。感知模块错了还能画个BBox出来看看但端到端模型只给一个方向盘转角你根本不知道它“看到了什么”“在想什么”。我的理解是端到端不等于不可解释。现在的方法可以做到一定程度的解释用注意力热力图看模型关注了哪些区域用中间层特征可视化看BEV空间里模型对障碍物的建模用轨迹多模态分布看模型认为哪些行为是合理的。我们在开发时做了一套可视化调试工具可以回放车的视角、渲染BEV特征、叠加注意力权重也能查看模型输出的多模态轨迹分布。这套工具帮我们定位了很多问题比如“模型在夜间没有关注到路边逆行的自行车”通过热力图一眼就能发现。不过也要承认目前的可解释性工具还没有形成统一标准很多时候还要靠工程师的个人经验去“猜”。这个方向还有很长的路要走。4.2 长尾场景模型再强也怕“没见过”端到端模型对训练数据分布十分敏感。我做过一个实验把训练数据里所有“施工改道路段”的样本剔除掉再拿一个小型测试集全是施工路段去测模型失误率直接飙升了5倍以上。反过来在数据里加上施工路段的样本模型又立刻转好。这印证了一个行业共识端到端模型本质上是一个高度复杂的数据插值器它无法可靠地处理训练分布之外的场景。解决这个问题没有捷径只能做三件事尽可能采集多场景数据让数据覆盖更广泛的真实世界分布用生成式模型如扩散模型合成边缘场景和罕见交互给模型“补课”设计安全兜底策略如降级模式、最小风险策略在模型不确定度很高时主动降低车速或者请求接管这里顺带提一下最近3DGS3D Gaussian Splatting相关的算法在自动驾驶仿真领域很火。用3DGS重建一个高保真的动态场景再配合交互式智能体生成仿真环境确实能大幅降低边缘场景数据的获取成本。但“生成”不等于“真实”生成的场景与真实物理世界的分布仍然有gap目前适合做辅助评测和数据补充完全替代真实测试还不太现实。4.3 纯端到端 vs 混合架构路线之争的真实考量行业内关于技术路线的争论非常激烈。一派认为端到端就应该“一条路走到底”感知、预测、规划全部神经网络化另一派认为安全攸关系统必须有明确的分层和冗余设计混合架构端到端感知 规则/优化规划才是量产的最优解。我的观点是技术路线的选择取决于应用场景和安全目标不能一概而论。在L2的辅助驾驶场景里人的监控是最后一道安全网纯端到端模型可以带来更自然的驾驶体验试错成本也相对可控。但在L4级的无人驾驶场景里车辆需要独自承担所有安全责任这时候纯端到端模型的风险就很大了——你很难证明它在所有可能场景下的行为都是安全的。我比较认同的做法是用端到端模型提供高度拟人化的驾驶策略但保留传统的安全监督与兜底层。实时监测模型输出的合理性和自车周围的安全边界一旦发现超出预设阈值就切换到保守策略甚至执行最小风险停车MRC。另外补充一个工程视角量产芯片上的算力是有限的。纯端到端的大模型如果要在车端实时运行需要做大量的量化、裁剪和算子优化。混合架构反而可以更灵活地调配算力——感知端用轻量模型持续输出规划端用优化器做快速校验整体对芯片的利用率更合理。5. 仿真与数据生成的新工具3DGS等技术带来的变量5.1 传统仿真的局限与新工具的引入自动驾驶仿真并不是新概念从早期的回放测试到现在的场景库生成工具链已经发展了十几年。但传统仿真有个尴尬之处手工搭建的场景模型与真实世界差距太大模型在仿真里学会了避让一个“水泥柱”到真实世界看到一棵树反而会愣住。近年来越来越多人把目光投向**3DGS3D高斯泼溅**这类新渲染工具。3DGS用一批高斯基元表示三维场景配合相机位姿可以实时渲染出高质量的新视角图像渲染速度远高于传统的NeRF方法。这意味着两件事第一我们可以用真实传感器数据快速重建高保真的静态场景第二可以在重建场景里插入动态物体如虚拟行人、虚拟车辆生成各种在真实世界里难遇见的交互场景。5.2 从“场景编辑”到“场景生成”的一条可行路径我自己试用3DGS做场景生成的大致流程是这样的用采集车跑一圈真实道路获得多路相机图像和位姿数据用3DGS离线重建这条路的静态背景场景在重建场景中手动或自动放置动态目标的初始位置和运动轨迹用仿真引擎控制这些动态目标运动并实时渲染出新视角图像把渲染图像流送入端到端模型生成决策轨迹计算安全与舒适度指标这套流程能批量生成大量“在真实道路位置发生的随机交互场景”比手工建模真实很多比纯路采数据像覆盖更多边缘case。当然它也有很多细节需要打磨比如动态物体的渲染伪影、光照变化的一致性、以及渲染与真实传感器分布差2D图像渲染和真实带噪图像的差异。目前它更适合做“数据补盲”和“模型压力测试”而不是直接作为训练数据的主要来源。5.3 生成式数据的边界在哪里关于生成数据的边界我踩过一个具体的坑用3DGS合成的数据训练模型去识别“躺在路面上的轮胎”模型看起来学会了但拿到真实路测时还是会漏检。后来分析发现合成数据里的轮胎纹理太干净、没有真实路面上那种磨损和污渍模型学到的是“形状纹理”的联合特征而不是单纯的形状特征。后来重新设计了纹理扰动和域随机化才把真实场景的漏检率降下来。这说明一个根本问题生成式数据算法再强大最终还是要经过真实数据的校准。用合成数据去扩充数据分布没问题但千万不要把生成数据当成真实数据的替代品。最好的策略是“合成生成 真实场景抽样验证”的迭代闭环逐步提高模型对真实世界分布的鲁棒性。6. 常见问题与排查技巧实录6.1 端到端模型训练不收敛怎么办训练端到端模型最常见的问题是loss居高不下或者震荡严重。我排查这类问题通常会按这个顺序来先检查数据管道是不是有的线程卡死了、数据增强时间太长、某个传感器的时间戳没对齐。很多时候“模型不收敛”其实是数据喂错了这个问题优先排查。再检查loss数值的量级如果辅助损失的数值比主损失大很多梯度会被辅助任务带偏。可以对不同损失项设置不同的权重或者做梯度裁剪。检查学习率端到端模型的损失面通常比较复杂初始学习率过高会直接震荡过低则收敛慢。建议先用torch/lr_finder做一次学习率扫描再确定初始值。最后才是模型结构问题比如特征分辨率太低、注意力层数不够等这类问题通常只在前面三步都正常时才会考虑。6.2 模型在仿真里表现好、实车翻车是什么原因这是最让人头疼的问题。仿真与实车差异大的原因通常包括传感器仿真失真仿真图像过于“干净”没有真实相机的噪声、动态模糊、色差和过曝动力学模型不一致仿真里用的是理想化车辆模型忽略了轮胎非线性、悬挂变形、路面附着系数变化等因素控制延迟端到端模型输出的轨迹要经过执行器响应仿真里通常没有精确建模这个延迟场景渲染差异物体表面材质、光照、阴影与真实世界差别大缓解思路几种一是做域随机化Domain Randomization在训练时随机改变仿真中的纹理、光照、天气、传感器噪声让模型学会泛化二是采用 sim-to-real 迁移技术先把合成数据预训练再用少量真实数据微调三是尽可能把车辆动力学模型建得更精细至少把执行器响应延迟和轮胎滑移加进去。6.3 车端推理延迟高、跑不满30Hz怎么办端到端模型车端部署是量产逃不开的挑战。常见优化手段包括模型量化从FP32降到INT8推理速度能提升2~4倍代价是精度可能下降一点点。量化时注意先做校准集避免极端outlier把量化范围撑大模型蒸馏把大模型教师的知识蒸馏到小模型学生用小模型在车端跑效果通常能逼近大模型耗电量却大幅下降算子融合和剪枝把连续的小算子合并成一个算子去掉冗余的通道和头减少计算量推理引擎优化针对量产芯片Orin、地平线征程、英伟达Thor等的底层算子库做适配很多时候直接调厂商的计算图优化工具就能提速30%以上异步流水线把感知、预测、规划做成不同频率的流水线感知10Hz、规划30Hz各自跑各自的节奏避免“木桶效应”拖垮整体延迟我最想强调的是算法工程师不要只盯着模型精度部署约束对模型架构的影响真的很大。如果从一开始就没想好最终要跑在什么芯片上后面返工的成本非常高。6.4 常见问题速查表问题表现可能原因排查与解法训练loss不降、波动严重数据管道堵塞/时间戳错位检查线程任务耗时与数据对齐逻辑仿真OK实车差传感器仿真失真/动力学不符域随机化更精确车辆模型真实数据微调训练集高精度、测试集崩溃数据分布过窄/过拟合增加场景多样性采样、难例挖掘、正则化BEV小目标物体验不出特征分辨率不足/小目标被下采样增加FPN/特征金字塔或在损失中提高小目标权重车端功耗高、发热严重模型过大/算子未优化INT8量化、蒸馏、算子融合、异步流水线夜间/雨雪场景表现差训练数据中此类场景占比低数据重采样平衡增加图像增强模拟夜间/雨天7. 给同行们的一些实在建议聊了这么多最后说点掏心窝子的话。第一不要神化端到端也别妖魔化端到端。它本质上是把传统模块化流程里很多“手写规则”换成了“数据驱动学出来的规则”优势是可扩展性强、拟人度高劣势是黑盒性、可控性差。技术选型不是立场问题而是工程问题——在哪个场景用哪种组合收益最大就选哪种。第二数据工程能力是端到端团队的护城河。很多团队把所有精力放在调模型结构上结果发现瓶颈根本不在结构而在于数据质量太差、样本分布不合理、评测体系不完善。一个能把“数据采集—清洗—标注—增强—生成—闭环评测”全链路搭建起来的团队价值比单点算法强太多了。第三传统算法和端到端不是替代关系。我在实际项目里见过很多组合打法A*和Dijkstra用于全局路径规划、PID或MPC控制底层执行、粒子群优化在标定和参数寻优中发挥作用、强化学习在仿真中训练决策策略、3DGS在场景重建中做数据补盲。真正成熟的方案往往是多种算法层的融合而不是一个模型解决所有问题。第四安全验证体系要提前建设不要等项目上线前才补。ISO 34505给了我们一个框架性的参考但具体到自己的系统还需要结合功能安全标准如ISO 26262以及实际运营场景的测试需求来定制验证流程。这块起步越早后面积累的测试资产就越值钱。我个人做了这么多年自动驾驶算法最大的感受是这个行业从来不缺炫酷的算法和炸裂的Demo缺的是扎扎实实把工程细节做透、把安全底线守住的耐心。端到端算法是一把好刀但刀越锋利越需要足够坚固的刀柄和刀鞘。希望同行们在追求模型能力的路上别忘了把验证体系、安全兜底和工程化能力同步做上去。
端到端自动驾驶算法全解析：从原理到工程落地
“端到端”大概是这两年自动驾驶圈子里被讨论最多、也最容易吵起来的概念。一边是特斯拉FSD V12带来的震撼效果一边是“黑盒”“不可控”的质疑声行业里对它既有期待也有焦虑。我自己的感受是很多人把端到端理解成“输入图像、输出方向盘转角”这个说法太粗略了真正落地的时候数据怎么组织、模型怎么训练、怎么去验证安全性、出了corner case怎么兜底每一步都有大量值得深挖的细节。这篇文章想把我对端到端算法的理解、实际跑实验时踩过的坑、以及对整个技术路线走向的判断系统整理一遍给同样在做自动驾驶算法或者准备切入这个方向的朋友们一个参考。1. 端到端算法到底是什么从“拼接”到“贯通”的范式转变1.1 传统模块化架构的困局过去十年自动驾驶的主流方案是模块化流水线感知、预测、规划、控制各管一段。感知模块负责把摄像头、激光雷达的数据变成障碍物边框、车道线、交通标志预测模块根据这些结果推算其他车未来几秒的运动轨迹规划模块再基于预测结果生成一条安全、平滑的轨迹最后控制模块去跟踪这条轨迹。这套架构的好处是每个模块都可以单独开发、单独测试、单独优化出了问题也能快速定位是感知漏检还是规划不合理。但做久了你会发现几个很难回避的问题。第一是信息损耗前一个模块输出的结构化结果会丢掉原始数据里的很多信息比如图像里一个被遮挡一半的行人姿态、路面上的细微纹理变化这些细节在传感器原始数据里明明存在但一旦被抽象成“一个3D框”就再也用不上了。第二是误差级联感知模块的漏检或者误检后续的预测和规划模块几乎没有纠错能力错误会一路传导下去。第三是模块间接口设计困难感知输出的“目标列表”到底应该包含哪些属性、预测模块输出的概率分布怎么传给规划器这些接口往往靠工程师手工设计很难做到最优。做规划的同事经常吐槽感知那边给过来的轨迹抖动一下规划就得重新优化半天。这种拆东墙补西墙的体验做过量产项目的应该都懂。1.2 端到端架构的核心思路端到端算法的思路很简单粗暴不再人为划分模块边界而是让一个大的神经网络直接学习“从传感器原始输入到驾驶决策”的映射关系。输入是图像、激光雷达点云、导航地图、车辆自身状态输出直接是轨迹点、方向盘转角、油门刹车开度或者更抽象一点的“驾驶意图”。这样做最大的优势是可微分的全局优化。整个系统是一个巨大的复合函数所有参数都可以通过损失函数反向传播端到端地更新中间不需要人为设计接口也不存在误差级联——因为整个系统是联合训练的模型会自己学会在感知不确时保守一点、在场景清晰时更果断一些。这种方式更接近人类驾驶的机制人类开车也不是先“识别出前方5米有一个行人”再做一串逻辑推理而是直接把视觉信息和操作经验融合在一起形成一种条件反射式的决策。当然这不是说端到端就没有感知和规划的区分了。更准确地说感知、预测、规划这些能力被压缩进了同一个网络的不同层和不同分支里它们共享特征、互相调制而不是各干各的。1.3 为什么前几年没火偏偏是现在端到端的概念早在上世纪80年代末就有学者拿ALVINN系统做过实验用单隐层神经网络把摄像头图像映射成转向角在卡内基梅隆大学旁边的公路上跑了几十公里。但那个时代算力撑不起大规模训练数据采集成本也高得离谱所以一直停留在实验室。真正让端到端成为行业主流话题是三件事同时发生的结果。一是Transformer和BEV感知的成熟。Vision Transformer让模型可以在图像空间做全局注意力BEV鸟瞰视角统一了多传感器特征表达这两个进展让端到端模型有了能够承载复杂驾驶场景的基础架构。二是数据闭环与仿真能力的积累。头部公司手里有数百万公里的真实路采数据再加上仿真引擎可以生成海量边缘场景端到端模型有了“喂饱”的土壤。三是大算力GPU集群的普及。训练一个端到端模型动辄需要几千张A100/H100同时跑很多天这在五六年前几乎是不可想象的资源量级。关于这个趋势我自己最深的体会是算力、数据、算法这三要素在端到端这个方向上终于形成了共振缺一个都转不起来。2. 核心技术栈与关键选型不是“一个大模型”就完事2.1 数据是第一生产力高质量数据集决定上限做端到端算法最核心的不是网络结构而是数据。模型结构大家抄来抄去差距很快就能抹平但数据质量、数据分布、数据闭环能力才是真正拉开差距的地方。一个可用的自动驾驶数据集通常包含以下几类信息多路摄像头图像前视、环视分辨率一般在2MP以上更高端的到8MP激光雷达点云如果传感器配置里有车辆自身的位姿、速度、加速度等状态信息高精度地图或导航地图信息人工标注的语义标签用于辅助损失或评测驾驶员操作记录在模仿学习方案中作为监督信号我在实际做数据清洗时踩过的一个坑是数据失衡。城市快速路的数据特别多但城中村窄路、施工改道路段的数据少得可怜。模型在这种不均衡数据上训练完日常场景表现很好一遇到窄路会车就“犯懵”。后来我们的做法是给不同场景类型设置采样权重并且用仿真工具专门补充难例数据才把问题压下去。另外数据的时空多样性也很重要。同一个路口在不同光照、天气、季节下的表现差异可能非常大。如果数据采集集中在某几个月模型就是对那个季节过拟合。有条件的话最好做跨地域、跨季节、跨时段的均衡采样这个对泛化能力的影响比调几个网络参数大得多。2.2 网络结构从CNN到Transformer再到BEV当前主流的端到端方案在感知骨干网络部分通常会选这三种之一纯CNN如ResNet、RegNet计算效率高、部署友好但感受野受限长距离依赖建模能力弱Vision TransformerViT全局建模能力强适合处理复杂交互场景但计算量偏大需要蒸馏或者裁剪才能上量产芯片CNNTransformer混合浅层用CNN提局部特征高层用Transformer做全局交互兼顾效率和效果目前很多落地项目采用这种方案在特征表达层面BEV空间基本成了共识。把多摄像头的图像特征通过几何投影和注意力机制统一到自车为中心的鸟瞰视角网格上再在这个统一空间里做目标检测、在线地图构建、占用网格预测。好处是不同模态的特征在同一个坐标系下对齐后续预测和规划分支可以直接在BEV特征上做不需要再来回切换坐标系。我个人的建议是如果团队是从零开始做不要一上来就上超大模型。先把一个中等规模的BEV感知模型跑通吃透数据流程和loss设计再逐步扩展到端到端的整体框架。直接套用几十亿参数的大模型光是调分布式训练和显存优化就能耗掉你一个月时间。2.3 规划控制部分当强化学习遇上传统优化端到端模型输出决策的方式也分好几个流派。一种是把规划模块也直接用神经网络替代输入BEV特征和历史轨迹输出未来几秒的轨迹点或控制量。这种方式“端到端”程度最彻底但可解释性和安全约束的嵌入比较困难。另一种是神经规划器与优化器结合神经网络负责生成候选轨迹或者给出一个较优的“初始解”传统优化器比如二次规划、模型预测控制再在这个基础上做平滑和安全校验。这种混合方式既享受了端到端特征提取的优势又保留了优化方法的约束能力是目前很多希望在量产上找到平衡点的公司选择的路线。在训练策略上模仿学习和强化学习都在被使用。模仿学习IL直接用人类驾驶数据做监督简单有效但受数据分布限制遇到没见过的场景容易手足无措。强化学习RL让智能体在仿真环境中试错理论上可以覆盖更多极端场景但奖励函数设计非常考验功力——你希望车开得快它就学会闯黄灯你希望车开得安全它就变成“乌龟车”不敢变道。后来很多人采用RLIL联合训练的方式先用模仿学习做预训练再用强化学习做微调效果比单用任何一种都好。另外提一句虽然现在大家都在谈神经网络规划但传统规划算法并没有被完全抛弃。像Dijkstra、A这类图搜索算法在全局路径规划中依然常用基于采样的RRT/RRT在复杂场景也有它的价值。端到端模型更像是一个“高效的通勤者”负责处理90%的常规场景传统算法则是那个“冷静的兜底者”在模型不确定或者安全校验不通过时接管。这两种角色不是对立关系而是互补关系。3. 从零跑通一个端到端训练流程实操记录与方法论3.1 数据闭环与训练流程设计我自己实际跑通一个端到端项目大致会分成五个阶段数据采集与预处理车端采集原始数据做时间对齐相机、lidar、IMU、CAN总线之间的时间戳同步非常关键差几十毫秒在高速场景就是一两米的偏差、传感器标定、地图匹配。数据量级从几百小时起步质量筛选要看光照、天气、遮挡程度。数据标注与挖掘人工标注目标框、车道线、可行驶区域等同时用规则和模型挖掘困难样本急刹车、近距离切入、交通参与者姿态异常等。这个过程很耗时建议优先保证难例数据的标注质量。模型训练输入通常是一个序列比如前后各1秒的帧数据采样频率10Hz左右输出是未来5~8秒的轨迹序列。训练分成两阶段先在大型通用数据集上做预训练比如在ImageNet或者某个大型BEV数据集上再在自采的驾驶数据集上微调。离线评测在独立测试集上计算各类指标包括感知类指标mAP、mOTA、轨迹类指标L2误差、碰撞率、不可行驶区域侵入率、舒适性指标加速度变化率、 jerk等。这里要注意一个经典陷阱模型在训练集所在城市测试效果很好换个城市或换个国家效果雪崩所以测试集的覆盖范围一定要多元化。闭环仿真验证把训练好的模型放进仿真环境中跑大量场景测试它的决策合理性。仿真的好处是可以批量验证边缘case缺点是仿真与真实之间存在sim-to-real gap仿真里表现好不代表真实世界一定行。我自己训练时的经验是loss的设计比网络结构更容易被低估。单纯用均方误差MSE去约束轨迹点模型倾向于输出“平均轨迹”会不自觉抹掉急转弯和紧急刹车这些动作导致驾驶风格极其保守。后来我们加入多模态轨迹分支每一模态负责一种驾驶风格再用一个概率头去选择最合理的模态效果明显改善。3.2 端到端模型训练中的参数细节举一个具体的训练配置例子方便你有个大致概念输入分辨率前视8MP图像缩放至1920×1080环视4路至1280×720时间序列长度10帧1秒采样间隔100ms特征图尺寸BEV网格自车为中心200m×100m分辨率0.5m视觉骨干ResNet-50或ViT-Small预训练权重从通用数据集加载轨迹模态数K3分别对应巡航、加速变道、减速避让损失函数分类损失选择哪个模态 回归损失每个模态下的轨迹点坐标 辅助感知损失分割/检测 正则化项优化器AdamW初始学习率5e-4cosine decayBatch size256分布式训练64卡A100约训练3万步训练时间约5~7天这些参数不一定适合所有项目核心是想让大家有个“量级感”。我之前见过一个团队batch size设太大导致模型严重过拟合到高密度车流场景后来缩减batch size并加大数据增强随机遮挡、色彩抖动、随机裁剪才缓解。3.3 评测体系ISO 34505带来的新思路2025年发布的ISO 34505《道路车辆——自动驾驶系统测试场景评价及测试用例生成》给自动驾驶测试场景的生成、评价和用例设计提供了国际标准框架。它的核心思路是不再只依赖人工设计测试用例而是通过系统性方法从真实事故库、自然驾驶数据库、边缘Case库中挖掘和组合测试场景并定义了一套评估场景质量、覆盖度和危险度的指标。对做端到端算法的团队来说这套标准很有参考价值。因为端到端模型最容易在“见过的场景”里表现好在“没见过但合理”的场景里出问题传统的固定功能测试很难覆盖这类盲区。ISO 34505提供的方法论让我重新审视评测体系建设与其撒胡椒面式地准备测试用例不如先做一个覆盖度分析识别场景空间里的“空白区”再有针对性地去仿真或实测中补充。顺着这个思路我们的测试流程做了一次调整模块级评测分别验证代码正确性、模型数值稳定性、极端输入下的鲁棒性系统级仿真评测包括IEC/ISO标准工况如切入切出、前车急停、行人横穿等也包括基于真实路采数据重建的场景回放实车路测在限定区域的开放测试场和指定道路上进行重点关注舒适性与安全兜底行为泛化性探针引入跨城市、跨季节、跨道路类型的分层采样测试验证模型在分布外场景的表现实话说ISO 34505的描述并不好“啃”很多术语比较抽象。我建议团队里最好有人先把标准消化透再对照现有测试流程做差异分析而不是全员硬啃。4. 落地过程中踩过的坑与争议直说是非曲直4.1 可解释性黑盒恐惧与可视化兜底端到端模型最被人诟病的一点就是不可解释。感知模块错了还能画个BBox出来看看但端到端模型只给一个方向盘转角你根本不知道它“看到了什么”“在想什么”。我的理解是端到端不等于不可解释。现在的方法可以做到一定程度的解释用注意力热力图看模型关注了哪些区域用中间层特征可视化看BEV空间里模型对障碍物的建模用轨迹多模态分布看模型认为哪些行为是合理的。我们在开发时做了一套可视化调试工具可以回放车的视角、渲染BEV特征、叠加注意力权重也能查看模型输出的多模态轨迹分布。这套工具帮我们定位了很多问题比如“模型在夜间没有关注到路边逆行的自行车”通过热力图一眼就能发现。不过也要承认目前的可解释性工具还没有形成统一标准很多时候还要靠工程师的个人经验去“猜”。这个方向还有很长的路要走。4.2 长尾场景模型再强也怕“没见过”端到端模型对训练数据分布十分敏感。我做过一个实验把训练数据里所有“施工改道路段”的样本剔除掉再拿一个小型测试集全是施工路段去测模型失误率直接飙升了5倍以上。反过来在数据里加上施工路段的样本模型又立刻转好。这印证了一个行业共识端到端模型本质上是一个高度复杂的数据插值器它无法可靠地处理训练分布之外的场景。解决这个问题没有捷径只能做三件事尽可能采集多场景数据让数据覆盖更广泛的真实世界分布用生成式模型如扩散模型合成边缘场景和罕见交互给模型“补课”设计安全兜底策略如降级模式、最小风险策略在模型不确定度很高时主动降低车速或者请求接管这里顺带提一下最近3DGS3D Gaussian Splatting相关的算法在自动驾驶仿真领域很火。用3DGS重建一个高保真的动态场景再配合交互式智能体生成仿真环境确实能大幅降低边缘场景数据的获取成本。但“生成”不等于“真实”生成的场景与真实物理世界的分布仍然有gap目前适合做辅助评测和数据补充完全替代真实测试还不太现实。4.3 纯端到端 vs 混合架构路线之争的真实考量行业内关于技术路线的争论非常激烈。一派认为端到端就应该“一条路走到底”感知、预测、规划全部神经网络化另一派认为安全攸关系统必须有明确的分层和冗余设计混合架构端到端感知 规则/优化规划才是量产的最优解。我的观点是技术路线的选择取决于应用场景和安全目标不能一概而论。在L2的辅助驾驶场景里人的监控是最后一道安全网纯端到端模型可以带来更自然的驾驶体验试错成本也相对可控。但在L4级的无人驾驶场景里车辆需要独自承担所有安全责任这时候纯端到端模型的风险就很大了——你很难证明它在所有可能场景下的行为都是安全的。我比较认同的做法是用端到端模型提供高度拟人化的驾驶策略但保留传统的安全监督与兜底层。实时监测模型输出的合理性和自车周围的安全边界一旦发现超出预设阈值就切换到保守策略甚至执行最小风险停车MRC。另外补充一个工程视角量产芯片上的算力是有限的。纯端到端的大模型如果要在车端实时运行需要做大量的量化、裁剪和算子优化。混合架构反而可以更灵活地调配算力——感知端用轻量模型持续输出规划端用优化器做快速校验整体对芯片的利用率更合理。5. 仿真与数据生成的新工具3DGS等技术带来的变量5.1 传统仿真的局限与新工具的引入自动驾驶仿真并不是新概念从早期的回放测试到现在的场景库生成工具链已经发展了十几年。但传统仿真有个尴尬之处手工搭建的场景模型与真实世界差距太大模型在仿真里学会了避让一个“水泥柱”到真实世界看到一棵树反而会愣住。近年来越来越多人把目光投向**3DGS3D高斯泼溅**这类新渲染工具。3DGS用一批高斯基元表示三维场景配合相机位姿可以实时渲染出高质量的新视角图像渲染速度远高于传统的NeRF方法。这意味着两件事第一我们可以用真实传感器数据快速重建高保真的静态场景第二可以在重建场景里插入动态物体如虚拟行人、虚拟车辆生成各种在真实世界里难遇见的交互场景。5.2 从“场景编辑”到“场景生成”的一条可行路径我自己试用3DGS做场景生成的大致流程是这样的用采集车跑一圈真实道路获得多路相机图像和位姿数据用3DGS离线重建这条路的静态背景场景在重建场景中手动或自动放置动态目标的初始位置和运动轨迹用仿真引擎控制这些动态目标运动并实时渲染出新视角图像把渲染图像流送入端到端模型生成决策轨迹计算安全与舒适度指标这套流程能批量生成大量“在真实道路位置发生的随机交互场景”比手工建模真实很多比纯路采数据像覆盖更多边缘case。当然它也有很多细节需要打磨比如动态物体的渲染伪影、光照变化的一致性、以及渲染与真实传感器分布差2D图像渲染和真实带噪图像的差异。目前它更适合做“数据补盲”和“模型压力测试”而不是直接作为训练数据的主要来源。5.3 生成式数据的边界在哪里关于生成数据的边界我踩过一个具体的坑用3DGS合成的数据训练模型去识别“躺在路面上的轮胎”模型看起来学会了但拿到真实路测时还是会漏检。后来分析发现合成数据里的轮胎纹理太干净、没有真实路面上那种磨损和污渍模型学到的是“形状纹理”的联合特征而不是单纯的形状特征。后来重新设计了纹理扰动和域随机化才把真实场景的漏检率降下来。这说明一个根本问题生成式数据算法再强大最终还是要经过真实数据的校准。用合成数据去扩充数据分布没问题但千万不要把生成数据当成真实数据的替代品。最好的策略是“合成生成 真实场景抽样验证”的迭代闭环逐步提高模型对真实世界分布的鲁棒性。6. 常见问题与排查技巧实录6.1 端到端模型训练不收敛怎么办训练端到端模型最常见的问题是loss居高不下或者震荡严重。我排查这类问题通常会按这个顺序来先检查数据管道是不是有的线程卡死了、数据增强时间太长、某个传感器的时间戳没对齐。很多时候“模型不收敛”其实是数据喂错了这个问题优先排查。再检查loss数值的量级如果辅助损失的数值比主损失大很多梯度会被辅助任务带偏。可以对不同损失项设置不同的权重或者做梯度裁剪。检查学习率端到端模型的损失面通常比较复杂初始学习率过高会直接震荡过低则收敛慢。建议先用torch/lr_finder做一次学习率扫描再确定初始值。最后才是模型结构问题比如特征分辨率太低、注意力层数不够等这类问题通常只在前面三步都正常时才会考虑。6.2 模型在仿真里表现好、实车翻车是什么原因这是最让人头疼的问题。仿真与实车差异大的原因通常包括传感器仿真失真仿真图像过于“干净”没有真实相机的噪声、动态模糊、色差和过曝动力学模型不一致仿真里用的是理想化车辆模型忽略了轮胎非线性、悬挂变形、路面附着系数变化等因素控制延迟端到端模型输出的轨迹要经过执行器响应仿真里通常没有精确建模这个延迟场景渲染差异物体表面材质、光照、阴影与真实世界差别大缓解思路几种一是做域随机化Domain Randomization在训练时随机改变仿真中的纹理、光照、天气、传感器噪声让模型学会泛化二是采用 sim-to-real 迁移技术先把合成数据预训练再用少量真实数据微调三是尽可能把车辆动力学模型建得更精细至少把执行器响应延迟和轮胎滑移加进去。6.3 车端推理延迟高、跑不满30Hz怎么办端到端模型车端部署是量产逃不开的挑战。常见优化手段包括模型量化从FP32降到INT8推理速度能提升2~4倍代价是精度可能下降一点点。量化时注意先做校准集避免极端outlier把量化范围撑大模型蒸馏把大模型教师的知识蒸馏到小模型学生用小模型在车端跑效果通常能逼近大模型耗电量却大幅下降算子融合和剪枝把连续的小算子合并成一个算子去掉冗余的通道和头减少计算量推理引擎优化针对量产芯片Orin、地平线征程、英伟达Thor等的底层算子库做适配很多时候直接调厂商的计算图优化工具就能提速30%以上异步流水线把感知、预测、规划做成不同频率的流水线感知10Hz、规划30Hz各自跑各自的节奏避免“木桶效应”拖垮整体延迟我最想强调的是算法工程师不要只盯着模型精度部署约束对模型架构的影响真的很大。如果从一开始就没想好最终要跑在什么芯片上后面返工的成本非常高。6.4 常见问题速查表问题表现可能原因排查与解法训练loss不降、波动严重数据管道堵塞/时间戳错位检查线程任务耗时与数据对齐逻辑仿真OK实车差传感器仿真失真/动力学不符域随机化更精确车辆模型真实数据微调训练集高精度、测试集崩溃数据分布过窄/过拟合增加场景多样性采样、难例挖掘、正则化BEV小目标物体验不出特征分辨率不足/小目标被下采样增加FPN/特征金字塔或在损失中提高小目标权重车端功耗高、发热严重模型过大/算子未优化INT8量化、蒸馏、算子融合、异步流水线夜间/雨雪场景表现差训练数据中此类场景占比低数据重采样平衡增加图像增强模拟夜间/雨天7. 给同行们的一些实在建议聊了这么多最后说点掏心窝子的话。第一不要神化端到端也别妖魔化端到端。它本质上是把传统模块化流程里很多“手写规则”换成了“数据驱动学出来的规则”优势是可扩展性强、拟人度高劣势是黑盒性、可控性差。技术选型不是立场问题而是工程问题——在哪个场景用哪种组合收益最大就选哪种。第二数据工程能力是端到端团队的护城河。很多团队把所有精力放在调模型结构上结果发现瓶颈根本不在结构而在于数据质量太差、样本分布不合理、评测体系不完善。一个能把“数据采集—清洗—标注—增强—生成—闭环评测”全链路搭建起来的团队价值比单点算法强太多了。第三传统算法和端到端不是替代关系。我在实际项目里见过很多组合打法A*和Dijkstra用于全局路径规划、PID或MPC控制底层执行、粒子群优化在标定和参数寻优中发挥作用、强化学习在仿真中训练决策策略、3DGS在场景重建中做数据补盲。真正成熟的方案往往是多种算法层的融合而不是一个模型解决所有问题。第四安全验证体系要提前建设不要等项目上线前才补。ISO 34505给了我们一个框架性的参考但具体到自己的系统还需要结合功能安全标准如ISO 26262以及实际运营场景的测试需求来定制验证流程。这块起步越早后面积累的测试资产就越值钱。我个人做了这么多年自动驾驶算法最大的感受是这个行业从来不缺炫酷的算法和炸裂的Demo缺的是扎扎实实把工程细节做透、把安全底线守住的耐心。端到端算法是一把好刀但刀越锋利越需要足够坚固的刀柄和刀鞘。希望同行们在追求模型能力的路上别忘了把验证体系、安全兜底和工程化能力同步做上去。
