9月11日,蚂蚁金服在谷歌开发者日上海2019上宣布开源了基于TensorFlow 2.0急切 执行的分布式深度学习系统ElasticDL。基于TensorFlow的支持弹性调度的深度学习系统,据我们所知,ElasticDL是第一 个。项目负责人王益和我们分享了ElasticDL项目的设计意图和现状,尤其是ElasticDL与TensorFlow 2.0以及 Kubernetes的技术关联。
分布式深度学习的技术思路
基于TensorFlow的分布式训练系统大致可以分为以下四类:
<中心>
其中,ElasticDL位于田字格的右上角。之所以选择这条技术思路,是为了利用Kubernetes实现容错和弹性调度。
高性能计算和云计算
在深度学习技术研发的早期,涉及的人员相对少,共用一个计算集群的人相对少,计算作业之间的协调可以通过口头交流实现。大家更关心缩短运行时间,也就是 从作业启动到结束的这段时间。高性能计算技术(HPC)是解决这个问题的有效途径,比如NVIDIA的cuBLAS和cuDNN 优化高性能数学计算,NCCL优化GPU之间的通信效率。
随着深度学习技术的大规模使用,很多工程师和研究员共用一个集群,通过商量来协调调度显然不可行了,大家开始使用集群管理系统调度分布式作业。这其中, Kubernetes近年来一枝独秀,已经在各大公有云中广泛使用。
云计算和弹性调度
在Kubernetes上启动分布式TensorFlow作业的常用方式是使用谷歌云开源的 Kubeflow.Kubeflow是Kubernetes的一个“插”件,它询问Kubernetes 计划分配哪几台机器来运行一个分布式作业中的各个进程,随后告知每个进程,所有其他进程的IP地址和端口。从而保证一个作业里各个进程 之间互相知道对方。
为什么需要让所有进程互相知道对方呢?这是TensorFlow ps-based分布 方式(上述表格中的左上)要求的.TensorFlow 1。x原生的分布式训练功能让一个作业中所有进程都执行TensorFlow 1。x运行时 程序。这些进程互相通信,互相协调成为一个“分布式运行时”,来解释执行表示深度学习计算过程的计算图(图)。在开始分布式训练之初,图 被TensorFlow运行时拆解成若干子图,每个进程负责执行一个子图——任何一个进程失败 (可能是被更高优先级作业抢占),则整个大图的执行就失败了,所以TensorFlow原生的分布式训练能力不是容错的(容错)。不过, 它是可以从错误恢复(fault-recoverable)——TensorFlow API提供检查站 的能力,如果一个作业失败了,可以重启作业,从最近的检查点开始继续执行。
Kubeflow可以在Kubernetes上启动基于TensorFlow原生的分布式计算能力的作业。但是因为后者并不能容错,所以 Kubeflow并不能无中生有。不能容错,也意味着不能弹性调度。
对弹性调度的诉求
在很多人共用计算集群的情况下,支持弹性调度意味着极大提升团队效率和集群的总体利用率。前者支持快速迭代以保持技术领先;后者决定企业成本和云计算 业务的盈利能力。
一个展示弹性调度效果的例子如下。假设一个集群里有N个GPU,一个作业包括一个进程,占用了N/2个GPU第。二个作业需要N/2 + 1个 GPU;但是此时机群里空闲GPU只有N/2个。如果没有弹性调度能力,那么第二个作业被迫等待, 直到第一个作业结束释放资源。这个等待时间很可能和第二个作业的运行时间同量级。此时,集群的利用率很低,是50%。如果有弹性调度,那么第二个作业可 以马上启动,用N/2个GPU做计算。日后如果有更多空闲资源了,调度系统可以增加其进程数量,充分利用资源。
另一个例子是,假设有一个作业已经在执行了,此时一个新的更高优先级的作业需要资源,所以调度系统杀掉了(抢占)了第一个作业的几个进程来腾出资 源启动第二个作业。如果没有弹性调度和容错,那么第一个作业会失败,所有进程都结束。直到有足够资源重启它,并且沿着最近的检查点继续。如果有 弹性调度,则第一个作业的剩下的进程可以继续执行,只是因为可用的进程(GPU)少了,所以速度慢一些而已。
以上两个例子都展示了弹性调度对集群利用率的提升,以及对团队工作效率的保障。需要注意的是:容错和弹性调度互为因果。容错的意思是,作业不受其 中进程数量变化影响。弹性调度时,作业里的进程数量会随集群工作负载情况增减,所以作业必须是容错的,才能和调度系统配合,实现弹性调度。也因为如 此,弹性调度依赖分布式编程框架和调度系统配合。
