kubernetes GPU共享技术调研
对于一个以内容分发为主的互联网公司来说，文章广告等的准确分发至关重要，而机器学习模型训练的效率和模型更新迭代的速度直接决定了内容分发效果的好坏。对于机器学习来说，算力是一切的根本，为了用海量数据训练更好的模型、加速整个内容分发流程，企业的 IT 系统需要具备快速、高效调用管理大规模 GPU 资源的能力。同时，由于算力资源十分昂贵，出于成本控制，企业也需要最大化 GPU 资源利用率。但是，对于一点资讯来说，GPU的利用率较低，资源使用比较紧张。一方面是处于非训练状态的实验占用GPU资源，没有及时释放；另外一方面是无法实现GPU共享，即使是再小的一个实验也要占用至少整块的GPU资源。对于第一个问题，可以通过监测训练任务状态，及时释放资源，但是对于第二个问题，目前还未做到GPU资源在多个Container之间共享。
GPU共享两个关键问题
1. 资源隔离
资源隔离主要采用的是虚拟化的解决思路，目前NVIDIA有两种 GPU 虚拟化的解决方案：
- GRID: 模式更多用于虚拟机场景，基于驱动，隔离型会做的比较强，但不开源，性能比较好。
- MPS: 应用到容器场景，基于软件的方式，隔离性比较弱，但也不开源。
2. 资源切分及调度
目前社区的GPU调度方案：
1.Nvidia 贡献的调度方案，只支持按较粗粒度的调度，按GPU块数调度。
Nvidia GPU Device Plugin
2.阿里云服务团队贡献的 GPU 共享的调度方案，其目的在于解决用户共享 GPU 调度的需求Kubernetes GPU共享实践
gpushare-scheduler-extender
gpushare-device-plugin
GPU共享技术实践
由于资源隔离主要采用的是虚拟化技术，并且NVIDIA提供的两种GPU虚拟化解决方案都没有开源，GPU共享在资源隔离方面的实践资料相对较少，大多关注GPU资源的调度。
1.阿里GPU共享实践
相关资料： Kubernetes的共享GPU集群调度
优点：
- 能够让更多的预测服务共享同一个GPU卡上，能够让使用者通过API描述对于一个可共享资源的申请， 并能实现该种资源的调度
缺点：
不支持该共享资源的隔离
前提条件：
延用Kubernetes Extended Resource定义，但是衡量维度最小单位从1个GPU卡变为GPU显存的MiB用户申请的GPU资源上限不会超过一张卡，也就是申请的资源上限为单卡
实现思路：
依赖于Kubernetes的现有工作机制:
- Extended Resource定义
- Scheduler Extender机制
- Device Plugin机制
- 利用 kubernetes Extended Resource机制，重新定义GPU资源，主要是对显存和GPU数量的定义。
- 利用Device Plugin机制，在节点上将GPU资源总量上报给kubelet,kubelet进一步上报给Kubernetes API Server。
- 利用k8s scheduler Extender机制，扩展调度器功能，负责在全局调度器Filter和Bind的时候判断节点上单个GPU卡是否能够提供足够的GPU显存，并且在Bind的时刻将GPU的分配结果通过annotation记录到Pod Spec以供后续Filter检查分配结果。
- 节点运行：当Pod和节点绑定的事件被Kubelet接收到后，Kubelet就会在节点上创建真正的Pod实体，在这个过程中, Kubelet会调用GPU Share Device Plugin的Allocate方法, Allocate方法的参数是Pod申请的gpu-mem。而在Allocate方法中，会根据GPU Share Scheduler Extender的调度决策运行对应的Pod。
2.腾讯GPU共享实践
相关资料：AI 在 K8S 中的实践：云智天枢 AI 中台架构揭秘
实现思路：
- 常规GPU使用，按块调度
- 使用Nvidia 提供的虚拟化技术
- 自研实现GPU半虚拟化： 基于驱动函数实现，改变了函数显存申请、释放和线程的发起函数。
3.才云科技GPU共享实践
相关资料：基于 Kubernetes 的 GPU 类型调度实现
实现思路：
利用kubernetes现有的工作机制：
- Scheduler Extender 机制
- Device Plugin 机制
- API Server 扩展机制（CRD）
- Admission 扩展机制（ResourceQuota）
优点：
虽未明确解决GPU共享问题，但根据其设计和实现，可以支持GPU共享，方案与方案1类似。相比方案1，还支持GPU类型调度以及对资源的使用进行限制。
缺点：
不支持该共享资源的隔离
1. 通过CRD（CustomResourceDefinition）定义两种资源：ExtendedResource 和 ResourceClass
ExtendedResource 描述了一种扩展资源，比如 NVIDIA GPU；
ResourceClass 定义了容器选择哪种扩展资源，它的使用方式和 Kubernetes 中的 Extended Resource类似，用户可以直接在容器中指定，就像使用 CPU 和 Memory 一样。
2. 利用 Scheduler 的扩展机制扩展Scheduler，负责调度容器中使用了ResourceClass资源对象的Pod
通过查询 ResourceClass 对象的定义过滤选择节点上的 ExtendedResource 资源，从而找到合适的节点并绑定，并将合适的 ExtendedResource 写到 Pod Annotation 中，供 Kubelet 组件使用。
3. 利用Nvidia Device Plugin插件，扩展NVIDIA GPU资源，负责与kubelet组件通信以及创建和维护 ExtendedResource 资源对象
ExtendedResource 资源中包含着 GPU 的频率、显存等信息，当多个容器想使用同一块 GPU 时，我们可以定义一个 ResourceClass 资源对象，在 ResourceClass 中声明使用多少显存（这里共享的是显存）。这样，应用部署时，我们只要在容器中声明使用该 ResourceClass 资源即可，之后 Scheduler Extender 会过滤符合条件的 ExtendedResource 对象，绑定到合适的节点上。
如果要实现资源共享，我们可能需要在 ExtendedResource 中记录显存的用量情况，供调度参考。
4.VMware GPU共享实践
相关资料：在 Kubernetes 中使用 vGPU 实现机器学习任务共享 GPU
实现思路：
利用GPU厂家、虚拟化厂商等提供的GPU虚拟化技术，对GPU进行虚拟化，把完整的GPU进行分割。然后按照调度物理GPU一样在k8s中调度GPU。
优点：
- 不用对k8s等进行而外扩展，开发工作量小
- 具备更好的隔离型
缺点：
- 需要使用如vSphere等虚拟化厂商提供的专门的虚拟化软件对GPU做虚拟化，并且需要付费
- 虚拟化对机器性能有损耗
5.其他相关资料
k8s官网对GPU调度的说明提供了Nvidia GPU容器调度能力，但是只能将一个GPU卡分配给一个容器
从零开始入门 K8s：GPU 管理和 Device Plugin 工作机制
如何在Kubernetes实现GPU调度及共享
Kubernetes GPU使用指南
Kubernetes如何通过Device Plugins来使用NVIDIA GPU
你真的了解多个docker容器如何共享GPU么？
Kubeflow 使用 Kubernetes 进行机器学习
总结
从社区、stackoverflow以及上述各公司的实践来看，目前GPU共享主要共享的是GPU的显存，资源隔离性差，存在资源抢占等情况，是否需要开展GPU共享相关的开发工作需要视公司机器学习对GPU的使用场景来决定；
GPU共享存在一定的限制：
用户申请的资源限制为单卡-
从显存共享的角度来说，单GPU卡共享具有可行性，主要实现步骤包括：
- 扩展资源定义，重新定义GPU资源，主要是对显存和GPU数量的定义
- 扩展调度器，负责在全局调度器Filter和Bind的时候判断节点上单个GPU卡是否能够提供足够的GPU显存
- 利用Nvidia Device Plugin插件机制，完成资源上报和分配
