自动驾驶革命：解密端到端背后的数据、算力和AI奇迹_风闻

作者 | 毫末智行数据智能科学家 贺翔

编辑 | 祥威

无人驾驶「全村的希望」

编者注：

本文是HiEV出品的「端到端」自动驾驶技术解读系列的第二篇，继该系列首篇文章《特斯拉掀起「端到端」风暴，自动驾驶持续开卷》后，本文从实际应用的角度，剖析实现端到端的挑战和应对策略。关于端到端的更多内容，欢迎添加微信号Yuting199701发送「端到端」加入交流群。

最近，特斯拉FSD V12的发布引发了业界对端到端自动驾驶的热议，业界纷纷猜测FSD V12的强大能力是如何训练出来的。从马斯克的测试视频可以大致归纳一下FSD V12系统的一些核心特征：

训练数据：1000万段、分布多样、高质量的视频，数据的采集、筛选、质量、分布是系统成功的重中之重

训练方式：采用端到端训练，不再有感知、规控等模块

车端代码：V11有30万行代码来处理各类场景，而V12则非常简单，不再针对任何场景定制策略，完全依靠数据编程

运行效率：50帧/秒，效率极高

这些特征如此炫酷，引领着自动驾驶技术风向。那么究竟什么是端到端自动驾驶，如何实现端到端自动驾驶呢？笔者作为自动驾驶领域的从业人员，将从实战应用的角度出发，探讨端到端如何落地。

自动驾驶的传统做法

从第一性原理来讲，自动驾驶就是一个序列到序列的映射过程，输入的是一个传感器信号序列，可能包括多个摄像头采集到的视频、Lidar采集到的点云、以及GPS、IMU等各类信息，输出的是一个驾驶决策序列，例如可以是驾驶动作序列、也可以输出轨迹序列再转为操作动作。

这个过程与大部分AI任务基本一致，这种映射过程就相当于一个函数 y = f(x)。但是实现这种函数往往难度比较大、任务极其复杂，对于这种复杂的任务，一般可以通过2类方式来解决：

分治法：将复杂任务分解成多个子任务，逐个解决，再组合起来，相当于 y = f(x)*g(x)…

端到端：直接寻找一个函数实现y = f(x)

传统分治法

分治法是将自动驾驶任务进行切分，定义多个子任务，每个子任务负责解决驾驶过程的某些特定问题，再进行系统集成来完成整个自动驾驶任务。传统上，这些子任务包括：

地图/定位：自动驾驶的汽车需要知道驾驶环境的地图，其包含的信息一般比我们日常使用的导航地图要多，例如车道数量、车端边界、道路曲率、交通路牌、交通信号灯、停止线、道路拓扑等信息。当前，有些公司采用厘米级高清地图，也有些公司采用更加轻量级的地图，也有很多公司提出了无图方案。然后，自动驾驶的汽车需要准确地知道其自身的位置和方向。传统上有使用全球定位系统(GPS)、惯性测量单元(IMU)的方式，也有结合感知技术，进行图片、Lidar点云匹配的方式来估计自身位置。

感知/预测：自动驾驶的汽车需要看懂周围的驾驶环境，感知任务负责识别障碍物、车道线、红绿灯等关键的交通元素。尤其对于动态障碍物，除了需要实时监控并跟踪其位置，还需要对其未来变化做出预测，这与人类驾驶汽车是一样的，需要对未来趋势做一个预判，才能采取正确的驾驶决策。这对于在下游任务的预测至关重要。

规划/决策：自动驾驶的汽车需要结合定位、感知、预测的结果，来规划未来的行驶路径，从而避开障碍物保证安全。规划过程需要考虑体感、安全、效率等各种维度的因素。传统的自动驾驶方案一般通过分场景的方式，来定制不同的驾驶决策，将复杂的世界抽象为少数几类典型场景，不同的场景采取不同的驾驶决策。

控制：最终，我们需要将驾驶决策转为车辆特定的动作来操控车辆。

以百度的apollo为例，整体系统架构如图所示，可见，要完成复杂的自动驾驶任务，需要先完成大量相对简单的子任务，这些子任务可以先进行独立开发测试，然后再将这些子任务集成到一个系统里进行验证。这种方式通过把复杂的任务切分、简化、分而治之，大幅度降低了系统开发难度，同时可以针对每个模块都的输入输出进行白盒化分析，系统具备很好的可解释性，这对自动驾驶而言至关重要，一旦发生事故，必须要进行深入分析，找到原因。

但是，这种方式也有明显的弊端，例如模块太多、集成困难、错误累加等等，同时由于系统设计时引入了太多的人为先验经验，导致自动驾驶能力上限比较低，系统的泛化性比较差，对于没有见过的场景往往无法处理。

「端到端」技术兴起

相比之下**，端到端自动驾驶不进行任务切分，希望直接输入传感器数据、输出驾驶决策（动作或者轨迹），从而抛弃传统自动驾驶里的感知、预测、规划、控制等各类子任务**。这种方式有明显的优势，例如：

效果上：不但系统更简单，还能实现全局最优。

效率上：由于任务更少、避免了大量重复处理，可以提高计算效率。

数据收益：不需要大量的人工策略、只需要采集足够多的优质驾驶数据来训练即可，可以通过规模化的方式（不断扩展数据）来不断提升系统的能力上限。

一个典型的端到端自动驾驶系统如图所示：

输入：大部分自动驾驶汽车都装载了相机、Lidar、毫米波雷达等各类传感器，采集这些传感器的数据，输入深度学习系统即可。

输出: 可以直接输出转向角、油门、刹车等控制信号，也可以先输出轨迹再结合不同的车辆动力学模型，将轨迹转为转向角、油门、刹车等控制信号。

可见，端到端自动驾驶系统就像人类的大脑，通过眼睛、耳朵等传感器接受信息，经过大脑处理后，下达指令给手脚执行命令，整个系统简单的都没啥可介绍的……。但是这种简单也隐藏了巨大的风险，例如可解释性很差，无法像传统自动驾驶任务一样将中间结果拿出来进行分析；对数据的要求非常高，需要高质量的、分布多样的、海量的训练数据，否则AI就会实现垃圾进垃圾出。

与传统的自动驾驶方式对比可见，同样的输入、同样的输出，传统自动驾驶包含多个任务（多个模块），但是端到端只有一个任务。此处容易产生一个误区，即认为传统的自动驾驶是多模块的、端到端自动驾驶是单模块的，把分模块与分任务的概念搞混了。

传统的自动驾驶是分任务的，必然是多个模块。端到端自动驾驶可以用单模块来实现，当然也可以用多模块来实现，其区别在于是否端到端训练。分任务系统是每个任务独立训练、独立优化、独立测评的，而端到端系统是把所有模块看成一个整体进行端到端训练、端到端测评的。

例如2023年CVPR best paper提出的UniAD就是一种分模块端到端训练方式，这种方式通过端到端训练避免了多任务训练的融合难题实现全局最优，又保留了分模块系统的优势、可以抛出中间模块的结果进行白盒化分析，反而更具灵活性对部署也更友好，如图所示：

分任务的自动驾驶系统更像model centric系统，开发者通过不断优化各个模型来提升各个任务的效果。而端到端自动驾驶则更像data centric系统，通过对数据的调优来提升系统效果。

早年，由于自动驾驶积累的数据还非常少，端到端系统的效果往往比较差。最近几年，随着带高阶辅助驾驶功能的量产车大规模落地，通过海量量产车可以采集到丰富的驾驶数据，覆盖各类场景，再加上最近几年AI算力的蓬勃发展，端到端自动驾驶在海量数据、海量算力的加持下，取得了突破性进展。

以特斯拉为例，通过遍布全球的几百万辆量产车，可以采集到足够丰富、足够多样的数据，再从中选出优质数据，在云端使用数万张GPU、以及自研的DOJO进行训练和验证，使得端到端自动驾驶能够从paper变成product。

到 2023 年初，特斯拉就声称已经分析了从特斯拉客户的汽车中收集的 1000 万个视频片段（clips），特斯拉判断完成一个端到端自动驾驶的训练至少需要100万个、分布多样、高质量的clips才能正常工作。

特斯拉通过分布在全球的几百万量产车，基于影子模式，每当自动驾驶决策与人类司机不一致时，就会采集并回传一个clip，已经累积了200P以上的数据，不管是数据规模、数据分布还是数据质量上都遥遥领先。为了能在云端处理这些数据，当前特斯拉拥有近10万张A100，位居全球top5，预计到今年底会拥有100EFlops的算力，并针对自动驾驶自研了Dojo，在算力上同样遥遥领先。

在2022年，毫末智行也开始了对端到端自动驾驶以及自动驾驶大模型的探索，走过了一条从看图说话到完型填空到写小作文的道路。

最早，毫末将端到端自动驾驶简单地定义为一个看图说话任务，希望输入一串图片、输出一串驾驶决策，这种方式与机器翻译输入一串中文输出一串英文非常类似，所以可以选择端到端的序列模型，通过对输入图片进行编码，再解码输出驾驶决策。

但是训练之后，发现难以找到足够的数据来训练模型，因为手里采集到的数据绝大部分驾驶行为都是雷同的，例如大部分都是直行，能用的数据不到2%。虽然项目效果未达预期，但是训练过程发现端到端训练需要消耗大量的算力，于是又开始着手解决算力问题，并且在2022年底跟火山引擎合作落地了业界领先的智算中心，等2023年大模型爆发再加上美国的制裁，算力市场已经一卡难求了，这也算一个意外收获。

端到端自动驾驶的挑战

从特斯拉的开发经验来看，端到端自动驾驶真不是一般的企业能玩的，其所需的数据规模、算力规模远远超出国内企业的承受能力。除了成本高昂，端到端自动驾驶的技术难度也非常高，想要从实现从paper到product落地，相当于跨越从二踢脚到登月的难度。

数据难题

端到端训练首先需要解决数据问题。早年自动驾驶企业大多依赖采集车采集数据，这种数据是不真实的、分布有偏的、低质量的，只能做个demo，难以进行大规模端到端训练。最近几年，随着量产车的规模化落地，业界很多公司都开始转向采用量产车通过影子模式采集数据，但这种模式依然面临艰巨的挑战。首先是采集策略问题，即如何平衡数据的长尾问题（有效性）和数据的规模问题（成本），如果采集策略比较宽松，我们往往发现采集回来的数据大部分是垃圾数据，根本没有使用价值，如果采集策略过于严格，又担心丢失大量有价值的数据。其次是数据的质量问题，如何定义数据质量是个艰巨的产品问题，如何精准地挑选出高质量的数据又是一个复杂的技术问题。然后是数据分布问题，如何从海量clips中提取有效的特征、如何统计数据的分布、应该考虑哪些维度，都需要大量的工作。对大部分自动驾驶企业，还会面临严重的数据泛化问题，因为不同的车型传感器配置差异巨大，采集的数据往往难以复用，而国内车企普遍车型众多，最后很可能是采了一堆数据放在那没法使用，看起来是数据资产，其实都是存储成本。毫不夸张地说**，数据会占据端到端自动驾驶开发中80%以上的研发成本**。

算力难题

在美国多轮制裁之下，国内采购GPU难上加难，大部分企业手里拥有的算力资源非常有限，拥有超过1000张A100的企业寥寥无几，甚至全国加起来都没有特斯拉一家企业多。如何在算力受限的情况下，进行端到端自动驾驶的研发，是一个值得深入讨论的问题。

算法难题

即使有了数据、有了算力，如何设计合适的自动驾驶算法来进行端到端训练，依然没有统一的答案。业界做过很多的尝试，包括模仿学习、强化学习等等。模仿学习是模仿人类专家的行为，从中学习最优策略，例如可以挑选一批高质量的驾驶行为数据来训练模型。强化学习则是通过与环境的交互和奖罚不断试错进行学习，可以设定一个奖励机制，例如更少的碰撞、更高的效率等，在仿真环境里进行大规模试错。

验证难题

端到端自动驾驶的评估也是一个十分困难的问题。自动驾驶测评分为2类：闭环评估和开环评估，主要区别在于闭环评估可以接受到反馈信号从而形成反馈闭环。开环评估可以对不同的任务通过输入输出来进行评估，例如单独评估感知、预测、规划的效果，并与真实数据或者标注数据进行对比，传统的自动驾驶可以通过开环评估迭代。而端到端自动驾驶则难以进行开环评估，甚至也有人认为开环评估的端到端自动驾驶根本没有意义。闭环评估一般通过在仿真引擎构建的虚拟世界里建立反馈闭环，但是仿真不真是业界一大难题，很难推广到现实世界中的各种场景。例如在接近大货车时，即使自动驾驶能完美地通过，乘客往往也会有严重的恐慌心理，这种心理很难模拟。而如果采用实车闭环测评，一方面测评成本太高，另一方面危险场景的hard case使用实车测评危险太大。

可解释性难题

如前文所述，可解释性是端到端自动驾驶的一个弱点。尤其是对于单模块端到端自动驾驶模型，实现可解释性极为困难，虽然可以将注意力权重可视化来提供部分解释性，但可靠性和实用性仍然十分有限，难以对事故、售后定责等问题给出有效的证据。对于分模块的端到端系统，虽然可以将中间结果抛出以提供更多的信息，但是这种信息往往是神经网络的隐层特征，跟直观的、真实的证据链还是有一定的差距，难以跟客户解释清楚。

上车难题

终于在云端完成了端到端自动驾驶的训练了，仿真效果也很好，最后是如何把这套系统搬到车上并且高效的运行。云端系统为了处理数以百万计的clips，一般都采用复杂的网络结构、巨大的网络参数（高达10亿甚至更多），再用成千上万张A100进行训练。但是车端往往只有非常低的算力、非常低的功耗，却要求极高的帧率（每秒处理的图片数量）、极低的延迟，这导致端到端自动驾驶上车十分困难，只有经过大规模的量化剪枝等提效手段之后才有可能。

这些最难的部分，特斯拉还没公开谈过是如何解决的。今年的特斯拉AI Day，大家可以期待一下特斯拉的端到端如何破解以上难题。在这之前，笔者谈一下毫末是如何做的。

自动驾驶端到端的探索

为了降低训练难度，毫末考虑将端到端大模型进行拆分，分为2个阶段，一个阶段解决感知问题（看懂世界），一个阶段解决认知问题（驾驶决策），这样做的好处有2个：

可以先独立训练，再进行联合finetue，降低训练难度；

不同的阶段可以采用不同的数据，大幅降低数据成本。

在感知阶段，主要任务是把视觉信号转为感知结果，可以利用海量的带高清视频的采集数据和量产车回传的各类corner case视频来训练。而在认知阶段，则根据感知结果来进行驾驶决策，不需要输入视频，只需要输入感知结果和驾驶行为即可，这种数据可以通过量产车进行大规模定向采集。通过这种拆解，既降低了任务的难度，又能充分利用不同的数据。

对于感知大模型，毫末从第一性原理出发，认为要实现端到端自动驾驶，感知就必须跟人类一样，同时具备****识别二维纹理和三维结构、认识万物这三个条件，并且最好是纯视觉的。基于这样的原则，我们建立了自监督感知大模型，将车载摄像头的二维视频数据进行编码，然后通过NeRF渲染来预测视频的下一帧图像，构建了4D特征空间。再通过多模态技术将视觉信号与文本信号对齐，实现识别万物。

对于认知大模型，输入的是感知结果、输出的是驾驶决策，由于感知结果和驾驶决策都是结构化文本，其处理的都是文本符号，我们自然而然地想到了引入NLP相关的技术。

在2023年之前，BERT模型在互联网领域取得了非常成功的应用，于是我们尝试将BERT类的掩码模型引入自动驾驶认知模型，通过量产车回传海量的<感知结果、司机动作>数据对。这样输入历史10秒的<感知结果、司机动作>、再用掩码盖住未来几秒的司机驾驶动作，然后让模型来预测驾驶动作，如果模型预测对了，就说明模型学会了开车，我们称之为完形填空。

但是训练效果并没有达到预期，分析后发现，与NLP任务完全不同，NLP通过mask部分单词，然后结合上下文可以把词猜出来，确实是完形填空。但是自动驾驶场景下，mask历史动作是毫无意义的，只能mask未来动作，即只有上文没有下文，这其实是写作文，大家都知道写作文的难度比完形填空高太多了。

而且，人类驾驶汽车不仅依赖历史感知结果，还更多的依赖对未来的预判，老司机往往对未来几秒的交通环境有非常好的预判，例如隔壁车道的车会不会突然变道、路边的行人会不会横穿马路等。基于这种预判，老司机再采取合理的驾驶动作。这种预判，从模型上讲就是一种生成式模型。于是我们将算法调整为GPT生成式模型，将历史感知结果使用BEV方式表达出来，再将BEV序列输入模型，让模型预测几秒钟之后未来世界可能发生的变化，这样就构建一个自回归的生成式模型，如下图所示：

然后，将感知和认识进行联合训练就可以实现端到端自动驾驶了。但是，我们发现仅通过这种方式进行训练，想要达到非常好的驾驶效果，需要的数据规模、算力规模都极为庞大，我们根本无法承受。

例如，在传统的分任务自动驾驶范式下，感知算法识别塑料袋后，可以人为设计一个塑料袋可以压过去的驾驶策略，这样训练成本很低，但是在端到端范式下想要让自动驾驶识别塑料袋并学习到塑料袋是可以压过去，需要大量数据进行训练，成本极高，这也是特斯拉手握数万卡的原因之一。

塑料袋、泡沫等软性材质是可以压过去的、交警的手势优先级是高于红绿灯的、救护车是要避让的，这些其实都属于人类社会的世界知识，这些知识都是人类经过长期学习之后获得的。

传统的基于人工策略的自动驾驶成本很低，就是因为通过人工策略直接把人类社会积累的知识用在了自动驾驶上，省去了训练成本。但是驾驶知识包罗万象，如果要基于人类知识为世间万物定制各类策略，也是一件不可能的事情。

那如何既能利用人类社会沉淀的知识，又能降低端到端自动驾驶的训练成本呢？考虑到大语言模型中压缩了几乎全人类的知识，如果能将跟驾驶决策相关的知识提取出来，应该能大幅度降低训练成本。

于是，毫末在端到端自动驾驶中又引入了大语言模型，通过感知大模型识别万物后，将这些信息输入LLM，通过LLM来提取世界知识，并作为辅助特征来指导驾驶决策。如图所示，这个系统极为复杂，算力消耗非常大，目前还只能在云端运行，未来几年将加快向车端的落地。

未来趋势

过去一年，大语言模型的发展思路给端到端自动驾驶很多启发，在模型、数据上都值得借鉴。

大模型

在自然语言处理领域，Chatgpt作为基础模型展示了极强的泛化能力。最近，学术界的研究在语言-视觉大模型上也取得了突破性进展，这种基础模型无疑会让自动驾驶如虎添翼。

特斯拉、Wayve等公司也提出将World Model作为自动驾驶基础模型的思路。World model是一种基于视频来预测未来世界的模型，例如特斯拉的world model可以根据prompt给出的动作来做出反馈，并生成未来的世界图像，而且能保证多视角、时序的一致性。

借助大语言模型LLM

大语言模型压缩了人类的大部分知识，当然也包括驾驶知识。可以通过与LLM进行交互，提取驾驶常识。例如传统的占用网络，遇到前方一个大塑料袋时，往往会以为空间被占用，但是基于LLM，我们可以获取塑料袋的物理知识，从而知道不必躲闪。通过这种方式，相当于副驾坐了一位见多识广的陪练，随时可以告诉你遇到corner case应该如何处理，但是通过语言模型指导自动驾驶依旧风险巨大，因为LLM提供的答案幻觉十分严重。

数据生成

端到端自动驾驶可以说是数据为王，为了解决长尾数据问题，业界也在尝试用AIGC技术构造数据。面对一个尚未解决的问题，如果现实环境难以采集到类似的数据，例如车祸，可以考虑使用AIGC技术来定向生成类似场景的数据，来快速提升效果。也可以使用仿真引擎来构造类似的场景，生成数据。

Zeroshot/fewshot learning

然而，不管数据规模有多大，自动驾驶模型始终都会遇到超出数据分布的场景，每次遇到问题都去找数据来训模型显然不够优雅，最好的方式是自动驾驶模型具备足够的泛化能力，只需要少量样本，甚至不需要样本就能解决这种分布之外的场景。大模型的出现，让这种能力成为可能。

长期来看，纵然各种挑战仍在，但笔者相信，端到端自动驾驶是未来最有希望实现无人驾驶的途径之一，大模型将对自动驾驶的技术发展产生深度影响。

参考文献：

https://arxiv.org/pdf/2307.04370.pdf

https://arxiv.org/pdf/2311.18636.pdf

https://arxiv.org/pdf/2306.16927.pdf

https://arxiv.org/pdf/2212.10156.pdf