近年来,AI 领域屡现突破性进展,吸引了全球企业争相采用 AI 技术来培育新增长、形成新动能、加快产业与科技的创新融合。在这个背景下,AI 人才开始供不应求,AI 产品迎来爆发。
然而新技术总有一定壁垒,机器学习不仅需要算法科学家构建新模型,工程师应用新模型,还需要工程师合力建设机器学习平台。而在应用机器学习的企业和团队中,建设机器学习平台正是重要一环。
那么机器学习平台是什么呢?它又有什么突出特性?今天,才云科技 AI 平台工程师 gaocegege 将为各位答疑解惑。
机器学习平台对于不同工程师角色而言,有着不同的意涵。之前我发布了几篇关于 Kubeflow 的文章,有不少的网友私下向我询问到底什么是机器学习平台,它与机器学习框架有何不同。在这篇文章里,我将从不同的维度来介绍一直谈论的机器学习平台到底是什么。
如果你有一个算法工程师
首先,我给大家讲个故事:
小咩是 TooYoung 科技的算法工程师,最近他正在为公司实现一个图像识别的模型。为了支持他的工作,公司 Infra 团队的工程师小婶给了他四台机器,每台各自配有 4 块英伟达显卡。
临走前,小婶拍了拍小咩的肩膀:兄弟,之后一个月,这些机器随便你用。小咩表面风轻云淡,心里其实已经乐开了花,他已经很久没有在这么多显卡的机器上放飞过自我了。
配备四块 GPU 的工作站 来源:Vladimir Iglovikov
四台机器中:
机器 A 的 TensorFlow 只支持 CPU;
机器 B 的 TensorFlow 的版本是 1.13;
机器 C 是公司里的算法科学家小莎在投稿 NeurIPS 时做实验用的,只安装了 PyTorch。
小咩叹了一口气,他飞快下楼买了一瓶快乐水,撸起了袖子,开始环境配置之旅。
第一台机器的问题在于已装的 TensorFlow 版本不支持 GPU。小咩熟练地卸载了机器 A 的环境,首先确认机器 A 上没有安装开源的英伟达驱动 Nouveau。之后,他开始安装英伟达的官方驱动以及 cuDNN,最后安装了支持 GPU 的 TensorFlow 版本。看着屏幕上打出的 Hello World,小咩嘴角扬起了微笑。
第二台机器的问题在于 TensorFlow 的版本太新了。于是小咩依样画葫芦,卸载了新版本,安装了旧版本。但在这个过程中,他发现 TensorFlow v1.4 不支持机器 B 上的 CUDA 9.0。虽然有些不情愿,小咩还是打开了谷歌,熟练键入“Remove CUDA 9.0 and install CUDA 8.0”。按照网友的指示,他终于解决了这个问题。
第三台机器问题比较少,小咩很快就处理好了。
接下来,小咩就可以开始自己的算法实验了。为了方便,他先在自己的笔记本电脑上建立了一个 Jupyter Notebook,将数据下载到电脑上,进行了小规模的实验。
经过一天的努力,他觉得自己的算法效果还算不错,可以放到服务器上进行分布式训练,以期更快的训练速度。于是他利用 /etc/hosts 给四台机器做了一个简单的服务发现,利用 TensorFlow 的分布式训练功能进行了分布式的训练。
经过数天调参,小咩模型的各项 metrics 都达到了公司的要求,于是他准备将模型发布到公司的生产环境中。小咩利用了开源项目 TensorFlow Serving,在公司内部的 PaaS 平台上新建了一个服务,并将自己训练的模型发布到了公司的生产集群上。看着流量稳定地灌入自己的模型服务,小咩深吸了一口气。
如果你有一个机器学习平台
时间一天天过去了,这个模型不知不觉已经在线上服务了数月,小咩也由工程师变成了公司里的 Tech Lead。最近,这一模型有了相关的增量模型,但小咩已经没有足够的时间再参与到一线的开发工作中了。为了进一步提升模型性能,小咩团队里的新进工程师小豆接起了这项任务,利用新的数据集重新训练模型,并再次发布。
在几个星期之前,Infra 团队利用开源项目 Kubeflow 为算法工程师和算法科学家们搭建了一个麻雀虽小五脏俱全的机器学习平台。小豆决定利用这一平台对模型进行训练。
他首先利用 Infra 团队已经打包好的 TensorFlow v1.4 的 Docker 镜像,用平台发起了一次分布式训练。训练中的服务发现,异常处理等都由平台自动完成。
训练间隙,小豆在查看文档发现平台还支持超参数训练,而且使用起来非常简单,只需要指定相应的参数搜索空间即可。于是他又发起了一次超参数学习任务,对模型的超参数选择进行了优化。
模型训练结束后,小豆利用平台上已有的模型服务功能,直接将训练好的模型上传到分布式存储中。平台根据配置自动完成了模型的部署,并针对算法工程师们关注的指标进行了细粒度监控。
机器学习的工程化落地
通过以上故事,我们可以了解到,机器学习平台的用户往往是机器学习算法科学家或工程师。而机器学习平台希望解决的是机器学习工程化落地的问题。
在小咩第一次进行模型开发与部署的时候,他遇到了很多来自系统环境和服务发现等原本应该由 Infra 来解决的问题。这其中包括服务器上的显卡驱动问题、TensorFlow 版本的问题、服务发现的问题、训练过程中的跟踪与错误恢复等。而当小豆在机器学习平台上进行模型训练和模型发布时,这些问题已经都交由平台来自动化处理,他可以专注于业务的开发。
对于机器学习工程师,TensorFlow、PyTorch 这些框架改变的是机器学习的编程范式,而机器学习平台改变的是机器学习的开发与发布流程。
而从基础架构工程师的角度来看,机器学习平台某种程度上类似 PaaS,但又有所不同。两者相同之处在于都涉及到资源的管理与调度、服务发现等功能,不同之处在于机器学习平台对于 GPU 有极其强烈的需求,与此同时,和传统的应用相比,机器学习有着不同的工作流程。
举个例子,传统应用可以很好地抽象出持续集成与持续部署工作流,应用的每一次提交都可以触发对应的测试与发布流程。而对于机器学习任务来说,测试往往并不是对代码本身的测试,而是对模型效果的测试。
类似的诸多差异导致了目前的 PaaS 等平台不能很好地处理机器学习这一应用场景的需求。换句话说,这时候我们需要一个新的平台,它既继承了 PaaS 的某些功能,又针对更好地支持机器学习业务,增加了大量新特性。
下面我们就来具体地谈谈,这些特性包括什么。
机器学习平台的特性
准备数据是一次机器学习任务的起点,但数据准备的平台化,从实现上来说应该是比较困难的。因为数据准备是一个需求差异非常大、很难将其标准化的过程。目前开源领域也有一些针对不同场景的打标工具,如 labelme 等,但这一方面的工程实现和研究性工作其实都不太常见。
训练是机器学习任务中的重中之重。机器学习平台的训练支持指的是,用户通过指定使用的资源数量、分布式模型(AllReduce、ParameterServer 等)、分布式配置(ParameterServer 数量等)等,直接在平台上进行模型训练。
从平台的角度来看,这一特性主要涉及到对不同类型的框架、不同的分布式模型、不同的硬件的支持,以及分布式训练任务的服务发现、错误处理,不同任务的资源隔离与复用等问题。除此之外,有些场景对于在线训练也有需要,如何支持在线训练,是一个机器学习全流程都需要考虑的问题。
再接下来,就是模型服务。这一特性与传统的 PaaS 比较类似,因为模型服务目前多是以 RESTful API 暴露给外部的,与传统的 Web 服务非常类似。不过从实现角度而言,不同的框架训练的模型往往需要用不同的方式发布出去,而且模型服务关注的度量指标与传统 Web 服务也有较大差别。
回到版本管理,传统的应用往往只涉及配置与代码的管理,而机器学习则多了不少新的维度,如模型,版本等。这一部分的特性虽然比较 dirty work,但是却与用户的使用体验息息相关。除此之外,还有整个过程中的监控问题(训练过程监控,服务过程监控),也是同样性质的工作。
在解决完上面的问题后,机器学习工作流的构建这一特性就水到渠成地摆到台面上了。如何让用户用尽可能少的交互取得他/她想要的效果,以及如何加强这一过程的自动化,是离不开工作流方面的工作的。
至于超参数训练与模型结构搜索,这是机器学习平台的高级特性。虽然自动机器学习听上去非常有前途,但相关技术目前仍处于研究阶段。对于超参数训练来说,最难过的一关是性价比问题。Random Search、Grid Search 和贝叶斯优化方法是最常用的调参方法,它们找到的参数确实可能比人工调参有更好的效果,但与此同时,它们也会需要更多的硬件资源。因此这一特性属于锦上添花,而不能起到雪中送炭的作用。至于模型结构搜索,就更遥远了。
小结
上述的介绍是挂一漏万的,一个成熟的平台系统一定有更多的细节值得去讨论,限于篇幅关系,这里不再展开。我撰写此文只是想大致说明一下,机器学习平台究竟是怎样的一个存在,它可以帮助到用户做到什么事情,提高了哪些方面的效率。
介绍完之后,再打一个小小的广告。我们团队目前正在招聘中。如果你对构建基于 Kubernetes 的 Cloud Native 机器学习平台系统感兴趣,可以了解下我司才云科技的产品 Caicloud Clever(戳文末“阅读原文”了解更多细节)。一直以来,我们始终在这一方面努力攻坚,成果也比较显著——目前才云科技在机器学习平台开源项目 Kubeflow 上的贡献位列全球前三。
本文转载自才云 Caicloud 公众号。
原文链接:https://mp.weixin.qq.com/s/JaL67jS3LQxu6uiFEimtug
评论