2021 年 6 月 23 日,云原生计算基金会(CNCF)宣布通过全球 TOC 投票接纳 KubeDL 成为 CNCF Sandbox 项目。KubeDL 是阿里开源的基于 Kubernetes 的 AI 工作负载管理框架,取自"Kubernetes-Deep-Learning"的缩写,希望能够依托阿里巴巴的场景,将大规模机器学习作业调度与管理的经验反哺社区。
项目地址:http://kubedl.io
随着 TensorFlow, PyTorch,XGBoost 等主流 AI 框架的不断成熟,和以 GPU/TPU 为代表的多种AI异构计算芯片的井喷式涌现,人工智能正快速进入“大规模工业化”落地的阶段。从算法工程师着手设计第一层神经网络结构,到最终上线服务于真实的应用场景,除 AI 算法的研发外还需要大量基础架构层面的系统支持,包括数据收集和清理、分布式训练引擎、资源调度与编排、模型管理,推理服务调优,可观测等。如以下经典图例所展示,众多系统组件的协同组成了完整的机器学习流水线。
与此同时,以 Kubernetes 为代表的云原生技术蓬勃发展,通过优秀的抽象和强大的可扩展性,将应用层与 IaaS(Infrastructure as a Service)层的基础设施完美解耦:应用能够以“云”的范式按需使用资源,无需关注底层基础设施的复杂性,从而解放生产力并专注于自身领域的创新。
Kubernetes 的出现解决了云资源如何高效交付的问题,但对于 AI 这类本身具备高度复杂性的工作负载还无法做到很好地原生支持,如何整合各类框架的差异并保留其通用性,同时围绕 AI 工作负载的运行时去建设一系列完善的周边生态及工具,业界还在不断探索与尝试。在实践中,我们发现了 AI 负载运行在 Kubernetes 生态中面临着如下挑战:
针对上述难题,阿里巴巴云原生,集群管理和 PAI 团队将管理大规模机器学习工作负载的经验沉淀为通用的运行时管理框架——KubeDL,涵盖分布式训练,模型管理,推理服务等机器学习流水线的各阶段,使工作负载能够高效地运行在 Kubernetes 之上。
1、分布式训练
KubeDL 支持了主流的机器学习分布式训练框架(TensorFlow / PyTorch / MPI / XGBoost / Mars 等),其中 Mars 是阿里巴巴计算平台开源的基于张量的大规模数据计算框架,能够分布式地加速 numpy,pandas 等数据处理框架的效率,帮助 Mars 作业以更 native 的方式集成进云原生大数据生态中。
我们将各类训练作业生命周期管理中的共同部分进行抽象,成为一层通用的运行时库,被各分布式训练作业控制器复用,同时用户也可以在此基础上快速扩展出自定义的 workload 控制器并复用现有的能力。借助声明式 API 与 Kubernetes 网络/存储模型,KubeDL 能够进行计算资源的申请/回收,各 Job Role 之间的服务发现与通信,运行时的 Fail-over 等,算法模型的开发者只需声明好此次训练依赖的 Job Role 及各自的副本数,计算资源/异构资源数量等,然后提交任务。另外,我们针对训练领域的痛点也做了诸多的特性设计来提升训练的效率与体验:
针对海量离线作业元数据需要长时间保存(Job CRD 被删除后元数据即从 etcd 销毁)的诉求,KubeDL 还内置了元数据的持久化,实时监听 Job/Pod/Events 等资源对象的变化,转化成对应的 Databse Schema Object 并持久化到存储后端中。存储后端的设计也是插件化的,用户可以根据自己的线上环境来实现存储插件并在部署时 enable。在 KubeDL 中 Job/Pod 默认支持了 Mysql 的存储协议,以及将 Events 收集到阿里云 SLS 服务中。
同时我们还提供了管控套件:KubeDL-Dashboard,用户不需要去理解 Kubernetes 的众多 API 并在各种 kubectl 命令中挣扎,即可界面化地上手简单易用的机器学习作业。持久化的元数据也可以直接被 Dashboard 消费使用。Dashboard 提供了简单的作业提交、作业管理、事件/日志查看、集群资源视图等功能,以极低的学习门槛帮助机器学习用户上手实验。
2、推理服务规格调优
GPU 虚拟化与分时复用技术的发展和成熟,让我们有机会在一块 GPU 上同时运行多个推理服务,显著降低成本。然而如何为推理服务选择合适的 GPU 资源规格,尤其是不可压缩的显存资源,成为一个关键难题。一方面,频繁的模型迭代让算法工程师无暇去精确估计每个模型的资源需求,流量的动态变化也让资源评估变得不准确,因此他们倾向于配置较多的 GPU 资源冗余,在稳定性和效率之间选择牺牲后者,造成大量浪费;另一方面,由于 Tensorflow 等机器学习框架倾向于占满所有空闲的显存,站在集群管理者的角度,根据显存的历史用量来估计推理业务的资源需求也非常不准确。在 KubeDL-Morphling 这个组件中我们实现了推理服务的自动规格调优,通过主动压测的方式,对服务在不同资源配置下进行性能画像,最终给出最合适的容器规格推荐。画像过程高度智能化:为了避免穷举方式的规格点采样,我们采用贝叶斯优化作为画像采样算法的内部核心驱动,通过不断细化拟合函数,以低采样率(<20%)的压测开销,给出接近最优的容器规格推荐结果。
3、模型管理与推理服务
模型是训练的产物,是计算与算法结合后的浓缩精华,通常收集与维护模型的方式是托管在云存储上,通过组织文件系统的方式来实现统一管理。这样的管理方式依赖于严格的流程规范与权限控制,没有从系统层面实现模型管理的不可变,而容器镜像的诞生解决的就是 RootFS 的构建-分发-不可变等问题,KubeDL 将两者进行结合,实现了基于镜像的模型管理。训练成功结束后,通过 Job Spec 中指定的 ModelVersion 会自动触发模型镜像的构建。用户可以在 ModelVersion.Spec 中约定模型的存储路径,目标的镜像 Registry 等基本信息,将每次的训练输出 Push 到对应的镜像仓库。
同时镜像作为训练的输出,以及推理服务的输入,很好地串联起了两个阶段,也借此实现了分布式训练->模型构建与管理->推理服务部署的完整机器学习流水线。KubeDL 提供了 Inference 资源对象提供推理服务的部署与运行时控制,一个完整的 Inference 服务可以由单个或多个 Predictor 组成,每个 Predictor 对应前序训练输出的模型,模型会被自动拉取并挂载到主容器 Volume 中。当多个不同模型版本的 Predictor 并存时,可以根据分配的权重进行流量的分发与控制,达到 A/B Test 的对照实验效果,后续我们还会在 Batching 批量推理和 AutoScale 上针对推理服务场景做更多的探索。
随着云计算的深入人心以及越来越多的业务都用云原生的方式进行,阿里云计算平台 PAI 机器学习团队推出了 DLC(Deep Learning Cloud)这一深度学习平台产品。DLC 采用全新的云原生架构,底层采用 Kubernetes 作为资源底座支持,而训练部分全面采用 KubeDL 进行管理,是 KubeDL 在深度学习云计算场景中的大规模实践。
DLC 在阿里集团内部内广泛支撑了众多的业务,包括淘系安全部达摩院的图像视频、自然语言、语音、多模态理解、自动驾驶等众多业务部门的深度学习计算需求。在服务于深度学习驱动的前沿业务生产中,PAI 团队在框架和平台建设方面积累了许多的经验,沉淀了兼容社区(eg,TensorFlow/PyTorch)并且具有鲜明特色的大规模工业界实践过的框架平台能力,如万亿规模参数的M6模型的训练、工业级图神经网络系统 Graph-Learn、极致资源管理和复用能力等等。
如今,PAI-DLC 的能力也在全面拥抱公有云,为开发者和企业提供的云原生一站式的深度学习训练平台,一个灵活、稳定、易用和高性能的机器学习训练环境,以及全面支持支持多种社区和 PAI 深度优化的算法框架,高性能且稳定的运行超大规模分布式深度学习任务,为开发者和企业降本增效。
公有云的 DLC 作为阿里巴巴集团机器学习平台最佳实践的透出,在产品细节、框架优化、平台服务等方面都吸取了工程实践中的宝贵的经验。除此之外,DLC 产品在设计之初就充分考量了公有云场景中的独特属性,提供了竞价实例、自动 Fail-Over、弹性扩缩等功能,为客户努力降低 AI 算力成本。
进一步的,DLC 也与 PAI 的其他公有云产品相结合,比如说服务于算法工程师建模的 DSW、服务于企业级 AI 全流程的、自动化的 AutoML、在线推理服务 EAS 等,打造全流程的 AI 标杆性产品。
作者 | KubeDL 团队
原文链接:http://click.aliyun.com/m/1000289993/
本文为阿里云原创内容,未经允许不得转载。