助力深度学习！阿里开源可插拔 GPU 共享调度工具

根据 Gartner 对全球 CIO 的调查结果显示，人工智能将成为 2019 年组织革命的颠覆性力量。对于人工智能来说，算力即正义，成本即能力，利用 Docker 和 Kubernetes 代表云原生技术为 AI 提供了一种新的工作模式，将 GPU 机器放到统一的资源池进行调度和管理，这避免了GPU 资源利用率低下和人工管理的成本。因此，全球主要的容器集群服务厂商 Kubernetes 都提供了 Nvidia GPU 容器集群调度能力，但是通常都是将一个 GPU 卡分配给一个容器。这虽然可以实现比较好的隔离性，确保使用 GPU 的应用不会被其他应用影响；对于深度学习模型训练的场景也非常适合，但是，针对模型开发和模型预测的场景还是会显得比较浪费。基于此，大家有了共享 GPU 的集群调度需求。

Kubernetes 共享 GPU 集群调度

共享 GPU 的集群调度就是能够让更多的模型开发和预测服务共享同一个 GPU 卡，进而提高集群中 Nvidia GPU 的利用率。而这就需要提供 GPU 资源的划分，而这里 GPU 资源划分的维度指的就是 GPU 显存和 Cuda Kernel 线程的划分。通常在集群级别谈支持共享 GPU 是以下两件事情：
1.调度
2.隔离，我们这里主要讨论的是调度，隔离的方案目前需要用户通过应用限制(比如使用 Tensorflow 的per_process_gpu_memory_fraction 来控制)，未来会提供基于 Nvidia 的 MPS 的可选项, 也会考虑 GPU 的方案。

而对于细粒度的 GPU 卡调度，目前 Kubernetes 社区并没有很好的方案，这是由于 Kubernetes 对于 GPU 这类扩展资源的定义仅仅支持整数粒度的加加减减，无法支持复杂资源的分配。比如用户希望使用 Pod A 占用半张 GPU卡，这在目前 Kubernetes 的架构设计中无法实现资源分配的记录和调用。这里挑战是多卡 GPU 共享是实际矢量资源问题，而 Extened Resource 是标量资源的描述。

针对此问题，我们设计了一个 Out Of Tree 的共享 GPU 调度方案，该方案依赖于 Kubernetes 的现有的工作机制:

• Extended Resource 定义
• Scheduler Extender 机制
• Device Plugin 机制
• Kubectl 的扩展机制

这个 GPU 共享调度扩展的好处是：利用 Kubernetes 的扩展和插件机制实现，对于 API Server，Scheduler，Controller Manager 以及 Kubelet 等核心组件没有侵入性。这就方便了使用者可以在不同 Kubernetes 版本上应用这个方案，无需 rebase 代码和重新构建 Kubernetes 二进制包。

用户场景

• 集群管理员：“我想提高集群的 GPU 使用率;在开发过程中，多个用户共享模型开发环境。”
• 应用开发人员：“我希望能够同时在 Volta GPU 上运行多个推理任务。”
  

[](https://www.atatech.org/articles/132268#2)目标

• 能够让使用者通过 API 描述对于一个可共享资源的申请， 并能实现该种资源的调度
  

[](https://www.atatech.org/articles/132268#3)非目标

• 不支持该共享资源的隔离
• 不支持超卖
  

[](