端到端自动驾驶实战：从模仿学习到Transformer模型落地

1. 端到端自动驾驶到底在解决什么问题1.1 从模块化流水线到单一神经网络的范式转移传统自动驾驶系统是典型的模块化架构感知模块负责检测车辆、行人、车道线预测模块负责推断其他交通参与者的未来轨迹规划模块负责生成自车路径控制模块负责将路径转化为油门、刹车和转向指令。这套流水线运行了十几年支撑了从L2到L4的大量落地项目但它的天花板也越来越明显。模块化架构最大的问题在于信息瓶颈。感知模块输出的是经过压缩的中间表示——边界框、语义分割图、轨迹点这些表示在压缩过程中丢掉了大量对下游决策有用的信息。比如一个被遮挡了一半的行人感知模块可能只给出一个低置信度的检测框预测模块拿到这个模糊信息后倾向于保守处理规划模块再基于保守预测做决策最终车辆可能做出过于谨慎的急刹。整个链路中每个模块都在做局部最优决策但全局来看未必是最优的。端到端算法的核心思路是用一个可学习的神经网络直接完成从原始传感器输入到控制输出的映射。摄像头像素、激光雷达点云进去方向盘转角、油门开度出来中间不再有手工设计的接口。这个想法并不新鲜早在1980年代就有ALVINN这样的尝试但真正让它变得可行的是三个条件的同时成熟Transformer架构带来的序列建模能力、大规模驾驶数据集的出现、以及模仿学习训练范式的工程化。我个人的判断是端到端不是要完全取代模块化而是在特定场景下提供一条更优的路径。模块化架构在可解释性、功能安全认证方面有天然优势端到端在应对复杂交互、减少信息损失方面更有潜力。两者会在相当长时间内共存。1.2 模仿学习为什么成为当前主流训练范式端到端自动驾驶的训练方法大致分三类模仿学习、强化学习、以及两者的混合。目前工业界落地最多的是模仿学习原因很直接——强化学习在真实驾驶场景中的试错成本太高。你不可能让一辆车在真实道路上通过撞车来学习什么是坏决策而仿真环境中的强化学习又面临sim-to-real的鸿沟。模仿学习的逻辑是人类驾驶员在真实道路上的驾驶行为本身就是一种“专家示范”我们让神经网络去拟合这些示范数据。给定当前帧的传感器输入和车辆状态网络输出应该尽可能接近人类驾驶员当时的操作。这是一个监督学习问题损失函数通常是预测控制量与真实控制量之间的L1或L2距离。但模仿学习有一个根本性的缺陷因果混淆。网络可能学到的是“看到方向盘转角大就输出大转角”这种捷径而不是真正理解场景。比如训练数据中左转时方向盘转角大网络可能简单地学到“转角大左转”而忽略了视觉场景中的左转信号。这个问题在端到端模型中特别隐蔽因为网络有足够多的参数去记住训练数据的表面特征。实践中缓解因果混淆的常用手段包括加入历史帧作为输入让网络学习时序依赖、使用多任务学习让网络同时预测未来轨迹和当前控制、以及在损失函数中加入对场景理解的辅助任务。但坦率地说这个问题至今没有完美解法也是端到端系统在安全关键场景中难以获得认证的主要原因之一。1.3 端到端方案适合什么样的团队和场景不是所有做自动驾驶的团队都适合立刻上端到端。根据我的观察以下几类团队更适合优先考虑端到端方案拥有大规模真实驾驶数据的团队。端到端模型的性能高度依赖数据量和数据多样性没有几十万甚至上百万段高质量驾驶片段很难训出泛化能力可接受的模型。传感器配置相对简单的团队。纯视觉或视觉为主的方案更适合端到端因为多传感器融合在端到端框架下会显著增加模型复杂度和训练难度。场景相对受限的团队。比如园区物流、港口运输、高速公路巡航等ODD运行设计域明确的场景端到端模型更容易收敛和验证。有较强AI工程能力的团队。端到端涉及大规模数据管道、分布式训练、模型部署优化等工程挑战不是调几个超参就能跑通的。反过来如果团队主要做的是L2级辅助驾驶、需要满足严格的功能安全认证、或者数据积累有限那么模块化架构仍然是更稳妥的选择。端到端不是银弹它只是工具箱里的一把新锤子。2. Transformer在端到端驾驶中的具体角色拆解2.1 为什么是Transformer而不是CNN或RNN端到端驾驶的输入本质上是多模态时序数据摄像头图像是空间二维信号激光雷达点云是三维空间信号车辆状态是低维时序信号导航指令是离散语义信号。要把这些异构信号融合成一个统一的表示Transformer的自注意力机制天然适合。CNN的局限在于感受野受卷积核大小限制要覆盖远处车辆和近处车道线需要堆叠很多层而且不同尺度的特征融合不够灵活。RNN的局限在于序列建模是串行的训练时无法并行长序列上的梯度传播也不稳定。Transformer的自注意力可以同时关注序列中任意两个位置而且可以并行计算这在处理长时序驾驶数据时优势明显。具体到端到端驾驶Transformer通常扮演三个角色特征提取与融合用Vision Transformer或Swin Transformer处理图像用Point Transformer处理点云然后通过跨模态注意力将不同传感器的特征对齐融合。时序建模将历史帧的特征序列输入Transformer编码器让模型学习场景的时序演化规律。决策输出用Transformer解码器或简单的MLP头将融合特征映射到控制量或轨迹点。2.2 感知端到端与规划端到端的边界划分“端到端”这个词在业界被用得很泛实际上存在不同的端到端程度。我倾向于把它分为三个层次层次输入输出典型方案感知端到端原始传感器数据感知结果检测/分割BEVFormer、PETR规划端到端感知结果导航轨迹或控制量UniAD、VAD全端到端原始传感器数据控制量纯模仿学习模型目前大多数宣称“端到端”的方案实际上是规划端到端感知部分仍然依赖独立的检测或分割网络。真正的全端到端方案在工业界还很少因为一旦感知出错整个系统没有任何冗余来纠正。我的经验是规划端到端是当前性价比最高的选择。它保留了感知模块的可解释性和可验证性同时在规划层面享受端到端带来的信息保留和联合优化优势。全端到端更适合研究探索短期内不太可能通过量产车的安全验证。2.3 自注意力机制在驾驶场景中的计算代价与优化Transformer的自注意力计算复杂度是序列长度的平方。驾驶场景中如果输入是10帧历史、每帧100个token序列长度就是1000注意力矩阵就是100万元素。如果再加上多摄像头比如6路和多模态图像点云序列长度轻松破万计算量会变得不可接受。实践中常用的优化手段有几种稀疏注意力只计算局部窗口内的注意力或者只让每个token关注固定数量的邻居。Swin Transformer的窗口注意力就是典型代表。线性注意力用核函数近似softmax注意力将复杂度降到线性。但线性注意力在驾驶场景中的精度损失需要仔细评估。Token剪枝与合并在推理时动态丢弃不重要的token或者将相似的token合并。这在BEV特征上特别有效因为BEV网格中大量区域是天空或远处背景。量化与蒸馏将FP32模型量化到INT8或者用大模型蒸馏小模型。部署到车端芯片时这是必选项。我在实际项目中的体会是不要一开始就追求全端到端。先用小规模模型验证端到端规划是否比模块化规划有优势确认后再逐步扩大模型规模和输入模态。否则很容易陷入“模型太大训不动、训动了跑不起来”的困境。3. 从零搭建端到端驾驶模型的实操路径3.1 数据管道的搭建从原始日志到训练样本端到端模型的数据管道比传统模块化系统复杂得多因为输入是原始传感器数据输出是连续控制量中间没有人工标注的中间表示。一条完整的数据管道通常包括原始数据采集车辆上的摄像头、激光雷达、IMU、CAN总线数据同步录制。时间同步精度要求到毫秒级否则输入和输出之间的对应关系会错位。数据清洗剔除传感器故障、时间戳异常、驾驶行为异常的片段。驾驶行为异常包括急刹、急转、频繁变道等这些片段如果混入训练集会让模型学到不安全的驾驶策略。场景挖掘从海量数据中筛选出有价值的场景。比如交叉路口、行人横穿、施工区域等。常用的方法包括基于规则的筛选如根据GPS判断是否在路口和基于模型的筛选如用聚类算法找出罕见场景。样本构造将连续驾驶片段切分成固定长度的样本。每个样本包含过去N帧的传感器数据和未来M帧的控制量。N和M的选择需要权衡N太小模型看不到足够的历史上下文N太大计算量爆炸M太小模型学不到长时规划M太大训练信号稀疏。数据增强对图像做颜色抖动、裁剪、翻转对控制量做相应的变换。注意翻转图像时方向盘转角要取反否则模型会学到错误的对应关系。提示数据管道中最容易出问题的是时间同步。我见过多个项目因为摄像头和CAN总线之间有几十毫秒的固定延迟导致模型学到的控制量总是“慢半拍”。建议在管道中加入时间对齐校验步骤用互相关方法估计并补偿传感器间的延迟。3.2 模型架构选型BEVTransformer还是纯视觉端到端当前主流的端到端驾驶模型架构有两类BEVTransformer方案先用图像骨干网络提取特征然后通过Transformer将多摄像头特征投影到统一的BEV鸟瞰图空间再在BEV特征上做时序融合和规划。代表工作有BEVFormer、UniAD等。这种方案的优势是BEV空间天然适合做规划不同传感器的特征在BEV空间中对齐后融合更自然。劣势是BEV投影本身是一个病态问题深度估计误差会传播到下游。纯视觉端到端方案直接用Vision Transformer处理前视摄像头图像输出控制量。代表工作有早期的NVIDIA Dave系列和后来的各种端到端模仿学习模型。这种方案的优势是结构简单、计算量小。劣势是缺乏空间理解能力模型很难从2D图像中准确推断3D空间中的距离和速度。我的建议是如果传感器配置中有激光雷达优先考虑BEVTransformer方案因为激光雷达提供的精确深度信息可以显著提升BEV投影质量。如果是纯视觉方案那么需要在模型中显式加入深度估计辅助任务否则模型很难学到准确的空间关系。3.3 训练策略模仿学习中的因果混淆与缓解手段模仿学习的训练目标看似简单——最小化预测控制量和真实控制量之间的差距。但实际训练中会遇到几个典型问题问题一模型学会“偷懒”。如果训练数据中大部分时间是直行模型可能简单地学到“输出零转角”就能获得很低的平均损失。但在需要转弯的场景中模型就会表现很差。缓解方法是使用加权损失对转弯、加减速等非直行场景给予更高权重。问题二因果混淆。前面提到过模型可能学到表面相关性而非真正的因果理解。一个有效的缓解手段是输入扰动在训练时对输入图像加入噪声或遮挡迫使模型依赖更鲁棒的特征。另一个手段是反事实数据增强构造一些“如果当时驾驶员做了不同操作会怎样”的样本让模型学习操作与场景之间的因果关系。问题三分布偏移。模型在训练集上表现很好但在测试集上遇到未见过的场景时性能骤降。这是模仿学习的固有问题因为模型只见过专家示范没见过自己的错误如何恢复。缓解方法是DAggerDataset Aggregation让模型在仿真或封闭场地中运行收集模型犯错时的数据由人类驾驶员标注正确操作然后加入训练集迭代训练。3.4 评估与验证离线指标与闭环测试的差距端到端模型的评估是一个容易被低估的环节。离线指标如控制量的L1/L2误差、轨迹的ADE/FDE只能反映模型在训练分布内的拟合程度不能反映闭环驾驶性能。一个离线误差很小的模型在闭环测试中可能因为微小的控制误差累积而偏离车道。闭环测试通常分三步仿真测试在CARLA、LGSVL等仿真器中运行模型评估碰撞率、车道保持率、完成率等指标。仿真的优势是可以大规模并行测试劣势是sim-to-real差距。封闭场地测试在测试场中运行真实车辆评估模型在真实传感器噪声和车辆动力学下的表现。这一步通常会暴露仿真中看不到的问题比如摄像头过曝、激光雷达反射异常等。开放道路测试在真实交通中运行评估模型与人类驾驶员的交互能力。这一步风险最高需要严格的安全员接管机制。我的经验是离线指标和闭环性能之间的相关性很弱。不要因为离线损失降到了很低就认为模型可以上路了。闭环测试中暴露的问题往往和离线指标无关比如模型对某个特定颜色的车辆反应异常、在特定光照条件下输出抖动等。4. 端到端方案落地时绕不开的工程难题4.1 车端推理的实时性约束与模型压缩端到端模型要在车端实时运行通常要求推理延迟在100毫秒以内最好在50毫秒以内。这对模型大小和计算量提出了严格约束。一个在服务器上跑得很好的模型直接部署到车端芯片上可能连10帧都跑不到。模型压缩的常用手段包括剪枝去掉网络中不重要的连接或通道。结构化剪枝去掉整个通道比非结构化剪枝去掉单个权重更适合硬件加速。量化将FP32权重和激活值量化到INT8甚至INT4。量化后模型大小减少4倍推理速度提升2-3倍但精度损失需要仔细评估。知识蒸馏用大模型教师指导小模型学生训练。学生模型可以小很多但性能接近教师。算子融合将多个连续算子融合成一个减少内存访问和kernel启动开销。这在Transformer模型中特别有效因为注意力机制涉及大量小算子。注意模型压缩不是一次性的工作而是需要和训练交替进行。通常的做法是训练一个大的教师模型然后蒸馏出小模型再对小模型做量化和剪枝最后在车端芯片上做算子融合和内存优化。每一步都可能需要重新微调。4.2 安全冗余端到端模型失效时谁来兜底端到端模型本质上是一个黑盒它的输出没有可解释的中间表示也没有形式化验证的手段。这意味着不能把安全责任完全交给端到端模型。实践中需要设计多层冗余模型级冗余同时运行两个独立训练的端到端模型如果两者输出差异过大触发降级。规则级冗余在端到端模型之外保留一套基于规则的保守控制器当模型输出超出合理范围时接管。硬件级冗余独立的安全监控芯片实时检查车辆状态和模型输出发现异常时触发紧急制动。远程接管在L4级系统中当车辆无法处理当前场景时请求远程操作员接管。这些冗余机制的设计需要在系统架构层面考虑不能等到模型训练完再补。我见过一些团队先训模型再想安全冗余结果发现模型输出频率和冗余系统的接口对不上不得不重新设计架构。4.3 数据闭环从路测到模型迭代的完整链路端到端模型的性能提升高度依赖数据闭环的效率。一个完整的数据闭环包括路测数据采集车辆在真实道路上运行记录所有传感器数据和模型输出。异常检测自动识别模型表现不佳的场景。常用的方法包括模型输出与人类接管操作差异大、模型输出不确定性高、车辆动力学异常等。场景标注对异常场景进行人工标注确定正确的驾驶操作。模型再训练将新标注的数据加入训练集重新训练模型。回归测试确保新模型在旧场景上不退化。OTA更新将新模型部署到车队。这个闭环的迭代速度决定了端到端系统的进化速度。特斯拉的FSD之所以迭代快很大程度上是因为它有一个高效的数据闭环。对于大多数团队来说数据闭环的瓶颈不在模型训练而在异常检测和场景标注。如何从海量路测数据中自动找出真正有价值的场景是一个比模型架构更难的工程问题。4.4 仿真环境在端到端训练中的真实价值仿真环境在端到端训练中的价值经常被高估。很多人以为可以在仿真中训练端到端模型然后直接部署到真实车辆。但现实是仿真数据和真实数据之间存在巨大的域差距。仿真器中的图像渲染再逼真也和真实摄像头捕捉的光影、纹理、噪声有本质区别。在仿真中训练的模型直接部署到真实车辆上往往表现很差。仿真真正有价值的场景是闭环测试在仿真中测试模型的闭环性能发现逻辑错误和边界情况。危险场景生成构造真实道路上难以采集的危险场景如突然横穿的行人、前车急刹等测试模型的应急反应。数据增强用仿真数据补充真实数据中稀有的场景但仿真数据在训练集中的比例不宜过高通常不超过20%。我的建议是仿真主要用于测试和验证而不是训练。训练数据的主体必须来自真实道路。仿真数据可以作为补充但需要仔细控制比例和域适应策略。5. 几个容易被忽视的实操细节5.1 控制量表示的选择直接回归还是离散化端到端模型的输出层设计有一个容易被忽视但影响很大的选择控制量是直接回归连续值还是离散化成若干档位再分类直接回归的优点是输出精度高可以输出任意角度的方向盘转角和任意大小的油门开度。缺点是回归损失对异常值敏感而且模型容易输出“平均”行为——在不确定时倾向于输出中间值导致驾驶行为保守。离散化分类的优点是训练稳定模型可以输出多模态分布比如同时给出左转和右转的概率。缺点是输出精度受档位数量限制档位太少会导致控制抖动档位太多又失去了分类的优势。实践中常用的折中方案是混合表示用分类头预测粗粒度的控制量再用回归头预测残差。这样既有分类的稳定性又有回归的精度。另一个方案是预测轨迹而非控制量然后用一个固定的控制器将轨迹转化为控制量。这样模型只需要学习“往哪走”不需要学习“怎么操作”降低了学习难度。5.2 历史帧长度的选择多少帧才够用历史帧长度是端到端模型的一个重要超参数。太短模型看不到足够的上下文无法判断其他车辆的运动趋势太长计算量增加而且模型可能学到无关的长时依赖。根据我的经验2秒左右的历史帧长度是一个合理的起点。在30FPS的采样率下大约是60帧。如果计算资源有限可以降到1秒30帧。如果场景中高速行驶较多可以增加到3秒90帧因为高速场景中车辆需要更长的历史来判断前车的减速趋势。但历史帧长度不是越长越好。我试过用5秒历史帧训练模型发现模型在大多数场景下表现和2秒差不多但在计算资源上消耗大了很多。而且过长的历史帧会让模型学到一些虚假的长时依赖比如“10秒前经过了一个路口所以现在应该减速”这在训练集中可能碰巧成立但在测试集中不成立。5.3 损失函数设计L1、L2还是其他控制量预测的损失函数选择看似简单实际上对训练结果影响很大。L2损失对大误差惩罚重模型会倾向于输出保守的平均值L1损失对异常值更鲁棒但梯度在零点不连续训练可能不稳定。实践中常用的方案是Huber损失它在误差小的时候表现为L2误差大的时候表现为L1兼顾了稳定性和鲁棒性。另一个方案是分位数损失让模型输出控制量的分布而不是点估计这样可以捕捉驾驶行为的多模态性。还有一个容易被忽视的点是损失函数的加权。如果模型同时预测方向盘转角和油门开度两者的量纲不同直接相加会导致量纲大的那个主导梯度。通常需要对不同输出维度做归一化或者手动调整权重。我的经验是方向盘转角的权重应该比油门开度大一些因为转向错误比速度错误更危险。5.4 模型不确定性的估计与利用端到端模型的一个关键缺陷是不知道自己不知道。模型在遇到训练集中未见过的场景时仍然会输出一个控制量而且可能置信度很高。这在安全关键场景中是致命的。估计模型不确定性的常用方法有蒙特卡洛Dropout在推理时保持Dropout开启多次前向传播得到输出分布。方差大表示不确定性高。深度集成训练多个独立模型用它们的输出差异衡量不确定性。贝叶斯神经网络将网络权重建模为分布推理时采样得到输出分布。这些方法都有计算代价在车端实时推理中需要权衡。一个实用的折中方案是只在关键场景中启用不确定性估计比如当模型输出与历史输出差异大、或者车辆处于复杂交互场景时才启用多次推理。不确定性估计的价值在于当模型不确定时可以触发降级策略比如减速、请求远程接管、或者切换到保守的规则控制器。这比让模型“硬着头皮”输出一个可能错误的控制量要安全得多。6. 我对端到端自动驾驶未来走向的个人判断6.1 端到端与模块化的融合趋势我不认为端到端会完全取代模块化。更可能的趋势是两者融合用端到端模型做规划但保留模块化的感知和预测作为冗余和验证。或者反过来用模块化系统做主要决策端到端模型作为“副驾驶”提供建议当两者一致时执行不一致时降级。这种融合架构的好处是兼顾了端到端的信息保留优势和模块化的可解释性、可验证性。实现上的挑战在于如何设计融合策略——是简单的投票机制还是更复杂的置信度加权这需要根据具体场景和安全要求来定。6.2 世界模型与端到端驾驶的结合可能世界模型是最近比较热的方向核心思想是让模型学习环境的动态规律能够预测“如果采取某个动作未来会怎样”。这和端到端驾驶天然契合如果模型能够准确预测未来场景的演化那么规划就变成了在预测结果上做优化。目前世界模型在驾驶中的应用还处于早期主要挑战是预测的准确性和长时稳定性。驾驶场景中的其他参与者行为高度不确定世界模型很难准确预测几秒后的场景。但如果只预测1-2秒世界模型可以提供有用的短期预测帮助端到端模型做出更好的决策。6.3 给准备入局端到端的团队几条实在建议如果你所在的团队正在考虑端到端方案我有几条从实际项目中总结的建议第一不要为了端到端而端到端。先明确当前模块化系统的瓶颈在哪里。如果是感知精度不够那应该先优化感知而不是换端到端。端到端解决的是信息瓶颈和联合优化问题不是所有问题。第二从规划端到端开始。保留现有的感知模块只把预测和规划替换成端到端模型。这样风险可控而且可以快速验证端到端规划是否比传统规划有优势。第三数据比模型重要。与其花大量时间调模型架构不如花时间构建高效的数据管道和场景挖掘系统。端到端模型的性能上限由数据决定模型架构只是逼近这个上限。第四安全冗余从第一天就要考虑。不要等到模型训好了再想怎么保证安全。安全冗余的设计会影响模型输出接口、系统架构、甚至传感器配置必须提前规划。第五保持耐心。端到端自动驾驶是一个长周期的事情从原型到量产可能需要3-5年甚至更久。中间会有很多次“看起来快成了”然后又发现新问题的循环。保持耐心持续迭代比追求短期突破更重要。我在实际项目中最深的体会是端到端模型的调试和传统软件调试完全不同。传统软件出问题可以定位到具体代码行端到端模型出问题只能通过分析数据分布、可视化注意力图、做消融实验来逐步缩小范围。这个过程很磨人但每次找到问题根源时的成就感也很强。如果你正在做端到端驾驶欢迎交流踩坑经验。