云原生场景中的 AI任务调度-阿里云开发者社区

一、AI任务的需求与DLC
1.1 AI产品应用
云原生场景里面的AI任务到底是什么样的？
现在的AI任务，已经广泛的应用到各种各样的产品，是生活中不可或缺的一部分，如语言翻译、淘宝上拍立淘识别商品、天猫精灵人工智能助手等。
此外还有在产品背后呈现的AI技术，如淘宝上跟据用户兴趣精准推荐用到的推荐系统和广告系统，也是AI技术。可以说，AI已经渗透到了业务产品中的方方面面。

1.2 AI任务运行平台
在阿里云平台上运用AI任务三大优势：云原生、弹性、线性加速。

云原生
完全基于云的基础设施，如Kubernets-native平台容器化，在各种各样的机型上都支持AI的任务，各种机器的用户均可使用。
如果用户对于资源要求较高，可以用SLA有保证的机型，如果用户对价格比较敏感，可以用Spot Instance这种价格会波动的机型。借助云原生的力量，使得AI可以做到开箱即用。

弹性
支持半托管和全托管的计算资源，用户在使用计算资源上，比如需要做AI任务，用相应的机器和完整的全套技术栈，把AI任务做完；而当业务不需要计算资源的时候，也不用支付资源的费用，通过全托管去相应控制。半托管和全托管，给到用户不同的资源控制选择。

线性加速
结合阿里巴巴内部使用AI计算的平台上优化的经验，我们的系统可以为AI任务提供线性加速能力，这通过通过云上通信优化，以及包括AI模型的数据并行、模型并行等方面的工作来完成，属于深度学习引擎框架层的范畴。

1.3 AI任务的独特性
关键词：异构计算资源、多种框架

AI任务不同于在云上常见的服务计算或大数据计算任务，AI任务有自己的独特性。
1）AI用户会使用异构计算资源。现在较为通用的是GPU。GPU提供更强的算力，但价格较为昂贵，典型的GPU机型价格是 CPU机型的10倍。
因为GPU的广泛应用，出现新的异构通信链路，如英伟达的GPU使用 NVLINK进行GPU之间的通信。机器间的通信方式是使用RDMA,可以bypass远程的 CPU进行通信。随着数据量越来越大，大规模的分布式计算才能满足很多用户的这种大数据计算诉求。这些是从计算资源与底层硬件的角度来看AI任务的独特性。

2）AI任务是多种框架，现在用的框架非常的多，AI是比较笼统的称谓，里面包括深度学习、相对传统意义点的决策、AI的算法，还有为特定应用开发的框架。如X-DeepLearning是阿里巴巴广告团队开发的深度学习框架,在广告领域使用效果优秀。

1.4 云原生深度学习平台DLC架构
为了在云上支持AI任务，我们设计了DLC产品，DLC呈现的技术架构如下图所示：

首先它是建立在云原生的ECS Clusters上面的，通过在原有的支持K8s的ACK的集群添加相应的DLC的组件，使得它可以变成DLC的集群，于是它可以直接拥有相应的AI能力，包括对AI任务的提交控制能力、享受对应的框架层和系统层的优化。

整体架构图如下：

最上层提供DLC Control Panel提供相应的管控、弹性支持，使得用户可以很容易在上面提交自己的任务，做到开箱即用。中间核心层则由PAI-Tensorflow与PAI-PyTorch两个框架进行支持。
我们提供深度定制的深度学习框架，在兼容社区的基础上做了进一步的优化，结合阿里内部的场景进行锤炼，其能力通过云上的方式输出，让更多的用户直接用上优化的效果。因为GPU很贵，比如加速两倍，就相当于节省一半的 GPU的资源，这对用户来说非常重要。
KubeDL Pro的CRD底层会结合在ALIYUN Cloud Kubernets的调度、容器化、GPU共享、Quota相关的优化，使得用户可以用较为便宜的方式使用资源，比较高效使用上 AI硬件这种独特的通信，还有计算的能力等。底层是支持现有的云原生的所有机型、通信还有存储方式。

二、KubeDL
KubeDL三大特性：
 云原生支持AI；
 易扩展支持更多AI workload；
 机器学习能力统一扩展。

2.1 云原生支持AI
为了能够在云原生的场景里面支持AI，我们跟阿里云团队一起合作开发了KubeDL任务提交组件，采用All-In-One的理念，使得可在一套通用开发operator上支持TensorFlow、PyTorch等典型的深度学习计算任务提交，也支持稀疏模型、树模型等典型框架，如下图所示：

它有三大特点：
第一,提供Unified Operator，兼容所有主流的框架，沉淀通用调度的能力。
第二,是通过插件化的调度能力，使得其可以非常容易的适配各种底层不同的调度器，提供相应的功能，如对AI来说很重要的GANG Scheduling。
第三,把代码和基础镜像做了一个解耦，使得做算法的同学只需专注代码问题，底层问题由我们解决。
第四，提供相应的Dashboard和监控的Panel，可以提供全周期任务的监控，白屏化整个管理流程。

以上内容已在GitHub上面开源，可扫图中的二维码查看。

2.1易扩展支持更多AI workload
KubeDL可以做一些针对性的扩展，支持更多的AI workload。

经典案例·大规模的工业界的图神经网络分布式框架GraphLearn。
GraphLearn框架目前已经应用在淘宝的搜索推荐里面。使用淘宝的用户都有这种体验，淘宝会根据用户平时刷淘宝看到的相关物品，通过浏览记录和购买记录，推荐相似物品，其背后都是一套图神经网络。它会分析用户的浏览，还有商品之间的特性，从而把图信息嵌入到深度学习里面，从而推断用户兴趣爱好，而图神经网络是目前深度学习中的热门流派。

上图是一个典型的TF任务，采用PS-worker架构，PS节点主要用于存储模型，对应的还有Work节点，它通过加载数据，从Ps节点上面获取相应模型，对数据在模型上做计算，最后把计算结果更新到模型之上来完成一个迭代训练流程。
云原生场景里面对于TF-Worker的支持，最早是属于TF-Opreator开发，现在KubeDL上面也可跟社区一样兼容对于TF任务的提交方式。
随着图神经网络在更多的领域得以广泛应用，我们也想把图神经网络的能力跟TF结合，这里引入GraphLearn-Server角色概念。不同于TF-Worker和TF-PS的计算节点，它通过把图数据进行预处理，还有图分割的相关操作，允许用户通过编程方式进行采样、聚合等操作，把最后结果同时反馈到TF-Worker，联合进行深度学习训练。
GraphLearn是一个图神经网络框架，如何在云原生场景里面加入这个角色，使得它可以跟已有的TF很容易工作起来。而GraphLearn也有自己的要求，它在启动顺序上有需求，即图神经网络要求GraphLearn必须比TF-Worker 先启动起来，当Worker处理的时候，能够得到 Server相应的响应。GraphLearn还基于一套不同于TF的地址发现机制，需要在KubDL里面能够一并进行支持。
KubDL的架构设计较为完善，把启动顺序进行了相应的抽象，添加GraphLearn的角色并达到上述功能可以很轻松的完成。我们总共仅需要10+行代码改动，就可以完美支持图神经网络。

2.3 KubeDL：机器学习能力统一扩展
经典案例·GANG Schedule

我们还是沿用图神经网络的场景来介绍GANG Schedule的问题，在引入图神经网络节点之后，有别于社区的TF。把新角色在同样的任务里做GANG Schedule，这在原生的TF-Operator里面并不支持。
在KubeDL里很容易做到，对于库底层，上面无论定义多少角色及类型，只要满足角色定义的逻辑，都会把它当成资源的Role，然后统一做GANG Schedule。
通过引入这一点，KubeDL可在底层做同时满足Cpu/Gpu的异构资源申请。例如， TF work会需要用到GPU来做加速计算，而PS和GraphLearn都只需要CPU，这里调度的时候，GANG Schedule考虑多种不同计算Role， GraphLearn与TF原生角色，一起进行了资源考量和任务拉起。

所有资源检查完毕，在集群里面会放行与调度执行，如果这一点没做好，可能其中一部分的角色已启动，另外一部分角色没有足够的资源，整个任务就hang在那，其余用户也无法使用这些资源，严重的话会造成资源死锁。
此外还需要统一的Quota检查，用户相应的Quota需要全部满足才可执行。这些可在底层统一做，它并不只是针对GraphLearn的角色，包含任务所需要的所有角色，也可以不需要任何改动的扩展到包括原生TF在内的其他框架。
因为云上追求灵活性，不同的用户会选择不同方案及对应调度器，例如社区里，就有Kube-batch对大数据计算来设计的调度器，现在也可支持AI的任务。而KubeDL的GANG Schedule能力可以支持Kube-batch，当然也可以延伸扩展到支持任意调度器。 KubeDL还可以支持ASI调度器，这是阿里内部支持双11日常的任务调度的高性能调度器，ASI上的能力也可通过KubeDL调用和实现，而YuniCorn调度器也同样支持。

三、KubeDLPro
在KubeDL的工作中，我们完成了对于深度学习任务的基本支持，而KubeDLPro诞生，源自于我们对于AI任务运算的特性需求的深入的理解与新硬件的挑战。

3.1 深入理解 AI任务运算的特性

做 AI任务调度，首先需要深入理解 AI任务运算的特性。
上图左边是对阿里内部计算任务做的一个统计， 80%计算任务命令Mini-batch时间约为600个毫秒以内，这样的频繁数据同步是AI Flow一个典型的要求。
从深度学习模型参数如今的发展上看，两三年前Bert的参数与如今最大模型PPT3相比之下已经非常小，说明用数据并行的方式在训练一个模型的时，如果80%的任务，可能每600毫秒需要通信整个模型参数的数据量，如今的模型通信的数据量非常大，对于整个的网络带宽都有个比较大的挑战。

3.2 新硬件的挑战

从底层硬件角度看，发现随着AI任务的引进，底层硬件也丰富起来。比如GPU，现在用的非常多的V100、A100等。阿里也有一些相应的AI推理的芯片，如含光800芯片，可以加速整个任务推理，在云上还有RDMA-Nic、SmartNic这种相应的通信优化的这种硬件。如何把上下两层之间，去弥合计算任务特性，以及跟底层硬件相关的间隙，对于AI任务的性能就显得至关重要。而我们通过通信、计算、存储、资源调度以及整套的监控相应的优化，试图去解决这个问题，这就是KubeDLPro。

3.3 KubeDLPro：拓扑感知调度

接下来介绍现在在KubeDLPro上面实现的一个能力，叫拓扑感知调度，通过下图展示一下它的功能。

举个例子，用户提交一个PyTorch任务，假设PyTorch任务需要4个GPU,这个任务用户就会起4个Worker，每个圆圈代表一个Worker，每个Worker运行在1个GPU上。
传统的调度方法会把这4个Pod放到一个资源池里面，调度器查看哪里的资源有一些空闲，就按照某一调度的策略做一个摆放。但是，实际上AI计算资源池并不是像之前那么简单。
上述例子调度执行后可以发现，其实任务被放在了两个不同的机器上，这里面橘黄色的模块表示一个机器，然后机器上它又有不同的GPU，每个GPU之间呈现不同的拓扑连接，而且并不是一个完全对称的。
上图展示的是一个典型v100的机型，每个绿色的方框代表一个GPU，黑色的线代表了GPU之间是通过NVLINK进行连接。
其中NVLINK在GPU通信是里面较为重要的硬件。
首先它的带宽比Pcie大很多，可能几倍于Pcie的带宽。
其次它可以使GPU跟GPU之间的通信做到零拷贝，不需要通过CPU，从而减少了数据搬移的代价。
在这个调度的场景里面，由于传统的方法并不关注和感知底层的数据网络通信拓扑，它有可能一个调度把整个PyTorch任务调到了两个机器、各使用两个GPU，并且同个机器内的GPU，甚至无法用NVLINK进行联系。拓扑感知调度就是感知底层的一些拓扑信息以及任务对通信的一个需求，它可以在空闲的资源里面选择最佳的、紧凑的、通信带宽大的机器/GPU来放置计算任务。

这种NVLINK带来的P2P GPU Direct通信的好处，一是不用数据拷贝，二是不用CPU跟GPU之间进行数据通信，三是0内核调用。

具体实现方法
首先做一层统一的感知设备间的通信能力，感知的东西，包括现在的NVLINK，然后PcleSwitch。比如同一个PcleSwitch的通信，会比跨PcleSwitch要差了百分之几十。QPI是不同的CPU socket之间连接的通信，此外还包括RDMA NIC，因为RDMA可以用上GPU Direct。AI任务的性能，在TCP网络和RDMA网络上也会呈现不同的效果。
以上优化内容均先在阿里巴巴内部GPU集群上面部署验证，我们针对于阿里内部典型的ALLReduce式的深度学习模型，可以带来1.12到10.54的性能提升。在云原生环境中，我们用PyTorch 10w分类任务做一个评估，与现有的社区的实现，两者相差就可以达到10倍的性能。
而观察发现，在阿里巴巴内部整个集群的角度，通过拓扑感知调度，NVLINK通信资源的利用率得到4倍的提升，有更多的任务及计算可以通过NVLINK的大带宽、免拷贝形式能够更快速完成。

3.4 拓扑感知调度系统架构

具体做法如上图所示，从下往上看，这里有4个GPU，NVLINK、PCleSw表示不同的网络拓扑连接，做一层Enhanced NVIDIA Device Plugin，从硬件的角度把拓普关联的关系抽取出来，把信息发给KubeDL的 Operator及集群调度器，使得可感知底层的硬件资源的拓扑。KubeDL会做拓扑感知Job的调度，通过调度器提供的资源预占的接口，使得它不只是做GANG的时候考虑任务之间使用GPU时相关联的特性，从而为它分配更大带宽、更好的通信位置，做到精准的GPU级别调度的分配。
主要的改动在三个层面，第一层是在KubeDL，第二层是在Scheduler Framework里面改Scheduler，第三层是在Enhanced整个的NVIDIA Device Plugin。

3.5 拓扑感知调度系统实现

上图是实现整个大体的逻辑，用户提交一个ALL-Reduce 任务，首先来到KubeDL，KubeDL会把相应的信息提交给GPU Coordinator，再生成资源预占的CRD,与此同时Device plugin上报的GPU拓扑保存在 CRD里。GPU Coordinator根据GPU拓扑的CRD以及任务资源需求的CRD分析做匹配，将整个任务所有需求考虑。进而调用调度器提供的预留资源接口，将这个任务预占，最终把相应的Pod的信息提交到调度器。调度器会做pod的调度消费，将刚才预留过的资源精准分配给相应的Pod，完成整个任务的调度，这就是对基础版的拓扑感知调度的实现方式。
上面的实现始于阿里内部GPU集群的验证，而我们也发现当下的硬件能力在社区的调度方案无法充分发挥其效果，于是把这个方案输出到阿里云的云原生平台，我们希望能让更多的人能够享受这样的服务。

3.6 直观举例分析

进一步的，举个直观的例子，当要提交一个8卡的深入学习任务，要用怎样的一个方式去提交？
比如单机8卡，所有东西都放到一个进程，指定去做通信设定，进一步拓展可以2机4卡， 4机2卡，极端情况做完全分布式8机1卡。上述不同提交方法各有利弊。1机8卡可以控制相应的计算资源，能让任务去走相应的NVLINK进行通信，缺点是无法快速获取资源。分布式的8机1卡优点在于，即使当集群里面存在一些碎片时，也可以更快拿到相应资源，比起1机8卡，其资源粒度更细，更容易拿到所需的资源，因而等待时间更短。
但现实情况是整个集群大多数情况，用户任务都在运行，不断的有任务完成，和到达，机器里剩余的可用卡数不同，并不是规整的2卡4卡8卡这种情况。这个问题应该如何解决？

在一个忙碌的集群里面，确实很难找到这种规整GPU的计算资源，于是就会出现一个问题。如下图所示，用户买了4个机器，每个机器8块卡一共32，目前空闲16块卡，用户希望提交一个2机每机4卡的任务，但无法提交。

其本质原因在于，集群里面找不到两个机器满足2机每机4卡的需求，因此这个任务被迫等待。可以发现， 2机4卡并不是唯一解决办法，如果以“3+5”的形式执行该任务，那么整个任务完成时间其实与提交2机4卡的任务一样。
在实际场景中，用户不知道当前跑的集群剩余资源的情况，所以也无法提前作出3+5这种资源申请，因此需要系统运行结合调度的情况，给用户做资源申请形状的改变，让用户在等待时间和运行时间上达到平衡。

而从用户侧，其实1机8卡和8机1卡所需要的代码完全不同，许多用户在这上面非常纠结。我们通过系统层能力来做到自动平衡，使用户编码上不用纠结。

拓扑感知自动聚合
进一步对拓扑感知做扩展，扩展到拓扑感知加自动聚合。建议用户在编码时完全按照分布式方式做编程，让用户写PyTorch的任务，以PyTorch DDP的方式，刚刚的例子写成一个8机的1卡。

通过KubeDL加上PAI框架，PyTorch里面相应的一些改动来支持用户行为，它会自动的选择。
第一是自动选择最佳的通讯拓扑。
第二是实现了跨Pod NVLINK的通信，现在社区的方案跨了Pod，无法看到另外一个GPU，也无法进行相应的NVLINK通信，会变成走Share Memory或者网络的情况。
第三是当这个Pod对其他Pod的 GPU可见时，通过框架自动分配 GPU的设备到相应的PyTorch Worker上，这需要改动相应框架知道在使用哪块卡。

上面举例的8卡任务，在这个场景里面可以被自动捕捉，然后以“7+1”（如上图所示）的形式运行。它与用户最初设想的两个机器里面4张卡的情况相比，性能也完全一样。目前整体该功能囊括在PAI DOC的产品里，TensorFlow和PyTorch均支持这样的功能。

四、总结

综上所述，云原生场景中的AI任务调度工作主要如下：
第一，是提供了完全开源的KubeDL组件，做到方便扩展，同时兼容社区所有的Tf-operator/PyTorch-operator等深度学习应用提交工具的接口。
第二，基于这套组件可以简易地进行扩展，许多开发者需要通过KubeDL来实现一些 AI任务提交，我们都有教学文档帮助大家实现。通过All-In-One理念，只要实现很简单的Operator，该任务就拥有底层相应资源优化的能力，通过调度器与AI框架做一些协调设计，在阿里内部的一些AI实现这种优势特性和能力，通过兼容社区的Operator、调度器的形式进一步透出，让 AI框架跟调度进行联动，硬件资源可得到充分利用。
第三，观察到大部分AI任务的用户都是算法工程师，他们在研究算法调参上花费大量时间，但对于系统底层并不是特别了解，需要我们对用户做到功能透明，使用户无需操心系统实现和硬件细节就可达到预期效果。GPU价格昂贵，我们希望能够不断优化做任务的训练速度，提升整个集群资源利用率和任务吞吐率。
（分享人：肖文聪）