Microsecond-scale Preemption for Concurrent GPU-accelerated DNN Inferences

这是到目前为止(2023/10)应该是唯一一篇在认真思考并且实现 GPU 抢占的论文了。
之前很多论文都研究过 GPU 怎么混部,怎么做算力和显存的隔离,但是目标都是提升利用率,但是很难保证长尾延迟。比较适合训练,但不适合推理。
但是这篇论文其实也是有很多限制的:
  1. 不支持 nvidia GPU,只支持 amd
  2. 模型需要经过 tvm 的编译,因为抢占的实现依赖了编译技术
这篇论文主要的工作就2个事情:
  1. GPU 抢占:real-time任务启动的时候,best-effort 任务怎么做到快速的退出。
  2. dynamic kernel padding:怎么在尽可能保证 rt 任务 latency 的情况下,混部 be 的任务
最终效果:
  1. 2% 的延迟损失,换取 7.7x 倍的性能提升

1. 系统架构

0
reef 在 GPU runtime 的基础上扩展了4个核心组件:
  1. Task Queues:一个rt队列和多个be队列,每个队列绑定一个 GPU Stream
  2. Scheduler:一个调度器,2种模式,rt模式,normal模式,如果当前没有rt任务,调度器会切换到normal模式,如果有rt任务,会切换到rt模式。这个地方应该是为了和下面的抢占进行协同
  3. Preemption:抢占模块,实现rt抢占be
  4. DKP:dynamic kernel padding
前面2个没啥东西,重点讲一下抢占是怎么实现的吧,这个比较有意思


Pathways – Asynchronous Distributed Dataflow for ML

其他参考:
xx

1. 论文背景、动机、贡献

在探讨现有 AI 模型的局限时,Jeff Dean 曾经说过,今天的人工智能系统总是从头开始学习新问题,我们为数千个单独的任务开发了数千个单独的模型,这种方式需要大量的数据和算力,是非常低效的
理想的发展模式应该是训练1个模型来干多个事情
0
而导致这个现象的根本原因,是因为过去10年的机器学习,总是 算法&硬件&系统 一起演进的,这种 co-evolution 的方式有一定的隐患:系统过于针对当前的任务,而不能很好的适应未来的需求
未来 ML 的需求是什么?
  1. 模型会越来越大:
    1. 多模态:复杂,参数多。纯粹的数据并行已经不行了,开始引入流水线并行、模型并行等新的并行训练方式
    2. 计算稀疏:大模型特有的一个问题
  2. 硬件异构:SPMD 不适用了,因为我们需要在不同的“硬件”上运行不同的代码,需要转向 MPMD
  3. 训推一体:提升硬件利用率
为了实现这个愿景,论文提出了一种叫 [Pathways] 的通用AI架构。Pathways 旨在用一个架构同时处理多项任务,并且拥有快速学习新任务、更好地理解世界的能力


Mix Precision Training 混合精度训练

这是一篇百度和 nvidia 合作的论文
实际上在 MPT 之前,已经有一些论文在做减少精度训练相关的工作了,比如:
  1. Binaryconnect: Training deep neural networks withbinary weights during propagations @2015
  2. Binarized neural networks. InAdvances in Neural Information Processing Systems @2016

1. 背景

随着现在深度神经网络模型越来越大,万亿参数,百万亿参数,深度学习训练所需要的GPU内存越来越多,内存优化迫在眉睫
Year
Name
Param
From
2018
110M
OpenAI
2018
349M
Google
2020
175B
OpenAI
2022
540B
Google
传统的神经网络训练里面,都是用FP32来保存权重、梯度等数据。但是FP32在大模型场景下(万亿参数)内存开销太大了
为了解决这个问题,MPT 论文提出了一种使用 FP16 精度来训练神经网络,同时基本不影响训练效果的方法

2. 实现

使用FP16会有很多好处:
  1. 大幅减少内存消耗:50%?
  2. 运算加速,FP16肯定要比FP32要快
但是随之带来的问题是:精度损失
IEEE标准中的FP16格式如下:
0
取值范围是5.96× 10−8 ~ 65504,而FP32则是1.4×10-45 ~ 3.4×1038
精度损失在神经网络训练里面可是比较致命的,可能会训练出截然相反的结果
为了解决这个问题,论文提出了3种方法


Singularity:Planet-Scale, Preemptive and Elastic Scheduling of AI Workloads

摘要

原文:https://arxiv.org/pdf/2202.07848.pdf

Singularity,微软的全局分布式调度服务,用于高效可靠地执行深度学习训练和推理工作负载。Singularity 的核心是一种新颖的、负载感知的调度器,它可以透明地抢占深度学习工作负载以及进行弹性伸缩,在不影响AI加速器(如 GPU、FPGA)的正确性和性能的前提下,提高利用率。

Singularity中的所有作业默认都是可抢占、可迁移、可动态调整(弹性)大小的:一个运行的作业可以动态透明地:

(a) 被抢占并迁移到不同的节点、集群、数据中心或区域,并从执行被抢占的位置恢复;

(b) 在给定类型的不同加速器上弹性伸缩resize;

我们的机制是透明的,因为它们不需要用户对代码做任何更改,也不需要使用任何可能限制灵活性的自定义库。此外,我们的方法显著提高了深度学习工作负载的可靠性。

结果表明,Singularity 提高了系统的效率和可靠性,对稳态性能的影响可以忽略不计。而且,Singularity 的设计与 DNN 架构无关,可以处理各种并行策略(例如,数据/管道/模型并行)。

 

1. 简介

Singularity 核心实现了 AI 任务的可抢占、可迁移、可动态调整,并且该实现与模型架构无关、与模型训练的并行策略无关,可以认为做到了用户无感

1.1. 设计目标

Singularity 为了最大化整个集群的吞吐量,采用以下设计原则:

  1. 不闲置资源:Singularity 将整个加速器集群视为单个逻辑共享集群,并避免任何资源碎片化或静态容量预留。Singularity 适时调度使用全球范围内的任何空闲资源,跨集群、AZ和工作负载边界(训练与推理)。
  2. 提供作业级别的 SLA:在适时使用空闲容量的同时,Singularity 通过遵守作业级别的 SLA 来提供隔离。例如,当推理作业的负载增加时,Singularity 通过弹性缩小或抢占训练作业来释放容量。
  3. 故障弹性恢复:DNN 训练作业运行时间长达数小时、数天甚至数周,因此从头开始成本损失巨大。在 Singularity 中,作业从它们被抢占的地方恢复,从而将故障重启成本最小化。

1.2. 关健机制

为实现上面的目标,整个 Singularity 系统的底层由两大重要的机制来支撑。它们分别是:

1) 抢占和迁移机制:Singularity 可以透明地设置检查点、抢占和迁移节点间甚至跨集群和区域的所有 DNN 作业。检查点是通过高效的的同步屏障 (synchronization barrier) 来实现分布式作业的所有参与者之间分布式状态的 一致性切分 (consistent cut)。

2) 伸缩和弹性机制:Singularity 使所有工作能够使用可变数量的 AI 加速器,以透明的方式 动态地、弹性地 伸缩资源。

Singularity 系统架构

  1. 这里涵盖了所有的 AI 算力,包括 GPU、FPGA、CPU、ASIC 等不同的硬件形态。
  2. 所有的算力资源都被容器化了
  3. 硬件抽象层(HAL)竟然 在一层基础软件之上,这层基础软件包括 NVML、NCCL、CUDA,也就是设备管理、设备通信、设备计算这三类功能。
  4. 硬件抽象层这里的 CUDA 指的是 CUDA Driver API f. 核心调度原语。高层原语包括:Failover、Suspend、Resume、Migrate、Scale Up/Down ,底层原语包括:Checkpoint、Restore、Distributed Barrier 。


阿里云 GPU Sharing in Kubernetes

文档:https://github.com/AliyunContainerService/gpushare-scheduler-extender/blob/master/docs/designs/designs.md

阿里云的 gpu sharing 只是实现了资源的按需分配和调度,并没有解决算力 & 显存隔离的问题

基于k8s原生的Scheduler Extender、Extended Resource、DevicePlugin机制来实现

提供2个接口:

  • aliyun.com/gpu-mem: 单位从  number of GPUs 变更为 amount of GPU memory in MiB,如果一个Node有多个GPU设备,这里计算的是总的GPU Memory
  • aliyun.com/gpu-count:对应于Node上的GPU 设备的数目

整体架构:


Blink Fast and Generic Collectives for Distributed ML

论文原址:https://arxiv.org/abs/1910.04940

blink 论文最创新的地方,其实就是在训练的过程中,考虑了硬件的拓扑结构,类似于最短路径优化,找到一个训练时间最短的路径

背景介绍

随着机器学习模型,和数据量的不断增长,模型训练逐渐由单机训练,转变为分布式的多机训练。在分布式深度学习中,数据并行是最为常用的模型训练方式。然而数据并行的模型训练过程中,需要频繁的做数据聚合/模型同步。参与运算的 GPU 数量越多,其对应的数据聚合的开销也会越大。当下单个 GPU 的算力不断增加,GPU 间的数据聚合成成了新的分布式机器学习的瓶颈。

各大公司也发现了数据聚合这个重大瓶颈,因此在软硬件上都提出了自己的解决方案。硬件层面上,GPU 厂商 Nvidia 发布了 GPU 之间直接相连的高速通信通道 NVLink,以及多 GPU 之间的路由器 NVSwitch。软件层面上,各大公司都相继发布了自己的 GPU 通信库(例如:Nvidia 的 NCCL,Baidu 的 Ring-AllReduce),或者针对 GPU 通信进行优化的分布式机器学习平台(最流行的 Uber 的 Horovod)。

然而,这些软件层面上的通信库或者机器学习平台,并没有充分利用所有的,同构和异构的网络通信线路。因此,由 UC Berkeley,Microsoft Research 以及 University of Wisconsin-Madison 组成的研究团队发布,能够充分利用所有同构及异构的网络传输线路,从而实现最优 GPU 间数据聚合的 Blink 项目。

论文摘要

当下流行的分布式机器学习平台(Horovod)或 GPU 间数据聚合的通信库(NCCL),其最大问题在于无法很好的解决网络异构性。网络异构性主要表现为如下三点:

1. 同构的 GPU 间链接线路,例如 NVLink,用于不同型号的 GPU 的对应 NVLink 的版本和带宽不同,其组成的网络的拓扑结构也不相同。具体区别如图一所示。

0

在一个 8 卡的 DGX-1 机器上:如果 GPU 是 P100,其对应的 NVLink 是第一代,带宽为 18-20GB/s,其拓扑结构如图 1 黑线所示。如果 DGX-1 用的 GPU 是 V100,其 NVLink 通信线路为第二代,带宽为 22-25GB/s。于此同时,相比 P100 的 DGX-1,V100 的 DGX-1 的网络拓扑结构也不同,其在 P100 的基础上,新增了一圈红色虚线的 NVLink 线路。


Bringing HPC Techniques to Deep Learning

原文地址: andrew.gibiansky.com/bl

Allreduce 其实一直是HPC领域很常见的一个技术,所以百度这篇论文其实讲的也是如何将Allreduce从HPC引入到深度学习领域,通过Allreduce算法,大大的提高了深度学习的模型训练速度

简介

过去几年中,神经网络规模不断扩大,而训练可能需要大量的数据和计算资源。 为了提供所需的计算能力,我们使用高性能计算(HPC)常用的技术将模型缩放到数十个GPU,但在深度学习中却没有充分使用。 这种ring allreduce技术减少了在不同GPU之间进行通信所花费的时间,从而使他们可以将更多的时间花费在进行有用的计算上。 在百度的硅谷AI实验室(SVAIL)中,我们成功地使用了这些技术来训练最先进的语音识别模型。 我们很高兴将Ring Allreduce的实现发布为TensorFlow的库和补丁程序,并希望通过发布这些库,我们可以使深度学习社区更有效地扩展其模型。

Introduction

在过去的几年中,神经网络已被证明是解决各种问题的非常有效的工具,并且在规模和计算需求方面迅速增长。 2012年,用于图像识别的SuperVision卷积网络通过两个星期的GPU和6000万个参数在对象识别方面取得了长足的进步。 2016年,研究人员在网络上进行语言建模方面取得了突破,该网络具有在32个GPU上进行了为期三周的训练的十亿多个参数。 在百度研究院的硅谷AI实验室中,2014年,我们的Deep Speech语音识别系统的第一次迭代大约有1100万个参数,而一年后的下一次迭代已增长到1亿个参数。

随着神经网络的参数数量和计算需求的增长,在许多节点和许多GPU上有效并行化神经网络训练变得越来越重要,因为等待大型网络训练数月会减慢实验速度并限制进一步的发展。 在此博客文章中,我们介绍了一种来自高性能计算(HPC)领域的技术,并演示了如何将其应用于深度学习以在神经网络训练中获得显着的性能提升。


AllReduce 算法的前世今生

原文:https://zhuanlan.zhihu.com/p/79030485

从事分布式深度学习相关工作的同学,应该都频繁地用到了AllReduce(规约)操作。

图1 AllReduce的示意图

但是对于训练框架中集成的AllReduce相关操作,其背后实现的原理是什么?

除了最近几年名声大噪的Ring AllReduce是否还有其他的AllReduce算法?

他们各自的性能开销如何?如何取舍?

本文尝试从一个较为全面的角度来展现AllReduce算法的前世今生,既分析经典算法,也介绍发展中的新秀。

MPI中的AllReduce算法

其实说到AllReduce,很多人脑海里的第一反应都是MPI_AllReduce。作为集合通信中的元老,和高性能计算领域的通信标准,在MPI_AllReduce这个通信原语背后,MPI中实现了多种AllReduce算法。

以openMPI源码为例,里面实现了多种allreduce的算法。具体的算法选择在

ompi/mca/coll/tuned/coll_tuned_decision_fixed.c

图2 openMPI源码中选择allreduce算法的代码片段