深度剖析机器学习基础架构设计的核心逻辑

博文视点
在人工智能飞速发展的今天，机器学习已经成为推动技术革新的核心动力。然而，如何为机器学习应用设计高效、稳定的基础架构，却是许多从业者面临的难题。

下面我们将通过一个实际部署案例，深入分析设计者在实践中如何权衡各种要素，做出关键决策。无论是自动驾驶模型训练，还是基于云原生的高性能计算，抑或是计算、存储、网络需求的设计实现，本章都将为你揭示背后的逻辑与方法。

如果你对机器学习基础架构的设计感兴趣，千万不要错过这篇干货满满的内容！

需求来源：自动驾驶模型训练

2016年，美国国家公路交通安全管理局（NHTSA）提出了自动驾驶技术的五个分级，并在实践中获得了业界的广泛认可。
L0：人工驾驶，由人类驾驶员全权驾驶车辆。
L1：辅助驾驶，车辆对方向盘和加减速中的一项提供驾驶操作，人类驾驶员负责其余的驾驶动作。典型场景如车辆自适应巡航。
L2：部分自动驾驶，车辆对方向盘和加减速中的多项提供驾驶操作，人类驾驶员负责其余的驾驶动作。典型场景如同时开启车辆自适应巡航和车道自动保持两个功能。
L3：条件自动驾驶，由车辆完成绝大部分驾驶操作，人类驾驶员需保持注意力集中，以备不时之需。
L4：高度自动驾驶，由车辆完成所有的驾驶操作，人类驾驶员无须保持注意力集中，但限定道路和环境条件。
L5：完全自动驾驶，在任何道路和环境条件下，都可以由车辆完成所有的驾驶操作，人类驾驶员无须保持注意力集中。
由于L4及更高级别的自动驾驶能够替代人类驾驶运营车辆的工作，因此被视为未来生产力提升的重要突破方向，各大车企（主机厂）也逐年增加在自动驾驶领域的研发投入，期望在此领域占据行业领先地位，并转化为经济价值。
在高级别自动驾驶领域较早投入的车企代表为B公司。B公司作为有超过100年历史的业界头部车企，在2015年前后就将自动驾驶技术的研发作为企业战略的一部分，并不断加大投入。2017年，B公司决定在中国建设一个自动驾驶研发中心，并基于《中华人民共和国网络安全法》的合规要求，将承载自动驾驶研发业务的数据中心也设立在中国本地。
自动驾驶技术包括路径规划、行为决策、运动规划和执行控制等，这些环节的核心技术都基于深度神经网络的AI算法实现。因此，自动驾驶技术研发的核心就是基于机器学习的训练和仿真。
与其他机器学习的训练类似，自动驾驶的模型训练依赖于GPU服务器基于神经网络建模，对海量数据的学习，并将产生的权重送到HILS（Hardware InLoop Simulation，硬件在环仿真）和SILS（Software In-Loop Simulation，软件在环仿真），再将仿真产生的数据送回数据湖进行模型迭代。总计需要的训练算力约为500TFLOPS （双精度）、仿真算力约为1000TFLOPS（单精度）。
此外，还需要约2000核（以超线程后vCPU计算）的CPU算力，用于部署其他研发相关的应用。
自动驾驶模型训练一般使用TensorFlow为代表的机器学习框架来实现。由于模型本身也是频繁迭代的，这里需要基于容器平台部署TensorFlow及实现CI/CD，同时需要使用容器来进行GPU的调度。
自动驾驶使用的数据分为以下几部分。
（1）在路测车辆上采集的数据。每辆路测车每天产生的数据量约为100TB，包括以下数据。
激光雷达采集的车辆周边数据。
激光雷达采集的车辆周边数据。
从CAN总线及OBD接口采集的汽车内部各类传感器的数据，如发动机转速、瞬时油耗等。
（2）仿真产生的数据。其内容与第（1）部分的数据内容几乎相同，仿真每天约读取和产生数据各为10PB。
（3）高精地图。它包含精确的地理信息数据和道路实景，可以理解为将自动驾驶路测区域进行了数字化。
这些数据需要存放在一个数据湖中，其中第（1）部分的数据保存14天，第（2）部分的数据保存7天。由于数据湖是为机器学习训练与仿真集群提供服务的，需要支持POSIX语义，并支持在容器中安装数据湖的客户端。
为了将机器学习集群、数据湖、路测车数据收集终端、HILS集群和SILS集群连接在一起，为开发团队提供访问，B公司还需要建设一个高可靠、高性能、易扩展的网络来支撑这个大型分布式计算存储集群。
自动驾驶机器学习系统所需的各模块及数据流向如图1所示。

B公司自动驾驶开发平台的需求代表着自动驾驶机器学习系统对基础架构的普遍需求，也可以在一定程度上代表所有机器学习业务对基础架构的需求。
因此，为B公司自动驾驶开发平台设计的基础架构集群方案也可以被改造后用于其他机器学习业务场景。

基于云原生的高性能计算模型训练

我们基于自动驾驶开发的需求，设计的自动驾驶机器学习系统的总体方案如图2所示。

在图2中，我们把自动驾驶机器学习系统分为如下四层。
（1）硬件层：包括存储池、计算池及连接节点的网络。
（2）存储与计算调度层：包括分布式存储软件和计算调度平台。
（3）数据层：包括数据工具及机器学习套件。
（4）可视化与协作工具：包括监控、检索及其他可视化组件。
此外，还有保证系统符合网络安全法规的一系列安全工具。
接下来将详细介绍系统中各层次和各模块的实现，特别是本书重点讲述的硬件、分布式存储和计算调度方面的内容。

计算需求分析与设计实现

B公司自动驾驶开发平台的计算与仿真需求可以使用GPU服务器集群实现。
对于训练型计算需求，我们使用了当时最先进的Nvidia Tesla V100 GPU实现。
每张Nvidia Tesla V100卡都具备7.8TFLOPS的双精度浮点运算能力。对于训练型计算的0TFLOPS的双精度浮点计算需求，需要64张Tesla V100卡（SXM2接口），也就是需要8台8卡GPU服务器。为保证控制平面的性能，GPU服务器也配置了Intel Xeon Scalable 8160处理器，每颗都具备24个物理核、48超线程，2路整机可以提供96个vCPU。由于Nvidia Tesla V100卡需要通过RoCE与其他机器的GPU进行通信，因此我们还为GPU服务器配置了两张100Gbps以太网接口卡。整机配置为：Intel 8160 CPU×2，768GB RAM，480GB SSD×2（RAID0），1.92TB NVMeSSD×2，Nvidia V100 SXM ×8/100GE×2/25GE×2。
对于推理型计算需求，我们使用Nvidia的推理型GPU Tesla T4实现。每张Nvidia Tesla T4都具备8.1TFLOPS的单精度浮点运算能力，124张Nvidia Tesla T4 GPU能满足1000TFLOPS的单精度计算需求。推理型GPU的服务器可以使用经济型的CPU：Intel Xeon Scalable 6138，每颗都有20个物理核。整机配置为Intel 6138 CPU×2，384GB RAM，480GB SSD×2（RAID0），Nvidia T4×4，25GE×2，共31台。
其他计算节点使用Intel 6138处理器实现，共25台，整机配置为Intel 6138 CPU×2，384GB RAM，480GB SSD×2（RAID0），10GE×2，能够提供80个vCPU。
由于用户有CI/CD的要求，并且期望使用Kubeflow一类的框架，在容器中部署TensorFlow，计算的调度需要使用容器平台。B客户综合考虑后选择了Redhat Openshift Container Platform（OCP），它是一个Kubernetes容器平台，并具备Service Mesh能力和对接Jenkis Devops平台的能力。Kubernetes的Master和Node都使用普通物理机实现，并通过Device Plugin机制调度GPU。

存储需求分析与设计实现

考虑到数据湖需要冷、温、热数据分层，并且需要提供海量数据的存储及高性能存取，我们采用MAPR实现数据湖。在10.3.2节中提到，MAPR是一个全分布式的系统，其性能能够随节点数线性提升。
模型和高精地图数据是所有的计算和仿真都需要访问的热数据，我们使用全SSD+三副本存储来实现，特别是要增加足够大的内存为MAPR提供缓存，整机配置为Intel 8160 CPU×2，768GB RAM，1.92GB SATA SSD×24，480GB SATA SSD×2，25GE×2，每台都可以提供46TB的物理容量，做三副本并保留部分冗余后，每台都可以提供12TB有效容量，整个集群共有20台。
其他从道路采集或仿真产生的图像等数据被视为温数据，与沉降后的冷数据类似，都采用纠删码方式来存储，只是纠删码比例有所差异。冷温存储节点的配置为Intel 4110 CPU×2，384GB RAM，480GB SATA SSD×2，12TBSATA×60，25GE×2，使用大量的SATA盘提供低成本、高密度的存储，整个集群共有280台。
MAPR具备适配了Docker和Kubernetes的客户端，Docker和Kubernetes发放的容器可以挂载MAPR提供的文件目录进行存储。
此外，在整个系统中还需要为Kubernetes及一些虚拟机提供共享的块存储和对象存储，这里使用了Ceph来提供存储卷。为提升性能，在集群中使用了SSD作为缓存，配合HDD提供较大的存储容量，整机配置为Intel 4110CPU×2，256GB RAM/480GB SATA SSD×2，1.92TB NVMe SSD×2，12TB SATA×12/25GE×2，整个集群共有6台。

网络需求分析与设计实现

在13.3节～13.4节，我们基于B公司的业务需求，评估了构建自动驾驶开发平台所需要的服务器数量，如表1所示。

其中，所有的服务器都需要通过10G以太网或25G以太网接口卡连接业务网络，而GPU训练服务器还需要另一张RoCE网络。
基于这些需求，我们规划的组网如图3所示。

在图3中，所有接入的交换机采用25G/10G以太网下连到服务器，服务器的两个25G/10G网口工作在Bond模式4，并连接到一对接入交换机。接入交换机通过100G以太网上连到核心交换机。核心交换机通过100G以太网连接到边界交换机。边界交换机上旁挂防火墙实现安全隔离。
此外，所有的GPU训练服务器还通过100G RoCE交换机互通，两张网卡各连接到两台RoCE交换机，实现冗余。由于训练服务器只有8台，暂时不需要过于复杂的组网。
为了提供服务器和交换机的带外管理，我们还增加了千兆下行、万兆上行的带外网络，连接到各服务器的IPMI口及交换机的带外管理口，并连接到边界交换机，为用户提供带外管理通道。
B公司自动驾驶开发平台组网设备整网的配置如表2所示。