总体目标
边缘容器平台为了增加产品的竞争力,也支持了GPU虚拟化能力, 因此需要调研业界的GPU虚拟化产品发展趋势, 了解它们优势和不足。
- 主要测试了理想GPU虚拟化的技术方案
- 对比业界的GPU虚拟化优劣
- GPU池化调研
为什么要实现GPU虚拟化
优势在于:
(1)集群中可以运行更多任务,通过分时复用,减少抢占。
(2)提高资源利用率(GPU/显存);GPU共享后,总利用率接近运行任务利用率之和,减少了资源浪费。
(3)提高服务质量(QoS),增强公平性,因为多个任务即可以同时开始享受资源;也可以单独保证某一个任务的
(4)减少任务排队时间,减小总任务的销号时间;假设两个任务结束时间分别是x,y,通过GPU共享,两个任务全部结束的时间小于x+y。
GPU资源池化技术的演进
- 简单虚拟化 ✅
- 任意虚拟化 ✅
- 远程调用 中间过程
- 资源池化 最终目标
什么是GPU远程调用
GPU远程调用是通过rCUDA实现的, rCUDA中间件架构图:
从上图可以了解到:
- rCUDA (remtoe CUDA)是Client-Server架构的服务。
- rCUDA 实现了RPC(CUDA接口) ,需要在服务器端和你的客户端机器部署其软件。
- rCUDA 是CUDA的远程调用版本,在本地无GPU的主机上远程访问有CUDA环境的GPU主机。
进一步可参考 http://rcuda.net/
rCUDA 通信方式有2种:
通信方式
|
|
|
---|---|---|
TCP |
常规方式 |
性能损失很大 |
RDMA(remote-DMA) |
高速网络 远程直接内存访问 |
目前支持RDMA的网络协议主要有三种
|
RDMA 优势: 直接进行数据传输,速度快,不需要CPU参与,RDMA网卡接替了CPU的工作,节省下来的资源可以进行其它运算和服务。
那么阶段4是GPU池化,池化又是什么呢?有什么技术难点呢?
什么是GPU池化
GPU池化(GPU-Pooling)的定义: 通过对物理GPU进行软件定义,融合了GPU虚拟化、多卡聚合、远程调用、动态释放等多种能力,解决GPU使用效率低和弹性扩展差的问题。 如下图所示,在不同的抽象层次,将需要加速的应用转发(Forwarding)到GPU资源池中。总的来说,越靠底层的转发性能损失越小,可操作的范围越大;但同时,编程量也越大,也越难。
GPU池化的难点:
- GPU架构种类繁多,API 繁多的问题,运行时除了 libcudart.so 这个动态库,还涉及cuDNN、cuBLAS、cuFFT 等一系列动态库和 API,涉及数千个不同的 API 接口。
更重要的是 CUDA 运行时是闭源的,内部实现逻辑无从探究 , 需要进行反向工程。具体来说目前的GPU架构: F架构, K架构, P架构,V架构, T架构,A架构。 -
架构调整,需要抽象出一个中间池化层: 统一API,屏蔽不同位置(本地,远端),不同类型的GPU
-
比GPU虚拟化进一步的,GPU池化对对context管理的需求将更加严格。因此如何利用Context(时分复用)和Stream(空分复用)实现用户进程的隔离,用户购买的隔离,计费隔离,GPU算力的量化隔离将是新的问题。
以下是参考了知乎上博主稻壳特溯 对GPU-POOL的构思
业界的GPU虚拟化方案对比
GPU虚拟化方案名称
|
描述
|
优势
|
不足
|
演进阶段
|
---|---|---|---|---|
nvidia MPS | 是nvidia为了进行GPU共享而推出的一套方案,由多个CUDA程序共享同一个GPU context,从而达到多个CUDA程序共享GPU的目的。同时可以设定每个CUDA程序占用的GPU算力的比例。 | 官方出品,稳定可靠,实现了资源隔离 | 多个CUDA程序共享了同一个GPU context,一个程序异常会导致全局。 | 阶段1 |
nvidia vGPU | 可以将一个设备映射到多个不同的虚拟机中去, | 同上 |
|
阶段2 |
nvidia MIG | 多实例,MIG 可将 A100 GPU 划分为多达七个实例,每个实例均与各自的高带宽显存、缓存和计算核心完全隔离。 | 同上 | 目前只针对A100 等有限的实现了MIG,对老卡则无法配置 | 阶段2 |
阿里cGPU | 通过劫持内核驱动,为容器提供了虚拟的GPU设备,从而实现了显存和算力的隔离; |
|
|
阶段2+ |
腾讯qGPU | 它是目前业界唯一真正实现了故障隔离、显存隔离、算力隔离、且不入侵生态的容器 GPU 共享的技术。(官方表述) |
|
没有继续维护 | 阶段2+ |
趋动科技 OrionX(猎户座) |
实现了GPU共享的能力,在资源隔离方面,使用了CUDA劫持的方案,通过MPS以及其他方式限制算力。 |
|
|
阶段4 |
百度双引擎GPU | 双引擎 GPU 容器虚拟化架构, 采用了用户态和内核态两套隔离引擎,以满足用户对隔离性、性能、效率等多方面不同侧重的需求。 |
|
|
阶段4 |
最值得关注的 趋动科技 和 百度的GPU虚拟化方案
OrionX(猎户座) 虚拟化方案
架构 |
Orion Controller + license授权模式 |
|
典型场景1 |
GPU池化优化的场景一:多个在线推理混合部署
OrionX池化能力关键词:化整为零,动态释放。
|
|
典型场景2 | GPU池化优化的场景二:在/离线推理混合部署,算力超分,昼夜复用 OrionX池化能力关键词:化整为零,动态释放,算力超分,任务优先级。 |
|
典型场景3 |
GPU池化优化的场景三:训练/推理混合部署,显存扩展,分时复用 OrionX池化能力关键词:化整为零,动态释放,算力超分,显存超分,任务优先级。 核心能力解读:
|
百度的GPU虚拟化方案
|
|
|
---|---|---|
架构图 |
|
|
基础能力 |
显存隔离、算力隔离。显存 1MB 级隔离;算力 1% 级分配; |
|
高级能力 | 编码器隔离(不懂)、高优抢占、显存超发、显存池化,远程调用,池化 |
实现了 4 种内核态算力调度算法:
|
双引擎 |
长尾延迟: 内核态由于采用了时分复用,对长尾延迟影响稍大。 用户态由于采用了空分复用,大大降低了对长尾延迟的影响。
|
在整体架构中我们采用了用户态和内核态两套隔离引擎,以满足用户对隔离性、性能、效率等多方面不同侧重的需求。
用户态方案的优点是性能好,长尾延迟低,适合追求机制性能、极致效率的业务场景,如延迟敏感的在线推理业务。 内核态方案的优点是, 尽管长尾延迟控制不如用户态,但在隔离性方面,内核态具备优势,更侧重于对隔离要求有强诉求的场景。
|
边缘容器产品ECK中的vGPU虚拟化能力汇总
行号 | GPU能力 | 是否支持 | 备注 |
---|---|---|---|
1 | 算力软隔离 | ✅ |
N个容器是按配置比例(1:4)共享gpu算力,而不是还是(1:1)完全共享gpu算力。 假定GPU算力是100, 目前容器1和容器2算力配置10 /40 ,进一步自适应为20/80 ,需进一步支持 |
2 | 显存硬隔离 | ✅ | 超过会(outof of memory)异常, 目前是10M为最小粒度, 后续以1M为最小粒度。 |
3 | 虚拟显存 | ✅ |
显存不够,内存来凑 超过会(outof of memory)异常 |
4 | GPU调度 | ✅ |
|
5 |
支持GPU实例类型 |
✅ |
|
7 | 多卡虚拟机 | ✅ | 使用2+个GPU部分算力 |
8 | CUDA依赖 | ✅ | 目前最高支持的版本是11.7 |
9 | 兼容性 | ✅ |
云原生:支持标准的 Kubernetes 和 Docker。 containerd呢? |
缺乏的能力 | |||
1 | 灵活的算例配置 |
对齐百度: 动态算力调整
|
|
2 | GPU拓扑感知调度 | 1台主机上的多个GPU之间采用NVLink进行互联互通,而不要采用PCIe进行通信 | |
3 | 算力超分 | 目前<=100% | |
4 | 编码器隔离 |
GPU 视频编解码能力, 流媒体 使用GPU硬件加速FFmpeg视频转码 |
|
5 | 远程调用 | rCUDA , remote-CUDA | |
6 | GPU池化 |
一套API 实现 GPU 资源的本地使用和远程挂载
|
|
7 |
针对不同场景,采用不同的调度策略
|
提供算力调整接口:
|
|
9 | GPU遥测 | 对齐 nvidia-DCGM 规范指标, |
什么是拓扑感知和nvlink
所谓的拓扑感知,就是在在k8s调度中,选择不同的GPU组合,会得到不同的训练速度,所以在GPU的调度过程中,选择最优的GPU组合,可得到最优的训练速度。
nvlink发展
|
Tesla V100 的混合立体网络拓扑
|
||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
对比下,常见的PCIe3.0x16数据传输带宽是32Gb/S, 而nvlink的总带宽是300GB/s , 起码相差80倍。
场景: 某服务需要2块GPU ,根据右边的拓扑图如何分配GPU , 才能发挥它的最佳性能呢?
|
进一步,可类比下 , 常见的GPU-manager中NUMA的拓扑感知: |
上图是使用 NVLink 连接 8 个 Tesla V100 的混合立体网络拓扑。图中也以看出每个 V100 GPU 有 6 个 NVLink 通道(绿色连接线),8 块 GPU 间无法做到全连接,2 个 GPU 间最多只能有 2 个 NVLink 通道 100GB/s 的双向带宽。有趣的是 GPU0 和 GPU3,GPU0 和 GPU4 之间有 2 条 NVLink 相连,GPU0 和 GPU1 之间有一条 NVLink 连接线,GPU 0 和 6 之间没有 NVLink 连接线,也就是说 GPU0 与 GPU6 之间的通信仍然需要通过 PCIe。
如何判断是否开启nvlink
没有
|
开启
|
如何实现
|
---|---|---|
没有开启nvlink ,则GPU0 和 GPU0 之间的状态是NS , 也就是不能使用 nvlink 实现高速互联,只能通过PCIE总线进行连接较低速率的互联。 |
开启了nvlink之后, GPU0 和 GPU1 互联是OK 的状态,可以通过nvlink高速通道进行互联。 |
使用nvlink桥接器 NVLink 高速 GPU 互连 | NVIDIA Quadro 必要条件:
|
边缘容器产品ECK的vGPU的落地情况
在边缘容器产品已经实现相关功能
测试: 分配了10%的GPU算力, 100*10M 的GPU显存 , 开启虚拟显存 vvmemory | ||
---|---|---|
|
|
最佳实践指导
编号 | ||
---|---|---|
1 |
cuda 有以下建议
3、cuda和显卡驱动基本都是向下兼容的,推荐 cuda11.x 版本最佳 |
|
下一步
1. 增强产品的健壮性
2. 针对大数据/AI 场景,支持 volcano
3. 针对的业务场景,提供灵活的算力配置接口
4. 支持GPU的国产化
5. 对标猎户,补齐不足
6. GPU远程调用的深入调研