拥抱云原生,数十万规模 GPU 卡的利用率极致优化之路
如果无法正常显示,请先停止浏览器的去广告插件。
1. 拥抱云原生
数十万规模GPU卡的利用率极致优化之路
陈煜东
腾讯云异构计算、THPC研发负责人
2. 关于我
陈煜东 dondonchen
腾讯云异构计算、THPC研发负责人
现负责腾讯云异构计算、裸金属高性能集群等相关
研发工作,具有多年的分布式资源调度、大规模集
群调度理论与实践经验。
3. 大纲
1. 自研 GPU 业务上云历程
2. qGPU 共享技术:如何实现容器级细粒度算力切分
3. 基于 Taco 的异构计算加速实践
4. 容器实例的 GPU 混部方案
4. 打破自研上云疑问点
• 稳定性
• 灵活性
• 成本降低
• 监控完善
• 部署难易度
5. 自研GPU业务上云历程
自研上云GPU规模
数十万
数万卡
数千卡
数百卡
2017
2018
业务初尝试
2019
监控
突发弹性能力
2020
License管理
一键自动化安装
多版本驱动管理
2021
qGPU
Taco训练加速
容器实例混部
2022
6. 大纲
1. 自研 GPU 业务上云历程
2. qGPU 共享技术:如何实现容器级细粒度算力切分
3. 基于 Taco 的异构计算加速实践
4. 容器实例的 GPU 混部方案
7. 音乐、广告面临的问题
GPU 算力 & 显存利用率低
• GPU资源价格昂贵、利用率低
问题
• vGPU资源切割不灵活
• 显存 / 算力 强隔离
• 多业务混合部署
• 仅支持最高端GPU
• 故障隔离性
8. NVIDIA vGPU
虚拟化级切卡 固定比例切分
9. GPU共享方案几个层次
Application
1
② CUDA API,包括Runtime API和Driver API,拦截、控制
③ UMD/KMD中间拦截、控制
cuDNN等库
nvidia控制
CUDA Runtime
① Framework(如TensorFlow、PyTorch)拦截、控制
2
容器
容器
Application
CUDA Driver
Application
…
UMD
用户层
UMD
3
内核层
nvidia Driver
GPU硬件
NVIDIA Driver/KMD
GPU 0
GPU 1
…
GPU 7
10. qGPU架构
user space
K8S
Kubernetes scheduler 集群调度算法
GPU manager + scheduler plugin
nvidia-docker2
PodN: 100% time slice & 14G vidmem
Pod0: 40% time slice & 5G vidmem Pod1: 40% time slice & 5G vidmem APP APP APP
nvidia-container-toolkit Framework Framework Framework
nvidia/qGPU runtime hook UMD UMD UMD
nvidia container toolkit
libnvidia-container
/dev/nvidia0
Shared GPU0
/proc/qgpu 配置
kernel space
qGPU
GPU节点
(CVM/BM/vGPU实例)
/dev/nvidia0
/dev/nvidiactl
Shared GPU0
/dev/nvidia0
/dev/nvidiactl
Whole GPU
显存/算力隔离功能通过劫持(open/ioctl/close/mmap)等系统调用完成
Scheduler
• BS/FS/Burst policy
• Kthread per GPU
nvidia driver(KMD)
/dev/nvidiactl
/dev/qgpu0
/dev/qgpuctl0
/dev/nvidia0
GPU 0
/dev/qgpu1
/dev/qgpuctl1
/dev/nvidiactl
GPU …
/dev/nvidiaN
GPU N
11. qGPU调度策略
k8s集群调度策略
计算任务
• Spread:平均分配 保证负载稳定均衡
• Binpack:尽量填满保证利用率
qGPU Kubernetes Scheduler
binpack
spread
• Best Effort:保证最大的Throughput
Pod
Pod
GPU0
GPU1
Pod Pod
Pod Pod
• Fixed Share:算力最低配置保证
• Burst Share:算力最低保证,允许占用空闲
GPUX
单节点单卡离线PODs支持的调度策略
policy
中文名
含义
Best Effort
(默认值) 争抢模式 默认值。各个 Pods 不限制算力,只要卡上有剩余算力就可使用。 如果一共启动 N 个 Pods,
每个 Pod 负载都很重,则最终结果就是 1/N 的算力。
Fixed Share 固定配额 每个 Pod 有固定的算力配额,无法超过固定配额,即使 GPU 还有空闲算力。
Guaranteed Share
with Burst
保证配额加弹性能力
调度器保证每个 Pod 有保底的算力配额,但只要 GPU 还有空闲算力,就可被 Pod 使用。例
如,当 GPU 有空闲算力时(没有分配给其他 Pod),Pod 可以使用超过它的配额的算力。注
意,当它所占用的这部分空闲算力再次被分配出去时,Pod 会回退到它的算力配额。
12. qGPU 单卡调度policy
配置信息:Pod1:
20% time slice;
Pod2: 30% time slice; 50% reserved;
Time slice: 20ms;
占有GPU
出让GPU
qGPU Scheduler Algorithm
Pod1
Pod2
有任务即提交/无QoS
Time slice = 20ms (default config)
10ms
Time
20ms
2 Pods with Best-effort policy
Pod1
任何一时刻一个POD运行/QoS
Pod2
Time slice = 20ms (default config)
10ms
20ms
2 Pods with Fix-Shared policy
Time
Pod1
同上/无IDLE/新POD退还
Pod2
Time slice = 20ms (default config)
10ms
2 Pods with Burst policy
20ms
Time
13. qGPU 在离线混部及调度方式
高优任务
低优任务
• 高优任务 平均分配 保证负载均衡
qGPU Kubernetes Scheduler
binpack
spread
Pod1
高优任务
GPU0
• 低优任务 尽量填满 保证资源利用率
Pod2 Pod1
低优任务 高优任务
• 支持在线 100% 抢占
• GPU利用率的极致提高
Pod2 � � GPU Pod3 � � GPU
低优任务
• 业内唯一GPU在离线混部技术
低优任务
GPU1
占有GPU
高优 Pod1提交任务
run imm
高优 Pod1
出让GPU
…
till done
IDLE .. for 100tick
resume
低优 Pod2
低优 Pod3
suspend
resume
suspend
低优 Pods 使用fix-share/burst调度策略
软件调度周期
默认20tick/可配
时间
14. qGPU 性能测评 – 多 Pod 场景
15. 大纲
1. 自研 GPU 业务上云历程
2. qGPU 共享技术:如何实现容器级细粒度算力切分
3. 基于 Taco 的异构计算加速实践
4. 容器实例的 GPU 混部方案
16. 广告分布式训练性能不升反降
理论速度(GB/s) 场景
A100 Device Mem 1555 Device2Device
A100 Nvlink 600 Peer2Peer
PCIe Gen4 x16 32 Host2Device, Device2Host
Tencent 50G VPC 6.25 Node2Node
最小(MB) 最大(MB) 50G VPC 所需要耗时
ResNet50 2 20.35 0.3ms ~ 3.2ms
TransformerXL 0.06 137 0.01ms ~ 21ms
Tflops/Gbs
T=M/B+a1M+a2
V100_FP32/VPC A100_TF32/VPC
15.6/25 156/50
17. 如何解决网络通信问题?
APP APP … APP
DL Framework DL Framework … DL Framework
两个维度的优化手段:
Distributed Framework(Horovod)
l通信算法。主要定义在分布式框架当中 LightCC
l通信协议。主要定义在集合通信协议当中 HARP
Communication library(NCCL)
GPU/NIC
GPU/NIC
…
GPU/NIC
18. LightCC
全局allreduce:
• 只有首尾的两个GPU是进行数据交互的
• 网络带宽的利用率比较低
2D allreduce :
• 先单机卡内nvlink进行数据传输计算
• 然后跨机通信切分数据计算
• 单机内nvlink传输计算
• 所有卡都同时在跨机收发数据,带宽利用率
• 传输的数据量减少
19. HARP自定义协议栈
Application
HARP API
问题:
HARP specific API
HARP
Stack
instance
HARP
Stack
instance
HARP
Stack
instance
l多机分布式训练中网络通信占比越来越重
zbuf
l云上没有RDMA环境下,内核socket通信效率低
tools
HARP的特点:
BSD socket API
DPDK / HARP HAL
user space
lBypass kernel,全路径内存零拷贝
l模块化无锁设计,可以进行多核性能扩展,cache miss低,I/O吞吐高
kernel space
Kernel TCP/IP stack
NIC
queue 0
NIC
queue 1
lNCCL Plugin方式集成,无需任何业务改动
…
NIC
queue N
20. 效果
ResNet50_BS256_A100_50G
TransformerXL_BS32_A100_50G
12000
350000
10123
10000
300000
250000
8000
7183
200000
6237
6000
5421
150000
4000
100000
2000
50000
798
ht
0
0
21. 大纲
1. 自研 GPU 业务上云历程
2. qGPU 共享技术:如何实现容器级细粒度算力切分
3. 基于 Taco 的异构计算加速实践
4. 容器实例的 GPU 混部方案
22. 为配合业务降本带来的问题
CPU
CPU
CPU
CPU
资源浪费
降本带来的问题:
1. 业务需要的CPU、MEM无法GPU等比例切分
2. 复用机型,后端无法定制多种规格物理机
GPU弹性容器实例
GPU
GPU
GPU
弹性容器实例宿主机
GPU
富裕年代,这些都不是事
23. 混部充分利用碎片资源
CPU
CPU
CPU
CPU
应对思路:将空洞的资源与CPU弹性容器实例混部
弹性容器实例
带来的问题:
1. 频繁的弹性伸缩,碎片资源如何高效利用
2. 资源的迁入与迁出如何设定
GPU弹性容器实例
GPU
GPU
GPU
GPU
24. 迁移策略
迁入
•
规格
小规格,创建时间早的
•
•
8c
时机
凌晨业务低谷迁入在线容器实例
宿主机
GPU卡全部售卖完,直接迁移
GPU卡部分售卖完,预留GPU实例需要的cpu/mem,剩余混部
12c
迁移中
•
•
•
•
16c
14c
4c
4c
实例信息生成最大堆结构
母机信息生成最小堆结构
先大规格实例迁移(避免更碎片化)
小规格实例填充 碎片
16c
24c
2c
2c
迁出
•
•
•
时机
GPU资源空出
计算预留GPU实例需要的数量,迁出多余的实例
目的端
其他GPU母机或者通用母机
重复迁移中的动作
宿主机 1 … n
弹性容器实例 1 … n
25. 收益
GPU宿主机碎片率
100%
95%
90%
%
3
5
80%
600
570
500
62%
70%
GPU宿主机浪费成本
400
60%
50%
300
40%
200
30%
20%
170
100
10%
0%
0
优化前
优化前
优化后
优化后
优化前
优化前
优化后
优化后
26. 总结
• 通过在GPU UMD KMD增加一层,实现更灵活的算力、显存切分调度
• 通过减少跨机数据通信与优化协议栈耗时,提升分布式训练效率
• 弹性容器实例通过资源混部与动态迁移能力,提供能灵活的规格,降低成本
27. 沟通交流
•
技术交流
•
•
微信:daoiqi
求贤若渴
• dondonchen@tencent.com
• 深圳、北京
• 调度、异构计算、裸金属、HPC
28.