在介绍完公有云的 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 更好的表现。