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通常扮演三个角色：

1. 特征提取与融合：用Vision Transformer或Swin Transformer处理图像，用Point Transformer处理点云，然后通过跨模态注意力将不同传感器的特征对齐融合。
2. 时序建模：将历史帧的特征序列输入Transformer编码器，让模型学习场景的时序演化规律。
3. 决策输出：用Transformer解码器或简单的MLP头将融合特征映射到控制量或轨迹点。

2.2 感知端到端与规划端到端的边界划分

“端到端”这个词在业界被用得很泛，实际上存在不同的端到端程度。我倾向于把它分为三个层次：

目前大多数宣称“端到端”的方案实际上是规划端到端，感知部分仍然依赖独立的检测或分割网络。真正的全端到端方案在工业界还很少，因为一旦感知出错，整个系统没有任何冗余来纠正。

我的经验是，规划端到端是当前性价比最高的选择。它保留了感知模块的可解释性和可验证性，同时在规划层面享受端到端带来的信息保留和联合优化优势。全端到端更适合研究探索，短期内不太可能通过量产车的安全验证。

2.3 自注意力机制在驾驶场景中的计算代价与优化

Transformer的自注意力计算复杂度是序列长度的平方。驾驶场景中，如果输入是10帧历史、每帧100个token，序列长度就是1000，注意力矩阵就是100万元素。如果再加上多摄像头（比如6路）和多模态（图像+点云），序列长度轻松破万，计算量会变得不可接受。

实践中常用的优化手段有几种：

• 稀疏注意力：只计算局部窗口内的注意力，或者只让每个token关注固定数量的邻居。Swin Transformer的窗口注意力就是典型代表。
• 线性注意力：用核函数近似softmax注意力，将复杂度降到线性。但线性注意力在驾驶场景中的精度损失需要仔细评估。
• Token剪枝与合并：在推理时动态丢弃不重要的token，或者将相似的token合并。这在BEV特征上特别有效，因为BEV网格中大量区域是天空或远处背景。
• 量化与蒸馏：将FP32模型量化到INT8，或者用大模型蒸馏小模型。部署到车端芯片时这是必选项。

我在实际项目中的体会是，不要一开始就追求全端到端。先用小规模模型验证端到端规划是否比模块化规划有优势，确认后再逐步扩大模型规模和输入模态。否则很容易陷入“模型太大训不动、训动了跑不起来”的困境。

3. 从零搭建端到端驾驶模型的实操路径

3.1 数据管道的搭建：从原始日志到训练样本

端到端模型的数据管道比传统模块化系统复杂得多，因为输入是原始传感器数据，输出是连续控制量，中间没有人工标注的中间表示。一条完整的数据管道通常包括：

1. 原始数据采集：车辆上的摄像头、激光雷达、IMU、CAN总线数据同步录制。时间同步精度要求到毫秒级，否则输入和输出之间的对应关系会错位。
2. 数据清洗：剔除传感器故障、时间戳异常、驾驶行为异常的片段。驾驶行为异常包括急刹、急转、频繁变道等，这些片段如果混入训练集会让模型学到不安全的驾驶策略。
3. 场景挖掘：从海量数据中筛选出有价值的场景。比如交叉路口、行人横穿、施工区域等。常用的方法包括基于规则的筛选（如根据GPS判断是否在路口）和基于模型的筛选（如用聚类算法找出罕见场景）。
4. 样本构造：将连续驾驶片段切分成固定长度的样本。每个样本包含过去N帧的传感器数据和未来M帧的控制量。N和M的选择需要权衡：N太小模型看不到足够的历史上下文，N太大计算量爆炸；M太小模型学不到长时规划，M太大训练信号稀疏。
5. 数据增强：对图像做颜色抖动、裁剪、翻转，对控制量做相应的变换。注意翻转图像时方向盘转角要取反，否则模型会学到错误的对应关系。

提示：数据管道中最容易出问题的是时间同步。我见过多个项目因为摄像头和CAN总线之间有几十毫秒的固定延迟，导致模型学到的控制量总是“慢半拍”。建议在管道中加入时间对齐校验步骤，用互相关方法估计并补偿传感器间的延迟。

3.2 模型架构选型：BEV+Transformer还是纯视觉端到端

当前主流的端到端驾驶模型架构有两类：

BEV+Transformer方案：先用图像骨干网络提取特征，然后通过Transformer将多摄像头特征投影到统一的BEV（鸟瞰图）空间，再在BEV特征上做时序融合和规划。代表工作有BEVFormer、UniAD等。这种方案的优势是BEV空间天然适合做规划，不同传感器的特征在BEV空间中对齐后融合更自然。劣势是BEV投影本身是一个病态问题，深度估计误差会传播到下游。

纯视觉端到端方案：直接用Vision Transformer处理前视摄像头图像，输出控制量。代表工作有早期的NVIDIA Dave系列和后来的各种端到端模仿学习模型。这种方案的优势是结构简单、计算量小。劣势是缺乏空间理解能力，模型很难从2D图像中准确推断3D空间中的距离和速度。

我的建议是：如果传感器配置中有激光雷达，优先考虑BEV+Transformer方案，因为激光雷达提供的精确深度信息可以显著提升BEV投影质量。如果是纯视觉方案，那么需要在模型中显式加入深度估计辅助任务，否则模型很难学到准确的空间关系。

3.3 训练策略：模仿学习中的因果混淆与缓解手段

模仿学习的训练目标看似简单——最小化预测控制量和真实控制量之间的差距。但实际训练中会遇到几个典型问题：

问题一：模型学会“偷懒”。如果训练数据中大部分时间是直行，模型可能简单地学到“输出零转角”就能获得很低的平均损失。但在需要转弯的场景中，模型就会表现很差。缓解方法是使用加权损失，对转弯、加减速等非直行场景给予更高权重。

问题二：因果混淆。前面提到过，模型可能学到表面相关性而非真正的因果理解。一个有效的缓解手段是输入扰动：在训练时对输入图像加入噪声或遮挡，迫使模型依赖更鲁棒的特征。另一个手段是反事实数据增强：构造一些“如果当时驾驶员做了不同操作会怎样”的样本，让模型学习操作与场景之间的因果关系。

问题三：分布偏移。模型在训练集上表现很好，但在测试集上遇到未见过的场景时性能骤降。这是模仿学习的固有问题，因为模型只见过专家示范，没见过自己的错误如何恢复。缓解方法是DAgger（Dataset Aggregation）：让模型在仿真或封闭场地中运行，收集模型犯错时的数据，由人类驾驶员标注正确操作，然后加入训练集迭代训练。

3.4 评估与验证：离线指标与闭环测试的差距

端到端模型的评估是一个容易被低估的环节。离线指标如控制量的L1/L2误差、轨迹的ADE/FDE，只能反映模型在训练分布内的拟合程度，不能反映闭环驾驶性能。一个离线误差很小的模型，在闭环测试中可能因为微小的控制误差累积而偏离车道。

闭环测试通常分三步：

1. 仿真测试：在CARLA、LGSVL等仿真器中运行模型，评估碰撞率、车道保持率、完成率等指标。仿真的优势是可以大规模并行测试，劣势是sim-to-real差距。
2. 封闭场地测试：在测试场中运行真实车辆，评估模型在真实传感器噪声和车辆动力学下的表现。这一步通常会暴露仿真中看不到的问题，比如摄像头过曝、激光雷达反射异常等。
3. 开放道路测试：在真实交通中运行，评估模型与人类驾驶员的交互能力。这一步风险最高，需要严格的安全员接管机制。

我的经验是，离线指标和闭环性能之间的相关性很弱。不要因为离线损失降到了很低就认为模型可以上路了。闭环测试中暴露的问题往往和离线指标无关，比如模型对某个特定颜色的车辆反应异常、在特定光照条件下输出抖动等。

4. 端到端方案落地时绕不开的工程难题

4.1 车端推理的实时性约束与模型压缩

端到端模型要在车端实时运行，通常要求推理延迟在100毫秒以内，最好在50毫秒以内。这对模型大小和计算量提出了严格约束。一个在服务器上跑得很好的模型，直接部署到车端芯片上可能连10帧都跑不到。

模型压缩的常用手段包括：

• 剪枝：去掉网络中不重要的连接或通道。结构化剪枝（去掉整个通道）比非结构化剪枝（去掉单个权重）更适合硬件加速。
• 量化：将FP32权重和激活值量化到INT8甚至INT4。量化后模型大小减少4倍，推理速度提升2-3倍，但精度损失需要仔细评估。
• 知识蒸馏：用大模型（教师）指导小模型（学生）训练。学生模型可以小很多，但性能接近教师。
• 算子融合：将多个连续算子融合成一个，减少内存访问和kernel启动开销。这在Transformer模型中特别有效，因为注意力机制涉及大量小算子。

注意：模型压缩不是一次性的工作，而是需要和训练交替进行。通常的做法是：训练一个大的教师模型，然后蒸馏出小模型，再对小模型做量化和剪枝，最后在车端芯片上做算子融合和内存优化。每一步都可能需要重新微调。

4.2 安全冗余：端到端模型失效时谁来兜底

端到端模型本质上是一个黑盒，它的输出没有可解释的中间表示，也没有形式化验证的手段。这意味着不能把安全责任完全交给端到端模型。实践中需要设计多层冗余：

• 模型级冗余：同时运行两个独立训练的端到端模型，如果两者输出差异过大，触发降级。
• 规则级冗余：在端到端模型之外保留一套基于规则的保守控制器，当模型输出超出合理范围时接管。
• 硬件级冗余：独立的安全监控芯片，实时检查车辆状态和模型输出，发现异常时触发紧急制动。
• 远程接管：在L4级系统中，当车辆无法处理当前场景时，请求远程操作员接管。

这些冗余机制的设计需要在系统架构层面考虑，不能等到模型训练完再补。我见过一些团队先训模型再想安全冗余，结果发现模型输出频率和冗余系统的接口对不上，不得不重新设计架构。

4.3 数据闭环：从路测到模型迭代的完整链路

端到端模型的性能提升高度依赖数据闭环的效率。一个完整的数据闭环包括：

1. 路测数据采集：车辆在真实道路上运行，记录所有传感器数据和模型输出。
2. 异常检测：自动识别模型表现不佳的场景。常用的方法包括：模型输出与人类接管操作差异大、模型输出不确定性高、车辆动力学异常等。
3. 场景标注：对异常场景进行人工标注，确定正确的驾驶操作。
4. 模型再训练：将新标注的数据加入训练集，重新训练模型。
5. 回归测试：确保新模型在旧场景上不退化。
6. 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年甚至更久。中间会有很多次“看起来快成了”然后又发现新问题的循环。保持耐心，持续迭代，比追求短期突破更重要。

我在实际项目中最深的体会是：端到端模型的调试和传统软件调试完全不同。传统软件出问题可以定位到具体代码行，端到端模型出问题只能通过分析数据分布、可视化注意力图、做消融实验来逐步缩小范围。这个过程很磨人，但每次找到问题根源时的成就感也很强。如果你正在做端到端驾驶，欢迎交流踩坑经验。