作者|ShiLang,Manshen近年来，随着稀疏模型计算能力的需求越来越大，CPU集群必须不断扩大集群规模以满足训练时效性要求，这也带来了资源成本和实验调试成本的上升。为了解决这个问题，阿里云机器学习PAI平台开源了针对稀疏模型的高性能同步训练框架HybridBackend，在同等成本下，GPU集群的训练吞吐量提升至CPU集群的5倍，大大降低了调试成本。也包含在ICDE22'中。HybridBackend背后的技术框架是如何设计的？未来有什么计划？今天让我们详细了解一下。1.什么是HybridBackend？HybridBackend是阿里云机器学习平台PAI开发的用于稀疏模型训练的高性能同步训练框架。其核心能力是以GPU集群的单位成本大幅提升训练吞吐性能。目前，HybridBackend已在阿里巴巴集团内落地多项业务，将阿里妈妈智能引擎训练引擎团队定向广告业务的年度数据训练任务时间从1个月缩短至2天。在企业中也有成功的应用。二、项目背景以搜索、推荐、广告业务为主要应用的稀疏模型训练系统一直是学术界和工业界的研究热点之一。与以计算机视觉（CV）和自然语言处理（NLP）为代表的密集模型训练相比，稀疏模型对离散特征（以分类ID作为训练数据）使用Embedding特征表达，具有数百GB到数十TB的内存.占用和消耗（比普通CV和NLP模型参数高一到两个数量级），从而突破单机内存容量限制，需要基于分布式系统的训练方案。由于此类早期分布式任务的模型结构相对简单，更新迭代速度较慢，因此通常采用定制的参数服务器（ParameterServer，PS）系统在大规模CPU集群上进行训练。随着以TensorFlow为代表的通用机器学习编程框架的出现，以及深度神经网络（DNN）在推荐模型（deeprecommendersystems）上的流行，业界逐渐转向通用机器学习编程框架（TensorFlow、PyTorch等）.)模型的端到端训练和推理，但此时仍以参数服务器（PS）和大规模CPU集群作为训练范式和基础设施。3.面临挑战随着稀疏模型计算能力需求的增加（比如Attention等结构的加入），CPU集群必须不断扩大集群规模以满足训练的时效性要求，这也带来了资源成本的上升实验的调试成本。以NVIDIAGPU为代表的加速器（accelerator）弥补了CPU设备单位成本和计算能力低的劣势，其在CV、NLP等对计算能力要求较大的训练任务中的应用已成为业界共识。但实践证明，简单地将PS训练范式中的worker从CPU设备换成GPU设备，并不能有效提高训练任务的吞吐量。通过剖析GPU的使用率，发现大量GPU计算资源闲置浪费。这表明，与CV和NLP任务相比，稀疏模型训练具有自己的模型结构和训练数据的特点，使得传统的PS训练范式无法有效发挥GPU设备的优势。我们以深度推荐系统经典的WideandDeep模型结构和TensorFlow框架为例，分析总结了PS架构下使用GPU设备训练的两个问题。1.改变硬件资源瓶颈从上图的WideandDeep模型结构可以看出，稀疏训练主要由Embedding阶段、特征交互阶段和多层感知器（MLP）阶段组成。Embedding阶段在PS范式中的训练至少占用了50%的训练时间。经过分析发现Embedding阶段的算子主要是内存访问密集型和通信密集型算子。需要的硬件资源主要是内存和网络带宽，而后两个阶段算子以计算密集型算子为主，需要的资源是算力。这意味着在PS范式训练下，在任何阶段，都可能出现某种硬件资源成为瓶颈，其他硬件资源被浪费的现象。以GPU的计算资源为例，我们观察到GPU使用率（SMUtil）在不同的训练阶段之间呈脉冲状变化（pulse）。2.算子碎片化（fragmentation）实际生产模型往往有数百个embeddingfeaturequery，每个featurequery会调用TensorFlow中的几十个operatoroperations（操作）。TensorFlow引擎在调度大量数千级操作时，需要额外的CPU线程开销；对于GPU设备，过多的CUDA内核提交给流处理器（TensorFlow下每个GPU设备只有一个流抽象）带来了GPUStreamMultiprocessor（SM）的调度开销，同时，数据处理的并发性每个算子的计算量不高，所以很难填满GPU的计算单元。CV、NLP等密集模型的训练也涉及到类似的问题。一般采用基于编译技术的优化方法来组合算子。在Wide和Deep模型等稀疏场景中，Embedding阶段的这些算子往往具有动态形状的特点。在TensorFlow的静态组合阶段，无法获取准确的算子大小进行优化。因此，像TensorFlow-XLA这样的技术被用在这种场景中并没有明显的收获。这些问题表明，为了最大限度地发挥GPU等高性能硬件资源的成本效益，提高单位成本的训练吞吐量，必须设计一种新的训练框架。据了解，国内外具有大规模搜索、广告、推荐业务的公司和硬件厂商都在开始研发新的框架，如NVIDIA的Merlin-HugeCTR[1]等。但是，阿里巴巴集团的云集群一般部署的是一个通用的计算节点，需要在集群上执行各种异构任务。切换到专用硬件非常昂贵且不切实际。基于这种实际需求，我们推出了HybridBackend，它可以同时适应集团内多样化和不断发展的稀疏模型技术。下面简单介绍一下HybridBackend的系统架构设计和技术亮点。4.HybridBackend的系统架构传统的参数服务器（PS）训练范式体现了通过扩展硬件数量来适应模型训练规模的思想。我们的系统同时考虑了硬件和软件（模型）层面的特点，实现了协同设计。高性能GPU集群的硬件特性决定了基本的训练范式，而稀疏模型本身的结构特性和数据分布带来的问题则通过更精细的系统优化方法来解决。1.使用大batchsize进行同步训练由于GPU设备带来的算力相对于CPU的巨大提升，过去需要几百个CPU节点的集群可以被几十台机器的GPU集群所取代。为了保持相同的总训练规模，同时提高单个GPU节点上的资源利用率，增加单个GPUworker上的batchsize成为必然选择。同时，由于集群规模的减小，通过同步训练可以有效避免陈旧，从而提高模型训练的准确率。与CPU设备之间通过PCIe和TCP进行网络通信相比，高性能GPU集群往往在单个节点的多个GPU设备之间配备高速网络互连（NVLink、NVSwitch）。这些高速连接的带宽通常是TCP网络带宽的数百倍（第一代NVLINK标定达到300GB/s），还可以配备基于RDMA技术的高速网络设备多个机器节点之间实现100-200Gbps的带宽。选择同步训练的第二个好处是可以使用高性能的集体通信算子库（NVIDIANCCL、阿里自研ACCL等）有效利用硬件机器的网络拓扑结构，从而提高通信性能。上述通信库在CV、NLP等基于数据并行的同步训练任务中取得了不错的效果。2.在培训单元中使用异构资源和同构角色。PS训练范式在系统的逻辑层面规定了不同的训练角色，如server、worker、evaluator。Server节点一般分配给大内存的CPU机器，而worker节点分配给计算频率高的CPU硬件。这样就形成了训练单元-任务角色-同质资源的耦合，通过增加训练单元的数量来横向扩展（scaleout）训练规模。在高性能GPU集群上，一个物理机节点往往包括多种异构硬件资源，如CPU、GPU处理器、GPU之间的高速互连、DRAM（动态随机存取存储器）、Non-volatileMemory（非volatilememory)等。这样除了横向扩展节点数量外，还可以通过纵向扩展利用多种异构硬件资源来达到扩展训练规模的目的。对于这种硬件架构，我们在系统设计中只保留一个统一的训练执行单元（Executor），每个Executor通过内部异构硬件资源执行不同的训练任务角色。一方面，在Executor内部任务执行时，可以有效利用底层硬件资源之间的局部性，加速训练；另一方面，Executor内部的硬件资源可以同时满足不同分布式训练范式所需要的硬件资源，这样我们就可以在模型结构的不同部分采用Hybrid并行训练策略。5.深度优化：HybridBackend的技术亮点由于稀疏模型结构和训练数据本身的特点，不断变化的硬件资源瓶颈和算子碎片化，上述系统架构仍然会对利用率产生一定的影响GPU等硬件设备在实际任务中的使用。问题。例如，在同步训练范式下，当所有Executor通过集体通信进行embeddingshuffle时，网络带宽资源成为瓶颈，而GPU计算资源闲置。一种解决方案是定制硬件资源，比如增加网络带宽资源以消除通信瓶颈，但这样的做法会将硬件资源配置与特定的模型结构耦合，这是一个专门推荐系统的老思路。我们的目标仍然是希望系统能够建立在云服务上可用的通用硬件配置（commodityhardware）上，并且可以很容易地水平扩展。一些硬件厂商也尝试以Hugekernel（人工将Embedding层的所有计算整合到一个kernel中）的形式来解决operatorfragmentation的问题。设计通用编程框架的初衷。基于此，我们基于软硬件协同的思想，设计了以下系统优化方法：1.基于数据与操作者感知的结合根据稀疏模型的结构特点，大部分细粒度的operators来自于庞大的Embedding特征查找（lookup）的数量，我们设计了一种称为D-Packing的优化技术。对于每个查询，虽然输入的训练数据不同，但使用的算子组合是相同的。对于这种具有数据并行性的模式，具有相同属性（维度、初始化器、校准特征组等）的Embedding表将被合并为一个新的Embedding表，后续的fetch查询算子也可以合并为一个新的大算子。merge算子可以多线程的方式顺序查询Embeddings，相对于乱序查询或者分成几个小表的查询，可以显着提高性能。查询完成后，根据原有代码需求进行去重和重定位，真正做到对用户透明。此外，通过分析分布式环境中特征查询阶段每个算子的语义，我们将一些内核与K-Packing融合，例如通过融合shuffle和stitch算子来消除冗余数据副本。通过数据和算子的语义融合，我们不仅减少了算子的整体数量，减少了碎片化，还避免了所有算子融合在一起的损失，通过穿插算子速率优化机会来提高硬件利用率。2.基于硬件资源瓶颈感知的交错执行为了消除具有相同硬件资源需求的算子同时执行造成的瓶颈，我们设计了两种交错算子的优化方法。首先，D-Interleaving利用流水线机制，通过对训练数据batch进行分割，对不同资源类型的operator进行调度交织，从而在训练的任何阶段都可以缓解某一资源的瓶颈。例如，在大batchsize的训练场景下，稀疏模型的MLP阶段也会产生featuremap的高内存占用。通过D-Interleaving，可以有效降低单个GPU设备的内存使用峰值，从而使更大的batchsize训练成为可能。其次，K-Interleaving在EmbeddingLayer内部的不同特征查询通道之间交织覆盖算子。例如覆盖通信密集型Shuffle操作和内存访问密集型Gather可以有效提升这两种资源。使用率。3.基于数据频率感知的参数缓存为了解决多级存储（GPU显存、DRAM等）之间的带宽和延迟问题，采用访问频率分布缓存机制。通过统计训练数据的ID，访问最热的数据缓存在GPU的显存中，冷数据和哈希表结构存储在主存中。主存中的数据会随着ID的访问频率而变化。对应于top-k高频ID的嵌入被刷新到GPU内存上的缓存中。这种混合存储可以同时结合GPU内存的高带宽和DRAM的大容量。未来，这种混合存储设计还可以扩展到使用更多的硬件设备，如英特尔持久内存和非易失性内存。六、应用场景HybridBackend已成功落地阿里妈妈智能引擎训练引擎团队的定向广告业务。在阿里妈妈CAN模型下，HybridBackend较上一代XDL训练框架具有明显的性能优势。你可以在下表中看到它在训练时间等多个指标上的显着提升。同时，我们也根据阿里妈妈一年的精准投放训练数据，测试了HybridBackend在模型规模增长下的表现。结果如下表所示。可以看到，使用128个GPU训练一个千亿规模的参数模型时，同样消耗了1年的数据。高性能集群上的HybridBackend仅需2天即可完成训练任务，而普通集群上的XDL-PS模式则需要1个月左右。7.Roadmap的后续我们计划定期发布Release版本。近期路线图如下：v0.6.0（2022年5月）：支持端到端的分布式同步训练和评估。v0.7.0（2022年9月）：优化了GPU利用率和显存使用率。v0.8.0（2023年1月）：进一步优化云训练性能。此外，在中长期，我们将在训练策略的演进、新硬件的优化、服务化能力的支持等几个探索方向上持续投入。我们也欢迎来自各个维度的反馈、改进建议和技术讨论。同时，我们欢迎并期待有志于开源社区建设的同仁参与共建。开源地址：https://github.com/alibaba/HybridBackend参考文献[1]Oldridge,Even,JulioPerez,BenFrederickson,NicolasKoumchatzky,MinseokLee,ZehuanWang,LeiWu等人。“Merlin：GPU加速推荐框架。”在美国国税局的程序中。2020.论文详情论文标题：PICASSO:UnleashingthePotentialofGPU-centricTrainingforWide-and-DeepRecommendationSystems论文作者：张元兴、陈浪石（合著者）、杨斯然、袁曼、易慧敏、张杰,王家芒,董建波,徐云龙,宋越,李勇,张迪,林伟,屈林,郑波论文链接：https://arxiv.org/abs/2204.04903
