一次关于GPU虚拟化的技术预研

最近领导派发了一个任务,需要研究一下GPU集群的相关技术。主要是为了解决两个方面的问题,一是目前的GPU资源使用过剩,一张显卡有24G显存,但是跑一个算法模型只用了6G,并且一个模型只能并发使用一张显卡,其他的的进程会被阻塞,效率利用低下;二是后期可以把算力集中起来,做大模型的训练。

折腾了挺久,把这一次的经历总结一下。

由于是第一次接触这一块技术,我搜寻了GPU集群的相关概念,马上找到了K8s的相关支持,支持使用设备插件把GPU资源暴露到集群,使得其他节点可以使用这些资源,详见kubernetes.io/zh-cn/docs/...; 一开始我以为这件事并没有那么复杂,问题迎刃而解。但是既然是技术预研,最好能够给出实践结果,并给出各项指标分析。在实践了之后,发现k8s的pod配置GPU的数量单位是个,也就是GPU独占,就算能够解决集群的方式,也不能解决并发使用的问题。

于是发现要提高GPU的使用率,离不开GPU虚拟化的概念。关于GPU虚拟化,网上的资料很少,还是了解大概的情况。 目前GPU虚拟化技术可以分为4个演变过程:

一:GPU的简单虚拟化,按照物理GPU的固定拆分,分成多个vGPU

二:任意虚拟化,将物理GPU从算力和显存等维度拆分,按照%切分成多个GPU

三:远程调用,AI应用服务器与物理GPU分离部署,使得应用可以调用远程的GPU服务器

四:GPU池化 , 将GPU资源统一管理,实现动态伸缩,灵活调度

按照目前的情况,实现前面三个步骤,差不多能够满足目前需求;至于池化后期业务扩展可以考虑改造。

后面分析市场上的相关方案,有nVidia的vGPU方案,有VMware的bitfusion方案,还有一些互联网公司的方案。 在分析了价格情况之后我优先选择了bitfusion方案。

方案包含多个组件, ①ESXI操作系统,可以更方便地去管理多个虚拟机,一定要在安装GPU的物理服务器上安装,不然还是识别不到显卡; ②vCenter,集群模式下多个vCenter可以管理多个ESXI,每个ESXI又可以管理多台虚拟机 ③bitfusion相关组件,包含服务端和客户端,以下是bitfusion方案的架构图,具体文档地址docs.vmware.com/cn/VMware-v...

在折腾了几天之后终于把环境装好了,虚拟机数量还是挺多的,不过好在是跑成功了。

.........(此处跳过各种调试场景)

列一下踩过的坑:①首先在bitfusion服务器需要开启显卡直通,不然虚拟机识别不到显卡 ②目前bitfusion支持的最新CUDA版本是11.5,如果CUDA环境太新,会提示驱动版本太旧,所以需要把CUDA以及各个版本依赖降一下

结果

两张显卡可以实现同时跑4个任务

但是!!

从结果来看速度慢了好几倍,猜想可能是CUDA版本和各个依赖的版本降低,导致GPU加速效果减少;bitfusion采用服务端和客户端的方式,可能会有带宽方面的瓶颈以及增加了其他方面的损耗。

不是说这个方案不好,只是说目前不太满足当前我们的场景,所以不得已放弃。如果大家用也可以选择尝试。

关于GPU虚拟化,资料确实少,普通消费级显卡虚拟化的意义不大,个人用户玩不起;而且需要硬件,软件同时支持。一般企业做这一块也会有专门的解决方案。后续可能会尝试其他方案的研究。

相关推荐
袋鼠云数栈UED团队10 小时前
基于 Lexical 实现变量输入编辑器
前端·javascript·架构
兆子龙12 小时前
像 React Hook 一样「自动触发」:用 Git Hook 拦住忘删的测试代码与其它翻车现场
前端·架构
兆子龙12 小时前
用 Auto.js 实现挂机脚本:从找图点击到循环自动化
前端·架构
兆子龙14 小时前
从 float 到 Flex/Grid:CSS 左右布局简史与「刁钻」布局怎么搞
前端·架构
爱勇宝18 小时前
2026一人公司生存指南:用AI大模型,90天跑出你的第一条现金流
前端·后端·架构
偷油师傅19 小时前
拆解 OpenClaw - 05:13 个省 Token 的设计
架构
兆子龙19 小时前
当「多应用共享组件」成了刚需:我们从需求到模块联邦的落地小史
前端·架构
sunny_1 天前
⚡️ vite-plugin-oxc:从 Babel 到 Oxc,我为 Vite 写了一个高性能编译插件
前端·webpack·架构
兆子龙2 天前
模块联邦(Module Federation)详解:从概念到手把手 Demo
前端·架构
Bigger2 天前
告别版本焦虑:如何为 Hugo 项目定制专属构建环境
前端·架构·go