关于腾讯云:公有云上构建云原生-AI-平台的探索与实践-GOTC-技术论坛分享回顾

5次阅读

共计 4880 个字符，预计需要花费 13 分钟才能阅读完成。

7 月 9 日，GOTC 2021 寰球开源技术峰会上海站与 WAIC 世界人工智能大会独特举办，峰会聚焦 AI 与云原生两大以开源驱动的前沿技术畛域，邀请国家级钻研机构与顶级互联网公司的一线技术专家，为参会的开发者和技术爱好者带来了最硬的行业技术干货，提供了一个难得的技术交流平台。

在本次会议上，腾讯云高级工程师高策进行了题为“私有云上构建云原生 AI 平台的摸索与实际”的技术分享，介绍了 AI 类业务在私有云上的现状以及相应的技术选型和面临的问题。最初通过剖析开源社区和业界的趋势，与听众分享了咱们对于将来全弹性的 AI 基础设施的瞻望。

本文由此次分享演讲内容整顿而成，分享给大家一起回顾精彩内容。

关注【腾讯云原生】公众号，后盾回复关键词【云原生 AI】可获取演讲 PPT 原稿。

深度学习倒退至今，新的模型构造层出不穷。自 2018 年 GPT-1、Bert 相继问世，模型构造的参数量呈指数级增长。目前 Transformer 等构造不仅在自然语言解决畛域发光发热，在计算机视觉等畛域，也呈野火燎原之势。由此可见，将来对于算力和显存的需要会越发强烈。而以 Nvidia 为代表的硬件厂商提供的硬件性能却并不能与之同步进步。上图展现了两者之间的鸿沟，红色线条是模型参数规模的变化趋势，目前正在以每年 120 倍的速度晋升。而绿色线条代表的显存容量每年进步的速度只有 2 倍。

因而，无论是在计算机视觉、自然语言解决等畛域，还是互联网行业落地宽泛的搜寻广告举荐畛域，分布式训练都成为了支流训练形式。

与之绝对应的，深度学习框架也呈百花齐放的态势。传统的框架如 TensorFlow、PyTorch、Keras 依然非常风行。而一些新的框架也逐步呈现，比方微软的 DeepSpeed、百度的 Paddle 等。

总结来说，目前 AI 在工业界的各个领域都有了宽泛的落地。传统的搜寻广告举荐畛域自不必说，在视觉与自然语言解决畛域，基于深度学习的办法曾经成为了 state-of-art。在游戏、机器人等畛域，强化学习也在缓缓走向生产。为了满足业务对简单模型的需要，新的硬件和框架层出不穷。当然，还有一个非常明显的趋势，不少 AI 类业务正在上私有云，心愿借助私有云的弹性计算能力升高算力老本，提高效率。

接下来，咱们介绍一下在服务私有云上的客户时对于云原生 AI 的一些察看。

基于私有云的云原生 AI 目前正在逐步落地，其中既包含稠密类的搜寻 / 广告 / 举荐业务，也包含浓密类的计算机视觉等业务。互联网畛域的举荐场景落地绝对较多。也正是因为搜寻 / 广告 / 举荐业务场景简单，端到端提早要求低，因而革新的老本绝对较高，所以大多数业务，尤其是离线训练过程，依然不能很好地利用云的弹性能力。

与此同时从深度学习框架的角度看，目前绝大多数的业务依然在应用 TensorFlow。这与之前的察看有肯定的相关性。搜寻 / 广告 / 举荐业务中 TensorFlow 依然占据了相对的市场。然而目前 PyTorch 的应用也越来越多，尤其是在计算机视觉、自然语言解决等畛域。

联合咱们的这些察看和实际，腾讯云原生团队围绕着 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 业务中还不能很好地利用弹性能力，而这是云计算带给咱们最大的红利。只有依靠真正的弹性架构，利用能力生于云上，长在云上，服务于企业降本增效的终极目标。