深度学习云服务适配问题研究
来源:用户上传
作者:
摘要：深度学习技术是支撑众多人工智能应用的基础，云服务是当今主流的计算能力供给模式。以云服务方式提供深度学习能力广受关注，构建这类服务的关键在于深度学习业务向云服务模式适配，具体涉及作业调度、存储接入和资源管理等方面的兼容性问题与适配型特性研发。OMAI深度学习平台将深度学习业务云服务化，通过作业调度中间层抽象、异构存储容器内挂载、资源表达式匹配等机制，有效解决了深度学习业务的云服务适配问题.OMAI为人工智能云服务研发提供指导思路。
關键词：深度学习;人工智能;云服务;高性能计算;平台软件
DOI：10.11907/rjdk.201139开放科学（资源服务）标识码（OSID）：
中图分类号：TP301文献标识码：A 文章编号：1672-7800（2020）006-0001-08
0 引言
深度学习技术作为人工智能领域的基础性技术，为互联网、金融、安全、教育、医疗等领域的众多应用提供技术支撑。近年来，深度学习云服务开始在各大云计算平台涌现，这是因为云服务模式能够解决深度学习技术门槛高、资源消耗多、需求波动大等问题，同时也体现出深度学习的业务需求具有一定的共通性和迫切性。然而，深度学习和云计算两个领域有其各自的发展轨迹，将深度学习平台作为一种云服务运行于云计算环境，势必遇到一系列有待适配的技术缺口及需要解决的工程问题。
公有云或私有云平台研发者已经或多或少地注意到这些问题并提出了解决方案，多种深度学习云服务的出现就是例证。然而，多数云服务由商业巨头开发，且存在软件架构迁就市场需求等现实问题，因此深度学习业务的云服务适配问题并没有系统地梳理和总结。本文基于对现有深度学习平台的分析，阐述了深度学习在云服务适配时可能遇到的问题，并对现有解决方案进行归纳整理，期望这些工作对未来深度学习云服务的研发提供有益启发及帮助。
本文提出OMAI（Oriental Mind Artificial Intelligence）深度学习平台。OMAI深度学习平台是一套以高性能计算（High Performance Computing，HPC）为特色，涵盖人工智能业务全流程的一站式平台软件，支持一体机、局域网、私有云与公有云部署。针对云服务适配，OMAI平台提出了作业调度中间层抽象、异构存储容器内挂载、资源表达式匹配等诸多机制，解决作业调度、存储接人和资源管理等不同的技术问题，构建一套系统化解决方案。
1 深度学习业务及其云服务特点
本文从深度学习运行时特征、服务化模式和云服务现状等角度介绍深度学习业务及其云服务特点。
1.1 深度学习运行时特征
深度学习业务分为研发层业务与应用层业务。前者指面向神经网络算法或人工智能应用的研发人员提供硬件、软件、算法、算力等基础设施服务的业务;后者指面向大众消费者或特定行业技术人员等最终用户，提供端到端应用服务的业务。研发层业务全生命周期包括算法开发、模型训练、训练过程可视化、模型验证、服务发布、数据推理等环节;应用层业务的全生命周期则以数据推理为核心，辅以模型增量训练等可选环节，以及前端界面、模型市场等周边服务。研发层业务的云服务适配问题，本质上是深度学习平台软件的上云问题，其涉及技术面广、代表性强，能够涵盖应用层业务的核心环节，因此本文的研究对象以研发层业务为主。
深度学习业务特征可从不同维度进行分类。考虑云服务场景的分类标准是业务的运行时特征，即运行模式。云计算环境中最常见的两种运行模式是微服务与批处理作业。表1给出深度学习业务各个环节的运行实体本质及归属运行模式，前述流程中的服务发布环节属于微服务的创建过程，无须分类单列。
（1）微服务模式。算法开发、训练过程可视化、在线模型验证和数据推理属于微服务模式，本质上是Web、REST或RPC服务，一般具有无状态特征，抑或是将状态持久化保存于外部存储器件。其生命周期长度取决于用户的主观需求，理论上可以无限长。尽管微服务可通过自包含或中间件方式独立运行，然而为了可管理性、可伸缩性和容错性等目标，实际场景下通常使用基于虚拟机、容器或无服务器（Serveless）技术的微服务调度与编排软件进行管理。
（2）批处理作业模式。模型训练、离线模型验证和数据推理属于批处理作业模式。它们本质上是普通进程，或为原生（native）进程，或基于Python等语言解释器;一般带有状态，在内存或显存中维护当前阶段的运行时信息。其生命周期长度取决于算法、算力、数据集大小等因素，一般情况为有限长，除非人为控制。尽管普通进程可以独立运行，然而为了可管理性、执行效率、资源利用率等目标，实际场景下通常使用批处理作业调度软件管理，这也是“批处理作业”模式名称的由来。
1.2 深度学习服务化模式
当一个组织内部的基础设施、应用与用户数量日益增长，或者打算提供对外服务时，软件的服务化就不可避免。深度学习业务的两种运行模式均可采用多种不同的服务化模式。微服务天然是为服务化设计的，传统上为Web应用或SOA（Services Oriented Architecture）中间件设计微服务调度编排软件，对深度学习业务中的微服务环节也适用。尽管不同的调度编排软件及运行环境（虚拟机、容器或无服务器架构）在云服务适配开发方面存在差异，但研发层业务用户可见的只是Web、REST或RPC接口，上述软件和环境对用户完全透明，其选型基本不影响服务体验。因此，微服务的服务化模式不是研究重点，这里不展开说明。
相比之下，批处理作业的服务化问题较为复杂。其核心原因在于：多数深度学习引擎以开发库（library）的形式发布，将运行时的控制权完全交给上层开发者，不提供面向服务化的运行时控制框架（调度框架）。这使得批处理作业的服务化工作必须补齐运行时控制的短板。运行时控制框架的设计或选型，既影响深度学习云服务的整体架构，又在一定程度上对研发层业务相关，因此成为深度学习服务化模式研究的重点。表2给出深度学习批处理作业中常见服务化模式所使用的调度框架及主要适用场景。 （1）大数据调度框架。大数据调度框架以Apache生态中的MapReduce、YARN调度框架为代表，其特点在于生态成熟，与大数据组件的交互性好，易于构建以数据为中心的工作流;可伸缩性和容错性设计较为完善，适合在已有的大数据集群上部署。基于这类框架的深度学习典型案例包括Yahoo！开源的TensorFlowOnSpark、Databricks发布的Spark Deep Learning，以及多种商业数据分析平台软件中的深度学习功能。
（2）高性能调度框架。以HPC生态中常见的Slurm、PBS调度器为代表。它们与高性能计算、通信及存储组件的交互性好，贴合深度学习训练对大规模矩阵运算及分布式通信的需求，特别适合基于MPI优化的深度学习引擎。其稳定性和可扩展性在大规模超算环境下得以验证，适合在已有的超算基础设施上部署。包括Amazon高性能计算服务（AWS HPC）、中国科技云人工智能平台在内的超算服务，均提供基于此类框架的深度学习解决方案。
（3）容器化调度框架。容器化调度框架以践行“云原生”（cloud native）理念的Kubernetes、Mesos DC/OS平台软件为代表。这类框架专门针对云服务的需求和特点设计，与云服务基础设施的交互性好，为业务上云带来很大便利。资源弹性与容错性是其主要优势，适合在已有的云计算环境中部署。这类框架的代表性深度学习解决方案有Kubeflow、Volcano等开源项目，多数公有云深度学习服务也选择了容器化路线。
1.3 深度学习云服务现状
近年来，人工智能的发展，催生了大量面向研发层业务的深度学习平台软件，部分软件支持云服务工作方式。为了归纳云服务特点以及分析深度学习业务的云服务适配问题，有必要对它们加以分类总结。本文采用云服务形态及定位两种分类维度。形态依服务受众可分为公有云服务和私有云服务，定位则与该服务的产品设计及发展历程相关。表3为在此标准下各类深度学习云服务的典型代表。
（1）公有云服务。公有云服务通过互联网面向公众提供服务。深度学习服务在公有云上一般处于SaaS层（开发工具）和PaaS层（能力集成）。深度学习公有云服务除面临多租户安全隔离、弹性伸缩与成本控制等公有云通用问题外，还需要解决专用硬件接人和复用等特有问题。
（2）私有云服务。私有云服务部署在组织内部，面向特定群体提供服务。深度学习服务在私有云中的安全性要求一般低于公有云，网络管理策略也相对简单。然而，私有云的资源限制导致其具有接人外部资源、构建混合云的需求，同时私有云往往涉及适配企业特有的组织构架与工作流程。
（3）以深度学习为核心的专业化人工智能服务。此类服务聚焦深度学习领域，在覆盖深度学习业务全流程的同时力图将局部技术点（如自动学习、算法模型库）做深做精。尽管其也支持传统机器学习及一定的数据处理功能，但往往不作为重点。此类服务一般以作业表单或RES了接口方式与用户交互，通常为用户提供较高的自由度，支持训练和部署自定义的算法模型。
（4）带有深度学习能力的综合型人工智能服务。此类服务更关注业务覆盖的广度，力图满足应用对人工智能技术的全方位需求，因此还包含传统机器学习、数据处理、服务编排、DevOps流程等服务。此类服务的用户交互形式比较多样化，以便适应人工智能领域不同细分业务特点。前两类人工智能服务大多属于独立规划与演进的产品。
（5）带有深度学习能力的数据分析服务。此类服务通常在数据分析平台基础上发展而来。传统的数据分析平台一般支持统计分析或机器学习方法。深度学习技术在补充其分析能力的同时，也具备一定的独立工作能力。此类服务往往继承了数据分析平台的工作流拖拽或笔记本交互使用模式，其算法模型一般以平台预置为主，对自定义程序的支持相对较弱。
（6）带有深度学习能力的高性能计算服务。此类服务通常是在高性能计算作业管理软件基础上发展而来。相比前几类覆盖深度学习业务多环节的服务，高性能计算服务一般只聚焦模型训练环节，以便充分利用超算硬件资源。此类服务普遍会继承高性能计算领域以作业脚本或表单为主的交互方式，支持用户提交自定义程序，且有较为严格的安全约束。
2 深度學习业务的云服务适配问题
从深度学习业务特点可以看出，并非所有业务环节均能精确适配云服务。深度学习的典型服务化模式也表明，并非所有服务化场景均具有“云原生”特征。从现有深度学习云服务实践可知，每款产品均有其设计取舍。因此，深度学习业务的云服务适配是一类综合性问题，尚不存在完美的解决方案。本文对这类问题进行系统性梳理，总结出其中3个主要问题——作业调度、存储接人和资源管理，并对问题的本质及相关研究成果进行综述。
2.1 作业调度问题
作业调度问题同批处理作业特性以及Python或原生进程的需求相关，这里分为运行模式适配和运行环境依赖两个子问题加以讨论。
2.1.1 运行模式适配
深度学习模型训练等核心环节的运行模式是批处理作业，典型的进程形态是Python或原生进程。然而，经典的云服务不能完全满足其需求，具体表现在：①弹性Ma-pReduce等大数据服务（如AWS EMR）虽然支持批处理作业调度，但主要服务于Java组件，存在安全沙箱等限制PY-thon或原生进程的设计;②容器实例或容器集群服务（如阿里云ECI）虽然与一些深度学习引擎主推的容器化运行模式一致，但它们为无状态的微服务设计，不支持群调度（gang-scheduling）等批处理专有特性，因而无法满足分布式训练需求;③基于容器的批处理服务（如Azure Batch）最大程度上满足了容器化与批处理两大需求，但仍存在分布式命令行参数配置复杂、进程行为控制语义薄弱等细节问题。
2017年以前，多数厂商选择自研深度学习批处理作业调度机制，如IBM PowerAI等脱胎于大数据系统的产品选择在Spark等大数据框架基础上构建深度学习支持能力，而大多数公有云深度学习服务选择在Kubernetes等容器平台上开发批处理作业调度。2017年以后，随着Kubeflow和Volcano两个开源项目的发布，容器化与批处理结合领域有了公认的解决方案，二者均通过Kubernetes的operator机制实现批处理作业的封装和抽象，并通过scheduler机制实现群调度等运行时的行为控制。主要不同点在于：Kubeflow倾向于提供高层次封装，且面向深度学习全流程设计;Volcano倾向于提供细粒度工具，且针对多种批处理调度场景设计。 相对于基于大数据和容器化框架的运行模式适配机制，基于高性能框架的工作比较小众。这与超算环境受众面小、从业人员动手能力较强有关。AWS HPC和中国科技云提供的深度学习能力，本质上是帮助用户自动创建批处理脚本，但后续操作仍需要使用传统作业管理命令或界面。随着人工智能业务的增长以及高性能计算技术向深度学习的渗透，高性能调度框架在深度学习领域的应用价值逐渐显现，这一趋势值得云服务开发者关注。
2.1.2 运行时环境依赖
深度学习领域的快速发展导致深度学习引擎、算法开发库的演进迅速，依赖关系复杂多变，它们对操作系统、编程语言及系统开发库的依赖也瞬息万变。深度学习的3种服务化模式普遍选择使用容器技术（Docker和Singularity）解决。容器使得作业进程包含上下文环境，避免管理复杂的环境依赖项。然而容器技术并非万能，考虑云服务下的作业动态调度场景，简单使用容器存在以下问题：
（1）开发库与驱动程序耦合。并非所有开发库都可通过容器实现与宿主环境的完全解耦，如CUDA、OFED等面向特定硬件的开发库就与宿主环境中的驱动程序存在版本依赖。以CUDA为例，NVIDIA GPU Cloud发布的镜像一般内置CUDA，通过定期升级宿主环境驱动程序的方法确保对新版CUDA兼容，同时逐步放弃旧版支持;另有一些公有云将不同版本的CUDA同时安装于宿主环境，由容器选择性挂载。两种方案在解决耦合问题时没有本质区别，区别只在于问题的归属者。
（2）镜像体积与拉取性能权衡。将更多的运行时依赖项置于容器镜像内部，就意味着作业调度时需要拉取更大的文件，这将对作业启动性能造成显著影响。除了对CUDA等体积较大、演进稳定的开发库实施上述挂载方案外，业界常用的优化方案还包括定期在宿主节点上拉取常用基础镜像或镜像的公共层，以及P2P等优化传输方案。
（3）作业内进程间依赖项的差异。同一分布式作业的不同进程（容器）间存在环境依赖项差异。以MXNet引擎的典型分布式作业为例，Master进程只需要最简单的PYthon环境，Server进程依赖更多Python开发库，Worker进程在此基础上还依赖CUDA。对3种进程统一使用完整的镜像势必造成资源浪费和性能损失。业界常用的优化方案包括为每种进程开发不同的镜像，或是将不同进程按特定规则合并到同一容器中执行。
2.2 存储接入问题
存储接人问题来源于深度学习作业对算法、模型、数据集等云上数据资产的访问，这里分为存储类型匹配和存储跨域访问两个子问题讨论。
2.2.1 存储类型匹配
深度学习作业要访问云上的数据资产，其前提是深度学习引擎、运行时控制框架以及云存储服务三者支持的存储类型存在交集。存储类型按接口类型划分，包括POSIX存储（如本地文件系统、网络文件系统）、对象存储（如AWS S3）、专有接口存储（如HDFS）等。
（1）深度学习引擎方面，TensorFlow通过通用的I/O中间层支持多种存储类型，而PyTorch对非POSIX存储支持有限，需要借助第三方库实现。
（2）运行时控制框架方面，大数据调度框架一般不干涉存储，而由应用直接访问存储;容器化调度框架则普遍提供对特定类型存储的容器内挂载机制。
（3）云存储服务方面，基于POSIX接口的本地文件系统、网络文件系统以及类AWS S3接口的对象存储几乎是云平台标配，专有接口存储也在部分大数据云服务中常见。
深度学习云服务开发者必须合理抉择上述三者的交集，才能让作业访问云存储变得可行和高效。几类备选存储的特征分析如下：①本地文件系统。它是必然可行的选择，也是线下环境的首选。然而在容器化环境中，本地文件系统的生命周期与容器相同，外部交互依赖于消耗时间空间的上传下载操作。同时，云服务也强调以数据为中心的交互，本地文件系统会割裂数据在服务间的复用;②网络文件系统（Network File System，NFS）。其可行性取决于运行时控制框架的支持程度，以Kubernetes为代表的容器化调度框架支持NFS挂载。但NFS在云环境中存在续跨域访问问题，需要开发者注意;③对象存储系统。REST接口的对象存储系统无须挂载即可使用，因此其可行性与运行控制框架无关，主要取决于深度学习引擎。不同于语义完备的POSIX存储，对象存储一般只支持顺序访问。这对其适用的数据资产类型造成限制，好在深度学习业务的常见资产访问操作不会超越顺序访问;④HDFS。其最大优势在于与Apache生态的大数据服务交互性好。HDFS的REST接口和顺序访问语义使其优缺点与对象存储类似，但亦存在跨域访问问题。
在当前公有云深度学习服务中，对象存储系统是主流。针对不支持对象存储的深度学习引擎，业界常用的解决方案包括在算法代码中调用第三方客户端、在深度学习引擎中添加访问支持，或在运行时控制框架层面实现文件系统挂载。在一些由数据分析平台演进而来的深度学习服务中，HDFS是主流，它們也常使用上述3种方法解决接口匹配问题。而在基于高性能计算集群的深度学习服务中，NFS及其它兼容POSIX接口的全局文件系统是主流，这与其固有的软件生态相适应。
2.2.2 存储跨域访问
深度学习业务访问存储服务时，需要考虑网络互通性。在单一局域网环境下，用户和开发者往往体会不到网络互通性对存储服务的影响，但在云服务环境下这一问题突显。私有云通常将用户和服务所在的局域网分设，用户需通过网关访问包括存储在内的服务。公有云的情况更为复杂，服务基础设施一般会按功能、地域和安全级别划分为多个局域网，网间路由与安全策略各异。网关机制不仅存在于用户与服务之间，还存在于各个服务组件之间。无论公有云还是私有云，用户的业务一般运行在名为“虚拟专有云”（Virtual Private Cloud，VPC）的局域网中，进一步增加了网络环境的复杂性。深度学习服务与存储服务在这种跨多网络环境下的交互，即构成存储跨域访问。 多数公有云的对象存储系统已经隐式解决了存储跨域访问问题，其实现原理是在云环境内部不同局域网及互联网的DNS服务器上为对象存储系统的域名设置不同的解析目标，使其指向本域可达的网关服务器。由于对象存储一般基于REST接口，普通的Web网关即可实现此功能。深度学习云服务组件可以从云环境内部的任意局域网、VPC或者互联网直接访问对象存储，简化了服务开发，故其是多数深度学习云服务优先支持对象存储的原因。不过，在公有云中使用对象存储系统还需要注意地域（region）概念，并非所有的公有云都支持地域无关的统一访问人口及跨地域的数据访问，深度学习云服务在这类公有云中一般要求为每地域一实例。
NFS、HDFS及其它面向局域网设计的全局文件系统在云环境下需要绑定到特定VPC，不支持隐式跨域访问。在实现深度学习云服务时对服务组件（运行于服务VPC内的主机）访问用户数据（位于用户VPC内的存储）带来了障碍。为解决这一问题，可以采取VPC对等连接或其它等价方式，实现跨VPC网络互通。同时，用户的VPC一般无法从互联网直接访问，这就需要云服务显式设计存储访问机制，将存储请求通过层层網关转发到用户的VPC中。此类设计对用户暴露的概念和操作相对复杂，在企业级定制产品中较为常见，在面向公众的产品中却不普遍。
2.3 资源管理问题
资源管理问题是云计算的共性问题，因为大多数云服务本质上体现了为用户管理软硬件资源的复杂性。这里将深度学习业务的资源管理问题分为应用对资源耦合及高性能资源复用两个子问题予以讨论。
2.3.1 应用对资源耦合
云计算环境为了实现高资源利用率及高灵活性，有将资源与应用解耦的倾向，这种设计对资源请求同构性强的应用友好。然而，深度学习业务不同环节、不同作业的资源请求差异性大。例如算法开发环境一般只需要CPU，模型训练需要使用训练型GPU（如NVIDIA V100），而数据推理需要使用推理型GPU（如NVIDIA T4）或FPGA;对于分布式作业，还需要选择性地使用高速以太网或InfiniBand网络。为所有宿主环境配齐各类资源显然是不经济的选择，这就需要运行时控制框架具有资源感知的调度能力，为不同的作业选择最合适的宿主节点。
仍以容器化调度框架为例说明。Kubernetes支持以量化请求方式申请CPU、内存等通用资源，以及GPU等通过插件接人的扩展资源，并支持以节点标签及其选择器（se1ector）方式描述量化请求不能表达的额外信息，例如GPU型号。这种机制在不涉及包含同类异构硬件的宿主节点的云计算环境中能较好地满足资源感知的作业调度需求。针对包含同类异构硬件的情况（如单机内有两种不同型号的GPU），亦有第三方开发者提出了ExtendedRe.source、ResourceClass等细粒度资源匹配机制。这些机制在硬件组成复杂的开发与实验环境中比较有用。但对于真实生产环境，考虑到硬件资源及软件版本的易维护性，应当尽可能避免同类异构硬件组合的复杂情况。
除GPU型号这种定性的资源感知指标外，在深度学习云服务中还需要注意诸如显存这样的定量指标。不同于支持时间片轮转的CPU资源和支持页面交换的内存资源，显存等资源数量不足并非只会影响执行效率，而是会直接导致作业失败。这一问题可以在容器化调度框架和算法程序两个层面解决。在框架层面，对于不涉及资源复用的情况，可以简单地将定量指标当作定性标签用于资源匹配。涉及资源复用时，上述ResourceClass机制及后续介绍的复用插件机制亦能提供支持。在算法层面，对于服务预置的算法可以采取资源感知的自适应设计，最大限度利用资源而不引发作业失败。
2.3.2 高性能资源复用
深度学习业务经常会使用高性能计算、通信与存储设备提升训练或推理效率。在多作业共享宿主环境的情况下，为提升资源利用率、降低服务成本，需要实现资源复用。并非每一种高性能资源都默认支持透明复用模式。资源复用需要考虑可行性、可用性、安全隔离及性能隔离等层面问题。某些ASIC和FPGA设备不提供多作业复用能力，这属于可行性问题;GPU虽然可被多作业复用，但显存总量有物理约束且默认不支持换出到硬盘，因此无法使瞬时内存超限的多个作业稳定并存，这属于可用性问题;GPU被复用时，多作业均可访问其虚拟设备文件，存在显存数据泄露风险，这属于安全隔离问题;InfiniBand网卡在被多作业直接复用时，每个作业的带宽无法得到保证，这属于性能隔离问题。在InfiniBand网卡上启用带有QoS支持的虚拟功能（Virtual Functions，VF）后，资源复用的多种问题可以得到解决。
仅在设备层面支持资源复用是不够的。深度学习云服务还需要在运行时控制框架层面以合理的方式应用这些底层机制，才能实现安全和性能有保障的资源复用。以Kubernetes场景为例，为了可用性与安全性目标，NVIDIA提供的GPU插件选择不开放GPU原有的复用能力，只允许一个GPU分配给一个容器组。阿里云开源的GPU共享插件开放了GPU复用能力，但不支持安全隔离和性能隔离，其适用于多个可信应用复用GPU，且在算法程序中自行保证资源用量的场景。腾讯设计的GaiaGPU机制”’）No通过系统开发库拦截GPU访问请求，在GPU复用的基础上实现了资源配额控制，从而满足多作业运行的可用性与性能隔离需求。
由于容器机制的弱隔离性，资源复用机制即使能够保证设备本身的安全隔离，仍有可能在其它方面具有安全风险。例如，部分资源复用机制依赖操作系统或容器的特权选项，使得从容器内部实施攻击更加容易。解决这类问题的思路是将用户身份感知的调度策略与资源复用机制相结合，避免互不可信的作业运行于同一宿主节点。此外，高性能生态中的Singularity非特权容器技术，以及基于轻量级虚拟机的Kata安全容器技术，也是实现高性能资源安全复用的可选方案，它们已在部分超算中心的高性能计算服务以及公有云的容器实例服务中实现，值得深度学习云服务参考。 3 OnAI深度学习平台
在介绍深度学习业务及其云服务特点，总结现有深度学习平台在云服务适配过程中遇到的问题和业界解决方案基础上，以OMAI深度学习平台为依托介绍笔者在此领域的研究与工程实践。
3.1 OMAI简介
OMAI深度学习平台是一套涵盖人工智能业务全流程的一站式平台软件。它提供开发环境、训练作业、可视化工具和推理服务等核心功能，支持算法、模型、数据集等资产管理。OMAI能够满足一体机、局域网、私有云与公有云等多种环境部署需求，具有面向最终用户、运营和运维人员的控制界面及REST接口。图1为OMAI软件架构。软件主体分为业务逻辑组件与资源管理组件两个层次，支持对接存储、用户、记账和日志等公共服务。
OMAI能够运行于大数据、高性能和容器化等多种集群，以一套平台软件支持多类服务化模式是其在产品定位层面与同类软件的重要区别。OMAI以支持高性能计算为特色，能够在云计算环境下充分发挥高性能基础设施能力，这是其在技术侧重方向上与同类软件的主要不同之处。
下面从作业调度、存储接人和资源管理3个角度阐述OMAI在深度学习业务服务化方面的工作实践及创新设计。
3.2 作业调度设计
3.2.1 公共抽象层
考虑到深度学习3种服务化模式各自的适用场景及功能优势，OMAI期望有机组合各方面优点，以统一的抽象支持大数据、高性能与容器化调度框架拓展平台软件的应用领域，这一思路符合当今互联网、云计算与超算业务相互融合与渗透的趋势，同时也是OMAI在云服务中体现高性能计算特色的途径之一。其方案是在业务逻辑组件与资源管理组件之间插入公共抽象层，对作业属性及作业操作分别提供统一接口。作业抽象对包括调度需求在内的作业元信息进行形式化描述，作业操作则涉及深度学习业务生命周期各环节的启停和管理操作，两者都要能映射到不同调度框架各自的作业管理语义中。
公共抽象层涉及的一个关键问题是分布式作业调度语义的表达，例如在多角色进程参与的分布式训练模式中，如何决定进程启动时机、如何界定作业结束状态等。调度语义表达方式的设计需要权衡灵活性与易用性。OMAI选择在作业抽象中定义若干通用的调度模式（如PS-Worker、Allreduce、ReliableService）以提升接口易用性;将特殊需求作为可扩展字段，以兼顾功能灵活性。每种模式的功能实现由资源管理组件完成，对用户和上层开发者高度透明。
3.2.2 集群驱动层
为将作业抽象翻译为每种运行时控制框架各自的作业管理语义，OMAI为每种框架研发了各自的集群驱动，构成资源管理组件中的集群驱动层。这一层提供对作业操作接口的具体实现。OMAI在容器化环境中基于Volcano设计集群驱动，Volcano提供的细粒度工具能够灵活组合，以服务于多种复杂的分布式运行模式。在此基础上，OMAI还设计或增强了全局障栅（barrier）、SGE（Sun Grid Engine）作业封装器、多角色MPI启动器等针对特殊运行模式的辅助组件，增强平台软件对深度学习引擎及运行模式的适应性，弥补现有调度框架对高性能应用调度特性支持的不足。
针对高性能环境，OMAI重点面向带有Singularity容器的Slurm集群设计。其集群驱动的主要职能是将作业抽象翻译为sbatch脚本，并对作业状态进行实时监控。OMAI提供sbatch模板渲染机制，以实现运行模式与具体作业的解耦。针对运行时环境依赖问题，OMAI充分利用高性能环境普遍具有的全局文件系统和模块加载机制：使用全局镜像存储与本地镜像缓存优化作业启动性能，使用模块动态加载解决应用对开发库版本的依赖问题。
3.3 存储接入设计
3.3.1 二级挂载机制
考虑用户的便利性和生态兼容性，OMAI对用户主推的存储系统是对象存储。针对不支持对象存储的深度学习引擎，OMAI提供一种二级挂载机制，即把对象存储以文件系统接口挂载到宿主节点，再通过本地目录映射机制挂载到容器中。这一方案可以借助Kubernetes的CSI（Coll.tainer Storage Interface）机制实现。OMAI团队已经研发了针对AWS S3兼容存储以及一种国产超算对象存储的二级挂载机制，从而可以有效支撑多类云计算和超算环境的存储接人需求。相比在算法程序中显式适配存储接口的传统方法，本机制具有对应用透明的优势，避免了各个应用反复对接存储的开销。
在不提供对象存储系统的高性能环境中，OMAI亦支持直接使用全局文件系统存储数据资产。这时的二级挂载机制体现在：①将全局文件系统中的用户目录挂载到宿主节点;②通过Singularity的路径绑定机制将用户目录中的作业映射到容器中。全局文件系统相比对象存储系统具有支持随机访问的优势，因此这一机制不但可用于存储数据资产，还可用于存储OMAI系统及用户作业的配置文件等其它信息。
3.3.2 VPC感知机制
并非所有深度学习业务需求都可以使用对象存储系统支撑，诸如Kaldi等面向高性能环境设计的深度学习引擎就依赖于全局文件系统，将它们引入云计算环境时有必要在深度学习云服务中支持NFS或其它兼容的存储系统。针对云环境下的VPC绑定问题，OMAI提供了VPC感知机制。在这一机制下，用户选择存储目录的操作将隐式指定存储所属的VPC，OMAI后台将在用户VPC与服务VPC间建立虚拟路由，从而使得服务VPC中的作业容器能够访问用户VPC中的数据資产。
VPC感知机制同样适用于HDFS，这有助于OMAI与Apache生态中的数据处理和分析服务协同工作，包括在模型训练之前使用数据处理服务对输人数据集进行预处理，或者把基于深度学习的数据推理作为数据分析流水线的组成部分。
3.4 资源管理设计 3.4.1 资源表达式匹配机制
在对接多种调度框架的公共抽象层中，应用所依赖的资源需求是作业抽象的重要组成部分。OMAI采用一种基于JSON语言支持扩展字段的资源需求表示方法，以及与之配套的资源表达式匹配机制。使用JSON表示资源需求，方便对不同的集群驱动进行解析;扩展字段机制则适应了调度框架以插件方式接人和复用高性能资源的设计。资源表达式匹配机制相比传统的标签匹配机制，增加了算术、字符串和集合运算能力，有助于对定量指标以及复杂条件实施匹配。以匹配GPU资源为例，本机制可以按GPU型号、显存容量、类别（训练或推理）等条件组合实施匹配。
相比Kubernetes生态中第三方提出的ExtendedResoHree、ResoureeClass等细粒度资源匹配机制，本机制实现的是节点级匹配而非设备级匹配，因而不适用单节点包含同类异构硬件的情况。该权衡是值得的，因为OMAI需要实现跨多类调度框架的通用性，并非每一类调度框架都支持涉及设备细节信息的细粒度调度，同时真实生产环境中也较少存在这种复杂的硬件组成情况。
3.4.2 增強型插件机制
针对云计算环境中最常用的Kubernetes调度框架，OMAI团队研发了具有增强特性的资源接人和调度插件。以GPU复用插件为例，相比阿里云开源、面向推理服务、以显存为资源选择依据的GPU共享插件，OMAI的GPU复用插件支持“毫GPU”等更多灵活易用的资源单位，也支持面向训练作业的单容器多GPU分配。在性能隔离方面，本插件参考了GaiaGPU设计。在安全隔离方面，出于对容器弱隔离性问题的整体规避，OMAI采取了用户身份感知的反亲和性调度策略。此外，通过集群驱动中的相关设计避免了同类插件经常存在的、源于与NVIDIA GPU插件互不感知的资源冲突问题。
增强型资源插件亦是OMAl支持其它高性能硬件、实现高性能计算特色的途径之一。这类插件使得高端硬件能力可以透明且安全地强化深度学习应用。
3.5 应用场景
OMAI现已服务于多种应用场景，其公有云服务已经上线并对公众开放使用，私有云服务也已支撑了某科研院所的遥感图像分析、某上市公司的数据处理平台等生产性业务。OMAI团队及客户在此基础上研发的应用涉及图像分类、图像增强、数据分析、数据预测、自然语言处理等领域。相比直接使用深度学习引擎或传统平台软件，OMAI为上述应用提供的核心价值在于云服务化，特色价值在于高性能，目标是使用户以低成本、高效率上线人工智能业务。
OMAI目前仍在继续开发演进，期望其设计思路能够对本领域的技术研究和产品研发带来启发，从而促进人工智能系统与应用的长足发展。
4 结语
深度学习技术是支撑人工智能应用的基础，以云服务方式提供深度学习能力是业界的主流趋势。深度学习业务实现具有微服务和批处理作业两种典型模式。业界通常采用大数据、高性能或容器化调度框架构建面向不同场景的深度学习云服务。对现有平台软件的分析表明，深度学习业务的云服务适配过程需要解决运行模式适配和运行时环境依赖等作业调度问题、存储类型匹配和存储跨域访问等存储接人问题，以及资源耦合与高性能资源复用等资源管理问题。业界现有的云服务针对不同问题提出了多种解决方案，在一定程度上满足了特定场景对深度学习业务云服务化的需求。OMAI深度学习平台是在系统分析上述问题的基础上，面向全流程、一站式、高性能目标设计研发的深度学习云服务软件。它具有作业调度中间层抽象、异构存储容器内挂载、资源表达式匹配等机制，解决了作业调度、存储接人和资源管理等层面的技术问题。OMAI的设计思路和研究实践可用于指导本领域研发工作。
转载注明来源:https://www.xzbu.com/8/view-15277945.htm
