7 月 9 日，GOTC 2021 全球开源技术峰会上海站与 WAIC 世界人工智能大会共同举办，峰会聚焦 AI 与云原生两大以开源驱动的前沿技术领域，邀请国家级研究机构与顶级互联网公司的一线技术专家，为参会的开发者和技术爱好者带来了最硬的行业技术干货，提供了一个可贵的技术交流平台。算法
在本次会议上，腾讯云高级工程师高策进行了题为“公有云上构建云原生 AI 平台的探索与实践”的技术分享，介绍了 AI 类业务在公有云上的现状以及相应的技术选型和面临的问题。最后经过分析开源社区和业界的趋势，与听众分享了咱们对于将来全弹性的 AI 基础设施的展望。编程
本文由这次分享演讲内容整理而成，分享给你们一块儿回顾精彩内容。缓存
关注【腾讯云原生】公众号，后台回复关键词【云原生AI】可获取演讲PPT原稿。服务器
背景与现状
深度学习发展至今，新的模型结构层出不穷。自 2018 年 GPT-一、Bert 相继问世，模型结构的参数量呈指数级增加。目前 Transformer 等结构不只在天然语言处理领域发光发热，在计算机视觉等领域，也呈野火燎原之势。因而可知，将来对于算力和显存的需求会愈加强烈。而以 Nvidia 为表明的硬件厂商提供的硬件性能却并不能与之同步提升。上图展现了二者之间的鸿沟，红色线条是模型参数规模的变化趋势，目前正在以每一年 120 倍的速度提高。而绿色线条表明的显存容量每一年提升的速度只有 2 倍。网络
所以，不管是在计算机视觉、天然语言处理等领域，仍是互联网行业落地普遍的搜索广告推荐领域，分布式训练都成为了主流训练方式。架构
与之相对应的，深度学习框架也呈百花齐放的态势。传统的框架如 TensorFlow、PyTorch、Keras 仍然十分流行。而一些新的框架也逐渐出现，好比微软的 DeepSpeed、百度的 Paddle 等。框架
总结来讲，目前 AI 在工业界的各个领域都有了普遍的落地。传统的搜索广告推荐领域自没必要说，在视觉与天然语言处理领域，基于深度学习的方法已经成为了 state-of-art。在游戏、机器人等领域，强化学习也在慢慢走向生产。为了知足业务对复杂模型的需求，新的硬件和框架层出不穷。固然，还有一个很是明显的趋势，很多 AI 类业务正在上公有云，但愿借助公有云的弹性计算能力下降算力成本，提升效率。机器学习
在公有云上的 AI 落地
接下来，咱们介绍一下在服务公有云上的客户时关于云原生 AI 的一些观察。分布式
基于公有云的云原生 AI 目前正在逐渐落地，其中既包括稀疏类的搜索/广告/推荐业务，也包括稠密类的计算机视觉等业务。互联网领域的推荐场景落地相对较多。也正是因为搜索/广告/推荐业务场景复杂，端到端延迟要求低，所以改造的成本相对较高，因此大多数业务，尤为是离线训练过程，仍然不能很好地利用云的弹性能力。性能
与此同时从深度学习框架的角度看，目前绝大多数的业务仍然在使用 TensorFlow。这与以前的观察有必定的相关性。搜索/广告/推荐业务中 TensorFlow 仍然占据了绝对的市场。可是目前 PyTorch 的使用也愈来愈多，尤为是在计算机视觉、天然语言处理等领域。
腾讯云原生AI服务
结合咱们的这些观察和实践，腾讯云原生团队围绕着 Kubeflow 构建了腾讯云容器服务的云原生 AI 产品化方案。目前已经开始免费内测，欢迎联系咱们试用，您的任何建议都会成为咱们的宝贵动力。 腾讯云云原生AI服务为用户提供了 AI环境的快速交付以及管理能力、弹性的 Jupyter 服务、以及分布式模型服务等能力，目前关于模型管理等产品特性也在逐步建设中。 此外，为了解决带宽性能的瓶颈问题，咱们不只在存储端联合腾讯 COS 团队，借助 GooseFS 缓存引擎优化，并且在计算端联合腾讯云优图实验室，借助其在训练与推理上多年来的经验沉淀，准备推出高度优化的深度学习框架。咱们会充分利用云原生AI做为统一窗口的优点，与腾讯云多个团队合做共建平台，提供开箱即用的产品化能力，反哺客户与社区。 更多关于云原生AI的最佳实践会在咱们后续的《云原生AI标准指南》以及《云原生AI前沿观察》系列中推出。
落地实践
在介绍完公有云的 AI 云原生落地状况后，咱们分享一下在公有云上运行 AI 类业务的典型选型。首先是训练相关的技术栈。首先，在最底层的云服务器侧，通常而言是由云厂商提供的虚拟机或者裸金属机器。目前大部分业务都采用 Kubernetes 容器服务，因此通常计算侧会将服务器组成 Kubernetes 集群进行资源管理和调度。在其上，通常会依赖对象存储、文件存储或者块存储进行训练样本和模型的存储。通常而言在读写压力不太大的场景下，大多使用对象存储。相比于其余方式，对象存储支持分层压缩归档，性价比高。在读写压力比较大的场景，文件存储和块存储有更多的落地。
为了可以尽量提升数据的吞吐，有时会利用一些计算侧的缓存进行加速。其中的选型包括 Alluxio 和腾讯云对象存储缓存加速产品 GooseFS 等。经过把远端的数据缓存在计算侧集群中，避免了远端拉取数据的开销，在某些场景下可以显著地提升训练速度。
构建在服务器和存储之上的是分布式训练的基础设施。目前 Kubeflow 被应用地最为普遍。经过 Kubeflow，用户能够轻松地建立出 TensorFlow、PyTorch、Horovod 等框架的分布式训练任务。而且 Kubeflow 能够很好地与 Kubernetes 的各类特性协同工做，可以支持 Volcano 等调度器。
尽管 Kubeflow 已经可以支持用户进行模型的训练和评估，可是直接使用 Kubeflow 仍然具备一些问题。不一样的数据依赖可能在不一样的数据系统中，所以数据处理的逻辑可能很是复杂。为了简化算法工程师的使用流程，提升用户体验，通常在上层会构建一个流水线系统，用来将机器学习流程中的各个环节进行组合链接。同时会提供方便的可编程环境，帮助算法工程师更快地实现业务。在这一环节中，通常来讲可选的系统包括 Jupyter、Argo Workflow、Airflow、Kubeflow 等。从用户的角度看，算法工程师只须要关心最上层的实验环境和流水线系统。而其下的各层 Infra 则由基础设施团队和公有云提供。这样的分层可以下降不一样角色的工程师的心智负担，提升效率。
接下来，咱们就以分布式训练为例，介绍选型中可能遇到的问题，以及解决办法。在分布式训练中，按照参数更新的方式不一样，能够分为 Parameter Server（如下简称为 PS）Worker 的模式和 AllReduce 的模式。在 PS 模式下，一共有两个角色参与训练，分别是 PS 和 Worker。其中 Worker 负责主要的计算，计算好的梯度会发送给对应的 PS，PS 更新对应的参数，随后发回给 Worker。在 AllReduce 模式中，每一个 Worker 中有全量的模型，不一样 Worker 接受不一样的数据，相互之间传递梯度，进行梯度的更新与同步。
不管上述的哪一种训练方式，都存在一些问题。首先是在模型参数较多的状况下，梯度或参数通讯时的网络带宽需求很高，网络会成为训练过程当中的瓶颈。这一问题在稠密类模型的训练中尤其明显。其次，在一个运行深度学习任务的集群上，每每运行着多个深度学习任务。不一样的任务都须要访问存储，这时存储带宽也可能成为瓶颈。总结起来，在网络和存储上，都有可能遇到带宽不足的问题。
在公有云上，一般云服务器不提供 RDMA 网卡，内网带宽一般在 20-50Gbps 左右。在这样的环境下，为了可以下降梯度同步带来的带宽压力，通常会须要进行梯度压缩等优化。梯度压缩能够下降单次同步的梯度大小，与此同时，也能够替换 AllReduce 的实现，选择对低带宽环境更为友好的实现，如 2DReduce 等。这些工做在腾讯云的 Ti-Horovod 中都有对应实现。它在低带宽的状况下会有比原生的 Horovod 更好的表现。
而若是在裸金属等服务器上进行训练，则能够利用 RDMA 网卡进行梯度的加速。在这样的训练环境中，存在一张 VPC 网卡，用于与对象存储等云产品交互；一张 RoCE 网卡以及一个显卡。所以须要进行必定的改造，来支持经过 VPC 网卡进行训练样本的拉取，而梯度同步更新则经过 RDMA 网卡进行。
而这样的方式，会有比较高的几率遇到以前所说的存储带宽的问题。梯度的同步经过高带宽的 RDMA 进行了加速，相对应地存储上就更有可能成为瓶颈。为了解决这一问题，在公有云上能够利用计算侧的缓存产品，如腾讯云的 GooseFS，或者开源的 Allxuio 等方案，将数据缓存在集群内，避免在训练时在线拉取对象存储中的数据，避免存储带来的瓶颈问题。
在推理场景下，架构相对更为简单。最底层依然是云服务器组成的 Kubernetes 集群，模型通常而言会存储在对象存储中，模型服务则会经过 TFServing、Triton Inference Server 或者自研服务框架的方式对外提供服务。
因为部分业务的端到端流程相对复杂，有繁复的前处理和后处理环节。若是使用 TFServing 或者 Triton Inference Server来实现，逻辑会尤其复杂。与此同时，模型服务会与内部的基础设施有耦合，须要对接内部的网关等服务。所以自研服务框架的需求也相对旺盛。尽管 TFServing 和 Triton Inference Server 在开源领域广受关注，可是目前仍有至关规模的业务使用自研服务框架。
将来展望
AI 业务在上公有云的过程当中，有各类各样的问题。在通讯、存储侧的带宽瓶颈自没必要说。除此以外，深度学习每每依赖 Nvidia 的诸多底层库，以及 Python 的各种依赖。在集成环境中，Jupyter 占用的 GPU 显存以及计算的利用率太低等。
基础架构的演进也必定会朝着解决这些问题的方向前进。咱们认为，将来的 AI 基础设施必定是全弹性的。在训练场景下，本来的训练方式须要将参与训练的各个角色的配置固定下来。好比由 5 个 Worker 参与的分布式训练任务，在训练过程当中须要保证有且仅有 5 个 Worker 参与。这使得资源的配置只能静态地指定，在集群资源状况发生变化时没法动态地调整参与训练的 Worker 数量。
目前，能看到有愈来愈多的深度学习框架正在支持弹性训练。以 Horovod 为例，它引入了 Driver 的概念，管理 Worker 的生命周期。当有任何一个 Worker 出现问题时，Driver 会捕获到异常而且根据配置从新创建环，让训练继续下去。在这一过程当中，训练不会中断。这使得训练任务能够在集群负载低，有空闲 GPU 的时候扩容，在集群负载高的时候缩容。这样的架构可以结合公有云的弹性实例等能力，在提升容错性的同时，下降训练的成本。
与之类似的，还有弹性的 Jupyter 能力。在 Jupyter 本来的实现中，每一个 Kernel 都是与 Notebook 运行在一块儿的，这也就意味着它须要长期占有一张完整的 GPU 卡，这一样使得 GPU 的利用率得不到提高。Jupyter 在卡的使用上若是可以作到按需申请使用，也必定会进一步地提升集群的资源利用率，降本增效。
总结
最后，咱们总结本次分享的主要观点。目前公有云的内网带宽仍然是制约 AI 业务上云的一个主要问题。咱们针对不一样的场景有不一样的方法能够缓解它，也有包括裸金属在内的 RDMA 方案可供选择。相信在将来随着公有云网络带宽的逐步提高，这将再也不成为问题。
其次，工业界目前仍然缺少 AI 基础设施的事实标准。目前有很是多的开源 AI 基础设施项目，其中 Kubeflow 是落地最多的，凭借着与 Kubernetes 的深度集成，与公司内部现有的基础设施可以更好地协同工做，有必定的优点。不过总体而言，目前这一领域仍然缺少事实标准。各个系统之间的差别很是大。这也是目前这一领域最大的问题之一，各个公司的 AI 基础设施都各有特点，难以像集群调度领域 Kubernetes 同样，在社区造成协力，共同推进行业进步。
最后，全弹性的架构是咱们认为的下一步演进方向。目前在 AI 业务中还不能很好地利用弹性能力，而这是云计算带给咱们最大的红利。只有依托真正的弹性架构，应用才能生于云上，长在云上，服务于企业降本增效的终极目标。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！