为什么我们需要机器学习平台？( 二 ) 整个机器学习的工程化落地过

与此同时，你发现并没有训练所需的数据(打上了标签的图片)供你使用，经过询问后。还好公司有提供一批数据，不然就得自己动手，一张一张吭哧吭哧了。然后把训练用的数据搞到服务器上，一番数据探索、预处理，代码编写、测试和折腾，写出了第一版，终于可以开始调参训练、优化了。伴随着一声清脆的回车，模型已经开始训练。可以摸鱼去了~
But ， A怎么知道模型训练的情况呢？机智的A早已把关键地方的日志进行了输出，同时配备了对应框架的可视化工具(Tensorboard) ，以此来观察模型的训练情况。但还有一个比较头痛的问题是，这个训练什么时候能结束，万一异常失败了咋办？A也不知道，只能在摸鱼的同时，不时地去Check训练状态。
几天过后，训练完成，找到了最合适的算法和参数，出来的模型准确度也符合预期，万事大吉。
诶，等等。如何把这个模型发布成一个可供其他service调用的RESTful API(gRPC) ，如何保障部署服务的实时性、安全性、扩展性、AB Testing？
革命尚未成功，同志仍需吭哧吭哧.....
为什么需要一个机器学习平台？从上面的故事中我们可以看到，整个机器学习的工程化落地过程，其实掺杂着与很多机器学习本身不是很相关，但是和基础设施、或者其他工程领域强相关而且通用的事情。比如环境搭建，框架版本适配，模型部署，训练任务监控、可视化；任务调度、多租户等。而对于机器学习工程师来说，他们更擅长的是算法、模型、数据探索等工作；相对于工程化方面的能力，他们可能并不擅长(可能也并没有兴趣..) 。当然，这还只是一个精简过的故事，如果是分布式训练，数据来源于分布式存储，那它的复杂度又上了一个台阶。
从上面的栗子，其实我们可以归纳出一个较为通用的机器学习落地过程，从原始数据的准备，到最后模型的部署。基本上所有的机器学习流程都带有这些阶段，我们用一张图来可视化：
文章插图
看到这一条流水线，很多人就自然而然想到了传统应用的CI/CD(持续集成、持续部署 & 持续交付)工具，比如Jenkins、GOCD 。从一次代码的提交到最后产品的上线、各个环境的部署，整个过程都是可以自动化的，从而实现端到端的交付，一步到位。我们的确可以把一次机器学习过程看做是一条pipeline ，里面划分了很多的stage ，当然不是每个stage都是必须的，而是相对自由的组合。但传统的CI/CD工具并不能很好支持这个机器学习的pipeline(到目前为止) 。
比方说，我们的训练Stage ，可能需要不同的环境、框架，需要能够拥有调度的功能(GPU/CPU) ，感知训练状态；能够获取对应的训练数据(存储能力支持) ，而这些数据，一般来说都是大数据，存在于外部存储中(对象存储、HDFS、NFS...) 。不能说通过传统的一个一个的下载的方式。而对于机器学习的测试，也不是写几个Case去测试算法代码，而是去测试训练出来的模型，比如评估模型的各种Metrics(准确度，精确率，召回率等) 。这是传统CI/CD工具的局限性。
另一点，既然说自己解决这些基础设施的问题很麻烦，那可以交给专门的人(平台)去做啊，这个时候就自然而然想到了PaaS这个东西，它不就是专门做这个事的吗？环境、框架、资源调度，应用打包、发布，要啥有啥，给它我的代码和数据，万事大吉。
但传统的PaaS平台，仍旧有其不足性。于机器学习来说，首先，对GPU、分布式训练等有着近乎狂热的需求(也是氪金的需求) 。所以对于GPU资源的管理和调度，分布式训练的部署等就显得很重要。传统的PaaS平台显然更擅长CPU、存储、无状态服务部署等，在这方面明显支持不足。同时，由于机器学习框架和环境的多样性，如何发布机器学习产出的模型。也和传统应用不一样。对于训练需要的数据准备工作而言，现有的PaaS平台更是很少有提供对应的标注工具。也就是对于机器学习整个流程的支持，传统PaaS还不足以支撑。
总结一下， CI/CD更擅长流程把控。这是我们所需要的。传统PaaS平台，擅长基础设施侧的工作。这也是我们所需要的，也就是：我全都要！！
这其实是一个PaaS平台和CI/CD的融合体，其中的一种实现，也就是机器学习平台。平台的好处，不用多说。有了平台后，这些工作(流程)就可以自动化、标准化、工程化。从而使机器学习工程师可以专注于业务开发。做他们最擅长的事。对企业而言，可以避免重复建设，统一管理资源和对接，为企业智能化发展提供基石。