我最近被问到最多的一个问题就是端到端算法到底行不行问的人里有做感知的、做规划的也有产品经理和投资人。每次聊到一半就会发现大家说的“端到端”根本不是同一个东西。这篇文章不打算复述某篇论文也不是给某个方案站台而是从工程师视角把自动驾驶中端到端算法涉及的几个关键问题拆开聊一遍它到底在解决什么问题、为什么让模块化架构的拥护者感到不安、量产落地时卡点在哪、做测试和评价的人又该怎么接招。如果你是正在选技术路线的团队负责人或者刚转入自动驾驶方向、想搞清楚端到端算法和传统方案差别的同学这篇文章应该能帮你节省不少时间。我尽量用讲人话的方式把其中的工程逻辑说清楚也会把我在实际项目中遇到的一些坑和判断依据交代出来。1. 这一轮“端到端热”到底在热什么1.1 先搞清楚大家说的不是同一个东西端到端这三个字被用得太宽了。严格从输入输出看端到端算法指的是把传感器原始数据摄像头图像、激光雷达点云、毫米波雷达目标直接丢进一个神经网络网络直接输出规划轨迹甚至方向盘转角、油门刹车开度。中间没有显式的障碍物框、没有车道线矢量、没有人工定义的驾驶策略模块。但真正大范围落地的自动驾驶系统几乎没有人敢这么干。现在大家嘴里的“端到端”至少在三个层面被混着用第一类是完全端到端图像进、控制指令出Wayve早期的原型车、NVIDIA Dave-2这类属于典型的探索案例更像学术实验和概念验证。第二类是分模块端到端感知、预测、规划全部做成可微网络联合训练、共享特征但中间仍然有结构化的隐式表示UniAD这类工作就是代表。第三类严格说只是感知端到端用一个大网络把感知和预测吃掉输出给后端的规则规划器很多量产车上的“端到端感知”其实属于这一类。这三类的数据需求、调试难度、安全边界完全不在一个量级。很多争论之所以没有结论是因为大家在用完全端到端的标准要求分模块端到端或者用分模块端到端的可解释性去否定完全端到端。讨论自动驾驶中的端到端算法第一步不是选模型结构而是先定义清楚你在哪一层做端到端。1.2 为什么偏偏是这个时间点火起来端到端的概念十多年前就有NVIDIA在2016年就做过图像直接映射方向盘角度的Demo当时的效果只能算实验室玩具。现在这轮热度能起来本质是三个条件同时到位了。第一个条件是Transformer架构把多模态融合问题简化了。摄像头图像、激光雷达点云、毫米波雷达目标过去要用不同头部分别提特征再手工对齐现在可以用统一编码器处理端到端的梯度可以从最终控制误差一路回传到所有传感器分支。第二个条件是数据积累到了临界量头部自动驾驶公司累计路测里程足够支撑数据闭环的冷启动。第三个条件是算力门槛降低了无论是车端Orin/Thor这一代芯片还是云端大规模训练集群都能支撑上亿参数模型的训练和实时推理。所以与其说是端到端算法横空出世不如说是数据、算力、模型结构三者同时成熟把“从原始数据学驾驶策略”这件事从不可用推到了可工程化。但也正因为它是被这三块同时推起来的落地时每一个短板都会变成瓶颈后面几章我会逐个展开。2. 信息瓶颈理论为什么模块化架构让位给端到端2.1 经典模块化流水线的“信息衰减”问题传统自动驾驶架构是清晰的流水线感知模块输出障碍物框、车道线、红绿灯状态预测模块基于这些低维输入预测目标轨迹规划模块在预测结果之上搜索或优化出一条安全路径最后控制模块跟踪。这套架构的优势是每个模块职责清晰哪个环节出问题可以单独定位。但它的代价是信息在模块间传递时被不断降维。感知模块输出一个“框”的时候框里面到底是什么形状的物体、表面材质是软的还是硬的、有没有被遮挡一半这些细节全部丢掉了。预测模块拿到的是一串检测框的历史轨迹它对目标的建筑学结构、交互意图的理解完全依赖感知模块的“转述”。举一个我在测试中真实遇到的例子一辆半挂车横在路口感知模块把它识别为了“卡车”由于横置姿态输出框的宽高比和普通卡车完全不同后端的预测模块按照“卡车直行”的模型给出了一条高速直行轨迹规划模块在这个轨迹上叠加了车道保持约束结果生成了拿不准的驾驶行为。但实际上如果能看到原始图像人很容易判断这是一辆正在右转等待让行的半挂车——它的车头朝向、车轮角度都写在像素里只是这些信息早就被“框”过滤掉了。这就是信息瓶颈的本质每个模块的输出只是对原始数据的一次有损压缩串行压缩的次数越多丢失的信息越不可恢复。端到端算法的核心动机就是让决策模块能够直接访问原始传感器数据而不是只能访问感知模块筛选后的“摘要”。2.2 可微全链路带来的范式变化分模块端到端和完全端到端虽然形式不同但它们共享同一个关键设计感知特征、预测概率、规划轨迹全部在同一个计算图里损失函数可以直接从最终驾驶行为反向传播到最底层的像素和点云特征。这意味着什么呢传统模块化训练中感知模块的优化目标是“框得准”评价指标是mAP预测模块的优化目标是“轨迹预测误差小”评价指标是ADE/FDE。这些目标单独看都没问题但合在一起不一定能导出最优的驾驶决策。感知模块可能为了框得准而输出大量低置信度目标预测模块为了误差小而给出平滑但不保守的轨迹规划模块拿到这些结果后只能被动接受。端到端架构里感知特征好不好不看它是否拟合了某个标注框而看它能否帮助规划模块做出安全高效的轨迹。网络内部会自动学会为真正影响决策的语义信息分配特征容量例如自发加大对目标朝向、相对速度、交互意图的编码权重同时压缩对驾驶决策无关的背景纹理的关注。这是“感知为决策服务”的真正落地也是端到端算法和旧架构最本质的差别。2.3 让位不等于全盘替换说了端到端这么多优势我也要说清楚它付出的代价。可解释性下降是最直观的问题传统规划器给出某条轨迹时工程师可以逐条追踪约束条件端到端网络给出轨迹时你只能看到一堆注意力热力图。安全证明更难了模块化架构可以用形式化方法证明“在所有检测到障碍物的场景下不碰撞”端到端网络很难给出这种数学保证。所以行业内真正理性的态度不是把所有模块都替换成端到端而是把端到端用在高价值、难建模的环节把安全兜底留给可验证的规则层。这也是我在后面讲量产方案时反复强调的一个观点端到端让车开得“像人”规则层保证车“不出事”。3. 数据闭环才是端到端算法的胜负手3.1 影子模式端到端训练数据从哪来传统模块化模型训练依赖人工标注的感知真值、有人工规则定义的驾驶策略数据量要求相对可控。端到端算法要学的是“人类驾驶行为”数据不再只是标注框和车道线而是原始传感器数据加上人类驾驶时的真实控制指令。这种数据的规模需求比传统方案高不止一个数量级。数据从哪里来量产车回传是最主流的答案背后的机制是影子模式。车辆正常行驶时端到端模型在后台并行运行持续输出“如果让我开、我会怎么开”的动作指令但它不执行执行的是人类驾驶员的操作或者规则规划器的输出。系统实时计算模型输出和驾驶员实际操作的差异只有差异足够大的片段才回传云端。这个设计的意义在于正常驾驶中绝大多数时间模型输出和驾驶员行为高度一致这些数据对模型提升几乎没有价值。真正有价值的是模型犯错的瞬间驾驶员猛打了一把方向、突然重踩刹车、加速绕过一个模型没有识别的障碍物这些都是“模型以为可以、人类认为不行”的宝贵难例。数据闭环的第一步不是堆数据量而是设计一套能够高效筛选难例的回传机制。3.2 标注、合成数据与World Model的边界传统感知标注是框、是线、是语义分割掩膜端到端需要的是“场景级真值”包括精准的各物体运动状态、道路拓扑、交互关系还有最重要的驾驶行为真值——人类在该场景下踩下每一脚刹车和油门的理由。人工标注这类超大规模场景数据根本不现实业界主流做法是“自动标注人工抽检”用高精度重建模型在离线环境重建场景自动生成动态目标的三维轨迹和朝向再结合高清地图生成道路拓扑真值。对端到端来说数据量虽然重要数据分布更重要。如果只在某个城市的固定道路上采集模型很容易过拟合到特定的路况节奏和驾驶风格。这就需要场景挖掘和仿真生成补盲区。合成数据和World Model世界模型这两年被反复提及核心思路是用生成模型补充数据分布中稀疏但极端危险的场景例如前车急刹、行人不规则横穿、施工区域变化。但要清醒认识到生成数据的价值有一个看不见的天花板如果生成器本身没有见过某类场景的物理规律它生成的训练数据不仅无效还会污染模型。我见过团队为了凑训练量用仿真器生成了大量穿模、物理不合理的场景丢进去训练后实车反而在正常场景上出现了原本没有的误判。合成数据和真实数据的比例、清洗策略需要作为一项严肃的工程任务来管理而不是无脑灌入训练集。3.3 闭环训练平台从数据回传到模型迭代的飞轮单次数据采集和标注只是一次性投入真正拉开差距的是持续迭代的飞轮速度。一个完整的闭环训练平台至少要包含五个环节数据采集层量产车队和测试车队持续回传原始数据和影子模式差异记录。难例挖掘层离线自动筛查高价值数据按风险等级、场景类别、分布稀疏度排序。标注生成层以自动标注为主、人工修正为辅形成训练集。训练评测层增量训练、模型回放验证、离线场景库回归。在线验证层小规模车队试运行、真实路测闭环采集新的难例回到第一环。这五个环节每个做起来都不轻松。难例挖掘如果优先度排序不对训练资源会被大量低价值数据浪费训练评测层如果没有历史场景回归机制模型可能在新增能力的同时遗忘掉旧场景的驾驶策略。这两条是我在项目里踩过最深的坑也是我认为端到端算法项目真正的工作量所在。4. 仿真测试与安全评价ISO 34505背后的工程挑战4.1 传统路测指标在端到端模型前失效了自动驾驶的测试评价过去主要依赖两个宏观指标接管率和MPI平均接管里程。端到端模型上线后这两个指标的局限性会被急剧放大。高速公路为主的测试路线MPI很容易做到几百公里一次接管但完全证明不了复杂城区工况的能力。不同驾驶员风格对“接管”的定义也完全不同有人看到模型犹豫就接管有人愿意多等两秒同一模型的MPI能差出一个数量级。更关键的是接管率和MPI都是结果指标它们回答了“系统是否让人类不安”却回答不了“系统为什么不安全”。端到端模型是一个黑盒如果没有场景级的评测体系工程师面对一次接管根本不知道是感知误判、行为决策失误还是控制振荡也就无法指导下一步迭代方向。2025年发布的ISO 34505标准把注意力正式拉到了“自动驾驶测试场景评价与用例测试生成”上这正好命中了端到端模型的评测痛点。4.2 场景抽象与用例生成从功能场景到具体场景ISO 34505的思路是把测试从“跑里程”变成“跑场景”。场景本身是有层级之分的功能场景是语义层面的描述比如“自车在双车道城市道路直行左前方车辆切入”逻辑场景在功能场景基础上添加参数范围比如前车切入时的相对速度范围、切入角度范围具体场景则是从逻辑场景中采样出的一组精确参数能直接转换成仿真器或实车测试的输入。测试用例生成的核心是怎么从巨大的参数组合空间里挑出值得跑的少量场景。完全遍历不可能随机采样效率低工程上常用三类方法基于组合测试的覆盖表设计把参数取值的两两组合覆盖住基于搜索算法的边界挖掘用NSGA-II这类多目标优化算法去搜索让系统失效的极端参数组合基于生成式交通流的交互场景构造让交通参与者行为连续变化、逼迫模型暴露问题。我和团队在实际建设场景库时的体会是场景库不是越炫越好而是必须能回答“模型在哪些场景失败、失败模式聚类是什么”。准备一张“功能场景清单”再为每个功能场景生成逻辑参数空间然后通过评估跑出的失败案例反向补充场景库覆盖这套方法论比盲目堆仿真里程要有效得多。4.3 我在评测端到端模型时使用的四维评估框架端到端模型表现很难用一个分数概括。我做评估时习惯把指标拆成四个维度每一维都对应一套可测量的子指标场景理解一致性模型对道路环境要素的感知是否与实际一致可评估为模型内部注意力是否聚焦在真正影响驾驶的要素上对比不同模型在同一场景下的感知特征。行为决策合理性变道时机、让行逻辑、目标车道速度匹配程度通过人工评价结合安全规则检查共同判定避免完全主观评审。安全边界保持最小离路沿距离、碰撞时间TTC、紧急制动触发率这些指标需要在线搜集离线回放时必须保留原始传感器数据。乘员舒适度纵向加速度、横向冲击度、方向盘平滑性端到端模型容易在决策边界附近产生高频调整必须专门监测。这个框架里没有一个指标能单独成为“通过/不通过”的金标准但四个维度放在一起能比较快地定位到一次失败到底是感知理解的问题、决策策略的问题还是控制平滑度的问题。对端到端这样难以解释的模型快速定位问题域比得到一个精确的综合评分更有价值。5. 量产路上的务实选择混合架构与算力约束5.1 车端算力墙大模型的推理代价算法设计得再漂亮量产时首先面对的是车端算力墙。一个为端到端设计的感知模型动辄数十亿参数直接跑在量产芯片上根本不现实。Orin 254TOPS的算力听起来充裕但还要同时跑安全感知、融合定位、车身控制留给端到端模型的算力预算通常只有几十TOPS。Thor这一代芯片虽然算力大幅提升但功耗和散热的约束依然存在。为了把大模型塞进量产盒子里量化、剪枝、蒸馏、稀疏化是标准四件套。我见过团队把FP32模型量化到INT8精度损失只有不到一个百分点策划也对齐顺利但在高温、低照度、摄像头进灰这些边缘工况下量化误差会被放大成危险行为。量化的收益巨大代价则是可迁移性差——在A芯片上量化调通的模型换到B芯片上可能表现完全不同。所以量产项目建议提前算清楚一笔账目标场景的驾驶复杂度需要多少模型容量车端芯片能提供多少有效算力两者之间如果要靠量化补补多少是安全的边界。这个问题拖到项目后期再评估往往会发现只能砍掉大量功能需求。5.2 端到端规则兜底当前最稳妥的落地形态从我对量产项目的观察来看纯端到端直接取代全部自动驾驶栈在短期内既不可靠也不经济。更现实的方案是端到端负责“像人一样开”规则层负责“绝对不能出事”。学术界和产业界讨论端到端时最大的分歧之一是可解释性。汽车行业的安全验证逻辑天然要求每个风险点可追溯一个全黑盒系统很难通过传统安全评估。混合架构的巧妙之处在于它保留了端到端的行为上限又给安全留下了一个可验证的兜底。我在多个项目里建议团队采用这种架构理由有三条一是它能在保留端到端行为上限的同时给安全验证一个明确的“停止线”二是可以在收集足够多数据、模型足够稳定之后逐步放宽规则限制给端到端更大的决策空间三是从组织协作角度看规则层的存在能保护传统规划团队的知识积累避免他们一上来就失去抓手。5.3 团队协作和工程节奏组织决定技术能走多远端到端项目对团队的组织方式提出了新要求。传统架构下的团队是串行协作的感知组交付感知结果规划组基于感知结果做轨迹两边只要接好接口就行。端到端模式下感知、预测、规划所有人都面对同一个网络和同一套失败场景联合调试成了常态。这种变化带来了极大的效率提升空间也带来了极高的管理复杂度。我见过刚转向端到端的团队第一周就在为“性能不达标应该归因于谁”吵架。要避免这种内耗建议从一开始就建立起“模型回放会”制度每周固定时间把新训练的模型放到过去三个月的难例场景库上跑一遍让团队所有人亲眼看到模型在哪变了、在哪退化了。很多争议在事实面前会自然消解剩下的问题才是真要投入资源解决的问题。6. 我对端到端路线的一些判断和参考建议6.1 端到端算法解决了什么问题又夸大激进了什么回到最初的问题端到端算法到底行不行我的判断是它解决了真实存在的问题——传统模块化架构的信息瓶颈和规则穷举困境这是不争的事实。但它也被资本和媒体放大到了过高的期待仿佛只要端到端上车自动驾驶就能瞬间跨越到完全无人驾驶。事实是端到端让系统的行为上限显著提高了但它的下限稳定性反而更依赖数据和测试体系。一个常被忽略的真相是端到端模型的能力上限由模型结构决定能力下限则由数据闭环和评测体系决定。模型结构再先进如果数据挖掘链路不完整、评测维度不全面量产时暴露的问题会比传统模块化架构更多。反过来数据和评测体系扎实的团队即使用相对保守的分模块端到端架构也能做出现阶段体验和安全兼顾的产品。6.2 给不同角色的从业者几句实在话如果你刚进入这个方向不建议一上来就追完全端到端。先把感知端到端、分模块端到端的原理和工程框架吃透理解清楚端到端的梯度回传到底解决了什么再做完全端到端的研究也不迟。面试和项目汇报时能讲清楚数据闭环的链路比会背某个模型结构重要得多。如果你是在做测试和验证的工程师建议尽快把场景化测试方法论建立起来。ISO 34505已经把场景评价和用例测试生成的框架摆出来了与其被动等着监管要求不如先主动在团队内部建场景库。未来端到端模型的可信度很大程度上取决于测试场景覆盖的深度和广度。如果你是技术决策者我建议不要迷信“端到端碾压传统”这种叙事。务实的态度应该是评估自身的数据资产、算力储备和车端部署条件再决定在哪一层引入端到端。先跑通影子模式建立难例回传链路再逐步扩大端到端的决策范围这条路径的容错率要远高于一步到位的完全端到端。6.3 未来的竞争在于数据运营效率端到端算法本身的结构创新红利正在被快速摊薄。各家的模型结构差距会越来越小真正的分水岭会在数据运营效率上拉开谁能更快收集到高质量难例谁能更快完成场景回流和模型迭代谁能在同等算力下训练出更稳健的模型谁就能在量产落地中占得先机。我个人的体会是端到端项目对团队的考验从一开始就不是“能不能训出一个漂亮的模型”而是“当模型在实车测试中暴露出问题时你的团队能不能用最短的时间找到原因、补上数据、重新验证、再次交付”。这条链路跑得顺的团队即便模型结构不是最新的体验也会持续稳定向上跑不顺的团队就算模型结构再先进也会在那些不断重复出现的长尾场景里被耗死。