searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

GPU虚拟化调研与落地

2023-02-20 07:36:50
978
0

总体目标

边缘容器平台为了增加产品的竞争力,也支持了GPU虚拟化能力, 因此需要调研业界的GPU虚拟化产品发展趋势, 了解它们优势和不足。

  1. 主要测试了理想GPU虚拟化的技术方案
  2. 对比业界的GPU虚拟化优劣
  3. GPU池化调研

为什么要实现GPU虚拟化

优势在于:

(1)集群中可以运行更多任务,通过分时复用,减少抢占。

(2)提高资源利用率(GPU/显存);GPU共享后,总利用率接近运行任务利用率之和,减少了资源浪费。

(3)提高服务质量(QoS),增强公平性,因为多个任务即可以同时开始享受资源;也可以单独保证某一个任务的

(4)减少任务排队时间,减小总任务的销号时间;假设两个任务结束时间分别是x,y,通过GPU共享,两个任务全部结束的时间小于x+y。

 

GPU资源池化技术的演进

  1. 简单虚拟化 ✅

  2. 任意虚拟化 ✅

  3. 远程调用 中间过程

  4. 资源池化 最终目标

 

什么是GPU远程调用

 

GPU远程调用是通过rCUDA实现的, rCUDA中间件架构图:

从上图可以了解到: 

  1. rCUDA  (remtoe CUDA)是Client-Server架构的服务。
  2. rCUDA 实现了RPC(CUDA接口) ,需要在服务器端和你的客户端机器部署其软件。
  3. rCUDA 是CUDA的远程调用版本,在本地无GPU的主机上远程访问有CUDA环境的GPU主机。

进一步可参考  http://rcuda.net/

rCUDA 通信方式有2种:

通信方式
 
 
TCP

常规方式

性能损失很大
RDMA(remote-DMA)

高速网络

远程直接内存访问

目前支持RDMA的网络协议主要有三种

  1. InfiniBand(IB)
  2. iWARP(RDMA over TCP/IP)
  3. RoCE(RDMA over Converged Ethernet) , RoCEv1和RoCEv2

RDMA 优势:  直接进行数据传输,速度快,不需要CPU参与,RDMA网卡接替了CPU的工作,节省下来的资源可以进行其它运算和服务。

那么阶段4是GPU池化,池化又是什么呢?有什么技术难点呢?

 

什么是GPU池化

GPU池化(GPU-Pooling)的定义:  通过对物理GPU进行软件定义,融合了GPU虚拟化、多卡聚合、远程调用、动态释放等多种能力,解决GPU使用效率低和弹性扩展差的问题。 如下图所示,在不同的抽象层次,将需要加速的应用转发(Forwarding)到GPU资源池中。总的来说,越靠底层的转发性能损失越小,可操作的范围越大;但同时,编程量也越大,也越难。

 

GPU池化的难点:

  1. GPU架构种类繁多,API 繁多的问题,运行时除了 libcudart.so 这个动态库,还涉及cuDNN、cuBLAS、cuFFT 等一系列动态库和 API,涉及数千个不同的 API 接口。
    更重要的是 CUDA 运行时是闭源的,内部实现逻辑无从探究 , 需要进行反向工程。具体来说目前的GPU架构:  F架构, K架构, P架构,V架构, T架构,A架构。
  2. 架构调整,需要抽象出一个中间池化层:  统一API,屏蔽不同位置(本地,远端),不同类型的GPU

  3.  比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 可以将一个设备映射到多个不同的虚拟机中去, 同上
  • 每个vGPU的显存和算力都是固定的,无法灵活配置。
  • 需要单独的license授权
阶段2
nvidia MIG 多实例,MIG 可将 A100 GPU 划分为多达七个实例,每个实例均与各自的高带宽显存、缓存和计算核心完全隔离。 同上 目前只针对A100 等有限的实现了MIG,对老卡则无法配置 阶段2
阿里cGPU 通过劫持内核驱动,为容器提供了虚拟的GPU设备,从而实现了显存和算力的隔离;
  • 适配开源标准的Kubernetes和NVIDIA Docker方案;
  • 用户侧透明。AI应用无需重编译,执行无需CUDA库替换;
  • 同时支持GPU的显存和算力隔离
  • 需要定制内核版本

  • 没有开源
阶段2+
腾讯qGPU 它是目前业界唯一真正实现了故障隔离、显存隔离、算力隔离、且不入侵生态的容器 GPU 共享的技术。(官方表述)
  • 适配开源标准的K8s和Docker
  • 无需重编译AI应用,运行时无需替换CUDA库,升级CUDA
  • 支持GPU的显存和算力隔离
没有继续维护 阶段2+

趋动科技

OrionX(猎户座)

实现了GPU共享的能力,在资源隔离方面,使用了CUDA劫持的方案,通过MPS以及其他方式限制算力。
  1. 基础的: 显存隔离、算力隔离

  2. 高级的: 实现了GPU资源池化,可以远程调用

  3. 通过统一管理GPU,降低GPU的管理复杂度和成本
  • 需要定制化使用,Orion Client Runtime的容器镜像。
  • 没有开源
阶段4
百度双引擎GPU  双引擎 GPU 容器虚拟化架构, 采用了用户态和内核态两套隔离引擎,以满足用户对隔离性、性能、效率等多方面不同侧重的需求。
  1. 基础的: 显存隔离、算力隔离。显存 MB 级隔离;算力 1% 级分配;

  2. 高级的: 编码器隔离、高优抢占、显存超发、显存池化。

  3. 2种模式: 可选择内核态和用户态模式
  • 技术复杂度高
  • 没有开源
阶段4

最值得关注的 趋动科技 和 百度的GPU虚拟化方案

 

OrionX(猎户座) 虚拟化方案

架构

Orion Controller
Orion Server
Orion Client

+ license授权模式

典型场景1

GPU池化优化的场景一:多个在线推理混合部署

 

OrionX池化能力关键词:化整为零,动态释放。

 

典型场景2 GPU池化优化的场景二:在/离线推理混合部署,算力超分,昼夜复用 OrionX池化能力关键词:化整为零,动态释放,算力超分,任务优先级。

典型场景3

GPU池化优化的场景三:训练/推理混合部署,显存扩展,分时复用 OrionX池化能力关键词:化整为零,动态释放,算力超分,显存超分,任务优先级。

核心能力解读:

  1. 化整为零: 虚拟化
  2. 动态释放: 在线/离线混合部署( 不算虚拟化技术)
  3. 算力超分: over-commit , 类似CPU
  4. 显存超分: 显存不够,内存来凑
  5. 任务抢占: 高优先级可抢占,算例分配

 

百度的GPU虚拟化方案

 
 
 
架构图
  1. 业务: 推理,训练,开发
  2. 调度: 针对不同场景,采用不同的调度策略
  3. 隔离: 增加池化层API,屏蔽底层差异 ;

基础能力

显存隔离、算力隔离。显存 1MB 级隔离;算力 1% 级分配;

 
高级能力 编码器隔离(不懂)、高优抢占、显存超发、显存池化,远程调用,池化

实现了 4 种内核态算力调度算法:

  • Fixed Share:每个 POD 分配固定的算力资源,即整个 GPU 的算力固定分为 n 份,每个 POD 分 1/n 的算力。
  • Equal Share:所有活跃的 POD 平分算力资源,即活跃的 POD 数为 n,每个 POD 分 1/n 的算力。
  • Weight Share:每个 POD 按照权重分配算力资源,即整个 GPU 的算力按照权重值分配给每个 POD。不管 POD 是否有业务负载,都按照权重分配算力。
  • Burst Weight Share:活动的 POD 按照权重分配算力资源,即每个 POD 分配权重值,活跃的POD按照权重的比值分配算力。
双引擎

长尾延迟:

内核态由于采用了时分复用,对长尾延迟影响稍大。

用户态由于采用了空分复用,大大降低了对长尾延迟的影响。

 

在整体架构中我们采用了用户态和内核态两套隔离引擎,以满足用户对隔离性、性能、效率等多方面不同侧重的需求。

 

用户态方案的优点是性能好,长尾延迟低,适合追求机制性能、极致效率的业务场景,如延迟敏感的在线推理业务。

内核态方案的优点是, 尽管长尾延迟控制不如用户态,但在隔离性方面,内核态具备优势,更侧重于对隔离要求有强诉求的场景。

 

边缘容器产品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调度
  1. 针对GPU的pod提供了额外的调度器
  2. GPU拓扑感知调度,需进一步支持
5

支持GPU实例类型

  1. GPU裸金属实例
  2. (虚拟机直通)虚拟化实例
  3. vGPU实例 ( 没有验证 ,缺乏环境需要license授权)
7 多卡虚拟机 使用2+个GPU部分算力
8 CUDA依赖 目前最高支持的版本是11.7
9 兼容性

云原生:支持标准的 Kubernetes 和 Docker。 containerd呢?
兼容性:对业务无侵入,无感知、CUDA 库不替换。

缺乏的能力
1 灵活的算例配置

对齐百度:  动态算力调整

  1. Fixed Share
  2. Equal Share
  3. Weight Share
  4. Burst Weight Share( 自适应
2 GPU拓扑感知调度 1台主机上的多个GPU之间采用NVLink进行互联互通,而不要采用PCIe进行通信
3 算力超分 目前<=100%
4  编码器隔离

GPU 视频编解码能力, 流媒体

使用GPU硬件加速FFmpeg视频转码

5 远程调用 rCUDA , remote-CUDA
6 GPU池化

一套API 实现 GPU 资源的本地使用和远程挂载

  1. CPU资源充沛, GPU资源不足
  2. GPU资源碎片化,整合利用碎片资源
7

针对不同场景,采用不同的调度策略

 

提供算力调整接口: 

  1. 在线,离线
  2. 推理,训练
  3. 白天,晚上
9 GPU遥测 对齐 nvidia-DCGM 规范指标,

 

什么是拓扑感知和nvlink

所谓的拓扑感知,就是在在k8s调度中,选择不同的GPU组合,会得到不同的训练速度,所以在GPU的调度过程中,选择最优的GPU组合,可得到最优的训练速度。

nvlink发展
 Tesla V100 的混合立体网络拓扑

对比下,常见的PCIe3.0x16数据传输带宽是32Gb/S, 而nvlink的总带宽是300GB/s , 起码相差80倍。

 

场景: 某服务需要2块GPU ,根据右边的拓扑图如何分配GPU , 才能发挥它的最佳性能呢?

 
 
nvlink条数
GPU0 GPU3 √ 2条  最佳组合
GPU0 GPU2 √ 1条  最佳组合
GPU0 GPU1 √ 1条  最佳组合
GPU0 GPU4 √ 2条  最佳组合
GPU0 GPU5 × 没有nvlink连接线,不能高速互联, 不是最佳组合
GPU0 GPU7 × 没有nvlink连接线,不能高速互联, 不是最佳组合
GPU0 GPU6

× 没有nvlink连接线,不能高速互联, 不是最佳组合

进一步,可类比下 , 常见的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

必要条件:

  1. GPU卡支持 , 例如 G3060 就不支持 ,T4卡,V100 则支持
  2. 硬件支持 ,购买 nvlink桥接器

 

边缘容器产品ECK的vGPU的落地情况

在边缘容器产品已经实现相关功能

 

测试: 分配了10%的GPU算力, 100*10M 的GPU显存 , 开启虚拟显存 vvmemory  

 

[root@fj-xiamen-4 home]# cat gpu-virtual.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cuda-gpu33
spec:
  containers:
  - name: cuda-gpu
    image: "docker.io/anibali/pytorch:1.11.0-cuda11.5-ubuntu20.04"
    command: ["/bin/bash"]
    args: ["-c", 'while true; do echo "Hello World"; sleep 10;done']
    env:
    - name: vvmemory
      value: "1"
    resources:
      limits:
    ideal.com/gpu: 1 ideal.com/vcuda-core: "10" ideal.com/vcuda-memory: "100" requests:
  ideal.com/gpu: 1 ideal.com/vcuda-core: "10" ideal.com/vcuda-memory: "100" [root@fj-xiamen-4 home]#

 

最佳实践指导

编号    
1

cuda 有以下建议
1、建议不要在 镜像里面 放 cuda 驱动


2、如果镜像里面放了驱动,宿主机的驱动要高于镜像 里面的驱动

 

3、cuda和显卡驱动基本都是向下兼容的,推荐 cuda11.x 版本最佳

 

CUDA 12.0 Update 1 Release Notes (nvidia.com)

 

 

下一步

1.  增强产品的健壮性

2.  针对大数据/AI 场景,支持 volcano

3.  针对的业务场景,提供灵活的算力配置接口

4.  支持GPU的国产化

5.  对标猎户,补齐不足

6. GPU远程调用的深入调研

 

0条评论
0 / 1000
Top123
29文章数
3粉丝数
Top123
29 文章 | 3 粉丝
Top123
29文章数
3粉丝数
Top123
29 文章 | 3 粉丝
原创

GPU虚拟化调研与落地

2023-02-20 07:36:50
978
0

总体目标

边缘容器平台为了增加产品的竞争力,也支持了GPU虚拟化能力, 因此需要调研业界的GPU虚拟化产品发展趋势, 了解它们优势和不足。

  1. 主要测试了理想GPU虚拟化的技术方案
  2. 对比业界的GPU虚拟化优劣
  3. GPU池化调研

为什么要实现GPU虚拟化

优势在于:

(1)集群中可以运行更多任务,通过分时复用,减少抢占。

(2)提高资源利用率(GPU/显存);GPU共享后,总利用率接近运行任务利用率之和,减少了资源浪费。

(3)提高服务质量(QoS),增强公平性,因为多个任务即可以同时开始享受资源;也可以单独保证某一个任务的

(4)减少任务排队时间,减小总任务的销号时间;假设两个任务结束时间分别是x,y,通过GPU共享,两个任务全部结束的时间小于x+y。

 

GPU资源池化技术的演进

  1. 简单虚拟化 ✅

  2. 任意虚拟化 ✅

  3. 远程调用 中间过程

  4. 资源池化 最终目标

 

什么是GPU远程调用

 

GPU远程调用是通过rCUDA实现的, rCUDA中间件架构图:

从上图可以了解到: 

  1. rCUDA  (remtoe CUDA)是Client-Server架构的服务。
  2. rCUDA 实现了RPC(CUDA接口) ,需要在服务器端和你的客户端机器部署其软件。
  3. rCUDA 是CUDA的远程调用版本,在本地无GPU的主机上远程访问有CUDA环境的GPU主机。

进一步可参考  http://rcuda.net/

rCUDA 通信方式有2种:

通信方式
 
 
TCP

常规方式

性能损失很大
RDMA(remote-DMA)

高速网络

远程直接内存访问

目前支持RDMA的网络协议主要有三种

  1. InfiniBand(IB)
  2. iWARP(RDMA over TCP/IP)
  3. RoCE(RDMA over Converged Ethernet) , RoCEv1和RoCEv2

RDMA 优势:  直接进行数据传输,速度快,不需要CPU参与,RDMA网卡接替了CPU的工作,节省下来的资源可以进行其它运算和服务。

那么阶段4是GPU池化,池化又是什么呢?有什么技术难点呢?

 

什么是GPU池化

GPU池化(GPU-Pooling)的定义:  通过对物理GPU进行软件定义,融合了GPU虚拟化、多卡聚合、远程调用、动态释放等多种能力,解决GPU使用效率低和弹性扩展差的问题。 如下图所示,在不同的抽象层次,将需要加速的应用转发(Forwarding)到GPU资源池中。总的来说,越靠底层的转发性能损失越小,可操作的范围越大;但同时,编程量也越大,也越难。

 

GPU池化的难点:

  1. GPU架构种类繁多,API 繁多的问题,运行时除了 libcudart.so 这个动态库,还涉及cuDNN、cuBLAS、cuFFT 等一系列动态库和 API,涉及数千个不同的 API 接口。
    更重要的是 CUDA 运行时是闭源的,内部实现逻辑无从探究 , 需要进行反向工程。具体来说目前的GPU架构:  F架构, K架构, P架构,V架构, T架构,A架构。
  2. 架构调整,需要抽象出一个中间池化层:  统一API,屏蔽不同位置(本地,远端),不同类型的GPU

  3.  比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 可以将一个设备映射到多个不同的虚拟机中去, 同上
  • 每个vGPU的显存和算力都是固定的,无法灵活配置。
  • 需要单独的license授权
阶段2
nvidia MIG 多实例,MIG 可将 A100 GPU 划分为多达七个实例,每个实例均与各自的高带宽显存、缓存和计算核心完全隔离。 同上 目前只针对A100 等有限的实现了MIG,对老卡则无法配置 阶段2
阿里cGPU 通过劫持内核驱动,为容器提供了虚拟的GPU设备,从而实现了显存和算力的隔离;
  • 适配开源标准的Kubernetes和NVIDIA Docker方案;
  • 用户侧透明。AI应用无需重编译,执行无需CUDA库替换;
  • 同时支持GPU的显存和算力隔离
  • 需要定制内核版本

  • 没有开源
阶段2+
腾讯qGPU 它是目前业界唯一真正实现了故障隔离、显存隔离、算力隔离、且不入侵生态的容器 GPU 共享的技术。(官方表述)
  • 适配开源标准的K8s和Docker
  • 无需重编译AI应用,运行时无需替换CUDA库,升级CUDA
  • 支持GPU的显存和算力隔离
没有继续维护 阶段2+

趋动科技

OrionX(猎户座)

实现了GPU共享的能力,在资源隔离方面,使用了CUDA劫持的方案,通过MPS以及其他方式限制算力。
  1. 基础的: 显存隔离、算力隔离

  2. 高级的: 实现了GPU资源池化,可以远程调用

  3. 通过统一管理GPU,降低GPU的管理复杂度和成本
  • 需要定制化使用,Orion Client Runtime的容器镜像。
  • 没有开源
阶段4
百度双引擎GPU  双引擎 GPU 容器虚拟化架构, 采用了用户态和内核态两套隔离引擎,以满足用户对隔离性、性能、效率等多方面不同侧重的需求。
  1. 基础的: 显存隔离、算力隔离。显存 MB 级隔离;算力 1% 级分配;

  2. 高级的: 编码器隔离、高优抢占、显存超发、显存池化。

  3. 2种模式: 可选择内核态和用户态模式
  • 技术复杂度高
  • 没有开源
阶段4

最值得关注的 趋动科技 和 百度的GPU虚拟化方案

 

OrionX(猎户座) 虚拟化方案

架构

Orion Controller
Orion Server
Orion Client

+ license授权模式

典型场景1

GPU池化优化的场景一:多个在线推理混合部署

 

OrionX池化能力关键词:化整为零,动态释放。

 

典型场景2 GPU池化优化的场景二:在/离线推理混合部署,算力超分,昼夜复用 OrionX池化能力关键词:化整为零,动态释放,算力超分,任务优先级。

典型场景3

GPU池化优化的场景三:训练/推理混合部署,显存扩展,分时复用 OrionX池化能力关键词:化整为零,动态释放,算力超分,显存超分,任务优先级。

核心能力解读:

  1. 化整为零: 虚拟化
  2. 动态释放: 在线/离线混合部署( 不算虚拟化技术)
  3. 算力超分: over-commit , 类似CPU
  4. 显存超分: 显存不够,内存来凑
  5. 任务抢占: 高优先级可抢占,算例分配

 

百度的GPU虚拟化方案

 
 
 
架构图
  1. 业务: 推理,训练,开发
  2. 调度: 针对不同场景,采用不同的调度策略
  3. 隔离: 增加池化层API,屏蔽底层差异 ;

基础能力

显存隔离、算力隔离。显存 1MB 级隔离;算力 1% 级分配;

 
高级能力 编码器隔离(不懂)、高优抢占、显存超发、显存池化,远程调用,池化

实现了 4 种内核态算力调度算法:

  • Fixed Share:每个 POD 分配固定的算力资源,即整个 GPU 的算力固定分为 n 份,每个 POD 分 1/n 的算力。
  • Equal Share:所有活跃的 POD 平分算力资源,即活跃的 POD 数为 n,每个 POD 分 1/n 的算力。
  • Weight Share:每个 POD 按照权重分配算力资源,即整个 GPU 的算力按照权重值分配给每个 POD。不管 POD 是否有业务负载,都按照权重分配算力。
  • Burst Weight Share:活动的 POD 按照权重分配算力资源,即每个 POD 分配权重值,活跃的POD按照权重的比值分配算力。
双引擎

长尾延迟:

内核态由于采用了时分复用,对长尾延迟影响稍大。

用户态由于采用了空分复用,大大降低了对长尾延迟的影响。

 

在整体架构中我们采用了用户态和内核态两套隔离引擎,以满足用户对隔离性、性能、效率等多方面不同侧重的需求。

 

用户态方案的优点是性能好,长尾延迟低,适合追求机制性能、极致效率的业务场景,如延迟敏感的在线推理业务。

内核态方案的优点是, 尽管长尾延迟控制不如用户态,但在隔离性方面,内核态具备优势,更侧重于对隔离要求有强诉求的场景。

 

边缘容器产品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调度
  1. 针对GPU的pod提供了额外的调度器
  2. GPU拓扑感知调度,需进一步支持
5

支持GPU实例类型

  1. GPU裸金属实例
  2. (虚拟机直通)虚拟化实例
  3. vGPU实例 ( 没有验证 ,缺乏环境需要license授权)
7 多卡虚拟机 使用2+个GPU部分算力
8 CUDA依赖 目前最高支持的版本是11.7
9 兼容性

云原生:支持标准的 Kubernetes 和 Docker。 containerd呢?
兼容性:对业务无侵入,无感知、CUDA 库不替换。

缺乏的能力
1 灵活的算例配置

对齐百度:  动态算力调整

  1. Fixed Share
  2. Equal Share
  3. Weight Share
  4. Burst Weight Share( 自适应
2 GPU拓扑感知调度 1台主机上的多个GPU之间采用NVLink进行互联互通,而不要采用PCIe进行通信
3 算力超分 目前<=100%
4  编码器隔离

GPU 视频编解码能力, 流媒体

使用GPU硬件加速FFmpeg视频转码

5 远程调用 rCUDA , remote-CUDA
6 GPU池化

一套API 实现 GPU 资源的本地使用和远程挂载

  1. CPU资源充沛, GPU资源不足
  2. GPU资源碎片化,整合利用碎片资源
7

针对不同场景,采用不同的调度策略

 

提供算力调整接口: 

  1. 在线,离线
  2. 推理,训练
  3. 白天,晚上
9 GPU遥测 对齐 nvidia-DCGM 规范指标,

 

什么是拓扑感知和nvlink

所谓的拓扑感知,就是在在k8s调度中,选择不同的GPU组合,会得到不同的训练速度,所以在GPU的调度过程中,选择最优的GPU组合,可得到最优的训练速度。

nvlink发展
 Tesla V100 的混合立体网络拓扑

对比下,常见的PCIe3.0x16数据传输带宽是32Gb/S, 而nvlink的总带宽是300GB/s , 起码相差80倍。

 

场景: 某服务需要2块GPU ,根据右边的拓扑图如何分配GPU , 才能发挥它的最佳性能呢?

 
 
nvlink条数
GPU0 GPU3 √ 2条  最佳组合
GPU0 GPU2 √ 1条  最佳组合
GPU0 GPU1 √ 1条  最佳组合
GPU0 GPU4 √ 2条  最佳组合
GPU0 GPU5 × 没有nvlink连接线,不能高速互联, 不是最佳组合
GPU0 GPU7 × 没有nvlink连接线,不能高速互联, 不是最佳组合
GPU0 GPU6

× 没有nvlink连接线,不能高速互联, 不是最佳组合

进一步,可类比下 , 常见的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

必要条件:

  1. GPU卡支持 , 例如 G3060 就不支持 ,T4卡,V100 则支持
  2. 硬件支持 ,购买 nvlink桥接器

 

边缘容器产品ECK的vGPU的落地情况

在边缘容器产品已经实现相关功能

 

测试: 分配了10%的GPU算力, 100*10M 的GPU显存 , 开启虚拟显存 vvmemory  

 

[root@fj-xiamen-4 home]# cat gpu-virtual.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cuda-gpu33
spec:
  containers:
  - name: cuda-gpu
    image: "docker.io/anibali/pytorch:1.11.0-cuda11.5-ubuntu20.04"
    command: ["/bin/bash"]
    args: ["-c", 'while true; do echo "Hello World"; sleep 10;done']
    env:
    - name: vvmemory
      value: "1"
    resources:
      limits:
    ideal.com/gpu: 1 ideal.com/vcuda-core: "10" ideal.com/vcuda-memory: "100" requests:
  ideal.com/gpu: 1 ideal.com/vcuda-core: "10" ideal.com/vcuda-memory: "100" [root@fj-xiamen-4 home]#

 

最佳实践指导

编号    
1

cuda 有以下建议
1、建议不要在 镜像里面 放 cuda 驱动


2、如果镜像里面放了驱动,宿主机的驱动要高于镜像 里面的驱动

 

3、cuda和显卡驱动基本都是向下兼容的,推荐 cuda11.x 版本最佳

 

CUDA 12.0 Update 1 Release Notes (nvidia.com)

 

 

下一步

1.  增强产品的健壮性

2.  针对大数据/AI 场景,支持 volcano

3.  针对的业务场景,提供灵活的算力配置接口

4.  支持GPU的国产化

5.  对标猎户,补齐不足

6. GPU远程调用的深入调研

 

文章来自个人专栏
云原生最佳实践
29 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
0
0