阿里开源 支持10万亿模型的自研分布式训练框架EPL(Easy Parallel Library)

本文涉及的产品
模型在线服务 PAI-EAS,A10/V100等 500元 1个月
模型训练 PAI-DLC,5000CU*H 3个月
交互式建模 PAI-DSW,每月250计算时 3个月
简介: 最近阿里云机器学习PAI平台和达摩院智能计算实验室一起发布“低碳版”巨模型M6-10T,模型参数已经从万亿跃迁到10万亿,规模远超业界此前发布的万亿级模型,成为当前全球最大的AI预训练模型。同时做到了业内极致的低碳高效,使用512 GPU在10天内即训练出具有可用水平的10万亿模型。

作者:王林、飒洋


导读

最近阿里云机器学习PAI平台和达摩院智能计算实验室一起发布“低碳版”巨模型M6-10T,模型参数已经从万亿跃迁到10万亿,规模远超业界此前发布的万亿级模型,成为当前全球最大的AI预训练模型。同时做到了业内极致的低碳高效,使用512 GPU在10天内即训练出具有可用水平的10万亿模型。相比之前发布的大模型GPT-3,M6实现同等参数规模,能耗仅为其1%。M6模型训练使用的正是阿里云机器学习PAI平台自研的分布式训练框架EPL(Easy Parallel Library,原名whale)。EPL通过对不同并行化策略进行统一抽象、封装,在一套分布式训练框架中支持多种并行策略,并进行显存、计算、通信等全方位的优化,来提供易用、高效的分布式训练框架。


EPL背后的技术框架是如何设计的?作为开发者我们可以怎么使用EPL?未来有哪些规划?今天一起来深入了解。


EPL是什么

EPL(Easy Parallel Library)是阿里最近开源的,统一多种并行策略的、灵活易用的自研分布式深度学习训练框架。


项目背景

随着近些年深度学习的火爆,模型的参数规模也增长迅速,OpenAI数据显示:

  • 2012年以前,模型计算耗时每2年增长一倍,和摩尔定律保持一致;
  • 2012年后,模型计算耗时每3.4个月翻一倍,远超硬件发展速度;

特别最近一年模型参数规模飞速增长,谷歌、英伟达、阿里、智源研究院都发布了万亿参数模型,有大厂也发布了百亿、千亿参数模型。随着模型参数规模增大,模型效果也在逐步提高,但同时也为训练框架带来更大的挑战。当前已经有一些分布式训练框架,例如:Horovod、Tensorflow Estimator、PyTorch DDP等支持数据并行,Gpipe、PipeDream、PipeMare等支持流水并行,Mesh Tensorflow、FlexFlow、OneFlow、MindSpore等支持算子拆分,但当我们要训练一个超大规模的模型时会面临一些挑战:

  • 如何简洁易用:
  • 接入门槛高:用户实现模型分布式版本难度大、成本高,需要有领域专家经验才能实现高效的分布式并行策略;
  • 最优策略难:随着研究人员设计出越来越灵活的模型,以及越来越多的并行加速方法,如果没有自动并行策略探索支持,用户很难找到最适合自身的并行策略;
  • 迁移代价大:不同模型适合不同的混合并行策略,但切换并行策略时可能需要切换不同的框架,迁移成本高;


  • 如何提高性价比:
  • 业界训练万亿规模模型需要的资源:英伟达 3072 A100、谷歌 2048 TPU v3,资源成本非常高;
  • 如何降本增效,组合使用各种技术和方法来减少需要的资源,提高训练的速度;


为了应对当前分布式训练的挑战,我们研发了分布式训练框架EPL,将不同并行化策略进行统一抽象、封装,在一套分布式训练框架中支持多种并行策略。EPL同时提供简洁易用的接口,用户只需添加几行annotation即可完成并行策略的配置,模型代码不需要改动。在用户无感的情况下,EPL通过进行各种显存、计算、通信优化,打造高效的分布式训练框架。


主要特性

  • 多种并行策略统一:在一套分布式训练框架中支持多种并行策略(数据/流水/算子/专家并行)和其各种组合、嵌套使用;
  • 接口灵活易用:用户只需添加几行代码就可以使用EPL丰富的分布式并行策略,模型代码无需修改;
  • 自动并行策略探索:算子拆分时自动探索拆分策略,流水并行时自动探索模型切分策略;
  • 分布式性能更优:提供了多维度的显存优化、计算优化,同时结合模型结构和网络拓扑进行调度和通信优化,提供高效的分布式训练;


开源地址

EPL(Easy Parallel Library)的开源地址是:

https://github.com/alibaba/EasyParallelLibrary

我们同时提供了model zoo,欢迎大家试用:

https://github.com/alibaba/FastNN


EPL主要技术特点

EPL通过丰富并行化策略,简单易用的接口,多维度的显存优化技术,和优化的计算通信加速技术,让每一个算法工程师都能轻松训练分布式大模型任务。

  • 丰富的并行化策略:EPL提供了多种并行化策略及其组合策略,包含数据并行,流水并行,算子拆分并行及并行策略的组合嵌套。丰富的策略选择使得不同的模型结构都能找到最适合自己的分布式训练方式。
  • 易用性:用户的模型编程接口和训练接口均基于TensorFlow,用户只需在已有的单机单卡模型上做简单的标记即可实现不同的分布式策略。EPL设计了两种简单的策略接口(replicate/split)来表达分布式策略及混合并行。分布式策略标记的方式让用户无需学习新的模型编程接口,仅需几行代码即可实现和转换分布式策略,极大降低了分布式框架的使用门槛。
  • 显存优化:EPL提供了多维度的显存优化技术,包含自动重算技术(Gradient Checkpoint),ZeRO数据并行显存优化技术,CPU Offload技术等,帮助用户用更少的资源训练更大的模型。
  • 通信优化技术:EPL深度优化了分布式通信库,包括硬件拓扑感知,通信线程池,梯度分组融合,混合精度通信、梯度压缩等技术。


技术架构

EPL框架如下图所示,主要分为以下几个模块:

  • 接口层:用户的模型编程接口基于TensorFlow,同时EPL提供了易用的并行化策略表达接口,让用户可以组合使用各种混合并行策略;
  • 中间表达层:将用户模型和并行策略转成化内部表达,通过TaskGraph、VirtualDevices和策略抽象来表达各种并行策略;
  • 并行化引擎层:基于中间表达,EPL会对计算图做策略探索,进行显存/计算/通信优化,并自动生成分布式计算图。
  • Runtime执行引擎:将分布式执行图转成TFGraph,再调用TF 的Runtime来执行;


并行化策略表达

EPL通过strategy annotation的方式来划分模型为多个TaskGraph,并在此基础上进行并行化。 EPL有两类strategy:replicate 和 split。通过这两种并行化接口,可以表达出各种不同的并行化策略,例如:

  1. 数据并行: 下面这个例子是一个数据并行的例子,每个模型副本用一张卡来计算。如果用户申请了8张卡,就是一个并行度为8的数据并行任务。


  1. 流水并行:在下面的例子里,模型被切分成2个 TaskGraph, "stage0"和"stage1",用户可以通过配置pipeline.num_micro_batch参数来设定pipeline的micro batch数量。 在这个例子里,"stage_0"和"stage_1"组成一个模型副本,共需要2张GPU卡。如果用户申请了8张卡,EPL会自动在pipeline外嵌套一层并行度为4的数据并行(4个pipeline副本并行执行)。


  1. 算子拆分并行:在以下例子中,EPL会对split scope下的模型定义做拆分,并放置在不同的GPU卡上做并行计算。


  1. 同时EPL支持对上述并行策略进行组合和嵌套,来组成各种混合并行策略,更多示例可以参考开源代码的文档和示例。


显存优化

当模型增长,GPU的显存常常成为训练大模型的瓶颈。EPL提供了多维度的显存优化技术,极致优化了训练显存消化。

  • 重算 Recomputation (Gradient Checkpoint):正常的DNN前向过程中会生成activation,这部分activation会在后向过程中用于梯度的计算。因此在梯度生成之前,前向的activation会一直存留在显存中。activation大小和模型结构以及batch size相关,通常占比都非常高。Gradient Checkpoint (GC) 通过保留前向传播过程中的部分activation,在反向传播中重算被释放的activation,用时间换空间。GC中比较重要的一部分是如何选择合适的checkpoint点,在节省显存,保证性能的同时,又不会影响收敛性。EPL提供了自动GC功能,让用户可以一键开启GC优化功能。
  • ZeRO:在数据并行的场景下,每个卡上会存放一个模型副本,optimizer state等,这些信息在每张卡上都是一样,存在很大的冗余量。当模型变大,很容易超出单卡的显存限制。在分布式场景下,我们可以通过类似DeepSpeed ZeRO的思路,将optimizer state和gradient分片存在不同的卡上,从而减少单卡的persistent memory占用。
  • 显存优化的AMP(Auto Mixed Precision):在常规的AMP里,需要维护一个FP16的weight buffer,对于参数量比较大的模型,也是不小的开销。EPL提供了一个显存优化的AMP版本,FP16只有在用的时候才cast,从而节约显存。
  • Offload: Offload将训练的存储空间从显存扩展到内存甚至磁盘,可以用有限的资源来训练大模型。


同时,EPL支持各种显存优化技术的组合使用,达到显存的极致优化。我们在T5模型上开启GC+ZeRO+显存优化的AMP技术,在性能保持不变的情况下,显存降低2.6倍。


应用场景

EPL适合不同场景的模型,在阿里内部已经支持图像、推荐、语音、视频、自然语言、多模态等业务场景,同时也可以支持不同规模的模型,最大我们完成了10万亿规模的M6模型训练,下面以M6和Bert模型为例进行介绍。


万亿/10万亿 M6模型预训练

训练一个万亿/10万亿参数模型的算力需求非常大,为了降低算力需求,EPL中实现了MoE(Mixture-of-Experts)结构,MoE的主要特点是稀疏激活,使用Gating(Router)来为输入选择Top-k的expert进行计算(k常用取值1、2),从而大大减少算力需求。

EPL支持专家并行(Expert Parallelism, EP),将experts拆分到多个devices上,降低单个device的显存和算力需求。同时数据并行有利于提升训练的并发度,因此采用数据并行+专家并行组合的混合并行策略来训练M6模型:MoE layer采用专家并行,其他layer采用数据并行。

EPL中提供简洁易用的接口来进行模型的混合并行训练,只需要增加几行annotation来配置并行策略,模型本身不需要任何修改。例如,M6模型采用数据并行+专家并行的策略,只需要增加如下图的annotation:

同时为了节约训练资源,提高训练效率,我们采用了EPL的显存优化技术和计算通信加速技术,包含自动 Gradient Checkpointing节省activation显存占用,CPU Offload技术用于优化optimizer states和weight的显存占用,采用DP+EP混合并行策略降低算力需求,和结合混合精度、编译优化等技术提高训练效率等。


借助EPL框架,首次在480 V100 上,3天内完成万亿M6模型的预训练。相比此前业界训练同等规模的模型,此次仅使用480张V100 32G GPU就成功训练出万亿模型M6,节省算力资源超80%,且训练效率提升近11倍。进一步使用512 GPU在10天内即训练出具有可用水平的10万亿模型。


流水并行加速Bert Large模型训练

对于Bert Large模型,结构图如下图所示:

由于Bert Large模型对显存消耗较大,Nvidia V100 16G显卡上batch size常常只有2-8左右(具体值和Embedding大小、Sequence Length等有关)。Batch size太小会导致算法收敛波动大,收敛效果差的问题。同时通过数据并行模式训练通信占比较高,分布式加速效果不理想。

分析Bert Large模型,由24层重复结构的encoder组成,可以使用流水并行进行加速。这里我们将Bert Large中的Encoder Layer 1~8层、Encoder Layer 9~16层,Encoder Layer 17~24层分别放在不同的卡上进行训练,并行化后的计算图如下图所示:

此时每张卡训练时的显存开销会减少,从而可以增大batch size以提升收敛加速。另外,对于模型过大单卡显存无法放下导致无法训练的场景,通过Layer间拆分的模型并行方式来进行分布式训练。通过epl.replicate接口可以实现模型的stage划分,同时通过流水并行的执行调度来提升并行化性能,如下图所示:


上述例子是一个流水micro batch mumber为5的情况。通过流水并行优化后的时间轴可以看出,在同一个时间上多张卡可以并行计算。当5个micro batch结束后,每张卡会将梯度进行本地的累计之后再进行update。与单纯的模型并行相比,通过流水的交替执行,提高了GPU的利用率。EPL还通过采用Backward-Preferred调度优化策略来提升流水并行性能,降低GPU空闲时间和显存开销。


为能够获得更高的水平扩展,EPL还支持在流水并行外嵌套数据并行来提升训练吞吐。EPL会自动推导嵌套的数据并行的并行度。在32卡GPU规模下,使用EPL的流水并行+数据并行,相较于数据并行得到了66%的提升。


Roadmap

我们决定建设开源生态主要有如下的考虑:

  • EPL发源于阿里云内部的业务需求,在服务内部业务的过程中,我们积累了大量的经验和理解,很好的支持了大规模、多样性的业务场景,在我们自身随着业务需求的迭代逐渐完善的同时,也希望能够开源给社区,将自身积累的经验和理解也同样回馈给社区,希望和深度学习训练框架的开发者或深度学习从业者之间有更多更好的交流和共建,为这个行业贡献我们的技术力量。
  • 我们希望能够借助开源的工作,收到更多真实业务场景下的用户反馈,以帮助我们持续完善和迭代,并为后续的工作投入方向提供输入。
  • 同时我们希望借助开源的工作,能吸引一些志同道合的同学、公司或组织来参与共建,持续完善深度学习生态。


后续我们计划以两个月为单位发布Release版本。EPL近期的Roadmap如下:

  • 持续的性能优化和稳定性改进;
  • 通用算子拆分功能;
  • 自动拆分策略探索的基础版;
  • 自动流水并行策略探索;


此外,在中长期,我们在下面几个探索性的方向上会持续投入精力,也欢迎各种维度的反馈和改进建议以及技术讨论,同时我们十分欢迎和期待对开源社区建设感兴趣的同行一起参与共建。

  • 全自动的模型并行策略探索;
  • 高效的策略探索算法和精准的CostModel评估;
  • eager model下的并行策略探索;
  • 更多新硬件的支持、适配和协同优化;
  • 高效的算子优化和集成、极致的显存优化、软硬一体的通信优化;


欢迎加入EPL用户交流群:


参考文献

  1. Whale: Scaling Deep Learning Model Training to the Trillions https://arxiv.org/abs/2011.09208
  2. https://openai.com/blog/ai-and-compute/
  3. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. https://arxiv.org/abs/1910.02054
  4. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding https://arxiv.org/abs/1810.04805
相关实践学习
使用PAI-EAS一键部署ChatGLM及LangChain应用
本场景中主要介绍如何使用模型在线服务(PAI-EAS)部署ChatGLM的AI-Web应用以及启动WebUI进行模型推理,并通过LangChain集成自己的业务数据。
机器学习概览及常见算法
机器学习(Machine Learning, ML)是人工智能的核心,专门研究计算机怎样模拟或实现人类的学习行为,以获取新的知识或技能,重新组织已有的知识结构使之不断改善自身的性能,它是使计算机具有智能的根本途径,其应用遍及人工智能的各个领域。 本课程将带你入门机器学习,掌握机器学习的概念和常用的算法。
相关文章
|
7天前
|
机器学习/深度学习 自然语言处理 并行计算
DeepSpeed分布式训练框架深度学习指南
【11月更文挑战第6天】随着深度学习模型规模的日益增大,训练这些模型所需的计算资源和时间成本也随之增加。传统的单机训练方式已难以应对大规模模型的训练需求。
34 3
|
9天前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
11天前
|
机器学习/深度学习 并行计算 Java
谈谈分布式训练框架DeepSpeed与Megatron
【11月更文挑战第3天】随着深度学习技术的不断发展,大规模模型的训练需求日益增长。为了应对这种需求,分布式训练框架应运而生,其中DeepSpeed和Megatron是两个备受瞩目的框架。本文将深入探讨这两个框架的背景、业务场景、优缺点、主要功能及底层实现逻辑,并提供一个基于Java语言的简单demo例子,帮助读者更好地理解这些技术。
34 2
|
13天前
|
存储 分布式计算 负载均衡
分布式计算模型和集群计算模型的区别
【10月更文挑战第18天】分布式计算模型和集群计算模型各有特点和优势,在实际应用中需要根据具体的需求和条件选择合适的计算架构模式,以达到最佳的计算效果和性能。
35 2
|
24天前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
103 2
基于Redis的高可用分布式锁——RedLock
|
3月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
1月前
|
缓存 NoSQL Java
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
55 3
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
|
25天前
|
NoSQL Redis 数据库
计数器 分布式锁 redis实现
【10月更文挑战第5天】
44 1
|
29天前
|
NoSQL 算法 关系型数据库
Redis分布式锁
【10月更文挑战第1天】分布式锁用于在多进程环境中保护共享资源,防止并发冲突。通常借助外部系统如Redis或Zookeeper实现。通过`SETNX`命令加锁,并设置过期时间防止死锁。为避免误删他人锁,加锁时附带唯一标识,解锁前验证。面对锁提前过期的问题,可使用守护线程自动续期。在Redis集群中,需考虑主从同步延迟导致的锁丢失问题,Redlock算法可提高锁的可靠性。
69 4