讲述｜余轶南

编辑 | Amy

编者注：

本文是HiEV出品的系列直播「硬核拆解BEV」第二期，地平线副总裁兼软件平台产品线总裁余轶南博士分享的内容梳理。

第三期商汤绝影量产行车智能驾驶研发负责人蒋沁宏分享的《BEV三大关键：数据、迁移和芯片部署》将在6月1日（周四）晚8点开播。

正文：

目前，自动驾驶最主流的传感器是摄像头，头部的一些主机厂也开始把摄像头作为主传感器。摄像头的优点在于：

•像素大，信息量丰富；

•比较常用，成本低廉。

近50年，计算机视觉整体上是step by step的发展模式。说到这里，不得不提马尔计算理论（Marr's computational theory），是关于对象识别的计算机视觉理论。

该理论指提取从图像到图像的一些基本要素，称之为2.5维要素图，最后根据2.5维表象形成信息，计算三维模型表征的一种逻辑。

这一逻辑到今天依然成立，但是表达方式可能不再是step by step模块化方式，它更多地使用神经网络来去替代。

在过去，我们在研究计算机视觉的过程中，有使用到行人检测算法、人脸检测算法、车辆检测算法，现在这些都被统筹到了神经网络算法当中。

一、深度学习成为主力，神经网络取代手工代码

从2012年开始，也就是在NIPS上发表Convolution Neural Network（卷积神经网络）论文作为起点，深度学习开始成为计算机视觉的主力算法。

这个算法有一个非常典型的特点，在规范了整个输入和输出以后，整个网络内部是如何抽取这些经验要素，以及最后如何处理这些经验要素，组成语义信息输出，其实是通过前向传播之后再后向传播的学习方式，而不是过去人工的方式，这样大大地简化了设计工作量，从而可以在更大规模、更加复杂的任务上得到更好的效果。

今天对自动驾驶来说，不仅包括视觉感知，还包括局部定位、对目标长短期的行为预测、自车的规划和控制，而这些都可以使用神经网络完成，我们将其定义为软件2.0。

和上一代相比，软件2.0最大的区别在于，它可以通过神经网络的设计替代过去通过人工来手写代码的方式完成任务。因此这对软件工程师或者代码量的要求，从比例上是开始缩减的，但是网络规模上不断增大。

对自动驾驶来讲，今天大部分的感知，或者称之为“大感知”、“广义感知”，都是通过数据来驱动的。

除感知以外，定位融合、地图定位融合、规划控制等，也都在从基于规则、手写代码实现的软件1.0方案，一步步转向数据驱动。

二、GPT启示下的端到端模型训练

去年至今，发生了一场新的通用AI革命，即以大规模训练模型引领的各种各样的GPT，形成多种模型。

而对于整个GPT模型来说，这跟之前深度学习的训练方式存在一定的差别，GPT主要是通过海量数据预训练，加少量数据监督学习，然后强化学习，这三阶段去完成。那我们把它映射到自动驾驶的这个系统里面，可以看到：

1.首先通过海量的预训练，去训练整个网络的主干；

2.完成各个子任务模块监督训练；

3.通过模仿，去学习人类驾驶行为；

4.再加上强化学习，矫正自动驾驶思维模式；

5.最终形成端到端的自动驾驶训练方式，形成端到端的模型。

不过训练是分阶段训练，不是一上来就大规模训练。在软件2.0的驱动下，整个自动驾驶算法的架构也产生了很大的变化，包括感知、定位融合、规划控制，分模块设计。

目前对于使用深度学习形成端到端的过程，行业已经形成共识：

无论是摄像头还是雷达，地图或者其他信号包括导航，都可以通过一种编码的方式Token化，比如卷积神经网络就可以认为是一种编码器，不同的传感器将它编码成想要的信息。

同时，各种控制命令、信号都可以编码，例如地图格式的转换，最后把这些信息形成一个完整的对外输出的Token，输出给认知和决策层。

模型主要网络也可以是Transformer类，或者类似的，最后通过decoding层直接生成最终的信号，给到车辆执行器。

在过去一年，地平线的同事以第一作者的身份，在 CVPR 发表了一篇文章《基于 Transformer框架实现自动驾驶端到端深度学习算法》，提到的架构如上所述。这样的架构兼具可解释性以及最终端到端的效果，在一些公开实验上，已经看到了很好的潜力和表现。

这篇论文发表的时候附带一个范例，有意思的是，虽然在整个训练过程中没有显性地给出红绿灯或者其他交通规则形式，但在整个大规模训练后，汽车可以根据红绿灯状态启停，这一过程中信息其实不在训练数据里，而是数据标注里。

整个大模型其实对场景常识的认知是能够自动通过预训练和参考过程学习。大家可能会问这样的算法架构模型这个规模有多大？

其实，目前整个自动驾驶模型，例如我们常见的这种大语言模型还是小得多，我们整个GPT语言模型想取得不错的效果，所需的数据训练量在几个T级别。但是随着算力增长，计算效率提升，不断增大算力，效果还会继续提升的。目前来讲，整个transformer都是T级起步，10T~20T，最大可能要几百个T。

未来网络越来越大，这些都依赖硬件基础设施。

对于云端来说，我们可以通过并行计算集群，实现大规模算力需求，但在车端，受限于车端面积、散热功耗等一系列约束条件，可能需要使用单芯片或者双芯片来实现算力，所以对端上单芯片算力、算效要求其实非常大。

而随着整个大算力需求增长，可以发现卷积神经网络和Transformer在架构上最大的区别还在于带宽的分配。

相比于卷积神经网络来说，如果卷积神经网络常见的带宽和计算的比通常是1:100到1:1000，而到Transformer这样的架构，通常计算带宽的需求和算力的需求比例大概是1:1到1:10。

未来架构里，芯片带宽可能会成为新的核心瓶颈。

从征程5到征程6，这两大芯片都大幅度提高了片上带宽以及带宽相比算力的比值，从而能更好地支持BEV加transformer等更大模型的方案。

BEV感知方面，这其实是相对于刚刚提到的端到端里第一个能够落实到量产的计算平台上的，最重要的一个感知算法。

第一，过去我们都是先在2D图像里做目标的检测，然后把它通过摄像头投射到3D里，这种技术的好处是整个计算非常直观。但整个投影过程都是使用软件的方式，没办法形成端到端。

而BEV相比于这个传统方案最大区别就是，它可以看到整个状态，通过一个上帝视角，对全局状态有一个更好的感知和预测能力，更有全局意识。

基于BEV多模态前、中融合比较能够容易地去融合多模态的传感器，不同角度的摄像头我们都可以通过一个全新网络来对它进行编码，然后编码之后把它投影到BEV视角下的形式。

而激光雷达天然就具备3D的视角空间，所以我们可以让激光雷达通过一些方式在3D空间形成一个特征，然后就比较容易做特征级别的对齐，在特征级拼接形成多模态。

相似的技术也可以用于超声波、毫米波，在BEV空间编码，之后进行加工，最终形成感知结果。这种中融合的方式很容易去做多模态的传感器融合，相较于后融合，整个架构更加简单，易于训练。

三、基于征程5的BEV感知

在征程5上，我们已经实现一套基于BEV的时空融合。

除了这个空间和多模态以外，还有时间融合的框架，可以把多个摄像头、多种传感器，包括时间融合到整个框架里。这里面又可以分为输入层，包括不同的传感器，例如前视、周视、鱼眼、激光雷达等。

通过BEV模型对整个图像进行编码，投影到BEV的空间，雷达链路也是一样的，之后再通过时空维度转换，把这些东西集中表达，最后通过一个神经网络和transformer架构合成，到输出层直接输出。

输出包括3D检测、物体跟踪状态、轨迹，以及车道线目标，车位静态障碍物以及占用网络及整个3D物体，整个端到端的系统可以从感知的目标检测到预测，再到轨迹到预测，全部都可以输出。

这里面很多是我们实际场景的实验结果，都是实车测试的：

第一，动静态通过BEV生成动静态结构，可以把所有的道路的动静态要素检测出来。

第二，通过这种架构，通过transformer不仅生成了道路相关的物理结构和信息，还生成了道路逻辑关系，例如车道之间的关联信息，车道线之间的关系，这些信息对地图都是非常有效的。

还有就是对所有目标物都可以预测行为轨迹，这种行为预测方法可以让我们提前对目标物进行行为预测，对其他车辆行驶路径可以预判，从而对自车行为进行干预。

另外，算法也可以实现相对复杂场景下的自动驾驶，例如左拐，右拐并线以及匝道口的博弈、汇出和对路边静止车辆自动规避和避让。

四、连线互动：BEV对芯片带来的挑战

此环节包含主持嘉宾周琳、元戎启行副总裁刘轩、复睿智行CTO 周轶以及直播观众与余轶南博士的探讨。

Q：特斯拉最近公布将在V12版本上推出端到端的技术，像transformer还是有很大容错率的，自动驾驶对安全性要求很高，基于transformer大模型，我们可以通过哪些途径提高安全性？

A：安全的确是我们在自动驾驶上面临的一个很大问题，自动驾驶安全可以分为两个方面。

第一，是功能安全，主要指系统失效问题，包括随机失效，或者是某些确定性的场景下失效。

行业对失效推出了很多的应对方式，例如硬件失效、软件失效以及最近的模型失效可以通过监控系统来诊断。如果系统失效，要将失效最小化从而降低风险。

第二，从某种意义上来讲，AI是一种不确定的系统或者概率系统，跟周边的环境有关，

不同场景下失效概率其实很低，我们所要确保的是不同场景失效概率尽可能低。如果某种场景下的失效概率是10的负6次方，甚至到10的负9次方，那从统计上来说，系统是安全的。当然我们仍需要关注这种场景下失效的危险和风险是什么。如果失效后仅仅是需要安全停车，那么风险很小。

如果失效后会发生严重的碰撞和事故，那么这种场景需要我们全行业一起去一步步地解决。失效问题一方面通过理论推导和实验解决，一方面需要通过实践去检验具体场景下的状态。

Q：您刚刚介绍了在征程5上面的方案，地平线芯片目前已经支持了BEV的方案，之前是不支持的。那这个转变是基于什么样的契机呢？

A：最重要的一点是芯片算力足够支撑这样的算法和计算规模。BEV算法其实在2015、2016年在学术界已经被提出来了，那时我们的效果和2D效果还是有不少差距的。

随着近几年芯片算力的提升，端到端系统算力指数级线性增加，有效算力增加。

Q：现在业内有很多BEV方案，不同方案需要不同的算子，而基于深度学习的方案需要其他算子，那地平线对这些算子是都可以支持还是支持其中一部分？支持的力度和广度怎么样？

A：大部分的算子都是支持的，最大的区别在于架构算力效率。如果整个计算是比较规整的，那效率很高，如果计算本身的跳变，例如内存里的跳变，这个不规整性比较强的话，整个计算的效率就低。

学术界的算法是多种多样的，但是产业界各家产品的BEV架构其实就两种，这两种模式算法其实各家做得都差不多，原因是在产品上要追求的不光是普通的实现，还有计算的效果。

在这样的算力下，最大化计算结果是怎样的，以及帧率的约束，包括像素分辨率的约束，大家基本是趋同的。所以学术圈的算法很热闹，产业界还是殊途同归的。

Q：无论是transformer、占据网络、BEV技术还是没有解决z轴上的一些问题，学术界和工业界对3D占据网络还是比较感兴趣的，这方面未来的规划是怎样的?

A：我们最近的量产项目已经上了占用网络、3D感知、预测这些功能，但我们发现如何使用这些算法是巨大的问题。

因为传统算法，主要是规控算法如何在规控层面使用BEV的点列，因为过去像我们L2这样的系统，例如车道都是用三次方程的表达形式，但这种方式在城区这种场景下是完全不可以的，所以需要退回到最原始的表达方式，也就是点列的方式，但是点列对于规控需要如何使用呢？这就是一个新问题。

Q：您刚刚讲到占用网络如何使用的问题，那今天不光是每一个格被占用，同时每一个格x、y、z三个方向的速度如何，这些信息需要综合起来，需要整个规控系统转化为数据驱动，或者是优化搜索的系统，只有这样才能使用。

您刚刚提到规控是很重要的模块，那么地平线有没有针对规控有更特别的设计和优化？

A：从神经网络的角度来讲，我个人认为，大部分的算法尤其是在后端，基本都趋于transformer加Token这种表达方式。其次，我们对transformer架构做了很多工作，例如我们的一篇文章，就有提到其实对整个后端，包括对目标、地图的编码以及对轨迹预测、使用，规控算法的使用来说，全是用一种方法调整去实现的。

我们在一两年前开始做下一代芯片，也是征程5的下一代芯片整个算力规划的时候，我们的判断是，感知未来自芯片算力上的规模需求可能只占1/3，甚至更少，剩下2/3或者1/3用来做什么，需要做环境理解。

环境理解不是指感知的环境，感知部分其实已经把所有的车道线、道路边缘等全部识别了，那环境理解最重要的是理解环境要素之间的关系。例如红绿灯和十字路口的关系，这些需要感知和大量数据分析推理而来。

对道路的表达形式已经开始变成点列，其实无非就是要在这些点位之间表达二阶关系。对规控来说，其实就是要去讲清楚自车形式轨迹，轨迹与轨迹之间也是有关联的。从这个角度来讲，其实所有后端的架构都可以被统一。

Q：刚刚聊到芯片算力，那目前地平线的合作伙伴也用了通用的芯片，那么从你们的角度出发，基于征程5的BEV方案，相较于友商的芯片方案，性能上相比怎么样？

A：这个问题需要深度横评，因为我刚刚讲到算力飙升只是代表了加阵列的数量以及整个计算的主频，就相当于我有那么多计算单元，但是怎么把它用起来，怎么把计算结果保存，整个流程如何进行其实是很难确定的。

而每家芯片这部分的技术都是核心，很难通过理论分析实现，尤其是作为第三方也很难评测。最好的方式就是像手机跑分一样评测。

Q：我们的目标平台是征程5，那在我们开发过程中，怎么保证我们未来转到征程5不会做太多额外工作？

A：整个芯片来讲：

•第一，兼容大部分芯片，能够使用我们的编程接口，能扩大一些自定义；

•第二，假设我们今天已经有一个结构，那我们可以通过工具链里的工具来适配；

•第三点，我们不但能去推动性能上的提升，还能告诉我们网络设计者整个神经网络节点信息，提供改进空间。

如果芯片的实际使用效率很低，这其实是一种巨大的浪费。

Q：在BEV时代，还是需要大量的数据标注，那地平线是如何降低人工标注数据在整个训练环节中的依赖？

A：我们讲软件2.0，讲端到端的网络，包括我们现在讲的大规模训练，里面最大的挑战不光来自模型结构本身，其实很大的挑战来自怎么去准备训练。

过去我们可以在2D空间对图片做手工标注，很小的一张图的成本就有好几千，但我们也可以通过一些大模型去做，我们通过人工的方式做，把成本控制住，做一套完整的自动化工序。

目前友商有去下载一些模型，使用公开的数据，呈现的效果很好，但是这些东西放到实际的系统上去应用并不可行，因为里面缺少一套完整的端到端的系统。

我们就做了这样一套系统，后续会命名，这套系统包括大规模数据标志、自动化标志、大模型的训练和评测，这样整个云端系统才能在后台、在前台的BBA层真正发挥作用。

Q：车展上我们公司发布了基于毫米波雷达加整个视觉的网络算法，但我们认为这种算法只是解决了空间探测能力问题，但实际在自动驾驶中，像您刚刚说的语音识别，对不同目标行为预测，在自动驾驶中可能比感知更重要一点。那怎样把网络跟语音信息在同一个结构里展现出来，然后让规控做得更好？是只用传统网络做？还是把这两个结合做？

A：最大的挑战不在于网络本身，最大的问题在于数据怎么标注，因为需要做大规模数据训练，所以整个数据散度以及规模都是比较大的。在我看来，今天能把这些事情做好的公司不多。

另外还需要大规模数据采集，采集所有量产车的数据，还需要比较廉价的数据采集方式获取数据，根据数据去做一些增强，从而生成我们所需的标准。

这个过程需要清洗数据，具体的行为方式很像做众包地图，但跟众包地图不完全一样，因为需要发现更多动态信息、关联信息，这个过程是需要自动化的。学术界有一些算法可以去做这些事情，这也是我们下一步需要攻克的。

Q：关于地平线征程5甚至征程6芯片，如何对transformer进行硬加速？

A：这方面的网络结构并不复杂，主要还是用一些传统的算子，我们本身就是支持的，问题的核心是如何把算子跑到最高。

经过我们测试发现，行业内典型芯片利用率基本在30%-40%，我们其实在做很多新型架构包括总线、带宽方面一些优化，希望把整个芯片的利用率做到50%以上。这也是我们必须做的。

Q：征程5目前是为理想Pro这个平台搭建的，如果征程5不含激光雷达，我们是否会去做全场景的BEV方案，如果不使用激光雷达，它可以在哪些场景包括城市，是否可以开高阶辅助驾驶。也就是说，不搭载激光雷达的方案能否实现纯视觉BEV？

A：在我们的芯片上开发BEV算法其实与激光雷达无直接关系。刚刚讲过，BEV这个架构可以支持多模态，有无激光雷达皆可。

有激光雷达的好处在于对于整个的方案准确度，尤其是近距离的准确度会更好，对于目标的距离角度的准确性、稳定性会更好。激光雷达也有它的缺点，例如恶劣天气，因为它是主动光，存在反射的问题。

从认知上来讲，第一基于BEV架构才有可能做城市NOA，高速NOA也可以拿来加强，但短期性能提升不明显，长期是有帮助的。高速NOA也是可以用BEV做保持系统。

征程5系统第一个量产项目里还未使用，但第二个会全部更新BEV架构，合作也会全部升级这个系统。BEV也可以优化高速上一些方案，提升效率。