GPU等加速卡共享方案的分类汇总与比较
〇、GPU等加速卡共享方案的分类汇总与比较
0.1 GPU共享方案分类汇总
| 方案类型 | 代表方案 | 优势 | 劣势 |
|---|---|---|---|
| 1)框架限制 | Antman等 | 1.针对特定场景，能提供较高的性能及用户灵活性。 2.实现相对简单 | 1.无法提供算力精准限制的的能力。2.框架更新频繁，可能需要不断适配，具体取决于实现方式。3.需要用户接入统一的的计算平台，多租户场景困难 |
| 2)CUDA劫持 | HAMi、rCUDA、vCUDA(gpu-manager)、GaiaGPU、Orion vGPU、趋动科技OrionX、Bitfusion（被VMware收购，现在已经不再对外销售） | 1.API开源，是非NVIDIA官方技术人员能够较容易实现的共享技术 | 1.CUDA库升级活跃，而当CUDA库有break changed升级时，劫持方案也需要不断适配，损耗损耗人力。 2.难以涵盖所有场景（一般场景可以），隔离不一定严格准确。 3.安全性低，用户可以绕过限制。 4.无法提供严格的算力限制能力 |
| 4)内核劫持 | cGPU、qGPU等 | 1.安全性高 2.共享损耗小 3.NVIDIA Driver的更新更少，适配需要很小 | 1.对OS有一定依赖 2.更新换代较困难 3.研发困难，对开发要求高 |
| 3)CUDA聚合 | Nvidia MPS | 性能最好。在多任务共享场景下，如果如果任务需要的的资源被满足，任务的完成时间基本没有没有影响 | 1.错误互相影响，如果一个任务退出(被使用者停止或任务本身出错)，如果该任务正在kernel，那么与该任务共享IPC和UVM的任务也会一同出错退出。故无法在生产与开发训练场景下大规模规模使用。 2.没有显存隔离，可以粗略限制计算资源。 3.无法定制开发 |
| 5)Mdev框架 | Nvidia GRID | 来自NVIDIA官方，可靠性与安全性高 | 1.不支持容器，虚拟机上使用上不够灵活。 2.无法动态调整资源比例(调整规格时需要重启物理服务器)。 3.有一定的共享损耗。 4.无法定制化开发 |
0.2 GPU共享方案比较
以下11个被调研过的GPU共享方案中，只有第2个方案HAMi是开源免费、项目当前活跃、支持多种加速卡、各个基本功能已经实现。其他方案，存在各类问题比如不开源、开源项目但最近几年已经不再更新、商业公司商业收费项目、支持的加速卡不够完善等。
基于上述原因，建议以HAMi这个开源项目为基础，进一步开发与封装公司GPU共享与虚拟化的解决方案。
| 序号 | 共享方案 | 来源 | 明显优势 | 严格缺陷 |
|---|---|---|---|---|
| 1 | Antman | 阿里云论文 | 开源；ACK下执行TF与PyTorch任务，能够提供高性能及用户灵活性 | 只在阿里云ACK集群中验证；生态不完善，项目5年年未更新 |
| 2 | HAMi | 第四范式、DaoCloud | 有现成的开源已实现的解决方案可用，基本功能已经实现；支持主流加速卡，如HAMi支持NVIDIA GPU、寒武纪MLU、海光DCU、天数智芯GPU；此项目当前比较活跃。 | 但CUDA库升级活跃，当CUDA库有break change式升级时，劫持方案需要同步修改适配； 是容器层面的虚拟化方案，不支持虚拟机层面的虚拟化； 目前无法支持物理加速卡的所有特性，如HAMi项目目前仅支持计算任务、不支持视频编解码处理，暂时仅支持MIG的"none"和"mixed"模式、不支持single模式等 |
| 3 | rCUDA | 西班牙巴伦西亚理工大学开发 | 可以做GPU资源池化 | 闭源的软件，提供的是二进制文件，可以申请下载试用，但不得用于商业用途，其最新版本是2020年7月份发行的rCUDA (v20.07)，支持的CUDA版本是9.0，最近几年没有更新、官网当前也不可访问。 |
| 4 | vCUDA(gpu-manager) | 腾讯开源 | 有现成的开源项目gpu-manager可用； | 开源项目gpu-manager已经3年没有再更新，目前也没维护，相关提问也无正式人员回复； 只支持NVIDIA系统GPU卡，且只支持Kepler框架及更新构架的GPU卡；只支持CUDA11.5.1及之前的版本 |
| 5 | GaiaGPU | 腾讯开源 | 有现成的开源项目可用（两次尝试搭建GaiaGPU使用环境，均失败） | 涉及的几个开源子项目最近3年内都未再更新； 无法在短时间内限制算力效率公平； 不确定是否支持GPU厂家之外厂家的加速卡 |
| 6 | Orion vGPU | 趋动科技开源 | 有现成的开源项目https://github.com/virtaitech/orion | github仓库代码已经将近5年未更新与维护；不确定是否支持NVIDIA厂家之外的加速卡；生态不完善，网上几乎找不到相关文章 |
| 7 | 趋动科技OrionX | 趋动科技研发 | 上市商业公司支持； GPU资源池化；做到将GPU应用与GPU/CPU资源分离部署，适配虚拟机与容器云平台两种主流场景 | 收费且售价昂贵 |
| 8 | cGPU | 阿里云研发 | 不仅适配标准的Docker和Containerd工作方式，而且还无锋兼容Kubemnetes工作方式，物理GPU的资源任意划分; 支持热升级、支持多卡划分功能 | 不开源、收费，且cGPU目前只能在阿里云ACK集群中使用。 |
| 9 | qGPU | 腾讯云研发 | 支持显存和算力的严格隔离；支持业界唯一在离线混部能力，GPU 利用率压榨到极致 | 腾讯付费产品，只能在腾讯容器云中使用。 |
| 10 | Nvidia MPS | Nvidia官方研发 | 可以做算力隔离与限制计算资源；性能是所有GPU共享方案早最好的。 | 不开源；只能在NVIDIA GPU上使用；存在错误传播缺陷 |
| 11 | Nvidia GRID | Nvidia官方研发 | NVIDIA官方研发，可靠性高。支持的NVIDIA GPU型号多而全；已有特性能够满足科研、生产、模型训练与推理绝大部分场景。 | 收费；只支持NVIDIA GPU |
1. 框架限制
1.1 Antman
论文：
- https://www.usenix.org/conference/osdi20/presentation/xiao
论文相关源码github地址：
- https://github.com/alibaba/GPU-scheduler-for-deep-learning
相关文章：
https://diandiangu.github.io/2020/12/02/AntMan-0/
https://zhuanlan.zhihu.com/p/451238714
概述
Antman是来自阿里PAI的框架层GPU共享方案，未虚拟。 Antman没有限制具体资源量，而是针对特定场景（论文中实验只是试验了TF与PyTorch资源密集型任务）的方案。它针对高低优先级任务训练场景，保障高优先级任务获得计算资源、兼顾低优先级获得计算资源，AntMan动态伸缩机制扩展GPU内存上限、提升了多个训练任务执行时的速度。属于时间复用。
AntMan的核心是一个云原生的Kubernetes调度器，它与KubeDL协作，负责协调TFJobs的执行。此外，项目采用了Kubernetes Scheduler Plugins，以优化对深度学习GPU pod的调度，同时依赖NVIDIA k8s-device-plugin来报告GPU资源给Kubernetes集群。
项目及技术应用场景：AntMan特别适用于大型企业和研究机构，这些机构可能拥有大规模GPU集群，且需要快速响应训练任务的需求变化。
优缺点
- 优点：
针对特定场景（经过论文实验验证过的是对于资源密集型的任务，AntMan能够保证优先级高的作业得到足够的资源。
对于突发的、短暂的工作负载，它可以有效利用空闲资源进行机会性调度，提高硬件利用率。
在模型迭代和超参数调优过程中，动态的资源分配可以大大缩短实验周期。
ACK下执行TF与PyTorch任务，能够提供高性能及用户灵活性。
- 缺点：
只在阿里云ACK集群中验证（基于kubernetes 1.18），虽然作者公布了论文中使用到的源码，但自2020年公布后的4年来，github项目并不活跃，社区参与度与活跃度极低
对用户影响大，需要用户统一的计算平台（阿里云ACK），多租户场景困难
AntMan实现与TF与PyTorch开源计算框架等mini batch任务耦合度较高，而这两个框架更新频繁，此时要求二次开发人员不断适配，增加了二次开发成本与难度
2. CUDA劫持
目前已实现CUDA劫持的解决方案有：HAMi、rCUDA、vCUDA、GaiaGPU、Orion vGPU等
2.1 HAMi
异构AI计算虚拟化中间件开源项目 HAMi 最初由 第四范式（4Paradigm） 与 DaoCloud 道客 联合开源。
官方网站：https://project-hami.io/zh/docs/
项目源码在github上的地址：https://github.com/Project-HAMi/HAMi
概述
CUDA劫持，是目前业界较普遍采用的第三方研发方案，属于时间复用。是通过劫持CUDA-Runtime(libcudart.so)和CUDA-Driver(libcuda.so)之间的api调用来运行的。代表性实现有腾讯开源的GPUManager 、第四范式与道客公司开源的k8s-vgpu-scheduler(现已变更为HAMi )。
腾讯开源的GPUManager还没有用过，从网上文章来看，实现了一些基本功能，但此项目最近3年没有再更新，不够活跃。
第四范式与道客公司开源的HAMi，已经安装并试用过。其在实现了GPU虚拟化基础上。还包含了如下特性：允许通过指定显存来申请算力设备、算力资源的硬隔离、允许通过指定算力使用比例来申请算力设备、对已有程序零改动、能够按GPU型号或uuid指定物理GPU白名单与黑名单、能够在k8s节点与物理GPU两个维度上指定调度策略、还能支持几个国产加速卡的虚拟化。该项目比较活跃，第四范式及一些兴趣爱好者最近几年一直在参与迭代更新，大概每两个月更新一个版本。
优缺点
以下是自己总结的一些优缺点，可能不够完善。更详细的内容可以参考其官网（我当前总结时官网还不够完善，没什么内容）。
- 优点：
有现成的开源已实现的解决方案可用
对用户程序无侵入，用户无感
以上两种实现方案支持碎片和整卡调度，提高GPU资源利用率
以上两种实现方案支持同一张卡上容器间GPU和显存的使用隔离
支持主流加速卡。如HAMi支持NVIDIA GPU、寒武纪MLU、海光DCU、天数智芯GPU，且此项目当前比较活跃。
- 缺点：
驱动和加速库的兼容性依赖于厂商。因为CUDA库是公开的，所以这种技术较容易实现，但CUDA库升级活跃，当CUDA库有break change式升级时，劫持方案需要同步修改适配。
是容器层面的虚拟化方案，不支持虚拟机层面的虚拟化。
网上有评价说“安全性不够，用户可以绕过限制”，但一旦将vGPU分配到容器中，在内网环境中自己使用，安全性问题一般不需过多关注。
难以涵盖所有场景，目前无法支持物理加速卡的所有特性，如HAMi项目目前仅支持计算任务、不支持视频编解码处理，暂时仅支持MIG的"none"和"mixed"模式、不支持single模式等等。
2.2 rCUDA
概述
是西班牙Universitat Politecnica de Valencia（西班牙巴伦西亚理工大学）并行架构组的一个开发项目，提供了一套远程GPU虚拟化解决方案，支持以透明的方式并发远程使用支持CUDA的设备。不仅可以部署在集群中，允许单个非MPI应用程序使用集群中的所有GPU，从而提高GPU利用率并降低总体成本，而且还可以在虚拟机中运行应用程序访问安装在远程物理机中的GPU。这是一个闭源的软件，提供的是二进制文件，可以申请下载试用，但不得用于商业用途，其最新版本是2020年7月份发行的rCUDA (v20.07)，支持的CUDA版本是9.0，最近几年没有更新、官网当前也不可访问。
rCUDA将创建一个高性能计算集群，集群中有些服务器上安装有GPU，当那些本地没有GPU资源的服务器上尝试执行需要GPU资源的应用程序时，通过将数据与代码在本地服务器内存与远程GPU显存中传输，执行内核的远程调用，所以rCUDA是一个client-server构架式系统。一方面，将针对高级CUDA运行api的包装器封装成库，在客户端进行使用；另一方面，在服务端启用网络监听服务以在特定的tcp端口监听与响应应用请求。位于集群中不同节点的多个GPU应用程序可以并发执行、充分利用安装在集群中的多个服务器上多个GPU。通过这种时分复用GPU的方式，它能够为每个远程GPU应用执行请求创建不同的服务器进程，分别执行并返回结果。
很明显，rCUDA和趋动科技的OrionX属于同一类。是跨进程、跨节点的思路，是真正做虚拟化，可以对GPU设备进行模拟，可以把一个物理GPU模拟成多个虚拟GPU，把多个跨物理节点的物理GPU进行聚合。在虚拟GPU的过程中可以对通讯、任务、多任务的行为进行优化。共享仅仅是其中一个容易想到的case。
优缺点
- 优点：
是跨进程、跨节点的思路，是真正做虚拟化，可以对GPU设备进行模拟，可以把一个物理GPU模拟成多个虚拟GPU，把多个跨物理节点的物理GPU进行聚合。
可以做GPU资源池化
- 缺点：
是一个闭源的软件。看网上的文章描述“提供的是二进制文件，可以申请下载试用，但不得用于商业用途。（因为其官网“www.rcuda.net”当前无法访问，故无法确认）”
2020年后，没有再更新。
西班牙巴伦西亚理工大学的官网https://www.upv.es/也没有找到这个项目的信息，网上的信息也很少，使用度不够，生态不够好
其支持的最新CUDA版本是9.0
其他信息
维基百科介绍：https://en.wikipedia.org/wiki/RCUDA，网页的最后有几篇关于或利用rCUDA的论文
维基百科上查询到此项目官网是“www.rcuda.net”，但此网站已经被篡改成在线赌博网站，现真正可用网站不知是什么
网上找到介绍到rCUDA的几篇文章
- https://blog.csdn.net/weixin_42082868/article/details/129932719、
- https://juniorprincewang.github.io/2017/11/01/rCUDA/
- https://www.ai-sprint-project.eu/node/223
2.3 vCUDA(gpu-manager)
https://github.com/tkestack/vcuda-controller
https://github.com/tkestack/gpu-manager
概述
GPUManager是腾讯自研的容器层GPU虚拟化方案，通过替换 CUDA 库实现 API 层面的转发，然后通过修改显存分配，任务提交等 API 函数来达到多个容器共享 GPU 的目的。除兼容Nvidia 官方插件的GPU资源管理功能外，还增加碎片资源调度、GPU调度拓扑优化、GPU资源Quota等功能，在容器层面实现了GPU资源的化整为零，而在原理上仅使用了wrap library和linux动态库链接技术，就实现了GPU 算力和显存的上限隔离。
在工程设计上，GPUManager方案包括三个部分，cuda封装库vcuda、k8s device plugin 插件gpu-manager-daemonset和k8s调度插件gpu-quota-admission。
vcuda库是一个对nvidia-ml和libcuda库的封装库，通过劫持容器内用户程序的cuda调用限制当前容器内进程对GPU和显存的使用
gpu-manager-daemonset是标准的k8s device plugin，实现了GPU拓扑感知、设备和驱动映射等功能。GPUManager支持共享和独占两种模式，当负载里tencent.com/vcuda-core request 值在0~100情况下，采用共享模式调度，优先将碎片资源集中到一张卡上，当负载里的tencent.com/vcuda-core request为100的倍数时，采用独占模式调度，gpu-manager-daemonset会根据GPU拓扑结构生成GPU卡的拓扑树，选择最优的结构（距离最短的叶子节点）进行调度分配。需要注意的是GPUManager仅支持0~100和100的整数倍的GPU需求调度，无法支持150，220类的非100整数倍的GPU需求调度。每张 GPU 卡一共有100个单位的资源，仅支持0 - 1的小数卡，以及1的倍数的整数卡设置。显存资源是以256MiB为最小的一个单位的分配显存。
gpu-quota-admission是一个k8s Scheduler extender，实现了Scheduler的predicates接口，kube-scheduler在调度tencent.com/vcuda-core资源请求的Pod时，predicates阶段会调用gpu-quota-admission的predicates接口对节点进行过滤和绑定，同时gpu-quota-admission提供了GPU资源池调度功能，解决不同类型的GPU在namespace下的配额问题。
GPUManager整体方案如下：
优缺点
- 优点：
- 项目开源
- 实现了GPU拓扑感知、设备和驱动映射等功能。
- 支持共享和独占两种模式
- 缺点：
开源项目gpu-manager已经3年没有再更新，目前也没维护，相关提问也无正式人员回复
只支持NVIDIA系统GPU卡，且只支持Kepler框架及更新构架的GPU卡
只支持CUDA11.5.1及之前的版本
需要对静态链接的程序重新编译，同时在 CUDA 库升级的时候也需要进行修改来适配新版本
2.4 GaiaGPU
概述
GaiaGPU起源于一篇北京大学与腾讯公司联合研究发表的论文“GaiaGPU: Sharing GPUs in Container Clouds”，它提供了一整套GPU共享解决方案，是完全开源的CUDA劫持类型GPU共享方案。
通过劫持CUDA的显存申请和释放请求，为每个容器管理它的显存使用量，进而实现了显存隔离。在算力隔离方面，使用者可以指定容器的GPU利用率。GaiaGPU中的vGPU Manager会监控利用率，并在超出限制利用率时做一些处理。此处可以支持硬隔离和软隔离。两者的不同点是，如果有资源空闲，软隔离允许任务超过设置，而硬隔离不允许。由于使用的是监控调节的方案，因此无法在短时间内限制算力，只能保证长时间范围内的效率公平，所以不适合推理等任务时间极短的场景。
GaiaGPU的构架图如下。
自己两次尝试搭建GaiaGPU使用环境，均失败。
优缺点
- 优点：
开源项目。看网上相关文章介绍，是由腾讯tkestack下几个几个开源项目vcuda-controller、gpu-admission、gpu-manager合并而成的。
支持算力与显存隔离。
能保证长时间范围内的算力调度公平性，但短时间内的不能。
- 缺点：
涉及的几个开源项目最近3年内都未再更新。
由于使用的是监控调节的方案，因此无法在短时间内限制算力，只能保证长时间的效率公平，所以不适合推理等任务时间极短的场景。
不确定是否支持GPU厂家之外厂家的加速卡。
2.5 Orion vGPU
Github仓库地址：https://github.com/virtaitech/orion
概述
Orion vGPU软件由VirtAI Tech 趋动科技开发，是一个为云或者数据中心内的AI应用、CUDA应用提供GPU资源池化、GPU虚拟化能力的系统软件。通过高效的通讯机制连接应用与GPU资源池，使得AI应用、CUDA应用可以不受GPU物理位置的限制，部署在云或者数据中心内任何一个物理机、Container或者VM内。
网上对此开源项目的使用与二次开发相关介绍很少，几乎没有。猜测商用动机都是考虑趋动科技的商用版本解决方案OrionX去了。
优缺点
优点：
开源项目
兼容已有的AI应用和CUDA应用，无需修改已有应用程序。
细粒度的GPU虚拟化支持。
应用可使用远程物理节点上GPU，应用部署无需受GPU服务器位置、资源数量的约束。
vGPU资源动态分配动态释放。无需重启Container/VM/物理机。
通过对GPU资源池的管理和优化，提高整个云和数据中心GPU的利用率和吞吐率。
通过统一管理GPU，降低GPU的管理复杂度和成本。
支持 TF 2.0, PyTorch 1.3, NVCaffe 深度学习框架。
从官网的介绍来看，可以支持Container/VM/物理机 多个场景。
缺点：
github仓库代码最后一次更新是在2019年底，已经将近5年未更新
github的提问，无官方人员回复
不确定是否支持NVIDIA厂家之外的加速卡
未试用过，对显存、计算资源的切分粒度与隔离度暂不确定
2.6 趋动科技OrionX
概述
是GPU over IP/IB技术的实践者和领导者，实现了AI算力资源池化。通过增加软件层，将GPU资源虚拟化并通过网络进行管理，视角是网络联通的整个GPU资源池，突破了以往单节点单卡或多卡视角的局限，实现了资源的动态分配和优化利用。用户可以根据实际需求，灵活地调整GPU资源比如增加或减少物理GPU卡、灵活解决模型训练与高性能任务执行中的GPU/CPU配比与多机多卡问题等，提供了GPU资源管理调度策略，做到了跨节点调用GPU资源，确保资源始终得到高效利用、将GPU应用与物理GPU解耦合。GPU全局资源池性能监控，降低了成本和运维复杂度。
优缺点
优点：
突破了以往GPU共享方案在单节点上共享GPU资源的局限，通过IP/IB网络存储技术真正将GPU资源池化，实现了按需扩容与几乎无损耗式使用GPU资源，做到将GPU应用与GPU/CPU资源分离部署，适配虚拟机与容器云平台两种主流场景，能够为用户提供企业级稳定便捷服务。具体优点如下。
资源池化：OrionX帮助客户构建数据中心级AI算力资源池，使用户应用无需修改就能透明地共享和使用数据中心内任何服务器之上的AI算力。
动态资源分配：OrionX支持将GPU切片为任意大小的vGPU，允许多AI负载并行运行，提高物理GPU利用率。
高性能：OrionX本地vGPU性能损耗几乎为零，远程vGPU性能损耗小于2%，确保了计算任务的高效执行。
弹性扩展：支持从单台到整个数据中心GPU服务器纳管，通过RDMA（IB/RoCE）或TCP/IP网络连接各个节点，实现资源池弹性扩展。
灵活调度：支持AI负载与GPU资源分离部署，CPU与GPU资源解耦合，有助于最大化数据中心基础设施价值。
全局管理：提供GPU资源管理调度策略，GPU全局资源池性能监控，为运维人员提供直观的资源利用率等信息。
对AI开发者友好：一键解决AI开发者面临的训练模型中GPU/CPU配比和多机多卡模型拆分问题，节省大量宝贵时间。
不仅支持虚拟机场景，还支持与容器云平台的集成，进一步简化了AI应用的部署和管理，降低了运维复杂度。
支持多款厂家的加速卡，包括NVIDIA、寒武纪、华为昇腾、海光
其他优特点可以参考其官网https://virtaitech.com/product/index查看或试用确认
缺点：
需要购买趋动科技的解决方案，且价格昂贵。
无法进行定制开发。
3. 内核劫持
3.1 cGPU
阿里云官网cGPU文档：https://www.alibabacloud.com/help/zh/egs/what-is-cgpu
概述
内核劫持，因为Nvidia Driver的更新更小，所以适配需求很小，但是研发比较困难（由于Nvidia的闭源性，在内核态做显存资源和算力资源的隔离，可以在一定程度上防止用户篡改，技术难度较高）。GPU共享方案目前来看还是各大厂商的核心技术能力，更是有趋动科技这样专门做GPU集群管理的公司。内核劫持的技术方案没有哪家厂商开源其代码，据相关大企业发布的产品来看，目前阿里云、百度云与腾讯云公有云上已经实现部署。
比如阿里云的cGPU就是内核劫持实现方案。cGPU实现了一个内核模块cgpu_km，可以将一个物理GPU虚拟成多个虚拟GPU设备。容器使用定制的容器运行时挂载虚拟GPU设备。当用户的程序请求下发到内核模块cgpu_km时，模块通过修改请求及回复来限制GPU显存资源。同时cgpu_km通过限制每个容器可下发到kernel的时间片来实现算力资源隔离与简单的算力调度。阿里云异构计算 cGPU 在做到算力调度与显存隔离的同时，也做到了无需替换 CUDA 静态库或动态库；无需重新编译 CUDA 应用；CUDA，cuDNN 等版本随时升级无需适配等特性。目前只能在阿里云上使用。
这个实现方案的核心在于cgpu_km这个内核模块，但并未开源。cGPU 架构图如下。
优缺点
优点：
兼容性好：不仅适配标准的Docker和Containerd工作方式，而且还无缝兼容Kubernetes工作方式。
操作简单：无需重新编译AI应用，运行时无需替换CUDA库。
资源灵活划分：物理GPU的资源任意划分。例如GPU显存动态划分，支持M级划分、GPU利用率动态划分，算力支持最小2%粒度的划分。
GPU实例规格无限制：适用于GPU裸金属实例，虚拟化实例，vGPU实例等各种GPU实例。
应用场景丰富：支持在离线混部业务、支持CUDA AI和渲染应用场景。
功能强大：具备高优先级的抢占功能和较高的可运维能力，支持热升级、支持多卡划分功能。
cGPU技术特性
支持容器调度GPU：将GPU资源做更细颗粒度的切分，提高资源利用率，提效降本
完整隔离：同时支持GPU的显存与算力隔离，避免不同进程之间的应用相互争抢资源、相互影响
更加简单：AI应用无需重新编译，无需构建新的容器镜像进行cuda库替换，对客户环境无侵入
缺点：
不开源且cGPU目前只能在阿里云ACK集群中使用。
若根据这些大企业提供的产品思路来研发时，对于小型企业不可行，技术实现难度大，成本太高。
3.2 qGPU
参考文章： https://www.tencentcloud.com/zh/document/product/457/42973
概述
腾讯云 Tencent Kubernetes Engine qGPU 服务（以下简称 TKE qGPU）是腾讯云针对 原生节点 推出的 GPU 容器虚拟化产品，支持多个容器共享 GPU 卡并支持容器间算力和显存精细隔离，同时提供业界唯一的在离线混部能力，在精细切分 GPU 资源的基础上，在最大程度保证业务稳定的前提下，提高 GPU 使用率，帮助客户大幅度节约 GPU 资源成本。qGPU 依托 TKE 对外开源的 Elastic GPU 框架，可实现对 GPU 算力与显存的细粒度调度，并支持多容器共享 GPU 与多容器跨 GPU 资源分配。同时依赖底层强大的 qGPU 隔离技术，可做到 GPU 显存和算力的强隔离，在通过共享使用 GPU 的同时，尽量保证业务性能与资源不受干扰。
qGPU 即QoS GPU，它是目前业界唯一真正实现了故障隔离、显存隔离、算力隔离、且不入侵生态的容器 GPU 共享的技术。qGPU 并不是开源的。
qGPU的方案框架图如下。
优缺点
优点：
大厂开发与运营的核心产品，付费产品有保障保障，支持GPU虚拟化使用者关注的基本功能，并提供了一些亮点功能。具体如下。
灵活性：精细配置 GPU 算力占比和显存大小。
强隔离：支持显存和算力的严格隔离。
在离线：支持业界唯一在离线混部能力，GPU 利用率压榨到极致。
覆盖度：支持主流架构 Volta（如 V100 等）、Turing（如 T4 等）、Ampere（如 A100、A10 等）。
云原生：支持标准 Kubernetes 和 NVIDIA Docker。
兼容性：业务不重编、CUDA 库不替换、业务无感。
缺点：
腾讯付费产品，并不开源
这类大厂产品，一般无法进行定制开发。
不确定是否支持除NVIDIA外的加速卡。
4. CUDA聚合
4.1 Nvidia MPS
概述
MPS是Nvidia官方最早提供的一种GPU任务共享方案，属于空间复用。它通过将多个进程的CUDA 上下文合并到一个CUDA上下文中，所有任务共同使用显存，省去上下文切换的开销的同时也在合并后的上下文中实现了算力隔离。但多个进程的CUDA上下文合并成一个后会带来故障传播这一致命缺陷，导致其无法在生产环境中被使用。
优缺点
优点：
性能是所有GPU共享方案早最好的。当多个任务使用的资源可被同时满足时，每个任务的任务完成时间基本没有影响。
可以做算力隔离与限制计算资源。
缺点：
不开源，所以无法在NVIDIA现有成果上进行定制与二次开发。
只能在NVIDIA GPU上使用，无法在Intel GPU与国产GPU卡上使用
不能做显存隔离
存在错误传播缺陷：一个任务退出时，如果此任务正在执行kernel，那么与该任务共离IPC与UVM的任务也会一同出错退出。因此无法在生产环境中使用。
5. Mdev框架
5.1 Nvidia GRID
概述
来自NVIDIA官方，属于时间复用的GPU共享产品，使用此产品需要再单独购买license。是虚拟机场景而非容器场景下的解决方案，它通过vfio-mdev为每个虚拟机提供一个vf与mdev，为它们提供了一个隔离性非常高的的硬件环境，能够做显存资源隔离（将一个物理GPU虚拟成多个vGPU，每个vGPU分配一个同样大小的显存。能够虚拟的最大vGPU个数跟license类型有关），算力按照一定策略进行隔离与分配（每个vGPU分到的算力资源跟配置的调度策略与vGPU上执行的任务有关。调度策略配置在安装有物理GPU的物理服务器上，变更调度策略需要重启物理服务器才能生效）。其共享模块在Nvidia driver及之下。
这个解决方案是被市场广泛接受的、由NVIDIA官方推出的GPU共享方案。
优缺点
优点：
由NVIDIA官方研发，可靠性高。支持的NVIDIA GPU型号多而全，且还在不断迭代更新。
已有特性能够满足科研、生产、模型训练与推理绝大部分场景。
安全性高。
缺点：
因为是NVIDIA的产品，只支持NVIDIA GPU。
在购买物理NVIDIA GPU之外，还需要另外购买使用NVIDIA vGPU的license且费用不便宜。
不支持直接虚拟到容器中，每个虚拟机中只能有一个vGPU。
无法动态调整vGPU规格。调整就意味着需要重新购买license。
有一定比例的性能损耗。
只能使用NVIDIA vGPU解决方案现有功能，无法继续进行定制化开发。
6. 参考文章
Nvidia GPU池化-远程GPU： https://blog.csdn.net/weixin_42082868/article/details/129932719
gpu-manager安装及测试介绍性文章：
- https://blog.csdn.net/weixin_46519031/article/details/132212258
- https://cloud.tencent.com/developer/article/1685122
HAMi项目地址：https://github.com/Project-HAMi/HAMi/tree/master
GPUManager 项目地址：https://github.com/tkestack/gpu-manager/tree/master
rCUDA维基百科介绍：https://en.wikipedia.org/wiki/RCUDA，网页的最后有几篇关于或利用rCUDA的论文
网上找到介绍到rCUDA的几篇文章：
https://blog.csdn.net/weixin_42082868/article/details/129932719、
https://juniorprincewang.github.io/2017/11/01/rCUDA/
https://www.ai-sprint-project.eu/node/223
腾讯vCUDA（gpu-manager）部署：
- https://blog.csdn.net/o0haidee0o/article/details/119407372（基本操作完成，但describe节点时未看到tencent.com/... 相关资源）
- https://www.cnblogs.com/deny/p/16305744.html#top（还没尝试使用）
- https://www.jf3q.com/article/detail/8437
k8s集群GPU调研报告： https://www.flftuu.com/2020/11/14/k8s集群GPU调研报告/
GaiaGPU: Sharing GPUs in Container Clouds： https://ieeexplore.ieee.org/abstract/document/8672318
GaiaGPU: 在容器云中共享GPU： https://wangjunjian.com/kubernetes/2022/01/28/gaiagpu-sharing-gpus-in-container-clouds.html
趋动科技官网：https://virtaitech.com/product/index
阿里云cGPU容器技术详解：https://aliyunfuwuqi.com/gpu/3481/
阿里云官网cgpu介绍文档：https://www.alibabacloud.com/help/zh/egs/what-is-cgpu
找到一个名为cgpu的github项目仓库https://github.com/lvmxh/cgpu （但在“DellR740 XD物理服务器“ + “Ubuntu20.04 LTS-amd64操作系统“上无法安装使用）
qGPU 概述： https://www.tencentcloud.com/zh/document/product/457/42973
盘点来自工业界的GPU共享方案：
- https://zhuanlan.zhihu.com/p/398369404
- https://my.oschina.net/u/4273516/blog/10120396
- https://blog.wangqi.love/articles/docker/gpu%E5%85%B1%E4%BA%AB%E8%B0%83%E7%A0%94%E6%95%B4%E7%90%86.html
GPU虚拟化，算力隔离，和qGPU： https://zhuanlan.zhihu.com/p/377073683