解读有关『端到端自动驾驶』的概念混淆、谎言及“路线之争”

PH值

苏清涛 九章衡言管理咨询

6月中旬，九章智驾跟辰韬资本、南京大学上海校友会自动驾驶协会联合发布了《端到端自动驾驶行业研究报告》，这份报告在行业引起了很多强烈反响。随后的两个月里，在这份报告的基础之上，笔者对端到端自动驾驶这个话题又有一些新的观察与思考，于是撰写了文本，作为对此前报告的修正及补充。

本文涵盖的内容见下方思维导图——

注：

九章撰文历来坚持“非必要，不废话”这一基本原则——任何不具备稀缺性的知识或信息都视为“废话”，尽量不予采用。不过，为了保证上下文的连贯性，也考虑到不同读者对该话题所掌握的背景知识参差不齐，本文第一章对废话的包容度比较高；其后的每章，也都包含了不同程度的废话。

为避免浪费读者时间，笔者会在废话含量比较高的章节的开头做个简单的提示，敬请谅解。

1. 端到端的定义及分类

1.1 端到端的基本定义

1.1.1 感知信息的无损传递

在此前的报告中，我们提到，端到端的核心定义应为：感知信息无损传递、可以实现自动驾驶系统的全局优化。

这个全局优化是如何实现的呢？具体地说，端到端模型通过神经网络的链式法则，从输出端（规划）向输入端（感知）贯通，输出结果可以将误差依次反向传播给所有模块，以最小化整体损失函数为目标，更加准确地更新每个网络层中的参数，从而达到全局最优。

1.1.2 不包括控制算法

值得注意的是，目前产业里大部分公司谈的端到端主要是指“感知—预测—决策规划”的端到端，而不包括控制。

何小鹏在此前的端到端发布会后就曾表示：“没有任何人敢说端到端都是神经网络。它是在一个体系里面完成的，就像刹车在哪里，它一定是有规则体系的。我们在规则体系里面有一个优势，能够把刹车控制器的算法沙盒做好。

1.1.2.1 关于“输出控制”的误解

有不少媒体称特斯拉的端到端系统包括了控制模块，能够实现「输入视频 + 输出控制」，但这是以讹传讹。

不过，据汽车之心在7月份的《端到端自动驾驶：谁在 All in，谁在观望》一文报道，蔚来汽车计划把控制代码也模型化，并纳入到端到端系统；而理想智能驾驶技术研发负责人贾鹏泽表示未来将把端到端、VLM 这两个系统继续合并成一个系统，“力大了之后 VLM 能跑实时了，直接输出 action”。这个该如何理解呢？

蔚来和理想讲的“控制”和“action”，很有可能就是指“规划轨迹”。

智加首席科学家崔迪潇说：action这个词是存在歧义的。比如，有的语境下，它指的是“是否超车”这样的决策；而在有的语境下，它指的是“刹车量”、“转向角度”等控制指令。 崔迪潇这个解释，也解答了一个困惑笔者很久的问题——早在三四年前，笔者就发现，通常，自动驾驶行业里的许多技术专家口中的“规控”，仅指决策规划，并不包括控制。 这些专家们并不在意自己说的东西会让别人产生怎样的误解，会造成怎样的“以讹传讹”，所以，已经习惯了这种不严谨，但我们作为听众或读者，一定要对此保持高度警惕。

不过，也有一位资深专家称，理想方面说的“action”确实指的就是“控制指令”。

1.1.2.2 把控制算法做进端到端的尝试

在2017-2018年那个阶段，有一些公司做到的端到端确实是包含了控制的，但后来就都把控制排除在外了。原因主要有如下几点：

•大家逐渐明白，控制部分，不同车型的差异比较大，很难将其做成标准化的接口；

•控制算法，传统Tier 1们做的东西已经很成熟了，自动驾驶公司做也没啥优势；

•把控制模块也纳入到一个具有不可解释性的黑盒里，实际上是把简单问题复杂化。

不过，产业界并未彻底放弃将控制算法做到端到端里面的尝试。比如，某主机厂正在做的端到端模型，就可以输出控制量（比如，方向盘角度、加速度、刹车力度等）。

为什么要直接输出控制量呢？原因有三——

•相比于行为轨迹，控制量要更接近最终结果。

•直接输出控制量，有助于模型摸清车辆的动力学模型和控制执行器的性能极限。

•在生成控制量的时候，可以把车辆动力学的一些约束给加进去——比如，在时速 100 公里的情况下，方向盘的最大转角不能超过多少。这样，最终采出来的状态空间就一定是车辆可执行的。

不过，端到端模型输出的控制量并不直接交给下游的控制算法，而是用于对轨迹做一次积分。

为什么要对轨迹做积分呢？ 因为，轨迹有可能会抖、会跳，这样的轨迹输出是没法直接给到控制算法去执行的，需要做后处理才行，而积分积出来的轨迹是平滑的，这就减少了对轨迹做后处理的需求。（某无人驾驶公司的算法总监说：这种做法违背了端到端的初衷。）

不过，零一汽车CEO黄泽铧说：“卡车的方向盘转45度，跟乘用车的方向盘转45度，是完全不同的概念。”笔者由此推断出，哪怕同样是乘用车，小轿车的方向盘转45度，跟大型SUV、MPV的方向盘转45度，也是不同的概念。可见，直接输出控制量，会影响到端到端系统的跨车型泛化能力。

1.2 两个类型及代表玩家

根据我们之前的报告，端到端可分为模块化端到端及One Model端到端两个大类（分别对应上图中的第三行和第四行）。这两个类型的特点及代表性玩家如下——1.2.1 模块化端到端

本小节的内容，在我们之前的报告中已经出现过，所列举的例子，在各媒体的文章中也出现过不少，但为了文章结构的连续性，在这里还是做个简单的提炼。对相关内容已经比较熟悉的读者可直接跳过。

模块化的端到端模型并没有完全抛弃传统的自动驾驶技术栈，它仍然包含可见的感知和规控算法模块，但改变了子模块连接的方式——传统自动驾驶系统下，感知模块和规控模块靠规则（显式）来连接，但在模块化的端到端模型下，感知模块和规控模块是用神经网络（隐式）连接起来的。

在传统自动驾驶系统中，显式连接的方式无法完成梯度传导，只能靠人工优化（必须对感知模块和规控模块分开调优）；但在模块化的端到端模型中，隐式链接的方式保证了整体网络的一致性，因而能够完成梯度传导——只要后面的结果不好，就可以对前面几个模块都进行训练。

正是跨模块的梯度传导，保证了对端到端模型的所有训练都有助于最终达到全局优化的效果。

上海人工智能实验室、商汤、地平线等机构/公司在2023年合作发表的CVPR最佳论文中提到的UniAD,就是模块化端到端自动驾驶方案的典型代表。事实上，UniAD也成为了模块化端到端自动驾驶方案的基准范式。

此外，华为在2024年4月份发布的ADS 3.0（感知部分采用GOD的大感知网络，预测决策规划部分采用PDP），小鹏汽车在2024年5月份发布的端到端大模型（由感知大模型XNet+规控大模型XPlanner+大语言模型XBrain三部分组成）、及大疆车载于宝骏云海上首发搭载的端到端模型，也属于此类。

需要注意的是，笔者在很多媒体的报道中看到了“两段式”“一段式”的说法，但按照我们此前报告中的定义，无论两段式还是一段式，只要不支持全局反向传播、且同时有具体模块功能作用划分的，都不能算是“One Model端到端”，而顶多只能算是“模块化端到端”。

如理想的端到端“系统一”，官方的说法是One Model端到端，但由于中间输出了BEV特征，因而，若按我们在此前报告中的分类标准评判，则是模块化端到端。

1.2.2 One Model端到端

One Model端到端中不再有感知、决策规划等功能的明确划分，从原始信号输入到最终规划轨迹的输出直接采用同一个深度学习模型。One Model端到端可以是基于大语言模型，也可以通过世界模型衍生而来。

1.2.2.1 基于大语言模型的One Model端到端

大语言模型具有很强的通识能力，所谓基于大语言模型做端到端，即感知信息被传输给大语言模型，大语言模型对这些信息进行解码，然后输出轨迹。

基于大语言模型的One Model端到端，最具有代表性的是Wayve（LINGO2)、理想（系统二）与零一汽车（ZSD方案）三家的方案。Wayve与理想的端到端方案已在媒体公开文章中被报道过很多次了，在这里，我们主要简单介绍一下零一。

在5月中旬的发布会上，零一汽车发布了基于多模态大语言模型的端到端自动驾驶系统。官方称，整个系统使用摄像头和导航信息作为输入，经过多模态大语言模型的解码产生规控信号和逻辑推理信息，可将系统复杂度降低90%。
零一汽车规划在2025年开始测试One Model端到端系统，2026年开始在部分应用场景开始稳定运营，并实现常态无人化。

1.2.2.2 基于世界模型的One Model端到端

世界模型是系统根据海量数据对物理世界的重建，它具备理解周围环境以及交互情况，并对其他道路交通的参与者的行为做预测的能力。

最关键的是，理论上，世界模型可以像人类一样“认知”世界、“理解”世界构成以及元素之间的关联关系，它不仅能够基于感知获取的信息预测结果，更重要的是，可以对新的、没有见过的数据也能形成泛化的“理解”，也根据它对世界的“理解”，从而对未来做出预测。

因而，理论上，只要对世界模型进行微小的调整或者增加一些输出链路及模块，就可以实现One Model端到端自动驾驶。

走这种路线的代表性公司有Wayve（GAIA-1)、蔚来。

(图片摘自公众号“雪岭飞花”）

基于世界模型的One Model端到端有一个任务是“预测驾驶场景的像素变化”。这个难度极高的任务，会逼迫模型不仅仅学习优秀驾驶员的行为，还必须广泛地学习交通知识与物理常识。

而蔚来在NIO IN上提出来的是一个难上加难的“世界模型PLUS”，它的复杂度更高、输出维度更多，这意味着可以和真值比对形成的监督信号更多，加速神经网络的训练，同时也可降低系统运行的黑箱程度。

不过，目前来说，将世界模型应用于车端的设想，更多地还停留在学术讨论层面，离落地还有一些距离。原因主要有如下几点：

•车端算力不足。当前的车端算力尚无法支持大的世界模型运行，至于后续是否可通过蒸馏或者其他降秩的方式在保持对真实世界理解的能力下最大程度地裁剪模型，还需要等待端侧硬件算力的持续迭代。

•网络带宽不足。世界模型涉及到的数据量非常大，而当前的网络带宽尚无法满足大规模数据实时传输的需求。

•运行速度太慢。由于输出图像需要的token比较多，所以，世界模型的运行要速度要比大语言模型慢得多。

商汤绝影智能驾驶副总裁石建萍、辰韬资本执行总经理刘煜冬等多位受访者均认为，世界模型在自动驾驶场景的应用，目前应该还处于很早期的探索阶段。当前，比较可行的是，用它来合成一些端到端模型所需要的数据。

一个典型案例是，理想在此前的端到端发布会上，提到了世界模型，但世界模型并不是直接用来做端到端方案的，而是作为闭环仿真工具的一部分提供合成数据。

此外，作为对世界模型在自动驾驶场景中的应用探索最早的公司之一，Wayve的第一个端到端模型GAIA-1是基于世界模型的，但第二代端到端模型LINGO-2则基于大语言模型，这也从侧面印证了将世界模型应用于One Model端到端还需要一段时间。

2. 端到端可降低自动驾驶系统的开发及维护成本

端到端对自动驾驶产品体验带来的提升，各路文章已经介绍得比较多了，本文就不再赘述。接下来的两章，我们主要梳理一下它对自动驾驶的研发工作带来的益处。 这种益处，可分为降本和增效两个方面。

2.1 降低了系统的复杂度

传统的感知-融合-预测-决策-规划架构可能涉及到十几个子系统和更多的软件模块，而端到端则可以将与之相关的子系统缩减为一个。由于模块数量大幅度减少，所以，系统设计的复杂度也大幅度减少了。

这一点是显而易见的，因此，无需赘述。

2.2 降低组织的内耗成本

本小节的内容，在之前的报告中已经出现过，已经看过报告的读者可以略过。

2.1里面提到，从模块化转向端到端，系统的复杂性大幅度降低。而子系统简化意味着研发团队的分工简化，进而可以减少部门墙对组织效率的影响。

很多时候，自动驾驶测试中遇到的问题，很难准确界定属于感知部门还是决策规划部门，也许无论哪个子系统的优化都可以解决这个问题，因而，在实际工作中这两个部门的接口也是最容易遇到责权不清的问题，这就间接地增加了系统工程、各个算法方向上的人力投入。而端到端的核心技术原理是全局统一优化，这同时也意味着组织目标的统一对齐。

2.3 减少了对数据标注的需求

5月中旬，零一汽车在发布会上提到，在采用端到端方案后，数据标注需求减少了90%。由于此前对这个话题关注不多，因此，对这个说法，笔者当时是相当惊讶，甚至是高度怀疑。这是真的吗？

随后，带着质疑与好奇，笔者向辰韬资本执行总经理刘煜冬等多位资深业内人士请教，在经过多个回合的交流后，最终梳理出的答案是：

从下图中的决策规划模型化阶段到模块化端到端阶段，再到One Model端到端阶段，模型训练对数据标注的需求依次降低。

•在模块化自动驾驶技术（上图中的阶段一、阶段二）中，由于感知模块跟规控模块之间是通过人为定义的规则连接，工程师们在做训练的时候，需要先让决策规划模块知道，感知模块看到的东西究竟是什么，所以，对感知的标注必不可少。

•在模块化的端到端（上图中的阶段三），每一个模块还是要先做一遍传统的训练，然后再合到一起做训练，因此，跟传统的自动驾驶算法训练一样，标注仍然是必不可少的（隐式表达特征这里需要标注）。只不过，由于感知和决策规划是连在一起的，在遇到问题后，系统可以通过被标注的决策规划数据来“反推”感知遇到了什么问题，所以，与阶段二相比，阶段三对感知数据的标注需求会有所下降。

•而在One Model端到端（上图中的阶段四）技术中，系统在输入感知信息后就直接输出了规划轨迹，不需要系统告诉“行人在哪里”、不需要做语义分割 ，所以，在理想的情况下，感知数据是一点儿标注都不需要。在这个阶段，面向感知的标注需求将会转向面向规划的标注需求。当然，规划的标注不涉及太多细节，就比感知的标注简单得多了。

尽管在理论上，One Model端到端的训练是不需要标注的，但在实践中，为了让模型能更快地收敛，同时确保其能真正理解那些它应该关注的目标，很多人会在模型中加入一些约束项（比如障碍物信息），让中间结果可视化。这些信息，是需要标注的。

对此，智加首席科学家崔迪潇说：

有些人说我在训练的时候，除了轨迹，我就不需要监督项，这种对训练和数据的要求是最简单的，但这里面的难点就是模型设计上，在不需要这些监督时，也能定义和寻找到驾驶任务中重要的信息。

许多公司都用到了多模态大语言模型的，会涉及到对一些信息的的处理，如果希望实现更强的交互能力，就还需要对这些信息做标注。

但无论如何，相比于原来的BEV那套东西来说，标注的内容已经简单得多了，工作量也大幅度下降了。

2.4 降低了代码管理工作的难度，并有可能降低人员离职带来的不利影响

在规则时代，代码管理的工作量特别大，而这块出的问题又特别多。

同一个公司内部的代码 ，不同Leader 的管理风格是不一样的，这导致有些模块的代码就很干净，而有些模块的就简直是“屎上雕花”（工程师语）。

并且，由于大部分的代码注释都写得不怎么样，因而，在写代码的人离职之后，后面再加入的人经常看不懂前面的人写的代码，甚至不明白当初写的规则是为了解决什么问题。因而，在工程师离职之后，很多研发成果就没有了。

尤其值得注意的是，哪怕离职的工程师并非团队的骨干成员，后续的研发工作也会受到很大的影响。

自动驾驶公司在上了端到端系统之后，代码量有望大幅度减少，那么，在训练框架完成之后，普通工程师的离职对研发工作带来的不利影响有没有可能被削弱？

多位受访者都认为，相比于之前的模块化方案，端到端确实更容易降低普通工程师离职对研发带来的不利影响。当然，这一效应要等研发体系收敛之后才更容易体现出来。

崔迪潇认为，在研发体系收敛之前，尽管上车的代码量减少了，但线下（模型的外围工作）的代码量是增加了；这个时候，普通工程师的离职对研发的影响也不小。而在研发体系收敛之后，代码量就很少了，这个时候，普通工程的离职就对研发没多大影响了。

【崔迪潇对“研发体系收敛”的定义：不仅包括设计、实施、应用，还要将应用中出现的问题，通过该套研发体系进行几轮的迭代、优化，发现和缓解了体系中的堵点和瓶颈。】