【导读】车载智能芯片——无论以何种方式来定义，都将如这十年间手机智能芯片一样改变下一个十年的芯片产业。当我们设计下一代车载智能芯片时，通用的车载芯片能否满足不断进化的自动驾驶算法？该如何审视高效性、鲁棒性这两个几乎相悖的指标？我们希望本文能给读者以启发。
作者 | 甘一鸣、朱禺皓 责编 | 唐小引
出品 | 《新程序员》编辑部
2016 年，我刚到美国留学，买下了自己人生中的第一辆车。这是一辆 2012 年建造的黑色日产 Altima。整辆车上没有一个显示屏，没有任何跟车、车道保持等辅助驾驶功能，我甚至说不出车上有哪些芯片是过去三十年半导体产业的结晶，而所有这些车载芯片的算力加在一起，也远远不如一台当时的旗舰智能手机。
自动驾驶软件进步迅速
我猜即便是当时汽车产业的人可能也很难想到，在三年后的 2019 年，特斯拉会把一台 14nm 制程，由 12 个核心的 ARM A72 CPU、ARM Mali G71 GPU，2 个神经网络加速器，以及大量不同硬件加速单元构成的，总算力超过 600 GFlops 的，充满算力的“电脑”，装进每一辆从生产线走下来的特斯拉中。
运行在这样一个充满算力的服务器上的，是特斯拉设计的“全自动驾驶”系统。无论有多么大的争议，特斯拉以及其余大量车企，带领着我们在自动驾驶这条路上开始头也不回地狂奔。
在三年后的今天，600 GFlops 算力的车载芯片已经不再能称为行业领先了，特斯拉最新的车载芯片已达到 72 TFlops。自动驾驶算法也得到大量更新，Transformer 取代了传统的 CNN（卷积神经网络）。更多的传感器，包括激光雷达、多输入摄像头等被广泛使用。快速发展的行业，让三年前最先进的自动驾驶系统，无论是硬件还是软件，都好似一个面对新款 iPhone 的黑莓手机，被时代的洪流抛在身后。
但整个行业还在进步。自动驾驶的任务变得更复杂，从基础的 L2 级别的辅助驾驶，进化到更有野心的 L4、L5 级别的全自动驾驶。随之而来的是更复杂的自动驾驶算法，算法驱动着硬件进化，我们每个研究者，与其说是站在自动驾驶这一宏大课题的“The beginning of the end”，不如说是刚刚达到了“The end of the beginning”。
通用性与专用性：一个算子的一生
智能车载芯片，一如智能手机芯片，在通用性与专用性之间达成了统一。在架构层面，一个多核心的通用芯片与多个专用硬件共同构成了片上系统。如神经网络加速器等专用硬件提供了大量的算力，为自动驾驶系统中的视觉识别系统等模块服务。
然而专用硬件仍然无法跳脱出通用性的问题，尤其对于硬件设计者而言，在当前这个算法演化要远快于硬件进步的时代，如何让硬件设计服务不同的软件算法？神经网络加速器给出了很好的范例：使用一个或多个通用的算子，来实现同一任务的不同网络，甚至不同任务对同一硬件的使用。
对于复杂的自动驾驶软件而言，以深度学习为核心的感知模块仅仅是其中的一个部分。其余如定位、规划、控制等模块至今尚未有一个明确的算子供硬件设计者使用。尽管有研究工作[1]试图在多种定位算法中寻找通用的计算模式，但绝大多数工作在为智能车载芯片设计专用定位或路径规划加速单元时，仍是简单地基于一个或多个算法来定制专用硬件。当自动驾驶软件向下一个版本迭代后，这一专用硬件很有可能将不再被使用。
对于通用算子的选择，硬件设计者需要考虑到以下两个维度：
第一，横向适配不同算法。不同服务提供商在其自动驾驶软件中，对于同一模块很可能使用完全不同的算法。硬件设计者可以通过使用在不同算法中都通用的算子来为不同的服务提供商设计硬件。
第二，纵向适配算法的不断演进。算法迭代的速度远超于硬件迭代的速度，而车载智能芯片在上车之后便很难更新换代。因此，为前后多代算法设计硬件平台也是我们需要考虑的范畴。
算子本身既能作为一个或多个简单的操作，也可以是一种更复杂的中间介质。在这之中，因子图[2]作为一个通用的介质正逐渐得到人们的关注。
作为概率图的一种，因子图本身表示一连串的概率分布的乘积。因子图有两种节点，分别为因子节点和变量节点。在因子图中，所有的节点都通过有向的边连接起来。大量以优化为目的的自动驾驶软件中的算法模块，包括以 SLAM 为代表的定位算法[3]，感知模块中的跟踪算法[4]、控制算法[5]等，都可以被表示为因子图的形式并被求解。举个例子，如下图所示是一个简易的由因子图表示的动作规划算法，其中左图包括了五个不同的状态，右图展示了被求解的矩阵 A，而虚线表示因子与矩阵中元素的对应性。
一个简易的由因子图表示的动作规划算法
当然，在不同的算法中，因子图的构建和求解过程可能是不同的，但这并不会阻止因子图作为一个潜在的通用表示形式被挖掘。基于此，我们将因子图作为一种中间介质，为 SLAM 定位算法设计了一款专用硬件[6]，继而将因子图用于路径规划算法和控制算法，尝试设计一款利用因子图加速的通用硬件，来为多个模块的算法加速。
自动化：算子提取与硬件生成
无论在哪个时代，设计硬件都是一件成本很高的事。一款可商用的专用硬件加速单元，需要消耗硬件设计和测试团队长达几个月的开发设计与验证后才能投入使用，这也是车载智能硬件迭代速度要远小于软件迭代速度的原因。并且，不同于传统的操作系统等通用软件，迭代后的版本也往往兼容前一代或几代的硬件平台，车载智能软件的迭代很可能将上一代平台远远甩在身后。
硬件设计者可以依赖的没有其他选择，只有开发的敏捷化、快速化与自动化。传统的硬件生成（High-Level Synthesis）存在着许多问题，如无法对底层多核心或异构架构平台进行优化；无法理解算法的核心瓶颈，仍然需要硬件工程师进行大量的人工调整与修饰等。
当我们有了一个合适的算子作为中间介质去设计硬件后，硬件设计的自动化变得更接近于现实。这其中又可以分为以下两个部分：
第一部分是从已有的或新的算法中去提取算子，但这并非易事。软件开发者在设计算法时并不会为底层硬件考虑，算法设计以正确性、高效性为唯一目的。而在硬件设计者看来，很多自动驾驶模块中使用的算法都是杂乱无序的。从这样一个或多个算法中提取一个固定算子，并将这一过程自动化非常具有挑战性。以我们的研究为例，即便在确定因子图为统一的中间介质后，在为不同的算法设计以因子图为通用介质的加速器时，仍然需要大量的人工设计。
第二部分是由算子自动生成硬件。在我们的工作中[7]，已经开始初步使用自动化或半自动化的方法来为自动驾驶软件设计硬件。如下图所示，展示了一个半自动化的求解定位算法后端的硬件架构，其中 D-Type 舒尔消元、M-Type 舒尔消元和 Cholesky 这三个硬件模块分解模块为自动生成硬件。
一个半自动化的求解定位算法后端的硬件架构
相比于 High-Level Synthesis，我们通常会先手动为通用的算子设计一个优化的硬件模板，这个模板电路可以被应用到使用该算子的算法专用硬件中。同时，我们可以根据数据量的规模和场景的复杂程度动态地调整硬件设计。
尽管存在着大量自动化的步骤，在更敏捷地开发硬件的路上，我们还有很多工作要做。例如，除了通用算子对应的硬件电路，算法或软件中还存在着大量其余的运算，这些运算对应的电路则需要我们人工进行设计。同时，对于专用硬件的数据存储方式，也需要根据计算模式去人工定制。
高效性还是鲁棒性？
和只以高效性为主要指标的智能手机芯片或服务器芯片设计不同，智能车载芯片的一个重要指标是在实时完成所需计算的同时，也要具备足够的容错能力，即系统的鲁棒性。车载系统的鲁棒性关系到至关重要的人身安全问题，这也是全自动驾驶能否真正被应用的关键所在。
然而，鲁棒性与高效性其实是一对相悖的指标。传统的容错计算在确保鲁棒性时通常添加备份资源这样的简单逻辑，无论是空间上的电路备份，还是时序上的重复计算，都试图通过对同样的计算内容做多次计算来保证结果的正确性。但这一逻辑本身就违背了计算系统的高效性，在空间上的电路备份增加了芯片面积和功耗，而时序上重复计算更是会带来时间上的负担，可能会导致车辆无法在很短的延时内作出符合环境变化的反应。
特斯拉和 ARM 等车载芯片设计者已经在真实系统中开始部署多机冗余系统。其中，特斯拉的“全自动驾驶”系统使用了两块相同的硬件部署了相同的自动驾驶软件，二者之间互为备份；ARM 为自动驾驶设计的 A 系列芯片也提供了锁止选项，即两个 CPU 核心运行一样的任务，并在每一个时钟周期比较两块 CPU 核心的输出信号，通过输出信号的异同可以判断出 CPU 核心是否存在错误，若出现错误，则报警以供系统设计者做出选择。
我们希望能在高效性与鲁棒性之间搭设一个桥梁，提供一种既保证鲁棒性，又尽量降低对高效性造成损失的方案。这一点，我们从软件系统的复杂性中得到了启发[8]。
自动驾驶软件是一个拥有多个不同模块数十种算法的复杂系统。不同的算法遇到错误后，对于整个系统的反馈也截然不同。我们发现，有的算法因为其设计，天然对于错误有着极强的鲁棒性。例如，对于感知模块中的算法而言，因为存在多个传感器分支的融合，单一传感器路径上的错误就可能被其他传感器的感知结果纠正。类似的，有些算法因为在运算过程中对输入信号进行积分后，与前值相加减得到新的结果，这一类算法对于错误的容忍度同样很高，当其输入信号出错后，其输出信号可能并不会影响到系统的最终运行结果。
在挖掘到这一信息后，利用自动驾驶软件内部不同的鲁棒性，可以帮助硬件设计者在确保鲁棒性的前提下，大幅降低硬件层面的负担。例如，在进行冗余计算时，硬件设计者可以对部分硬件进行备份，并将受错误影响较大的模块（如控制模块）调度到有备份的硬件上运行。而那些对错误不敏感、容错能力强的模块，则可以被调度到无备份的硬件上，以此来实现更好的运行速度。
车载智能芯片的下一个十年
经过过去数年间的突飞猛进，车载智能芯片已经获得了大量的关注，并被部署到了实际的生产、生活中。但无论是学术界还是工业界，对于车载智能芯片的未来发展，还有着相当多的问题需要我们解决。
AIGC 生成车载芯片未来（By Imagine with Meta AI）
首先是车载智能芯片的可编程性。同一家硬件厂商可能服务于不同的车厂，通常来说，不同车厂之间的自动驾驶软件的设计逻辑是不同的。硬件设计者有动力为自己的硬件设计一套通用的编程模型，以供不同的软件服务商使用。这一编程模型可以在更好地挖掘硬件算力的同时，给软件设计者提供接口。
其次是多车通信和车路通信。车路协同与多车协同被人们认为是实现最高级别自动驾驶的一个关键步骤，和其他车辆及路边处理单元分享信息可以更好地辅助车辆做出决策。即便硬件设计者和软件提供商可以就车路协同与多车协同达成接口的统一，这一设想仍然存在着不少问题。
举个例子，和云计算一样，车车协同与车路协同存在的一个关键性问题在于个人数据的隐私性，车主是否乐见将本车信息与他人进行分享，分享之后又会引发何种安全性隐患，隐私计算是否会在其中扮演重要角色，这一系列问题都是学术界与工业界亟待解决的。
总体而言，不需要任何多余的宣传或者营销，自动驾驶及其硬件设计将成为我们这一个时代的“风口”。但关于如何设计效率够高的专用性硬件，如何做到敏捷开发，如何在兼顾高效性的同时保证鲁棒性等问题，依然有待从业者提出新思路去解决。我们作为相关课题的研究者，也非常期待与大家共同合作，为这些问题给出答案。
参考文献
[1] Gan, Yiming, et al. "Eudoxus: Characterizing and accelerating localization in autonomous machines industry track paper." 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 2021.
[2] Loeliger, Hans-Andrea, et al. "The factor graph approach to model-based signal processing." Proceedings of the IEEE 95.6 (2007): 1295-1322.
[3] Zhang, Yanhao, Teng Zhang, and Shoudong Huang. "Comparison of EKF based SLAM and optimization based SLAM algorithms." 2018 13th IEEE Conference on Industrial Electronics and Applications (ICIEA). IEEE, 2018.
[4] Schoellig, Angela P., Fabian L. Mueller, and Raffaello D’andrea. "Optimization-based iterative learning for precise quadrocopter trajectory tracking." Autonomous Robots 33.1 (2012): 103-127.
[5] Rawlings, James B., and Brett T. Stewart. "Coordinating multiple optimization-based controllers: New opportunities and challenges." Journal of process control 18.9 (2008): 839-845.
[6] Hao, Yuhui, et al. "Factor Graph Accelerator for LiDAR-Inertial Odometry." Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design. 2022.
[7] Liu, Weizhuang, et al. "Archytas: A framework for synthesizing and dynamically optimizing accelerators for robotic localization." MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture. 2021.
[8] Gan, Yiming, et al. "Braum: Analyzing and protecting autonomous machine software stack." 2022 IEEE 33rd International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2022.
本文精选自《新程序员006：人工智能新十年》，大模型时代，《新程序员》助你快人一步进入智能新纪元！欢迎大家订阅年卡。
