从GPU虚拟化到池化

字数 5593阅读 2589评论 7赞 2

内容摘要：

GPU虚拟化和共享需求迫在眉睫，PCIe直通、SR-IOV、MPT等方案可实现GPU设备虚拟化，vGPU、MIG、MPS、rCUDA等方案可实现GPU虚拟化和共享，MIG支持裸机和容器，GPU算力池化可解决GPU使用效率低和弹性扩展差的问题，算力隔离、故障隔离是关键，API转发的多任务GPU时间分片的实现模式相对容易实现和应用最广。

当前摘要为AI生成

智能化应用如人脸识别、语音识别、文本识别、智能推荐、智能客服、智能风控等已广泛应用于各行各业，这些应用被称为判定式A I 的范畴，通常和特定的业务场景相绑定，因此在使用GPU（ Graphics Processing Unit ）卡的时候也通常各自独立，未考虑业务间GPU共享能力，至多实现vGPU 虚拟化切分，从而一张物理GPU 卡虚拟出多张vGPU ，可以运行多个判定式AI 应用。随着大模型的兴起，对 GPU 算力的需求越来越多，而当前现实情况使企业往往受限于有限的GPU卡资源，难以支撑众多的业务需求，同时由于业务特性等，即便进行了虚拟化，往往难以充分使用GPU 卡资源或持续使用资源，从而也造成有限的卡资源也无法有效利用。

## **从GPU虚拟化需求到池化需求**

智能化应用数量的增长对GPU 算力资源的需求越来越多。Nvidia虽然提供了GPU 虚拟化和多GPU实例切分方案等，依然无法满足自由定义虚拟G PU 和整个企业GPU资源的共享复用需求。TensorFlow 、Pytorch 等智能化应用框架开发的应用往往会独占一张GPU 整卡（ AntMan 框架 是为共享的形式设计的 ），从而使GPU 卡短缺，另一方面，大部分应用却只使用卡的一小部分资源，例如身份证识别、票据识别、语音识别、投研分析等推理场景，这些场景GPU卡的利用率都比较低，没有业务请求时利用率甚至是0 % ，有算力却受限于卡的有限数量。单个推理场景占用一张卡造成很大浪费，和卡数量不足形成矛盾，因此，算力切分是目前很多场景的基本需求。再者，往往受限于组织架构等因素，GPU由各团队自行采购和使用，算力资源形成孤岛，分布不均衡，有的团队GPU 资源空闲，有团队无卡可用，为解决GPU 算力资源不均衡等问题，同时支持GPU算力的国产化替代，协调在线和离线资源需求、业务高峰和低峰资源需求、训练和推理、以及开发、测试、生产环境对资源需求不同，实现算力的统一管理和调度复用，实现GPU资源的切分、聚合、超分、远程调用、应用热迁移等能力，提升GPU 资源的利用率，GPU算力池化需求迫在眉睫。
## **GPU设备虚拟化路线**
 GPU 设备虚拟化有几种可行方案，首先是PCIe直通模式（PCIe Pass-through技术， pGPU），也就是将物理主机上的整块GPU卡直通挂载到虚拟机上使用。但这种方式是独占模式，GPU卡没有虚拟化切分，并不能解决多个应用运行在一张卡上的问题，因此意义不是很大。第二是采用 SR-IOV技术，允许一个PCIe设备在多个虚拟机之间共享，同时保持较高性能。 通过SR-IOV在物理 GPU 设备上创建多个虚拟 vGPU 来实现的，每个虚拟 vGPU 可以被分配给一个虚拟机，让虚拟机直接访问和控制这些虚拟功能，从而实现高效的I/O虚拟化。 NVidia 早期的vGPU 就是这样的实现，不过NVidia vGPU 需要额外的license ，额外增加了成本。 SR-IOV 虽然实现了1：N 的能力，但其灵活性比较差，难以更细粒度的分割和调度。第三是 MPT（Mediated Pass-Through，受控的直通）模式。MPT本质上是一种通用的 PCIe 设备虚拟化方案。兼顾了1:N灵活性、高性能、功能完整性，但逻辑上相当于实现在内核态的device-model，厂商通常不会公开硬件编程接口，因此采用MPT 可能会形成厂商依赖。用的最多的模式是API 转发模式。根据AI 应用的调用层次（如下图），API 转发有多个层次，包括CUDA API转发（ ① ）、GPU Driver API 转发（ ② ）和设备硬件层A PI 转发（ ③ ）。设备硬件层API通常是难以获得的，因此目前市面上通常采用CUDA API 转发模式（截获CUDA 请求转发，也被称为用户态）和GPU卡驱动 Driver  API转发模式（截取驱动层请求转发，也被称为内核态）。另外AI开发框架往往和GPU卡绑定（比如华为支持CANN框架，海光支持D TK 框架，英伟达则支持TensorFlow 、Pytorch 等框架），AI应用在使用AI框架时，也可以在AI框架层进行转发，在AI应用迁移时比较有用。
![](/home/attachment/202405/16/1216527_171584790656852.png)
 AI应用调用层次
## **GPU虚拟化和共享方案**
 了解了GPU设备虚拟化的方式，基于设备虚拟化技术，看下GPU虚拟化和共享的实现方式。GPU虚拟化和共享有多种方案，英伟达从官方也提供了 vGPU 、MIG 、MPS等方案，以及非官方的vCUDA 、rCUDA 、内核劫持等多种方案。
|   |   |   |   |
| ------------ | ------------ | ------------ | ------------ |
| GPU共享方案 | 描述 | 优势 | 不足 |
| NVidia vGPU | 在VM应用尚虚拟GPU，可以将一个设备映射到多个不同的虚拟机中去，创建多个vGPU。 | 官方支持，稳定可靠，实现了资源隔离 | 每个vGPU的显存和算力都是固定的，无法灵活配置。需要单独的license授权。不支持容器 |
| NVidia MPS(Multi-process Scheduling) | 是nvidia为了进行GPU共享而推出的一套方案，由多个CUDA程序共享同一个GPU context，从而达到多个CUDA程序共享GPU的目的。同时可以设定每个CUDA程序占用的GPU算力的比例。 | 算力隔离好，Volta MPS兼容docker容器，支持资源配置（每个Client Context只能获取一定比例的threads），提高了多容器共享GPU的QoS | 多个CUDA程序共享了同一个GPU context，一个程序越界访问内存会导致VM中的CUDA应用都会被杀死，故障隔离差，仅支持linux，GPU算力>3.5 |
| NVidia MIG（Multi-Instance GPU） | 多实例，MIG 可将 A100 GPU 划分为多达七个实例，每个实例完全独立，均具有各自的高带宽显存、缓存和计算核心（GPU核心、内存和Nvlink带宽等资源）完全隔离。 | 物理隔离，安全性高，多租户支持；动态资源调整；故障隔离；支持虚拟化、容器 | 目前只针对A100、H100、A30 等有限的GPU卡实现了MIG，对老卡则无法配置 |
| rCUDA | Remote CUDA，Client-Server架构，远程共享方案，可与vCUDA结合实现远程vGPU调用 | 本地不需要GPU，实现远程调用 | 延时长，性能较差 |
| vCUDA | Virtual CUDA，在CUDA层拦截转发 | GPU API转发技术，API开源，较容易实现的GPU池化共享方案。 | 是CUDA库升级快，需不断适配，成本高；难以涵盖所有场景，隔离不准确；安全性低，用户可以绕过限制；对用户有影响，需要不断适配；无法提供算力精准限制的能力 |
### **Nvidia VGPU方案**
 Nvidia vGPU 是Nvidia 提供的一种虚拟化方案，可靠性和安全性高，但不支持容器，只能虚拟化若干个vGPU ，使用不灵活；无法动态调整资源比例；有一定的共享损耗；不支持定制开发，需支付额外license 费用。
### **MIG方案**
 MIG是多实例GPU方案。只支持L inux 操作系统，需要CUDA11 / R450 或更高版本；支持M IG 的卡有A100, H100 等比较高端的卡；支持裸机和容器，支持 vGPU 模式，一旦GPU卡设置了MIG 后，就可以动态管理 instance 了，MIG 设置时persistent 的，即使reboot也不会受影响，直到用户显式地切换。借助MIG，用户可以在单个GPU 卡上获得最多7倍的G PU 资源，为研发人员提供了更多的资源和更高的灵活性。优化了GPU的利用率，并支持在单个GPU上同时运行推理、训练和高性能计算（HPC）任务。每个MIG实例对于应用程序都像独立GPU一样运行，使其编程模型没有变化，对开发者友好。
### **MPS(Multi-Process Scheduling)**
 MPS多进程调度是CUDA 应用程序编程接口的替代二进制兼容实现。从 Kepler 的GP10 架构开始，NVidia 引入了MPS ，允许多个流（Stream）或者CPU 的进程同时向GPU 发射K ernel 函数，结合为一个单一应用程序的上下文在GPU上运行，从而实现更好的GPU利用率。当使用MPS 时，M PS Server会通过一个 CUDA Context 管理GPU硬件资源，多个MPS Clients会将他们的任务通过MPS Server 传入GPU ，从而越过了硬件时间分片调度的限制，使得他们的CUDA Kernels 实现真正意义上的并行。但MPS由于共享CUDA Context 也带来一个致命缺陷，其故障隔离差，如果一个在执行k ernel 的任务退出，和该任务共享share IPC 和UVM的任务一会一同出错退出。
### **rCUDA**
 rCUDA 指remote CUDA ，是远程GPU调用方案，支持以透明的方式并发远程使用CUDA 设备。rCUDA 提供了非GPU 节点访问使用GPU 的方式，从而可以在非GPU 节点运行AI应用程序。rCUDA 是一种C/S 架构，Client使用CUDA 运行库远程调用Server 上的GPU接口，Server监控请求并使用GPU执行请求，返回执行结果。在实际场景中，无需为本地节点配置GPU资源，可以通过远程调用GPU资源从而无需关注GPU所在位置，是非常重要的能力，隔离了应用和GPU资源层。
### **vCUDA**
 vCUDA采用在用户层拦截和重定向CUDA API的方式，在VM中建立pGPU的逻辑映像，即vGPU，来实现GPU资源的细粒度划分、重组和再利用，支持多机并发、挂起恢复等VM的高级特性。 vCUDA 库是一个对n vidia-ml 和l ibcuda 库的封装库，通过劫持容器内用户程序的CUDA调用限制当前容器内进程对GPU 算力和显存的使用。vCUDA 优点是API开源，容易实现；缺点是CUDA 库升级快，CUDA 库升级则需要不断适配，成本高；另外隔离不准确无法提供算力精准限制的能力、安全性低用户可以绕过限制等。目前市面上厂商基本上都是采用 vCUDA API转发的方式实现GPU算力池化。
## **GPU算力池化云原生实现**
 GPU池化（GPU-Pooling） 是通过对物理GPU进行软件定义，融合了GPU虚拟化、多卡聚合、远程调用、动态释放等多种能力，解决GPU使用效率低和弹性扩展差的问题。 GPU资源池化最理想的方案是屏蔽底层GPU 异构资源细节(支持英伟达和国产各厂商GPU) ，分离上层AI 框架应用和底层GPU 类型的耦合性。不过目前AI框架和GPU 类型是紧耦合的，尚没有实现的方案抽象出一层能屏蔽异构GPU。基于不同框架开发的应用在迁移到其他类型GPU时，不得不重新构建应用，至少得迁移应用到另外的GPU，往往需要重新的适配和调试。
 
 算力隔离、故障隔离是 GPU 虚拟化和池化的关键。算力隔离有硬件隔离也就是空分的方式，MPS共享 CUDA Context 方式和Time Sharing时分的方式。越靠底层，隔离效果越好，如MIG 硬件算力隔离方案，是一种硬件资源隔离、故障隔离方式，效果最好。但硬件设备编程接口和驱动接口往往是不公开的，所以对厂商依赖大，实施的难度非常大，灵活性差，如支持Ampere架构的A100等，最多只能切分为7个MIG实例等。Nvidia MPS是除MIG外，算力隔离最好的。它将多个CUDA Context合并到一个CUDA Context中，省去Context Switch的开销并在Context内部实现了算力隔离，但也致额外的故障传播。MIG和MPS优缺点都非常明显，实际工程中用的并不普遍。采用API 转发的多任务GPU 时间分片的实现模式相对容易实现和应用最广。
 
 根据AI应用使用GPU 的调用层次，可以实现不同层次的资源池化能力。比如CUDA层、Diver层、硬件设备层等。 在不同的抽象层次，将需要加速的应用转发(Forwarding)到GPU资源池中。总的来说，越靠底层的转发性能损失越小，可操作的范围越大；但同时，编程量也越大,也越难。
![](/home/attachment/202405/16/1216527_171584823823561.png)
 由于云原生应用的大量部署，GPU 算力资源池化需要支持云原生部署能力，比如说支持Kubernetes 、Docker 服务，通过K8s Pod绑定由GPU 资源池按需虚拟出来的 vGPU ，执行Pod 中的应用。不管是英伟达的GPU 卡或者是国产GPU，所有的卡都在算力资源池中，当前可以将不同的卡进行分类，不同框架的应用按需调度到合适的分类GPU算力池上。从而提升资源管理效率。算力资源池同样需要实现相应的资源、资产管理和运行监控和可观测性，优化调度能力，减少GPU 资源碎片。随着AI应用需求的迅速增长，算力资源池化在未来一段时间内将是企业关注的重要的一个方面。

GPU池化 GPU虚拟化 AI GPU 虚拟化

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论7 条评论

jason2006xu技术经理昆仑银行
22小时前

本文讲述从GPU虚拟化到池化云原生实现，通俗易懂，GPU的算力资源池化是云计算的未来趋势，新知识领域，学习了。

chenmingfu

基础架构组长西部某城商银行
1天前

随着AI及大模型等应用的普遍推广，GPU算力资源对信息科技发展起到不可替代作用，如何实现GPU资源池化是非常值得研究的，可大力降低投入成本。

匿名用户
1天前

GPU的算力资源池化是云计算的未来趋势，新知识领域，还需向作者多学习！

byson存储研发工程师平安科技(深圳)有限公司
2天前

这篇文章深入探讨了GPU虚拟化和池化技术，对解决当前企业面临的GPU资源利用效率低下和扩展性问题提供了全面的视角。文章不仅详细介绍了多种GPU虚拟化技术，如PCIe直通、SR-IOV和MPT等，还讨论了Nvidia的vGPU、MPS和MIG等方案，以及非官方的rCUDA和vCUDA方案。特别值得注意的是，文中对GPU算力池化的探讨，强调了算力隔离和故障隔离的重要性，并展望了云原生环境下GPU资源管理的未来，为IT专业人员和技术决策者提供了宝贵的信息和洞见。

ccww552010

软件开发工程师某科技企业
2天前

GPU虚拟化和池化技术的进步正推动着计算资源管理的革新。通过PCIe直通、SR-IOV和MPT等技术，我们能够将物理GPU资源灵活地分配给多个虚拟机，实现资源的高效利用。Nvidia的vGPU、MIG和MPS方案进一步增强了GPU的共享和隔离能力，尤其MIG技术通过硬件层面的实例划分，为多租户环境提供了强大的支持。然而，这些技术在灵活性、故障隔离和跨平台支持方面仍有待提升。随着云原生技术的兴起，GPU资源池化将更加重要，它将帮助企业更好地应对AI应用的快速增长和资源的动态需求。

lql2000系统工程师某银行
3天前

GPU资源的池化，在当前效益为王的数据中心确实是刚需，期待有更多成熟的产品落地，把有限的GPU价值最大化。

其它城市商业银行
3天前

从GPU虚拟化需求到池化，确实很好的提升了GPU实际效率，降低成本。

Ctrl+Enter 发表

匿名评论

从GPU虚拟化到池化

添加新评论7 条评论

文章目录展开目录

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料