system: [SYSTEM]

user: 2. 基于Ray的自动驾驶系统设计 自动驾驶的实现不仅要求车辆准确地采集环境信息，还要求车辆能够根据环境信息及时做出正确的驾驶决策。因此随着环境信息量的提升，车辆处理器需要更强的数据处理能力，更强的计算能力才能实时地完成决策。 当前已量产的拥有部分自动驾驶能力的汽车中的大部分是采集的视觉环境感知模型，其输入信息大多是经由摄像头采集的图像信息，但对于更高级别的自动驾驶来说这些信息是远远不够的。而在引入了基于激光雷达的环境感知模型和各类雷达数据之后，现有平台已经难以支撑对海量的数据的计算处理任务。随着通讯技术的发展，通讯延迟或将控制在车辆操作窗口时间以内 [ 11 ] [ 12 ]，因此车辆的本地计算任务大部分可以交付于分布式云计算平台进行处理。借助分布式云计算平台更强大的算力以大大加强自动驾驶汽车的计算能力，使其能够面对更加复杂的环境，拥有更高级别的自动驾驶能力。 Ray是一个高性能的分布式执行引擎，设计之初便致力于于支持人工智能应用的分布式执行，拥有相关的人工智能应用的相应支持与所需的API。支持TensorFlow [ 13 ] 等机器学习框架尤其是对强化学习应用有着更高层次的支持。 远程自动驾驶系统中的远程分布式服务器集群要解决的就是汽车上计算平台的算力不足的问题，即要满足高性能和低时延的需求，但其实低时延的需求不仅要求远程分布式服务器集群的高性能以减少计算的时间，还对传输的网络延迟有要求。在这里不讨论网络延迟相关的技术，仅从降低计算时间出发，那么这两个需求可以合并成对高性能的需求。 通过分别与单机平台和基于MPI的分布式系统进行性能测试实验，我们发现基于Ray的分布式系统的确在计算能力上对两者均有着很大的优势。基于Ray的远程分布式服务器集群能够提供远大于汽车本地搭载的计算平台的算力，同时也拥有相对其他分布式系统更好的性能，能够更好地高级别自动驾驶的需求。 2.1. 远程自动驾驶系统的任务调度 远程自动驾驶系统可划分为车辆本地处理平台和远程分布式服务器集群，两部分之间的任务调度方式如图1所示，自动驾驶各个子任务由本地计算平台做预处理，而它将会将设计好的需要云平台负责的计算和数据处理的任务则交付于分布式计算平台进行处理。而这些任务借助基于Ray框架的分布式计算平台能够快速地完成，并且把相关任务处理完成后所需的结果交回车辆计算核心，控制车辆行驶。 图1. 远程自动驾驶系统示意图 2.2. 基于Ray的自动驾驶框架 Ray的体系结构如下图，它能够提供高可伸缩性和容错能力的系统层 [ 7 ]。 图2. Ray的体系结构示意图 如图2所示，系统层和应用程序层两部分共同组成Ray的体系结构，系统层主要包含GCS和自底向上的分布式本地调度器。GCS存储着系统中的所有控制状态，这样其他组件就可以是无状态的，方便容错，也方便其他组件的横向拓展。而本地调度器降低全局调度器的负担，增强了系统的吞吐量，他们共同调度各类任务给应用层处理，同时也对整个系统的数据进行管理。而应用层由Driver、Worker和Actor三类进程组成，他们分别处理用户程序、无状态任务和有状态任务。机器学习相关的API和计算模型在应用程序层实现。 正是有了以上机制，在自动驾驶系统中各类有状态的任务，如：路线规划任务、跟车任务等可以在分布式平台上不改变其本身各项依赖地完成处理。而各类无状态的任务，比如在进行视频处理时可以将视频分成图片的集合，一个headnode将图片分发给各个workernode加速处理，最后headnode汇总处理。而由少数headnode和大量workernode组成的集群便是基于Ray的分布式系统，如图3所示。 图3. 远程分布式服务器集群结构示意图 Ray集群包括一组同类的工作节点和一个集中的分发结点。分发结点中的Driver进程是一种特殊的Worker进程，它负责执行用户程序，它将任务提交给其他Worker进程处理，因此能够了解程序各个部分的依赖关系，并且在合适的时间将任务分布式异步地在集群上进行处理。从而大大提升了单位时间内的计算速度。 Ray框架对于任务引入了Actor模型。在Ray中的Actor有状态，不同于Task (Ray中无状态，可细分的任务)，它源于一种并发模型，也是共享内存并发模型的替代方案。因此在Ray中使用的Actor模型提供给Ray将传统复杂分布式事务给拆分成由事件驱动的线性处理流程的能力。因此使得Ray框架的性能更好，吞吐量更高，从而响应速度更快。 在远程自动驾驶系统的应用中Ray集群将位于服务器端，它将接收来自车辆的数据，并且由一个集中的GCS控制，调用集群中可用的单元为车辆进行自动驾驶的计算。 通过Ray的独特设计，它能够通过调用多个工作节点来为远程自动驾驶系统提供以下功能： 1) 支持毫秒级的任务，同时拥有每秒处理百万级别任务数的能力。 2) 嵌套的并行性。Ray可以提供将一个任务拆分成数个并行处理的子任务，并且将这些子任务进一步拆分为更小的并行子任务。 3) 在运行的时候动态地确认任务的依赖。 4) 在共享的可变状态下运行任务。 5) 支持异构资源，如CPU、GPU等。 Ray提供的以上的特性能够满足自动驾驶的以下需求： 1) 自动驾驶对系统性能的要求。自动驾驶的各个任务需要动态执行，这些任务可能相互之间有着耦合，例如高精度地图、车道识别、路权优先级判断、长距离路径规划、短距离路径规划等等。嵌套的并行性能够使得这些任务以恰当的方式并行处理。而这种强大的并行能力又不会影响到有着共享的可变状态以及有着动态的依赖的任务。正是因为其强大的并行能力，因此分布式集群能大大加速任务处理的速度。 2) 自动驾驶复杂任务对异构硬件的需求。例如车道规划、图像识别、车辆控制等等任务，处理这些任务需要用到异构硬件。而Ray能够通过Actor来调用诸如CPU、GPU等异构资源，满足自动驾驶的需求。 2.3. 实验仿真 本文实验基于Python实现。硬件配置：4台相同配置计算机，CPU均为10900k，GPU均为RTX2080TI；软件配置：运行环境为Python 3.8.5；基于Ray 1.1.0框架和Redis 3.5.3数据库。若未特别说明则本文实验均基于此实验环境。 我们首先准备了48次基于SHA256哈希函数的计算任务用以模拟自动驾驶中所需要进行的任务。在分别由基于Ray的4台计算机系统、2台计算机系统以及单机平台上调用不同worker数量的情况下，统计完成计算任务的耗时。结果如图4所示，可以看到在16个worker的情况下Ray框架还能运用上CPU超线程的特性对计算进行加速。与调用单个Worker的计算耗时相对比，Ray的分布式集群大大降低了计算耗时，且随着节点和worker数量的增多节约更多计算时间。 图4. Ray集群同单主机平台完成任务耗时结果对比 图4显示在处理相同的复杂计算任务集合时，单主机平台完成计算任务所需时间与Ray分布式集群仅调用一个Worker的情况下所需时间相同，而随着分布式集群调用更多Worker后其所耗时间大幅度降低。将复杂运算交由基于Ray框架的分布式集群以加速运算是可以实现且效果很好的。以上面的任务为例，当有多个计算任务需要处理的时候单机平台受限于自身处理设备的并发量和计算能力，其算力是有一个明显的上限的。 图5. Ray与MPI在AllReduce中的平均执行时间 我们利用AllReduce来模拟分布式情况下的机器学习工作负载，在拥有4个节点的Ray集群上使用Ray的API实现的Ring AllReduce，又使用OpenMPI来进行Ring AllReduce，结果如图5所示，Ray集群在100 MB时和1 GB时均明显好于OpenMPI的成绩。这将在进行大量的数据处理时为自动驾驶任务节约出宝贵的时间。 而基于Ray框架的分布式系统则因为Ray的优秀的任务调度设计和分布式所带来的算力资源的极大丰富，其处理能力大大强于基于MPI的分布式计算系统以及单机系统。