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

本文涉及的产品
模型训练 PAI-DLC,100CU*H 3个月
模型在线服务 PAI-EAS,A10/V100等 500元 1个月
交互式建模 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)是人工智能的核心,专门研究计算机怎样模拟或实现人类的学习行为,以获取新的知识或技能,重新组织已有的知识结构使之不断改善自身的性能,它是使计算机具有智能的根本途径,其应用遍及人工智能的各个领域。 本课程将带你入门机器学习,掌握机器学习的概念和常用的算法。
相关文章
|
1月前
|
Java 数据库
在Java中使用Seata框架实现分布式事务的详细步骤
通过以上步骤,利用 Seata 框架可以实现较为简单的分布式事务处理。在实际应用中,还需要根据具体业务需求进行更详细的配置和处理。同时,要注意处理各种异常情况,以确保分布式事务的正确执行。
|
1月前
|
消息中间件 Java Kafka
在Java中实现分布式事务的常用框架和方法
总之,选择合适的分布式事务框架和方法需要综合考虑业务需求、性能、复杂度等因素。不同的框架和方法都有其特点和适用场景,需要根据具体情况进行评估和选择。同时,随着技术的不断发展,分布式事务的解决方案也在不断更新和完善,以更好地满足业务的需求。你还可以进一步深入研究和了解这些框架和方法,以便在实际应用中更好地实现分布式事务管理。
|
7天前
|
分布式计算 大数据 数据处理
技术评测:MaxCompute MaxFrame——阿里云自研分布式计算框架的Python编程接口
随着大数据和人工智能技术的发展,数据处理的需求日益增长。阿里云推出的MaxCompute MaxFrame(简称“MaxFrame”)是一个专为Python开发者设计的分布式计算框架,它不仅支持Python编程接口,还能直接利用MaxCompute的云原生大数据计算资源和服务。本文将通过一系列最佳实践测评,探讨MaxFrame在分布式Pandas处理以及大语言模型数据处理场景中的表现,并分析其在实际工作中的应用潜力。
32 2
|
1月前
|
消息中间件 监控 数据可视化
Apache Airflow 开源最顶级的分布式工作流平台
Apache Airflow 是一个用于创作、调度和监控工作流的平台,通过将工作流定义为代码,实现更好的可维护性和协作性。Airflow 使用有向无环图(DAG)定义任务,支持动态生成、扩展和优雅的管道设计。其丰富的命令行工具和用户界面使得任务管理和监控更加便捷。适用于静态和缓慢变化的工作流,常用于数据处理。
Apache Airflow 开源最顶级的分布式工作流平台
|
29天前
|
存储 Java 关系型数据库
在Spring Boot中整合Seata框架实现分布式事务
可以在 Spring Boot 中成功整合 Seata 框架,实现分布式事务的管理和处理。在实际应用中,还需要根据具体的业务需求和技术架构进行进一步的优化和调整。同时,要注意处理各种可能出现的问题,以保障分布式事务的顺利执行。
51 6
|
29天前
|
数据库
如何在Seata框架中配置分布式事务的隔离级别?
总的来说,配置分布式事务的隔离级别是实现分布式事务管理的重要环节之一,需要认真对待和仔细调整,以满足业务的需求和性能要求。你还可以进一步深入研究和实践 Seata 框架的配置和使用,以更好地应对各种分布式事务场景的挑战。
29 6
|
28天前
|
消息中间件 运维 数据库
Seata框架和其他分布式事务框架有什么区别
Seata框架和其他分布式事务框架有什么区别
25 1
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
22天前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
65 5
|
25天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
55 8

热门文章

最新文章