小米:基于 K8s 原生扩展的机器学习平台引擎 ML Engine 实践

发布于:2019 年 12 月 26 日 09:56

小米:基于K8s原生扩展的机器学习平台引擎 ML Engine实践

相比于传统的调度系统,Kubernetes 在 CSI、CNI、CRI、CRD 等许多可以扩展的接口上有很大提升。从生态系统上来讲,Kubernetes 依托于 CNCF 社区,生态组件日趋丰富。在云原生设计理念方面,Kubernetes 以声明式 API 为根本,向上在微服务、Serverless、CI/CD 等方面可以做更好的集成,因此不少公司开始选择基于 K8s 搭建机器学习平台。在 ArchSummit 全球架构师峰会(北京站)的现场,InfoQ 采访到了小米人工智能部高级软件工程师褚向阳,听他分享小米机器学习平台以及基于 K8s 原生扩展的机器学习平台引擎 ML Engine。

2015 年,现任小米人工智能部高级软件工程师褚向阳加入了创业公司——数人云,开始进行 PaaS 平台的研发,算是国内比较早的一批投身容器化 PaaS 平台研发的工程师,后来去到京东广告部,这个阶段积累了一些 GPU 的使用经验,为他之后来小米做机器学习平台打下了基础。采访中,褚向阳表示,相较于通用型 PaaS 平台,机器学习平台更加聚焦业务,需要对机器学习相关业务具备清晰认知,并理解困难点。在小米工作的这段时间,褚向阳参与构建和优化了小米 CloudML 机器学习平台以及 ML Engine 架构。本文,褚向阳分享了他的一些实践经验和想法。

小米 CloudML 机器学习平台

对于机器学习平台的定位,褚向阳套用了 ABC 概念图(如下图),并表示机器学习平台应该处于这三者中间的支撑位置,只有机器学习平台可以充分利用云原生的计算能力和特性,不断加速把数据转化为用户价值的循环过程,这也是机器学习平台真正起作用的地方。

小米:基于K8s原生扩展的机器学习平台引擎 ML Engine实践

在小米,机器学习平台承载了图像、NLP、声学、搜索推荐等应用业务,各应用作为用户接入机器学习平台,然后可以利用平台提供的所有功能,比如训练、Pipeline、模型服务等,机器学习平台团队对用户提供这些能力的定义,帮助用户更好的使用这些服务。

小米:基于K8s原生扩展的机器学习平台引擎 ML Engine实践

在这个全景图中,核心逻辑也就是平台接入层、模型框架层和资源管理层被抽离出来形成了 ML Engine。

ML Engine 架构设计演进

据介绍,ML Engine 是基于 K8s 原生扩展的新一代机器学习平台引擎 ,在此之前,小米机器学习平台应用了原生 K8s 的所有对象,比如原来的 Job、Deployment、Service 等,初期的 CloudML 架构图如下所示:

小米:基于K8s原生扩展的机器学习平台引擎 ML Engine实践

如上图,分布式训练任务主要是一组 Job/Pod+SVC,模型服务主要是 Deployment+SVC+Ingress。褚向阳表示,最初的架构在队列、状态同步,生命周期管理和调度策略层面均存在挑战,比如随着业务规模逐渐成熟,大部分业务训练对分布式提出了比较强的需求,当时虽然可以支持,但用户体验上不够友好。最终,出于解决这些问题的想法,团队开始对平台进行改进。

团队对可能的开源方案进行了调研,发现 TF Operator 的设计理念与现有想法比较吻合,但又没有完全解决问题,因为小米需要对多个框架做统一支持,所以团队决定通过自研解决问题。ML  Engine 的主要思路则是充分利用 K8s 原生的扩展机制,包括 CRD / Webhook / Scheduling Framework 等,将机器学习平台相关的业务模型、控制逻辑和调度策略融入到 K8s 集群中,提供更好的生命周期管理,同时满足高可用、稳定性和易维护性的云原生特性。最终,ML  Engine 变成了由 CRD、Webhock、定制调度器组成的状态。

小米:基于K8s原生扩展的机器学习平台引擎 ML Engine实践

总结来看,ML Engine 新版架构具备如下特点:

  • 机器学习平台业务的合理抽象 CRD
  • 针对机器学习任务特性的定制调度器
  • 公共的 validating/mutating 逻辑
  • 提供统一的对外接口

褚向阳表示,整个引擎可以理解为基于 K8s 原生扩展做的定制和改造,使它更适合于平台直接把它当做机器学习能力的输出口。举例来说,K8s 里面可能只有 Job,没有机器学习训练或者模型推理,但是通过 ML  Engine 将这些能力抽象到了平台里面,用户调用 K8s 的 API 或者 SDK 时,就可以使用定义好的模型推理和训练能力,直接做 API 级别的交互。

为什么不直接放在 K8s 之上?

对 K8s 的改造其实也花费了团队不少精力,但在褚向阳看来,整个社区的发展,包括 Tensorflow,都在对 K8s 进行扩展,以保证真正把 K8s 用的更灵活,或者真正使用好这份扩展性,也就是云原生的特性,可以很好地继承云原生的稳定性、高可用特性等。如果只是底层基于 K8s,而不做任何改造,很难用好。正是基于这样的扩展机制,开发团队才可以更加灵活和可靠的设计业务场景。

为什么不直接用 K8s 生态里面的工具?

如开篇所言,K8s 依托 CNCF 形成了丰富的开源生态,开源社区中也有很多工具可供选择,但褚向阳表示,这些工具不会为了机器学习一个场景调整调度策略,或者资源分配逻辑。举例来说,深度学习和机器学习中占据主导地位的 GPU 资源,在其他场景下并不常见。目前,社区在这方面比较火的项目是 Kubeflow,小米也吸取了很多 Kubeflow 的优势,但是为了能给平台向上提供统一的接口,只能把这些作为引擎里的关键组成部件。

ML Engine 对多框架的分布式训练支持

在小米,ML Engine 训练任务的核心用例有用户给定训练代码及启动命令 (可选:定义数据及产出物);支持选择不同的机器学习框架及运行时环境 (CPU/GPU);下发集群,需要支持分布式启动训练,且需要遵循一定的调度优化策略等。

褚向阳表示,ML Engine 训练任务的整体流程为:

1、发起训练任务请求;
2、提交 K8s,创建 ML Train;
3、触发 ML Engine Controller;
4、根据 MLTrain Spec,决定创建 TF Job;
5、ML Train Code 相关 Spec,触发 git-sync Mutating 逻辑;
6、Patch Request;
7、Pod 调度;
8、识别分布式任务,触发 framework plugins

小米:基于K8s原生扩展的机器学习平台引擎 ML Engine实践

在整个过程中,小米机器学习团队逐渐解决了用户接口层统一、框架状态统一等问题。谈到未来的发展方向,褚向阳表示,整体还是以解决内部需求为主,只要内部用户有需求,团队都会满足。功能上,主要考虑将计量、计费也抽象成 CRD,提供更方便的数据管理逻辑和更丰富的模型服务管理能力。 此外,与模型优化相关的项目,或者说所有可以提高效率的做法也会实时关注,并在时机成熟后积极尝试开源。

经验总结

在机器学习平台搭建层面,每家公司由于背景、业务不同,所以会出现不同的做法,在褚向阳的理解中,K8s 原生的扩展性、服务的可用性保证以及服务的易维护性是可取的优点,但使用时需要注意 admission webhook 是把双刃剑,建议设置过滤条件,以及处理好各框架不同版本之间的 golang 依赖等。

最后,容器也有自己的应用场景,K8s 诞生之初就对无状态应用提供了非常好的支持,无论是开发快速试用环境,还是用来跑大规模分布式训练的任务调度,包括云原生的推理服务,都是非常合适的。如果希望充分发挥云原生的特性,不但平台层和应用层要做改造,底层的支撑平台,包括存储等都要为云原生做好准备,否则会遇到各种各样的困难。

采访嘉宾:

褚向阳,小米人工智能部 / 高级软件工程师。2013 年毕业后加入红帽软件,吸收开源文化,接触 OpenStack 和 IaaS 平台相关技术。2015 年底开始加入容器云创业公司,参与打造容器化的 PaaS 平台,2018 年从京东广告部加入小米人工智能部,负责小米机器学习平台的建设,重点支持各个框架的分布式训练,订制优化 K8s 调度,努力提高平台用户体验的同时保证集群利用率。持续关注 Kubeflow 社区及性能优化相关开源项目发展。

阅读数:2080 发布于:2019 年 12 月 26 日 09:56

评论

发布
暂无评论