拥抱云原生,数十万规模 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.

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-16 09:16
浙ICP备14020137号-1 $お客様$