开发者学堂课程【PAL 平台学习路线：机器学习入门到应用：云原生场景中的 AI 任务调度】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/855/detail/14124
云原生场景中的 AI 任务调度
内容介绍：
一、AI 任务的需求和 DLC
二、KubeDL
三、KubeDLPro
一、 AI 任务的需求和 DLC
AI 任务的实际需求，以及对应的云上的解决方案 DLC。会通过里面的一些技术细节，主要从KubeDL 和 KubeDLPro 两个方面来看云原生场景中的 AI 任务调度的相关的一些问题，以及如何将一些阿里的实践搬到的云场景里服务更多的用户。
首先现在的 AI 任务已经广泛的应用到各种各样的产品当中，也是生活中不可或缺的部分，例如多语言的翻译，淘宝拍立淘的识别功能等等，像天猫精灵这样的人工助手也是比较广泛的应用。还有一些在产品别后使用的技术也有 AI 的身影，比如淘宝很多购物量是通过对用户兴趣的精准推荐来实现的，这里用到的是推荐系统和广告系统，这里面都有 AI 技术的身影，AI 应用无处不在。
·Computer Vision
·Natural Language Processing
·Speech Understanding
·Recommendation
·Advertisement
·...
1. AI 任务运行平台
设想中的 AI 是希望 AI 的任务可以运行在像阿里云这样的平台上面，其具备一些比较好的特性，即在阿里云上做 AI 有一些好处：
（1）云原生：完全基于云基础设施像一些机器，包括 Kubernets-native 这样的平台、容器化，多种机型支持 AI 的任务，用户可以根据自己的需求，包括 cpu/gpu 的机器都可以使用(GN6V, GN5 等)。有些用户对资源要求比较高，可以用有保证的一些机型；支持 ACK/ECI,针对价格比较敏感的用户，可以用价格有弹性、会波动，有时便宜的机型。不管是希望要求质量高还是对价格比较敏感的用户，使 AI 可以做到开箱即用。
（2）弹性：支持半托管&全托管弹性资源,用户可以做到需要进行什么类型的任务，就可以拉起相应的机器和整套的全站的技术站，从而完成 AI 任务。在不使用的时候，也不用花费相应的费用。进一步可以针对数据大小选择托管类型。
（3）线性加速：结合在平台上优化的经验，为 AI 任务提供线性加速，通过云上的通信优化数据并行&模型并行等等来做增强。支持亿级别的分类任务多引擎性能增强。这个主要是在深度学习引擎框架程序做的内容，本节主要分享 AI 在云上调度方面的内容。
2.AI 任务的独特性：
AI 的任务其实也不同于平时在云上常见的一些这种 deploy 这个网站的 service，还有大数据计算这样的任务，AI 任务具有一定独特性
（1）异构计算资源：第一个主要现在比较通用的是 gpu，但 gpu 现在的价格相比于 cpu 来说十分昂贵，因为 gpu 可以提供更强的算力。典型的一个 gpu 的机型，价格可能是 cpu 机型的十倍，正是因为gpu比较昂贵，如果浪费的话就非常严重了。那么就使得需要把资源用好，因为 gpu 的引入，广泛应用，使得说我们这里面的话，第二是因为由于 gpu 的引入，广泛应用使得这里出现一些新的异构通信电路，比如英伟达的 gpu 就使用 AVLKNK 进行 gpu 之间的通信，对于机器签，更好的通信方式是使用 DMA 就可以 bypass 远程的 cpu 的进行通信，随着数据量越来越大，所以需要一个大规模的分布式的计算，才能满足很多用户的一些诉求。这个是从计算资源，也就是从底层硬件的角度来看待这个独特性的问题。
（2）多种框架：现在使用的框架其实非常的多，AI 是一个比较笼统的称谓，但其实其中也包括深度学习，也包括一些相对传统的决策树，随机森林这样的 AI 算法，当然还包括一些像为特定应用开发的一些框架。例如 X-DeepLearning 就是阿里巴巴广告团队开发的一个深度学习的框架，用在广告上面效果也非常的好。
①TensorFlow
②PyTorch
③XGBoost
④X-DeepLearning
3.云原生深度学习平台 DLC 架构图
为了支持在云上的一些 AI 的任务，设计了的 DLC 产品，DLC 技术可以呈现这样的技术架构，首先它是 build on 云原生的 ECS 的 class 上面的，通过这个把原有的知识 KBS 的 ack 的集群去添加相应的 DLC 组件，使得它可以变成一个 DLC 的集群，于是可以直接拥有相应的这种 AI 的能力，包括对 AI 任务的提交，控制，包括享受对应的框架层，系统层这样的一些优化。
下图为整体的架构图，最上层提供了一个 Control Panel（管控，弹性，Meta，Dashboard） 提供相应的管控，弹性，这样的支持，使得用户可以很容易的去提交自己的任务，可以做到开箱即用。中间核心层，是由两个部分来支持的。第一个是深度学习框架，在金融社区的基础上做了很多的优化，也是结合阿里内部的一些场景，它的能力可以通过云上的方式，让更多的用户可以直接用上这样优化的效果，因为上文提到 gpu 很贵，但如果说两倍加速的情况下，那么就相当于可以节省一半的 gpu 资源，其对用户来说非常重要。另外一个是主角，此处会主要讲解 KubeDL Pro 相关的内容，例如 KubeDL Pro CRD。底层会结合在 KBS native 的调度、容器化、GPU 共享、Quota 相关的一些优化，使得可以用比较便宜的方式使用一些资源，比较高效的使用上 AI 硬件独特的通信、计算的能力等，底层支持现有的各种云原生所有的机型、通信，还有存储方式。
二、 KubeDL
1.云原生支持 AI
首先为了能够在云原生的场景里支持 AI，与阿里云团队一起合作开发了 KubeDL 任务提交的组件。这里采用了叫做 all in one 的理念，使得可以在一套通用云的 offer，就是开发商 operator 上面去支持pencil flow PyTorch 这种典型的，目前非常火的深度学习的计算任务的提交，当然也支持一些稀疏模型，树模型相关的一些典型的框架。（1）特点：
①unified operator ：兼容主流框架，沉淀 job 通用调度能力。
它提供 unified operator 兼容，也就是兼容所主流的框架，然后沉淀于通用调度的能力。
②插件化调度能力：适配多种调度器的 GANG scheduling。
通过插件化的调度能力，使得可以非常容易的去适配各种底层不同的调度器，相应的提供的一些 picture。比如，对 AI 很重要的就是 GANG scheduling。
③代码和基础镜像解耦，提高研发效率。
将代码和基础镜像做了解耦，使得做算法只要专注于代码的问题即可。底层的问题，由 handel 来完成。
④KubeDL Dashboard 全周期监控，白屏化任务的自助管理。
提供相应的 Dashboard 和监控的 panel，即可以使得提供全周期的任务监控，白屏化整个的管理流程。这一套东西，已经在 Guitar depart 上面开源，若感兴趣，可以看下图相应的链接，扫对应的二维码看开源的实现。
2.KubeDL：易扩展支持更多 AI workload
接下来是 KubeDL。首先 KubeDL 它有一些比较好的能力，使得可以很容易的进行针对的扩展，来支持更多 AI 的 workload。这里面举一个典型的例子，这当然也是开源的在大规模的工业界的图-神经网络分布式框架叫做 graphlearn，这个框架现在已经广泛地应用在淘宝的搜索推荐，公司也有很多的业务在使用。如果平时刷淘宝看一些推荐相关的物品，会通过浏览记录和购买东西推荐一些相似的，或者你感兴趣的物品。其实它背后都是这样的一套图-神经网络的功能，它会分析用户的浏览和商品之间的特性这其中相关联的关系。把图的信息嵌入到深度学习里面，这也是现在非常火的深度学习的一个流派。下方有一张图，如果对于典型的 pencil flow 使用比较熟，即是一个深度学习引擎，现在用的最火的是谷歌的开源的 tensorflow。它是有一些 ps 节点主要用于存储模型，对应的它还有一些 work节点，通过加载数据，然后从 ps 节点上面拿相应的模型，对于数据在模型上做一些计算，最后把这个结果又更新到模型里面，这个是 tfworker 的这样的角色。云原生场景里面对于 tfworker 的知识最早是属于 tfoperator（tensorflow operator）也是社区开发的一套东西。现在，在 KubeDL 上面也可以跟社区一样，兼容对于 tensorflow 任务的提交方式，更进一步，因为在发现这个图-神经网络，已经在更多的领域广泛应用起来了后，就是把这种图-神经网络的能力跟 Pencil flow 给它做一些配合，结合起来。这里引入了一个叫做 graph learn server 这样角色的概念，它其实是一个不同于 tensorflow worker 和 pencil props计算的节点，它通过把图数据进行预处理，还有 partition 相关的操作，允许用户通过编程的方式，在上面做采样、聚合等等操作。把最后的结果，同时放到 cancelledword 上面去联合进行深度学习的训练。关于 graphlearn，只要知道它是一个图-神经网络的框架即可。现在要关注怎么在云原生场景里面加入这样的角色，使得它可以跟已有的pencil flow Hitachi 很容易 work 起来，并且当然希望这种 effort 越小越好，基于 KubeDL 可以很轻松能够实现这一点，其可以完美的、很容易支持对于启动顺序上的一些差异，比如说图-神经网络要求 graphlearn server 必须比 worker 先起来，当 worker 去做一些处理的时候，能够得到 server 相应的响应。还有另外一个是它基于一套不同于 tensorflow 原生的地址，发现这样的东西，那么这些也需要在 KubeDL 里面能够一定的进行支持。由于 KubeDL 的设架构设计比较优秀，把一些启动顺序做了一些相应的抽象，使得其加入这样的角色，只需要改动很少的代码，这里经过实现，仅仅需要差不多十行代码的改动，就可以完美支持图-神经网络的使用。
（1）典型案例
·graph-learn*大规模图神经网络的分布式框架
①不同于 tf-worker/tf-ps 的新角色
②启动顺序
③地址发现
3.KubeDL：机器学习能力统一扩展
关于统一能力的扩展，举例 GANG scheduling，还是沿着刚刚图-神经网络的问题，首先在引入图-神经网络 GANG schedule server 一个节点之后，其实是区别于社区的 pencil flow ，所以如果将新引入了角色同样的在任务里面做一个 gang schedule ，它在原生和 operator 里面是不支持的，但是它就可以很容易的去做到这一点。因为对于 KubeDL 的底层来说，其会觉得上面的无论定义多少角色，对什么样的类型，只要满足某个这种角色定义的逻辑，都会把它当成这种资源的 role，然后统一做 GANG schedule。那么就是通过引入这一点，可以在底层去做一个同时满足 CPU、GPU 等异构资源申请的这样的杠。这里举实际例子， tf worker 会需要用到 gpu 来做加速的计算，而 ps 和 graph learn 都只需要 cpu。第二，就是计算不同的 role，例如 PS eleven server，tf worker。第三个，当所有的资源，检查 ready，恰好集群里面拥有这么多资源的才会放行让调度方可执行，如果这一部分没有做到，可能会导致其中一部分角色启动，另外一部分角色没有足够的资源而停滞住，其他人也用不到这些资源，更严重会造成死手。所以统一的扩大检查，就是用户相应扩大要满足才可以进行执行，这些都可以很简单的在底层统一的做，而且其并不只是为 graph learn 这样的角色单独成立，其可以不需要任何改动的扩展到原生的 tf 等其他的一些框架。
（1）典型案例：GANG schedule
①大规模分布式机器学习任务需要所有的资源申请同时满足
②同时 CPU/GPU 等异构资源申请多种不同的计算 role
③所有资源 Ready 方可执行
④统一 Quota 检查
还有一个挑战，需要应对不同的生产的环境，因为在云上，大家追求灵活性，那么这个地方可能不同的用户会选择不同的方案和对应相应的调度器。例如像社区里面，就有 Kube-batch 原来是为大数据计算来设计的调度器，现在，当然它也可以支持一些 AI 的录入，杠的能力，原生拓展到去支持的调度器。 ASI 调度器，这样的一套 KubeDL ，也是在阿里巴巴内部使用的，是阿里的 ASI 调度器，也是阿里内部支持双11日常的用户调度通用的调度器，ASI 上面杠的能力，也可以通过 KubeDL 很容易的调用和实现。最后，是 YuniCorn调度器，其是 HDM 社区做的，在借用 KYS HDM 的这样的调度系统，同样也可以在这上面去支持。
（2）典型案例：GANG schedule
①大规模分布式机器学习任务需要所有的资源申请同时满足
②复杂多样的生产环境
三、 KubeDLPro
1. 深入理解 AI 运算的特性
第一，为了做 AI 任务的调度，首先需要去深入的理解 AI 任务运算，计算过程这样的特性，下方左图做了统计，对阿里内部的计算任务做的统计，发现80%的计算任务，它的 mini batch（小批量，需要同步的一个单位）时间大概是600毫秒，仅仅比半秒多一点。那么这样频繁的数据同步，是 AI 物落一个典型的要求。第二，从现在的深度学习模型参数的发展上来看，可能从两三年前的 BERT 大概的参数和现在最大的模型 GPT-3 相比，已经非常小。这说明了比如用数据并行的方式，在训练一个模型的时候，每600毫秒需要通信整个模型参数的数据量，现在的模型通信的数据量非常的大，对于整个网络带宽，都有比较大的挑战。
2.新硬件的挑战
从上层应用的角度，若从底层硬件的角度来看，就会发现随着AI 任务的引进，现在的底层硬件也变得更加的丰富起来，首先 gpu 现在用的非常的多，像 MI100，A100等等。例如阿里，也会有一些相应的 AI 推理的芯片，让含光800这样的芯片可以加速整个任务的推理，当然还有相对比较通用的计算硬件 cpu。在云上，还会有 RDMIA Nic，Smart Nic这样相应的通信优化的硬件。基于 KubeDL，如何去将上下两层拟合计算任务特性相关的 gap，以及跟底层硬件相关的 gap，主要就是透过通信、计算、存储、资源调度，以及整套的监控相应的优化，把这些增强的功能叫做 KubeDLPro。
3.KubeDLPro：拓扑感知调度
接下来在 KubeDLPro 上实现的叫做拓扑感知调度的能力，展示有怎样的功能。首先，举个例子，就是用户提交一个拍拖组的任务，假设这个拍拖组的任务需要四个 gpu，那么用户这个任务就会起四个 worker，每个 worker 对应一个 gpu，这里面用圆圈来代表一个 worker，这种传统的调度的方法，就会把这四个 pods 放到资源池里去看看哪里有空闲，按照某一个调度的策略做这样的摆放。但是实际上，在 AI 的目录里面，可以发现其实整个资源池并不是像之前一样的简单。例如刚刚举的例子，放下去之后，会发现其实任务被放在了两个不同的机器上，这里面橘黄色的模块表示一个机器，这个机器上又有不同的 GPU，GPU 之间呈现不同的拓扑连接，并不是一个完全对称的，那么下图的机型是典型的 V100的机型，其中每个绿色的方框代表gpu，黑色的线代表了gpu之间是通过 NV link 进行连接。其实这里的意思是 NV link 是 gpu 通信里面比较重要的硬件，它的带宽就比 PCIeSw 要大很多，可能达到几倍于 PCIeSw 带宽的程度，更不用说网络的带宽。其次，它可以使得 gpu 跟 gpu 之间的通信达到零拷贝，不需要通过 cpu，简化了整个数据搬移的代价等等。在这个调度的场景里面，首先是因为传统的方法，并不能够感知非常复杂的网络图，它有可能通过这样调度，把整个拍拖的任务调到了两个机器，两个 gpu，而且用的同个机器内的这个 gpu，甚至也没有办法用 NV link 进行联系这样的一个场景里面。
这里做的事情，就是通过这样的方式去感知底层的拓扑的信息，以及任务，对通信的需求，使得可以在空闲资源里面选择最佳的、紧凑的、通信带宽大的这样的一些机器和一些 gpu 来放置计算任务，那么就像刚提到的这种 NV link 带来的这个 p2pGPU Direct 通信，它有若干个好处：首先不用数据拷贝，其次不用 cpu 跟 gpu 之间进行数据通信，第三零内核调用。
（1）NVILINK p2p GPUDirect通信：
①0数据拷贝
②0 CPU-GPU 通信
③0内核调用
这些具体该如何实现，首先是这里制作出一层去统一的感知设备间的通信能力，包括NV link，PCIeSw。比如同一个 PCIeSw 的通信也会比跨 PCIeSw 要差了百分之几十。 QPI 就是不同的new note 之间的连接的通信，当然也包括 RDMA NIC。因为这个 RDMA ，可以让你使用用 gpu direct over RDNA，在有网卡的那个socket和没有网卡 socket 上会呈现不同的效果。那么嵌套东西，首先是在阿里巴巴内部的 gpu 提供去 deploy。针对于阿里内部典型的 AllReduce 的深度学习模型，它可以带来这个1.12x 到10.54x 的性能的提升。那么后面就把这样的一套东西搬到了云上，用 PyTorch 10w 分类的任务做了评估，发现相比使用现有社区最好的方法，在云原生场景里面，这两者相差就可以达到相差十倍性能的程度。观察起来会发现，其实在阿里巴巴整个集群的角度，通过拓扑感知调度，NV link 通信资源的利用率得到一个显著的提升，达到四倍的提升，更多的任务，更多的计算，可以走 NV link，大带宽，免拷贝的一种应用形式，也说明了更多的任务可以用更快的速度完成。
（2）统一感知设备间的通信能力
①NVLINK
②PCleSw
③QPI
④RDMA NIC
（3）业务效果
①Alibaba 典型 AllReduce 深度学习模型:1.12x~10.54x
②PyTorch10w 分类任务:10x
③NVLINK 利用率:4x
4.拓扑感知调度系统框架
那么具体从下往上讲，首先下图比如画了四个 gpu，再随便画了一些 NV link 和 PCIeSw 表达出这里有一些不同网络拓扑的连接，这里制作一层 Enhanced NVIDIA Device Plugin，从硬件的角度去把这样的一些拓扑的关联关系给它抽取出来，然后把这样的信息发给 KubeDL 和operator 以及集群的调度器，那么使得可以感知到底层它的硬件资源的拓扑是什么样子。KubeDL，它会做拓扑感知的调度，它通过调度器提供的资源预占这样的接口，使得其可以不仅仅做杠，可能在杠的时候，甚至把任务之间使用 gpu 的相关联的特性也考虑上，从而为它分配一个更大带宽，更好的通信的位置，做到精准的这样的 gpu 的调度的分配。所以主要的改动，就是在这三个层面，一是在 KubeDL，另一个是在 scheduler from work 里面的schedule，第三是在 Enhanced NVIDIA Device Plugin。
5.拓扑感知调度系统实现
这是整个实现的大体逻辑，用户提交 All-Reduce 的任务的时候，首先会来到 operator，就是刚才提到的 KubeDL 里面，那么 KubeDL 会去把相应的信息提交给叫做 gpu coordinator 的角色，接着它会去 group 的资源预占这样的 CRD。与此同时，这里的 Device plugin 上报的这种 gpu 拓扑也是存在一个 CRD，这里面的 gpu coordinator 根据 gpu 拓扑的 CRD，以及任务资源需求的 CRD 去分析，然后做一个 mapping，把整个任务所有的需求做一个 mapping。然后调用调度器提供预留资源这样的接口，去把这个任务做一个预占，最终再把相应的这个 pod 的信息进行提交到调度器。调度器就会做一个 pod 的调度消费，把那些刚预留过的资源精准地分配给相应的 pod，使得完成整个任务，调度总体的实现是通过这样的形式。这个就是基础版的拓扑感知调度实现的方式，在这上面，主要一开始的实现，其实这些问题也都是从阿里内部通过对于自己的 gpu 集群，跑一些 AI 的任务，然后发现现在硬件的能力以及社区上的一些方案还没有办法用的特别好，所以把这样的方案实现出来，通过阿里云云原生的平台，让更多的人能够用上。
6.One more thing
接下来是One more thing，就是刚刚的拓扑感知调度，其实是在解决用户已经提交这么多的 gpu 了，比如说这里用户已经交了一个4卡的任务，那么这个4卡的任务，到底应该怎么调度的问题。上文刚刚故意跳过了一个问题，就是当要提交一个深度学习的任务的时候。这里举一个的例子，例如有一个8卡的任务，到底是要以怎样的值去提交，比如说有一个方案，单机8卡所有东西都摁到一个进程里，这里自己进入设置通信设定等等。另外一个方案可以2机，每个机器4卡。那么更扩展的情况，4个机器，每机2卡，再到极端的情况，就是完全做一个分布式，8个机器，每个机器1卡。这些其实都是不同的提交方法，它有好有坏，那么在同一个进程里面去提交的话，自然就可以控制相应能够拿到的计算资源，都能让任务去做相应的 NV link 来进行通信。但是如果这里提交一个8机，每机1卡的任务也有好处，当集群里面存在资源碎片的时候，可以更快的拿到相应的一些资源，因为相当于只要八个1卡的资源，比起之前只要一个8卡的资源，力度更加的细，更容易拿到，等待时间就会更短。其实刚刚用户想的时候是很美好的，单机8卡，两机4卡效率会比较高，但是整个集群里面很多时候是因为你的任务跟别的人同时在执行，有不断的有任务完成、到达。例如说像有的机器剩三块卡，有的剩五块卡，有的六卡，有的七卡，其实都跟用户想的不太一样，用户以为自己有八块卡，这样的任务应该怎么做呢。
这里做一个总结，也是举一个例子，一个忙碌的集群里面，确实很难找到这种规整的 gpu 计算资源。那么会出现一个情况，比如一位用户，买了四个机器，每个机器八块卡，一共32块打过来，现在空闲的机器能看到16块，然后提交一个2机，每机4卡的任务，就是交不上去，因为在这个集群里面，找不到一个刚好把2机，每机4卡任务放上去的位置，那么这个任务就被迫等待。但是实际上也可以发现其实不一定必须2机4卡，比如说用3+5的形式，整个任务完成时间，其实跟最短的2机4卡是一样的。比如说在这个举例中，灵活的变成3+5的形式，就会轻松的运行起来，不会遇到上面的问题。那么更进一步，能不能等到运行时结合调度的情况，给用户做一些资源申请形状的改变呢？
是否能让用户在等待时间和运行时间两边到达平衡，不要将这种困难的工作交给用户去完成。用户也不知道当前跑的集群、剩的资源到底是怎么样，而且其从一开始写代码上就会不一样，单机8卡任务的代码，肯定和8机1卡的代码完全不一样。那么这就让很多的用户都非常的纠结，能不能通过系统层的能力来做到自动平衡，就使得用户编码上不用纠结，最后运行起来的性能还是可以非常的好。
在这里，进一步的对拓扑感知做扩展，扩展到拓扑感知+自动聚合。这里是建议用户在编码的时候就完全按照分布式的方式做编程，比如说要对用户写一个 Pytorch 的任务，按照 Pytorch ppt 的方式，刚刚的例子写成一个8机1卡，在这边就是通过 KubeDLPro+PAI 框架，就是 Pytorch 里面相应的一些改动来支持用户行为。那么会自动选择最佳的通信拓扑，具体怎么做，刚刚在前面示范过。第二，实现了跨 pod 的 NV link 的通信，就现在社区的方案，跨 pod 是没有办法看到另外一个 gpu 的，那自然就没有办法进行相应的 NV link 的通信，都会变成 memory 或者网络之类的情况。第三，当 hold 对其他的 gpu 可见的时候，通过框架自动分配 gpu 的设备，到相应的 Pytorch 的 work 上面，使得知道在用哪块卡，需要一个框架的相应的改动。刚刚所说的8卡的任务，就是在这个场景里面，它会自动被捕捉到，然后给调度到这样的一个那种7+1的形式运行起来，其性能跟原来用户设想的2机4卡的情况相比是完全一样的。目前这样整体功能，也都在整个DLC的产品里面，对于 TensorFlow 和 Pytorch 现在都支持这样的功能。
（1）用户编码的时候按照分布式方式编程：
e.g,PyTorch8卡代码按照 ddp 的形式写成8机1卡
（2）KubeDLPro+PAI 框架
①自动选择最佳通信拓扑
②跨 Pod NVLINK 通信自动分配 GPU 设备
上述8卡任务实例:
红色圆圈为分配的资源
总结。在云原生场景里 AI 任务的调动相关的工作。第一个，是提供了 KubeDL 这样的组件，然后这也是一个完全开源的东西，并且可以很轻易的去扩展。因为这里做到金融社区所有的 tf-operator/pytorch-operator 的单个的事情。第二个，基于这套组件可以很容易的进行扩展，这里也非常欢迎更多的开发者把他们所需要的 AI 任务提交的能力通过 KubeDL 来实现，教导大家怎么去实现的KubeDL 的 operator 。通过 all-in-one 这样的理念，使得只要很简单的实现 operator 那么任务就拥有刚刚说的底层相应的资源优化的能力，相当于可能通过一个抽象的程序，共同的支持这样的方案，不再区分到底是什么样的计算任务，其都可以原生的做到支持。另外，通过调度器还有 AI 框架作了协调的设计，进一步把在阿里内部的 AI 实践的优势特性和能力，通过一种兼容社区的 operator、调度器这样的形式更进一步的让 AI 的框架跟调度进行联动，使得硬件的资源可以被利用的更好。第三，就是理念，因为观察到 AI 的用户大部分都是算法工程师，他们花在研究算法、调参相关的时间非常多，但是对于系统底层他们并不是特别了解。这里就需要让这个功能够做到尽量的对用户的透明，使得他们不用去管系统实现和硬件的细节就可以达到想要达到的效果，同时也是效率优先。因为 gpu 确实很贵，那么肯定希望能够不断的去进行任务的训练速度的优化，并且提升整个提取资源的利用率，使得大家的任务吞吐率都能够上去。
（1）兼容社区容易扩展：KubeDL 提供了兼容社区tf-operator/pytorch- operator 等深度学习应用提交工具的接口，通过 all-in-one 的理念让这些工具可以最大化共享优化方案,并且容易扩展到更多的 AI 应用。
（2）调度和 AI 框架协调设计：KubeDLPro 拓展了云原生场景中的 AI 任务调度，把阿里巴巴 Al 实践中的优秀特性和能力通过兼容社区的方式透出；并通过 Al 框架和调度的联动，进一步释放硬件的能力。
（3）用户透明高性能：AI 任务的用户通常都是算法工程师,通过底层的用户透明优化,使得他们不用关注于系统和硬件的细节,更加专注于算法和数据;效率优先，关注任务的训练速度优化和资源使用率。
