作者：陈迪豪，小米深度学习工程师，负责小米云深度学习平台的架构和实现，目前专注于TensorFlow和Kubernetes社区。
责编：何永灿，欢迎人工智能领域技术投稿、约稿、给文章纠错，请发送邮件至[email protected]
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅《程序员》
机器学习与人工智能，相信大家已经耳熟能详，随着大规模标记数据的积累、神经网络算法的成熟以及高性能通用GPU的推广，深度学习逐渐成为计算机专家以及大数据科学家的研究重点。近年来，无论是图像的分类、识别和检测，还是语音生成、自然语言处理，甚至是AI下围棋或者打游戏都基于深度学习有了很大的突破。
而随着TensorFlow、Caffe等开源框架的发展，深度学习的门槛变得越来越低，甚至初中生都可以轻易实现一个图像分类或者自动驾驶的神经网络模型，但目前最前沿的成果主要还是出自Google、微软等巨头企业。
Google不仅拥有优秀的人才储备和大数据资源，其得天独厚的基础架构也极大推动了AI业务的发展，得益于内部的大规模集群调度系统Borg，开发者可以快速申请大量GPU资源进行模型训练和上线模型服务，并且通过资源共享和自动调度保证整体资源利用率也很高。
Google开源了TensorFlow深度学习框架，让开发者可以在本地轻易地组合MLP、CNN和RNN等模块实现复杂的神经网络模型，
但TensorFlow只是一个数值计算库，并不能解决资源隔离、任务调度等问题，将深度学习框架集成到基于云计算的基础架构上将是下一个关键任务。
除了Google、微软，国内的百度也开源了PaddlePaddle分布式计算框架，并且官方集成了Kubernetes等容器调度系统，用户可以基于PaddlePaddle框架实现神经网络模型，同时利用容器的隔离性和Kubernetes的资源共享、自动调度、故障恢复等特性，但平台不能支持更多深度学习框架接口。
而亚马逊和腾讯云相继推出了面向开发者的公有云服务，可以同时支持多种主流的开源深度学习框架，阿里、金山和小米也即将推出基于GPU的云深度学习服务，还有无数企业在默默地研发内部的机器学习平台和大数据服务。
面对如此眼花缭乱的云服务和开源技术，架构师该如何考虑其中的技术细节，从用户的角度又该如何选择这些平台或者服务呢。
我将介绍小米云深度学习平台的架构设计与实现细节，希望能给AI领域的研发人员提供一些思考和启示。
云深度学习平台，我定义为Cloud Machine Learning
，就是基于云计算的机器学习和深度学习平台。首先TensorFlow、MXNet是深度学习框架或者深度学习平台，但并不是云深度学习平台，它们虽然可以组成一个分布式计算集群进行模型训练，但需要用户在计算服务器上手动启动和管理进程，并没有云计算中任务隔离、资源共享、自动调度、故障恢复以及按需计费等功能。
因此我们需要区分深度学习类库以及深度学习平台之间的关系，而这些类库实现的随机梯度下降和反向传播等算法却是深度学习应用所必须的，这是一种全新的编程范式，需要我们已有的基础架构去支持。
云计算和大数据发展超过了整整十年，在业界催生非常多优秀的开源工具，如实现了类似AWS IaaS功能的OpenStack项目，还有Hadoop、Spark、Hive等大数据存储和处理框架，以及近年很火的Docker、Kubernetes等容器项目，这些都是构建现代云计算服务的基石。
这些云服务有共同的特点，例如我们使用HDFS进行数据存储，用户不需要手动申请物理资源就可以做到开箱即用，用户数据保存在几乎无限制的公共资源池中，并且通过租户隔离保证数据安全，集群在节点故障或者水平扩容时自动触发Failover且不会影响用户业务。
虽然Spark通过MLib接口提供部分机器学习算法功能，但绝不能替代TensorFlow、Caffe等深度学习框架的作用，因此我们仍需要实现Cloud Machine Learning服务，并且确保实现云服务的基本特性——我将其总结为下面几条：
-
屏蔽硬件资源保证开箱即用
-
缩短业务环境部署和启动时间
-
提供“无限”的存储和计算能力
-
实现多租户隔离保证数据安全
-
实现错误容忍和自动故障迁移
-
提高集群利用率和降低性能损耗
相比于MapReduce或者Spark任务，深度学习的模型训练时间周期长，而且需要调优的超参数更多，平台设计还需要考虑以下几点：
-
支持通用GPU等异构化硬件
-
支持主流的深度学习框架接口
-
支持无人值守的超参数自动调优
-
支持从模型训练到上线的工作流
这是我个人对云深度学习平台的需求理解，也是小米在实现cloud-ml服务时的基本设计原则。虽然涉及到高可用、分布式等颇具实现难度的问题，但借助目前比较成熟的云计算框架和开源技术，我们的架构和实现基本满足了前面所有的需求，当然如果有更多需求和想法欢迎随时交流。
遵循前面的平台设计原则，我们的系统架构也愈加清晰明了，为了满足小米内部的所有深度学习和机器学习需求，需要有一个多租户、任务隔离、资源共享、支持多框架和GPU的通用服务平台。
通过实现经典的MLP、CNN或RNN算法并不能满足业务快速发展的需求，因此我们需要支持TensorFlow等用户自定义的模型结构，并且支持高性能GPU和分布式训练是这个云深度学习平台的必须功能，不仅仅是模型训练，我们还希望集成模型服务等功能来最大化用户的使用效益。
计算机领域有句名言“任何计算机问题都可以通过增加一个中间层来解决”。
无论是AWS、OpenStack、Hadoop、Spark还是TCP/IP都是这样做的，通过增加一个抽象层来屏蔽底层资源，对上层提供更易用或者更可靠的访问接口。小米的cloud-ml平台也需要实现对底层物理资源的屏蔽，尤其是对GPU资源的抽象和调度，但我们不需要重新实现，因为社区已经有了很多成熟的分布式解决方案，如OpenStack、Yarn和Kubernetes。
目前OpenStack和Yarn对GPU调度支持有所欠缺，虚拟机也存在启动速度慢、性能overhead较大等问题，而容器方案中的Kubernetes和Mesos发展迅速，支持GPU调度等功能，是目前最值得推荐的架构选型之一。
目前小米cloud-ml平台的任务调度和物理机管理基于多节点的分布式Kubernetes集群，对于OpenStack、Yarn和Mesos我们也保留了实现接口，可以通过实现Mesos后端让用户的任务调度到Mesos集群进行训练，最终返回给用户一致的使用接口。
目前Kubernetes最新稳定版是1.6，已经支持Nvidia GPU的调度和访问，对于其他厂商GPU暂不支持但基本能满足企业内部的需求，而且Pod、Deployment、Job、StatefulSet等功能日趋稳定，加上Docker、Prometheus、Harbor等生态项目的成熟，已经在大量生产环境验证过，可以满足通用PaaS或者Cloud Machine learning等定制服务平台的需求。
使用Kubernetes管理用户的Docker容器，还解决了资源隔离的问题，保证不同深度学习训练任务间的环境不会冲突，并且可以针对训练任务和模型服务使用Job和Deployment等不同的接口，充分利用分布式容器编排系统的重调度和负载均衡功能。但是，Kubernetes并没有完善的多租户和Quota管理功能，难以与企业内部的权限管理系统对接，这要求我们对Kubernetes API进行再一次“抽象”。
我们通过API Server实现了内部的AKSK签名和认证授权机制，在处理用户请求时加入多租户和Quota配额功能，并且对外提供简单易用的RESTful API，进一步简化了整个云深度学习平台的使用流程，整体架构设计如图1。
图1 云深度学习平台整体架构
通过实现API Server，我们对外提供了API、SDK、命令行以及Web控制台多种访问方式，最大程度上满足了用户复杂多变的使用环境。集群内置了Docker镜像仓库服务，托管了我们支持的17个深度学习框架的容器镜像，让用户不需要任何初始化命令就可以一键创建各框架的开发环境、训练任务以及模型服务。多副本的API Server和Etcd集群，保证了整个集群所有组件的高可用，和Hadoop或者Spark一样，我们的cloud-ml服务在任意一台服务器经历断网、宕机、磁盘故障等暴力测试下都能自动Failover保证业务不受任何影响。
前面提到，我们通过抽象层定义了云深度学习平台的接口，无论后端使用Kubernetes、Mesos、Yarn甚至是OpenStack、AWS都可以支持。通过容器的抽象可以定义任务的运行环境，目前已经支持17个主流的深度学习框架，用户甚至可以在不改任何一行代码的情况下定义自己的运行环境或者使用自己实现的深度学习框架。在灵活的架构下，我们还实现了分布式训练、超参数自动调优、前置命令、NodeSelector、Bring Your Own Image和FUSE集成等功能，将在下面逐一介绍。
