2月22日-26日，计算机体系结构顶级会议HPCA 2020在美国加州圣地亚哥召开。阿里巴巴共有两篇论文入选，是国内唯一有论文收录的企业，其中一篇名为《EFLOPS: Algorithm and System Co-design for a High Performance Distributed Training Platform》，该论文系统性介绍了阿里巴巴的高性能AI集群的节点架构、网络架构、和通信算法，并展示了EFLOPS集群为阿里巴巴内部业务带来的价值。论文第一作者、阿里巴巴高级技术专家董建波对此做了详细解读。
过去几年，AI一直是业界最受关注的领域之一，围绕AI的技术研究热度一直居高不下，包括AI算法模型、训练框架、以及底层的加速器设计等。然而极少有人从集群架构角度探究过，AI业务的运行模式与传统大数据处理业务的差别，以及AI集群的架构设计应该如何优化。
为解决这一问题，阿里巴巴率先投入了高性能AI训练集群EFlops的研发，通过算法架构的协同设计，通信算法的效率达到理论上限，实现了集群规模的近线性扩展。通过和拍立淘团队合作在EFlops系统上，将拍立淘百万分类大模型的训练速度提升4倍，并首次支持千万分类模型的训练；与阿里巴巴机器翻译团队合作，提升阿里巴巴翻译模型精度的同时，将训练时间从100小时降低至12小时。
论文作者之一，阿里巴巴资深技术专家蒋晓维在会议现场分享
1. AI训练的算力需求
人工智能已经广泛应用在阿里巴巴集团内部的各个业务，包括：搜素推荐、智能翻译、预测服务、城市大脑、自动驾驶等。为了获得更好的识别准确率，神经网络的模型和相关的训练数据集急剧增长。因而，复杂大模型训练的训练时间也开始以“星期”甚至“月”为单位开始计量，比如，拍立淘增量训练的数据集高达数亿张图片，使用1张GPU进行训练需要两周时间；而从全量训练需要几十亿张图片，需要2-3个月才能完成。除了海量数据的获取和理论算法的革新，AI的快速发展更离不开AI计算能力的提升和基础设施的演进。
EFlops是阿里云智能基础设施事业部（AIS）联合达摩院机器智能、阿里云智能计算平台、达摩院计算技术实验室及平头哥等多个团队，共同建设的高性能AI训练集群。旨在研制下一代AI计算系统，可同时为训练和推理任务提供算力支持，更好地支撑阿里巴巴未来机器学习业务（如城市大脑、搜索推荐等云端AI需求）。
2. 传统数据中心的问题
AI业务既不同于大数据处理，也不同于高性能计算业务。直接采用传统数据中心架构来构建AI集群，会面临很多问题，导致集群的扩展性和规模受到很大限制。AI业务与通用大数据处理业务有着不同的计算模型。如下图所示，传统大数据处理业务是通量型负载，其子任务独立性强，处理流程以流式或单向图为主。而AI业务则是高性能计算负载，子任务之间交互频繁，一个迭代的计算任务启动依赖于上一迭代的计算完成。此外，AI业务与高性能计算业务有着不同的通信模型。传统高性能计算业务以GPU等加速器为协处理器，以CPU为中心，负责节点间通信。而AI业务大量采用GPU等加速器作为业务计算的主体，仍然沿用原有以CPU为中心的通信架构，势必引入复杂的通信层次，造成极低的通信效率。
3. EFlops网络化服务器架构
如上图所示，传统服务器架构存在三种拥塞。首先，传统的数据中心服务器通常只配备一个网络接口（独立网卡或者Bond网卡），当该服务器配备多个高速IO设备时（比如GPU）并通过网络接口直接通信，就会面临很大的流量汇聚，成为系统的瓶颈。其次，类似的端口拥塞会发生在PCIe Root Port上。当多个高速IO设备同时访问系统主存时，PCIe Root Complex需要接收所有设备发来的访存请求，并转发至CPU内部总线，再通过DDR总线访问系统主存。需要说明的是， AI训练过程也被划分为多个迭代，每个迭代中都要进行梯度的同步和参数更新，然后才能启动下一批次的数据载入。因此，对分布式AI训练任务而言，同步式的网络接口和内存访问非常常见。此外，GPU之间的通信距离的差异会导致显著的性能差异。CPU socket之间的QPI/UPI进一步加剧了这一性能差异。而AI训练任务的梯度AllReduce是一个全局性的同步操作，其完成时间往往受限于最慢的链路。所以这种链路带宽的不公平性也会导致系统性能的下降。
如上图所示，为了降低上述端口拥塞问题，我们在每个服务器内配备了与GPU等量的NIC，并将GPU和NIC进行绑定配对，使每一对绑定的GPU和NIC处于同一PCIe Switch之下，约束GPU的网络通信只能经由自己绑定的NIC。这样，GPU的网络通信流量全部被局限在PCIe Switch之内，避免了网络接口上的拥塞。同时，我们将包括GPU和NIC在内的所有高速IO设备尽量平均分布于所有可用的Root Port上，以缓解对同步式访存对Root Complex的压力。最后，在PCIe Fabric流量较大的情况下，可以禁用GPU之间通过PCIe Fabric直接通信，使其通过网络接口进行通信，利用网络协议栈的流量控制机制来降低系统的拥塞程度。
4. EFlops系统互连架构
当前很多数据中心的网络拓扑都采用Fat-tree，它将网络中的交换服务器划分为多个层次，各层都具有相同的对剖带宽。但由于路径选择的哈希算法总是存在碰撞的可能，网络中的拥塞是无法避免的。虽然TCP/IP网络的拥塞控制算法已经非常成熟，而拥塞控制在RDMA网络中仍然是一个巨大的挑战。在EFlops项目中，我们并不是从拥塞控制算法角度出发，而是从更上层进行网络的流量管理，以彻底解决网络的拥塞问题。
如图3所示，配合多网卡服务器结构，我们在EFlops项目中提出了BiGraph网络拓扑。该拓扑与传统的Fat-tree拓扑有相似之处，也存在根本的区别。与Fat-tree拓扑类似，我们将网络中的分为两部分（Upper和Lower），各部分之间通过Clos架构进行互连，形如两层Fat-tree拓扑的Spine和Leaf交换机。与Fat-tree不同的是，我们在两部分交换机上都可以直接接入计算服务器；即每一个交换机都扮演了Fat-tree拓扑中的Spine和Leaf两个角色，最大跳步数为3。
BiGraph拓扑具有两个重要的特性：1）他在两层交换机之间提供了丰富的物理链路资源。在N个计算服务器的系统中，两层交换机之间至少存在着N/2个物理链路可供使用。2）接入不同层次的任意两个计算服务器之间的最短路径具有唯一性。我们可以充分利用这一特性，在通信库甚至更高层次进行服务器间通信模式的管理。比如，在建立连接的时候，选择合适源和目的服务器，来控制网络上的路径选择。
5. EFlops算法架构协同设计
Allreduce是数据并行训练场景下的最主要集合通信操作，其中常用的通信算法包括Ring-based、Tree-based和Halving-Doubling等（后文以Ring、Tree、HD作为简称）。本文主要关心Ring算法和HD算法，因为前者算法是应用范围最广的算法之一，而后者是本文的优化对象。
Ring算法的主要流程包括：1）接收左侧节点发送来的一个chunk数据，2）并与本地数据进行制定allreduce操作，生成allreduce操作的中间值，3）将上一个step生成的中间值发送给右侧节点；4）将接收和发送的数据chunk指针进行更新。HD算法主要流程包括：1）将所有节点按照距离进行配对，2）每个节点发送一半数据给配对节点，并接收另一半数据进行allreduce操作，3）每个新的step，所有节点重新配对；其中，配对的距离加倍，而传输的数据量减半（也就是上一个step接收数据的一半）。
可以看到，Ring和HD算法在数据传输量上没有区别，都是2S；其中S是Message的大小。从通信次数角度看，Ring算法需要N-1个Step的通信，而HD算法只需要log2N个Step；其中N是参与节点个数。而Ring算法只需要N个连接，而HD算法需要N*log2N个连接。需要特别指出的是，HD算法的每个Step只需要N/2个连接。
结合BiGraph拓扑的特性进行分析，可以看到：BiGraph拓扑两层交换机之间存在N/2个物理链路，而HD算法每个step需要N/2个连接。BiGraph拓扑两层交换机之间最短路径的确定性，提供了一种可能性：将HD算法的连接和BiGraph拓扑的物理链路进行一一映射，避免他们之间的链路争用，以彻底解决网络拥塞问题。
基于此，我们进一步提出了Rank映射算法，将HD算法的通信连接一一映射至BiGraph网络的物理链路，避免了网络的拥塞，该算法Halving-Doubling with Rank-Mapping（HDRM）已实现于我们定制的集合式通信库ACCL。算法具体步骤和算法结果举例如图：
6. EFlops性能评估
为了评估EFlops系统的性能，我们部署了16个节点，共计64个GPU的训练集群。其中每个节点配置了4个Tesla V100-32G的GPU，以及4个ConnectX-5 100Gbps网卡。网络环境按照BiGraph拓扑进行设计，其中8个物理交换机划分为16个虚拟交换机，分别部署于BiGraph的两层。基于此平台，我们对分别对通信性能和应用端到端性能进行评估。
6.1 通信性能评估
实验结果表明：在64-GPU系统规模下，EFlops的HDRM算法小包（比如1KB Message）通信性能，是Ring算法的6倍；对大包（比如256MB Message），HDRM算法带宽比Ring高10Gbps。原始的HD算法小包性能优于Ring，因为小包性能决定于通信延迟；HD算法只需要log2N个step，而Ring算法需要N个step。相反，Ring算法的大包性能优于HD，因为大包的性能取决于有效带宽；HD算法连接数更多，受拥塞影响更大，因此性能较差。随着系统规模增加，小包通信延迟增加，大包通信带宽降低。EFlops的HDRM算法性能受系统规模影响最小，体现出最好的规模扩展性。
6.2 应用性能评估
我们对MLPerf的ResNet50模型进行了评估，在达到指定准确率之后，计算单位时间图片处理数量。如图呈现了EFlops系统和单网卡系统的性能对比，包括全系统吞吐量和单GPU平均吞吐量。可以看到，EFlops系统的性能基本达到了线性扩展，而单网卡系统的单位吞吐量明显随着规模逐步下降。与世界顶级的AI计算系统相比，EFlops虽然使用了性能较低的硬件资源（V100-PCIe性能低于V100-SXM2约10%）也表现出了相当的性能。
我们分析了阿里巴巴内部应用的性能收益。以拍立淘百万分类模型为例，EFlops系统可以提升通信性能5.57倍，端到端性能34.8%。因为通信量占比不高，HDRM算法提升通信性能43.5%，整体性能4.3%。对Bert模型而言，通信量明显高于拍立淘百万分类模型，仅HDRM算法就可以提升通信性能36%，端到端性能15.8%。
可以预见，随着系统规模进一步增长，EFlops的性能收益将显著提升。基于64节点集群的收益，我们进一步搭建了512 GPUs的高性能AI训练集群。初步的评测结果显示，EFlops集群仍然能保持接近线性的扩展性（基于ImageNet训练集，Resnet50 模型）。
7. 结论
针对AI算力日益增长的需求，大规模AI训练集群的架构设计显得尤为关键。在分析传统数据中心架构的不足，以及相应的负面影响，我们提出了EFlops的一体化系统设计方案。通过网络化服务器架构、BiGraph网络拓扑、以及相应的HDRM通信算法，EFlops系统实现了近线形扩展，显著提升了阿里巴巴AI业务的性能。
