导读 随着深度学习技术的进一步发展，将深度学习技术进行更好地应用成为了当前发展的趋势，想要将产业智能化快速深入推进，人工智能基础设施的建设不可或缺。因此深度学习平台十分重要，它是产业智能化的基础技术底座。今天会和大家分享下阿里云云原生深度学习平台 PAI-DLC 实践与落地。

今天的介绍会围绕下面三点展开：

1. 机器学习平台介绍

2. 深度学习平台 DLC 架构设计

3. 未来展望

分享嘉宾｜穆冰森 阿里巴巴 高级技术专家

编辑整理｜周旻萱 南开大学

出品社区｜DataFun

01/机器学习平台介绍

首先分享一下机器学习平台的背景，以及机器学习平台需要具备哪些能力。

1. 机器学习平台需要具备的能力

机器学习平台通常主要包括四大类能力，即数据处理，模型开发，模型训练和模型部署。

（1）数据处理阶段，主要包括数据预处理，特征工程等。

（2）模型开发阶段，模型又分为传统的机器学习算法如 Xgboost，SVM 等，以及现在流行的深度学习算法，模型的开发工具指的是 jupyter notebook/webide 这种能够提高开发效率的交互式开发工具。

（3）模型训练主要是通过算法框架训练模型，目前常见的有 PyTorch，TensorFlow，PaddlePaddle 等，另外还有其它一些在框架之上封装的算法引擎。数据存储相关问题包括在训练过程中样本数据存储在什么位置以及如何加载，是否做了一些数据缓存、数据加速、提高数据 IO 等，且模型训练可能牵扯到异构的硬件包括 CPU、GPU，以及如何利用国产化的 DCU 芯片去做模型训练的加速等等。

（4）模型部署，当模型训练完后需要去进行 serving，其中包括很多 serving 推理框架，包括 ONNX，TF serving 等。有些公司可能会自研一些推理框架。同时为了提高推理的速度，会使用异构硬件进行推理加速。

2. 机器学习平台产品架构

PAI 是一个典型的 PaaS 的平台，底层 是 IaaS，包括 CPU、GPU、FPGA、NPU，以及阿里云的容器服务（ACK）。上层是机器学习框架，除了支持各种开源的框架外，还集成了 PAI 开源的一些机器学习训练框架，如面向不同业务场景的 Easy 系列，面向 NLP 的 EasyNLP，面向推荐的 EasyRec 以及面向 CV 的 EasyCV 等，通过这种封装可以提供更便捷友好的平台能力。同时在 PaaS 里边提供了智能数据标注、可视化建模、交互式建模的能力。以及核心的 PAI-DLC，它主要负责训练, 并且是一个底层的基础平台，即所有的 Easy 系列、PyTorch 和 TensorFlow 都可以运行在 DLC 上，和预测服务。除此之外，还提供了一些开发者工具，如编译优化等。在 PaaS 之上则是做一些预训练大模型相关细分领域应用的 SaaS 服务。

02/深度学习平台介绍

1. 深度学习平台的特性

业界的很多机器学习平台都有相同的特征，平台的目的基本上是一样的，可能真正实现的时候会有一些差异。

效率体验包括两方面，一方面是用户体验，另一方面是深度学习训练平台的流畅度和性能。

用户管理 和资源管理比较相关，比如一个公司有一个集群和一些资源，内部有不同的组织和部门，这些部门或者组织都有独立的预算，我们可以通过给他们划分不同的 Quota 来实现资源的分配和管理，同时用户可以属于一个或者多个不同的 Quota，这里用户和资源管理就是对 Quota 和用户的管理。

节省成本主要指提高集群资源利用率，降本增效。

弹性主要指资源的弹性，基于资源的弹性实现弹性训练、弹性推理等，弹性又分为向内和向外，向内主要体现在资源的重调度，包括扩缩容以及 Quota 间的借还等；向外体现在比如可以使用 Spot Instance 等弹性的资源来做弹性的训练和推理，同时使用 Spot Instance 因为价格相对便宜还可以节省成本。

可复现主要是指通过数据、代码、参数进行版本管理等手段实现实验的可重现。

异构算力主要是指不同计算加速的硬件。

训练离不开数据，如何通过平台管理这些数据也是一个需要关注的地方，数据自治就是指这样的一个数据管理系统。

最后是 AutoML 自动调参的能力。

以上就是一个深度学习平台的主要特性。

2. 云原生深度学习平台 PAI-DLC 架构

上图展示了 PAI-DLC 的整体架构，从下往上看，最底层是硬件基础设施层 ，类似于 IaaS，包括 CPU、GPU/DCU、FPGA、RDMA 等，以及 NAS/OSS 等一些存储。在这之上，是 K8S 相关的 ，比如标准的插件，使用这些插件可以提供对硬件资源的抽象和能力。PAI 的平台部分 是基于 Kubermetes CRD 的开发技术，实现了一整套支持多种分布式框架进行训练的能力，其中 KubeDL Operator 是负责 TF job、Pytorch job、MPI 以及 XGBoost 等训练任务的提交和管理这样一个 all in one 的控制器。再上层是 DLC service ，主要是做一些鉴权、认证，同时会给出一些 Open API，基于 Open API 也会提供 Web 白屏化、命令行、SDK 的能力。整个 DLC 是建立在 K8S 上的，这要求在整个平台的部署过程中都是需要容器化的，另外 Open API 能够让平台具有更好的扩展性和被集成的能力。

下面将具体介绍其中的一些能力，以及这些能力是如何体现到真正的商业化过程中的。

（1）容器化

容器化分为两部分，一部分就是服务容器化 ，另外一部分是引擎容器化。PAI 在训练框架优化、训练加速等方面都有很深的积累，会把这些能力以容器的方式提供给用户使用。那如何进行容器化的改造呢，我们基于开源的 argo，搭建了一个全流程的 CI/CD（持续集成持续部署）的工具，支持完整的 CI/CD 过程，从代码到镜像的构建和发布，直到最终服务部署的过程。除了提供 PAI 优化后的镜像以及社区的开源镜像外，平台同时也支持客户自定义的镜像。

（2）Open API

Open API 在云里面边是比较重要的，一方面，例如 SDK 的自动生成和发布与之有关；另外，很多时候需要第三方的客户去集成，即客户通过 Open API 的方式去集成到自己的平台或者系统中。我们会对里面的所有资源进行抽象，统一地去定义一个资源和权限，最后变成一个类似于增删改查的方式去对外服务。

（3）AI 负载调度

原生默认的调度器在调度效率方面和扩展方面都有一些问题，以往都是通过 K8S webhook 的方式去做一些插件能力的开发。为了更好的支持 AI & 大数据的任务，目前社区主流的调度器主要有 2 种，一种是完全自研的调度器 ，比如华为的 Volcano；另外一种就是 Scheduling Framework 这种插件式的框架进行开发支持。在 AI 和大数据里边，包括 AI 的分布式训练，以及 Spark 这些任务都需要多个角色（Pod）去协作完成，例如它们需要进行一些通信才能去正常地训练。默认的调度器会逐个 Pod 地调度，当资源不满足时，会出现资源的死锁等现象，导致资源的浪费，解决这样的问题就需要用到 Coscheduling 的调度能力。

该调度方法的含义是要么都满足，要么都不满足。如果提交的是一个四个 worker 的任务，我们可以设置只有四个 worker 的资源都被满足，或者最少满足多少资源，这个任务才会被调度，如此可以防止部分调度引起的资源死锁和资源浪费。基于 Scheduling Framework 的架构，可以通过 label 的机制给每个 Pod 打上一个的 Pod Group 标签，再通过排序把同一个 group 的 Pod 放在一起去调度，如此实现 All-or-Nothing 的能力。

另外最常见的是资源碎片的问题。调度器的默认策略是 Pod 优先选一个比较空闲的 Node，空闲是指 CPU/GPU/ 内存等比较空闲的 Node 去调度 Pod。这样的调度策略容易产生碎片的问题，会影响集群的利用率，比如集群内有 2 台 8 卡的机器，先调度了 2 个 4 卡的任务，这 2 个任务分布在不同的节点上，这时如果再提交一个 8 卡的任务就会因为资源无法满足被拒绝调度。扎堆调度就是为了解决这个碎片化问题，比如在给节点打分的地方根据 Node 资源的水位去做一些策略，比如资源充足水位高，那么打分就高，因此就让它优先被调度。

下面介绍 Capacity scheduling 的能力，即资源配额管理。原生的 K8S 原生的配额管理 CRD -- ResourceQuota，存在一些缺陷，即每次需要预先固定分配资源，分配完后会在每个 Namespace 下创建一个 ResourceQuota 的 CR，当提交任务时其会做资源的判断，去看是否满足 Quota。但无法实现不同 Quota 之间的共享。

阿里云 ACK 团队自研了一个树形结构 CRD ElasticQuotaTree， 支持多级 Quota 管理，可以实现精细化的资源管理。另外，它支持多种的资源配置，如 CPU/GPU/RDMA/ 网卡等，都可以进行管理, 并且支持通过 min、max 语义实现 Quota 之间的借还；min 表示最少保证的资源份额，max 表示最多可用的资源份额。

（4）GPU 虚拟化和共享调度

接下来介绍节省成本方面的能力。

关于 GPU 虚拟化，业界存在很多不同的方案。目前 PAI 采用的是阿里云自研的一套 GPU 的虚拟化方案，支持显存的隔离和算力的隔离，并且对规格大小没有限制，最小可以做到 1% 的算力级别，显存可以做到 1MB。同时它兼容 Linux 作系统以及各种的 GPU 卡，如
T4/P100/V100/A100/A10/2080 等。

使用了虚拟化技术之后，是去做 GPU 的共享调度，其最小可以支持 0.1 卡，0.01 卡虽然是理论可以做到，但是在实际工作中 0.01 卡的算力意义不是很大。在 DLC 上提交一个任务，指定一个卡数如 0.2，然后它会自动把 Pod 启动在一个 0.2 卡上，相当于有 20% 的算力和显存。同时，支持指标采集，GPU-exporter 能够方便地拿到 Pod 的一些指标，如GPU的利用率，显存的变化等。并且会与 schedule 合作去完成 Quota 的记账。另外它也支持单机多卡和多机多卡的场景。

（5）EasyScale 精度无损弹性训练

**EasyScale 是基于 PyTorch 的一个精度无损的弹性训练框架。**弹性能够节省成本，提高整个集群资源的利用率，但是随之而来也会涉及到资源的抢占和归还，其中抢占又分为温和抢占和暴力抢占，如果是暴力抢占相当于直接把一个任务停止掉，那么这次任务训练就会失败，如果一个训练时长为六七天的任务，成本代价有点大。针对这些情况，PAI 自研了一套 EasyScale 的弹性训练框架。传统的弹性训练框架存在的问题是，训练过程中改变 GPU 的数量将会改变整个训练过程，其中的 batchsize，learning rate 等超参数都会发生一些变化，导致最终训练的模型的精度损失。

EasyScale 是在 PyTorch 上做了一些抽象和封装，引入了 EasyScale Thread 线程的概念，基于 GPU 去做分时复用，当传统的弹性训练框架发生缩容的时候，它会在一个卡里边起两个 EasyScale thread，两个 thread 分时复用在同一张卡上， 同时会把在训练过程中影响精度的数据做好保存，在后面进行还原，从而保证整个训练过程中的超参数保持不变，从而保证精度的无损。

同时 EasyScale 还支持异构的场景。GPU 不同卡型的算力的大小是不一样的，EasyScale 可以根据不同的卡型去调整计算量，使之能够保证在异构的环境下无损的弹性训练。

（6）数据访问

数据访问，目前 PAI-DLC 支持 OSS、NAS、CPFS 这三种介质，当然还有其他的，比如可以在 Pod 内去通过 SDK 访问外部的一些存储。同时提供两种挂载方式，本地挂载和 PVC 挂载。支持数据加速，也就是数据的缓存，集成了阿里云的 Fluid 用于缓存引擎，并支持数据亲和性调度，比如有一个任务用了同一个数据集，会尽可能地把使用同一数据集的任务调度到对应的节点上。并且还支持数据安全隔离，这也是 ToB 场景里面一个重要的需求，很多客户都会对自己数据的安全性、隔离性有比较高的要求。

（7）可观测性

DLC 同时兼容阿里云 SLS 日志组件和开源的 ELK 组件，借助它们做 Pod 日志和事件的采集、持久化和查询分析，另外通过各种 exporter，比如 Node Exporter，GPU Exporter，RDMA 等去监测机器 GPU 的利用率，网卡流量的变化等信息，并且能够可视化地展示每个任务的资源变化曲线。通过对日志、事件以及各种指标的监控和分析，从而帮助我们更容易地分析定位一些问题。同时还支持 Tensorboard，能够可视化地监控训练的过程等情况。

03/未来展望

业界都在提一站式的机器学习平台，但在真正使用的过程中其实对很多部分还都是比较割裂的，还是有差距的。如何去做以模型为中心的 MLOps，优化这部分的体验值得考虑。另外在机器平台里边有离线训练和在线的推理服务，其中就会涉及到离在线混部统一调度的问题。

另外，随着国产化 GPU 芯片的发展，会有越来越多的客户选择国产化的芯片，未来机器学习平台肯定需要去适配这种变化。再者关于机器学习平台本身的一些标准化，比如交互等。还有就是机器学习平台在多场景的输出能力，目前 PAI 对外主要有四种部署形态，公共云的全托管，公共云的半托管，以及专有云，还有线下轻量化输出的形态，这些不同的形态在机器学习平台怎么去做标准化也是一个比较重要的课题和未来的一个方向。

04/问答环节

Q1：worker 在不同机器怎么缩容？

A1：worker 缩容，对于 EasyScale 来说一个 worker 没了，EasyScale 内部相当有一个协调者，它会监测到缩容的情况，并备份好一些相关信息，并在一个 Pod 里面启动两个 thread，这两个 thread 跟原来的两个实际上是一一对应的，所有的参数都一样，只不过通过分时复用的技术去运行，且性能会稍微差一些。

Q2：GPU 虚拟化会不会开源，开源的版本好像很久没有更新？

A2：GPU 虚拟化对于每一个公司其实都是一个比较核心的技术，但是大体上都会分为显存隔离和算力隔离，对于该技术方案每个厂商和公司都会有一些核心的能力，精细的地方可能不太一样，这些能力暂时可能不会被开源，因为需要保持商业竞争力，这也可以理解。

今天的分享就到这里，谢谢大家。

▌2023数据智能创新与实践大会

数据架构/数据效能/智能应用/算法创新......

4大体系，专业解构数据智能

16个主题论坛，覆盖当下热点与趋势

70+演讲，兼具创新与最佳实践

1000+专业观众，内行人的技术盛会

点击下方链接了解详情：

DataFunCon2023（北京站）：数据智能创新与实践大会