ElasticDL:蚂蚁金服开源基于TensorFlow的弹性分布式深度学习系统

  • 时间:
  • 浏览:0
  • 来源:大发5分彩-大发5分快3

9 月 11 日,蚂蚁金服在2019谷歌开发者大会上海站上开源了 ElasticDL 项目,这是业界首个基于 TensorFlow 实现弹性深层学习的开源系统。

开源地址为:elasticdl.org

开源中国采访了ElasticDL项目负责人王益,对该深层学习系统的技术细节进行了全面介绍。

一、基于 TensorFlow 2.0 和 Kubernetes 实现弹性深层学习

这一 基于 Eager Execution 模式的开源项目名为“ElasticDL”,它是四个多 Kubernetes 原生深层学习框架,根据介绍,ElasticDL 主要有四大特点:

l 容错性

l 弹性调度

l 易用性

l 高效

其中又以容错与弹性调度形状最具特色。

ElasticDL 实现了容错和弹性调度的分布式深层学习,时需极大提升集群的总体利用率,一起显著减少用户提交作业以前停留作业启动的时间(pending time)。

王益介绍:“ElasticDL 是大伙儿儿知道的第四个多基于 TensorFlow 实现弹性深层学习的开源系统。具体地说,ElasticDL 是基于 TensorFlow 2.0 和 Kubernetes 实现弹性深层学习的。”

(一)集群效用从 1/N 到 N/N

在深层学习技术研发的早期,公用四个多计算集群的人相对少, 计算作业之间的协调时需通过口头交流实现。开发者更关心缩短运行时间,也可是从作业启动到现在现在刚开始的这段时间。高性能计算技术(HPC)是处理这一 问题的有效途径,比如 NVIDIA 的 cuBLAS 和 cuDNN 优化高性能数学计算、NCCL 优化 GPU 之间的通信下行速率 。

随着深层学习技术的大规模应用,在这一 工程师和研究员公用四个多集群的情况表下,通过商量来协调调度显然不可行,于是大伙儿儿现在现在刚开始使用集群管理系统调度分布式作业。

Kubernetes 近年来可能性逐渐成为集群管理的重要工具,目前可能性在各大公有云中广泛采用。可是,让 TensorFlow 能更好地运行在 Kubernetes 集群上,一起提升利用集群进行深层学习的下行速率 和资源利用率(效用),显得非常具有实际意义。

关于提升集群资源利用率,王益举了四个多比较极端的例子:假设四个多集群有 N 个 GPU,而四个多任务只使用其含有一个多,现在四个多多任务占用了四个多 GPU。当非要弹性调度机制时,四个多要求所有 N 个 GPU 的任务时需停留前四个多任务现在现在刚开始都都上能现在现在刚开始,这一 停留时间可能性高达数天甚至数周,在停留期间,集群的效用是 1/N;而拥有弹性调度能力以前,新的任务时需在 N-1 个 GPU 上立即运行,可是 Kubernetes 时需在第四个多任务完成后将占用的 GPU 赋予这一 任务,这一 情况表下,集群整体效用是 200%。

ElasticDL 在容错与弹性调度上全部都是不错的表现,它的现实意义便是高效处理集群效用问题。

(二)ElasticDL 何如实现?

前边讲到集群资源利用率提高的前提其实可是 ElasticDL 的“弹性调度”形状带来的,而弹性调度依赖于容错能力。

容错是指作业不受其中程序运行运行运行数量变化的影响,在弹性调度过程中,作业里的程序运行运行运行数量会随集群 workload 情况表相应增减,这一 这一 作业时需是容错的,都都上能配合调度系统,实现弹性调度。

在这一 过程中,容错通常由分布式框架实现,比如 Spark 和 ElasticDL 时需做到当有程序运行运行运行挂掉,可能性新的程序运行运行运行加入时,作业不想暂停可能性重启,可是平滑地继续。而弹性调度是由分布式框架和分布式操作系统(集群管理系统)一起实现的。比如,当有程序运行运行运行挂掉的以前,分布式框架应该通知集群管理系统新启程序运行运行运行来补位 —— 至于集群管理系统时需启动起来,取决于用户剩余 quota 和集群的忙碌情况表。

1. 基于 Kubernetes-native

通常使用 Keras 的 model-fit API 和 Estimator,开发者只时需调用 API 即可进行分布式训练或预测,然而 ElasticDL 不依赖于 TensorFlow runtime 实现分布式计算,它的实现在 runtime 之外。

ElasticDL 通过 Kubernetes-native 机制来完成分布式计算,而这也为其带来了容错性与弹性调度的能力。

所谓 Kubernetes-native 指的是四个多程序运行运行调用 Kubernetes API 来起止程序运行运行运行,它与 Google MapReduce 的机制累似 。MapReduce 是四个多 Borg-native 的分布式计算框架,用户通过运行四个多 Borg 客户端程度启动四个多 MapReduce 作业;Borg 客户端调用 Borg API 提交作业,可是启动四个多 master 程序运行运行运行;这一 master 调用 Borg API 启动其它 workers 程序运行运行运行。

在 ElasticDL 中,用户调用 ElasticDL 的命令行客户端程序运行运行启动作业;这一 客户端程序运行运行调用 Kubernetes API 启动 master 程序运行运行运行,master 程序运行运行运行继续调用 Kubernetes API 启动其它程序运行运行运行。

“ElasticDL 的整个容错和弹性调度机制都依赖于 Kubernetes-native 架构”,王益介绍:“可能性 worker 挂了,按照分布式深层学习训练算法的数学形状,时需不想处理, 即可确保训练过程继续。可能性四个多 parameter server 程序运行运行运行挂了,master 会选着四个多 worker 程序运行运行运行,让它转换角色替补上挂掉的 parameter server 程序运行运行运行。”

在这一 种生活情况表下,master 都会调用 Kubernetes API,请它再启动四个多额外的 worker 程序运行运行运行。可能性启动成功,master 会带其加入到与其它程序运行运行运行的公司合作 者中。master 程序运行运行运行的情况表(主可是四个多 task queues:todo、doing 与 done)时需保留在 Kubernetes 集群的 etcd 存储系统中。

“曾经,万一 master 挂了,重启的 master 程序运行运行运行时需从 etcd 继承前世的情况表。任何程序运行运行运行挂了,master 都会请 Kubernetes 去启动四个多新的程序运行运行运行代替挂掉的程序运行运行运行。而 Kubernetes 是有无能完成使命取决于用户剩余 quota 和集群剩余资源情况表。”

2. 基于 TensorFlow 2.0 Eager Execution

为什会 会 ElasticDL 又基于 TensorFlow 2.0 呢?王益介绍,这是可能性 TensorFlow 2.0 带来了 Eager Execution 形状,正是针对这一 形状的尝试,让开发团队实现了 Kubernetes-native 的调度妙招,从而让 ElasticDL 支持容错和弹性调度。

分布式学习时需了解每个程序运行运行运行根据局部训练数据计算得到的 gradients,都都上能汇总什么 gradients 来更新模型。

TensorFlow 1.x 的执行妙招被称为 Graph Mode —— 深层学习计算步骤被表示成四个多 graph 数据形状,TensorFlow runtime 会解释执行这一 graph。其中,gradients 的计算过程是 graph 的一每种,这一 这一 为了得到 gradients,分布式深层学习系统时需 hack 进入 graph 的执行过程“偷取”gradients。

这一 做法时时需户写程序运行运行的以前写这一 帮助“偷取”的代码,增加了程序运行运行的简化度,也增加了对编程者的要求。

TensorFlow 2.0 提供的 Eager Execution Mode 中,通过四个多叫 tape 的数据形状,它时需把获取 gradients 的能力以 API 的妙招暴露给开发者,ElasticDL 正是以曾经的妙招将其实现。

通过这一 对比,其实也反映了业界基于 TensroFlow 进行分布式深层学习的不同设计思路。王益介绍,当前基于 TensorFlow 的分布式训练系统大致时需分为四类:

其中时需修改 TensorFlow runtime 的工作主要由 Google TensorFlow 团队完成。可能性 TensorFlow runtime 是用 C++ 写的,把网络通信和同步功能实现在这一 层次里,运行下行速率 很高。可是,理论上 C++ 代码时需通过感知 TCP/IP 链接是有无中断,来判断程序运行运行运行是有无挂掉,从而实现容错。

“可是 TensorFlow runtime 应该是平台无关的,这一 这一 不应该含有访问特定集群管理系统,请它重启挂掉的程序运行运行运行的代码,这一 这一 不易实现弹性调度”,王益指出了二者的区别:“与之相对应的,通过调用 TensorFlow API 实现分布式计算的思路,通信性能往往受到 Python 语言性能以及非要在 runtime 內部实现‘微操作’的限制。但它的好处是时需自由调用集群管理系统 API 来管理程序运行运行运行。”

很明显,ElasticDL 通过 TensorFlow 2.0 带来的新形状实现了 TensorFlow runtime 外直接调用集群管理 API 而完成了弹性调度。

二、ElasticDL 替代 Kubeflow 的使用

Kubernetes 曾经是四个多用来管理无情况表应用的容器平台,可是当前没人来越多公司用它来运行各种各样的工作负载,不得劲是使用它来运行机器学习相关任务。

Kubeflow 基于 Kubernetes,它把模型训练、超参数训练与模型部署等机器学习任务类型进行组合并以容器化的妙招部署,提供了整个机器学习流程各个系统的高可用与便捷性,使用 Kubeflow 就时需进行各种各样的机器学习任务。

目前 Kubeflow 是在 Kubernetes 上启动分布式 TenosrFlow 作业的主流操作,这可能性也是开发者更为熟悉的模式。

“具体来讲,Kubeflow 会询问 Kubernetes 计划分配哪几台机器来运行四个多分布式作业中的各个程序运行运行运行,可是告知每个程序运行运行运行所有其它程序运行运行运行的 IP 地址和 port,从而保证四个多作业里各个程序运行运行运行之间互相知道对方。”

为什会 会 时需让所有程序运行运行运行互相知道对方呢?这是 TensorFlow ps-based distribution 妙招要求的。(也可是前边提到的对比基于 TensorFlow 的分布式训练系统表格中左上角的类型)

王益解释:“TenosrFlow 1.x 原生的分布式训练功能让四个多作业中所有程序运行运行运行都执行 TensorFlow 1.x runtime 程序运行运行。什么程序运行运行运行互相通信,互相协调成为四个多‘分布式 runtime’来解释执行表示深层学习计算过程的 graph。在现在现在刚开始分布式训练之初,graph 被 TensorFlow runtime 拆解成若干子 graph;每个程序运行运行运行负责执行四个多子 graph —— 任何四个多程序运行运行运行失败 (可能性是被更高优先级作业抢占),则整个大 graph 的执行就失败了。这一 这一 TensorFlow 原生的分布式训练能力全部都是容错的(fault-tolerant)。”

不过,TensorFlow Python API 提供了 checkpoint 的能力:可能性四个多作业失败了,时需重启作业,从最近的 checkpoint 现在现在刚开始继续执行。这一 这一 它时需从错误中恢复(fault-recoverable)。

Kubeflow 时需在 Kubernetes 上发挥 TensorFlow 原生的分布式计算能力,可是可能性后者未必能容错,这一 这一 Kubeflow 未必能无中生有。非要容错,也原因分析 非要弹性调度,而这正是 ElasticDL 的特长。

三、与 SQLFlow 联动

前边介绍了 ElasticDL 的实现机制与现实意义,总结起来主可是可能性 ElasticDL 通过 TensorFlow 2.0 提供的新形状 Eager Execution 实现了 TensroFlow runtime 外直接调用集群管理 API,从而实现了 Kubernetes-native 机制来完成分布式计算,继而实现容错与弹性调度,最终达到极大提升集群总体利用率的目标。

除此之外,ElasticDL 还四个多多重要的形状——易用性。ElasticDL 的易用性与曾经工具密不可分。

有几个月前,蚂蚁金服开源了四个多机器学习工具 SQLFlow,这一 工具旨在让开发者调用 AI 像写 SQL 一样简单。据介绍,SQLFlow 都都都上能抽象出端到端从数据到模型的研发过程,配合底层的引擎及自动优化,具备基础 SQL 知识的开发者即可完成大每种机器学习模型训练及预测任务。

通过与 SQLFlow 联动,开发者时需用扩展后的 SQL 语法,非常精炼地描述整个数据流和 AI 流程。SQLFlow 把四个多 SQL 程序运行运行翻译成四个多实现整个 end-to-end machine learning 的程序运行运行,这一 程序运行运行时需调用 xgboost、PyTorch,可能性 ElasticDL、TensorFlow 实现训练任务。

王益举例,在有 SQLFlow 以前,可能性要为四个多电子商务网站构造四个多推荐系统,时需开发日志埋点、在线数据清洗、形状工程、模型训练、验证与预测等模块,每个模块可能性时需投入四个多团队数周甚至数月的时间。

而 SQLFlow 出显以前,这一 流程时需用 SQL 语言描述成四个多很简短的程序运行运行,SQLFlow 时需把它翻译成上述数据和 AI 流。

可能性 SQL 是一种生活只描述意图,不描述过程的语言,这一 这一 SQL 程序运行运行通常都很简短。可是也可能性这一 原因分析 ,SQL 程序运行运行里含有的信息量有限。比如,用户不想通过 SQL 指定分布式调度和训练算法。“什么每种时需 ElasticDL 根据模型特点自主决定”,王益补充:“这也是为什会 会 说 ElasticDL 也时需反过来为 SQLFlow 提供易用性。”

四、ElasticDL 开源的下一步计划

关于开源后接下来的发展,王益表示,ElasticDL 项目目前位于早期探索阶段,API 还在演化过程中。“此次开源的版本,尚不包括自动选着分布策略和算法的代码,相比在 TensorFlow runtime 中实现分布式计算,基于 TensorFlow 2.0 Eager Mode 的 Python API 实现的分布式训练性能差距还很大”,他介绍:“ElasticDL 团队在和 Google Brain 团队公司合作 者,开发上述 asynchronous SGD + delayed model update 能力、以及 Kubernetes-native AllReduce,希望在下四个多版本中时需提供给大伙儿儿使用。”

可是王益又具体介绍,上述一种生活分布式训练策略,一种生活会用于模型含有较大的参数的情况表,比如分布式 embedding table,另一种生活用于模型参数较小的情况表。而这也是 ElasticDL 自动决断分布式训练算法的四个多例子。

当时人面,在 SQLFlow 中,可能性要让用户能提供尽量少的参数,AI 引擎还时需更加智能,提供包括 AutoML 等功能。

王益感叹:“ElasticDL 项目任重道远。”

五、受访嘉宾

王益,目前在蚂蚁金服负责 AI 基础架构工作。他于 2007 年从清华大学计算机系博士毕业,先后在 Google(中国)、腾讯、LinkedIn(美国总部)与百度硅谷研究院工作,期间在硅谷和北京各有一次创业经历。参加工作以来,王益无缘无故专注于 AI 基础架构工作,参与和领导了多个核心 AI 系统的研发。