而如果在裸金属等服务器上进行训练，则可以利用 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 在卡的使用上如果能够做到按需申请使用，也一定会进一步地提高集群的资源利用率，降本增效。
总结