[Dis/MLsys/net]Herring: Rethinki
2021-07-11
Herring: Rethinking the Parameter Server at Scale for the Cloud
地址：sc'20
周四看了大概的内容，今天把实现细节理一理
二、背景和相关工作
- PS
在DL训练早期，很多工作，聚焦于PS架构，异步训练快，同步训练准确度高。基于PS架构的方法有如下优点：
1.1 通讯只有两跳
1.2 异步参数同步
1.3 使用的带宽少
PS架构收发M的数据，All-Reduce的方法收发2M的数据
PS架构的缺点
1.1 需要额外的计算资源作为server，这个也好解决，用GPU作为计算资源，CPU作为server的服务端
PS架构的瓶颈
1.1 不平等的带宽分配
PS架构中，当worker增加的时候，server会承担很大的流量压力
1.2 bursty的通讯模式
1.3 网络拥塞
最近BytePS在这方面有做一定工作，但是只靠以太网的TCP和参数sharding还不够
- Allreduce-based approaches
All-reduce架构的工作最近出现很多，对于不同拓扑的研究，节点内，节点间的优化也可以达到很大的规模，但是All-reduce方法本身更多的网络跳数和网络流量也在更大规模的系统上有问题
designing communication libraries for efficient bandwidth usage is crucial for deep learning workloads 设计一个ML适用的网络通讯库去充分利用带宽是很重要的
- Gradient compression（为啥要提到梯度压缩，为了showPS的好处）
为了提高并行效率，一部分工作聚焦梯度量化，一部分工作聚焦稀疏化梯度，一部分工作讨论如何减少梯度更新，还有结合三种类型的工作；
如果使用PS架构，开发者可以更自由的使用模型压缩技术来加速过程。
三、介绍本文提出的Herring库
herring库使用了EFA（AWS在网络方面提出的创新）和BFB（balanced fusion buffer），
Herring层次化的，现在节点内部减少通讯，然后再不同节点传播
Herring 比Allreduce的方法好，是因为PS架构的内在网络优势和充分利用了EFA的buffer
3.1 BFB是什么
在ML训练中，参数被切分然后分配到不同的服务器上，参数服务器把variables作为一个原子单元，在反向传播的过程中，对gradients的需求是有顺序的，所以对不同服务器的收发数据量是不同的，某一个时刻，可能只有一个server在传输数据，其他都在闲着
BERTlarge 有398 trainable variables. 398 variables 分配在 256台设备上，some servers will own only one parameter.在反向传播的过程中，一个时刻可能只有一个或者两个gradient被reduce
BFB是放在GPU的缓存，到达一定数量，就把他们copy到CPU，切割成N份（N是parameter servers的个数），每份对应一个参数服务器；
所以每个服务器上的数据量是一样大的，除了最后一个。
- Balanced Fusion Buffer without Negotiation
每轮varience计算完了之后，会给server发数据，但是如何保证每台服务器上的数据顺序是正确的？
第一个服务器算完之后决定顺序，然后广播到每一台设备上
这里average的过程没有想明白
3）Proxy Parameter Servers
充分利用网络，让一台设备上启多个进程
A. Herring Workflow
第一轮：
each variable is assigned an order index in the first worker
variable被第一个worker配置上一个index，
第一轮计算结束后，index被广播到剩下的所有集群
顺序迭代：这六个顺序没理解，所以先机翻
step1:
当梯度在后向传递中变得可用时，它们被复制到平衡融合缓冲区（BFB）。当下一个融合缓冲区准备好时（属于该BFB的所有梯度都准备好了），woker进程使用MPI_Barrier来等待同一节点的其他GPU准备好相同的融合缓冲区。当特定的融合缓冲区在同一节点的所有GPU上准备就绪时，ncclReduceScatter被用来使用NVLinks对节点内的融合缓冲区进行平均。每个GPU获得融合缓冲区1/nGPU的平均输出，其中nGPU是节点内GPU的数量。
step2:
ReduceScattered融合缓冲区在GPU实例上，然后被复制到使用PCIe链接的CPU内存。由于每个GPU复制1/nGP U的缓冲区，用于复制的总带宽为用于复制的总带宽是nP CIE × bwP CIe，其中nPCIE等于PCIe链接的数量，bwPCIe是每个PCIe链接的带宽（大约12GB）。每个PCIe链接的带宽（在EC2 P3dn.24xlarge中约为12GBps）。
NCCL在节点中使用一个PCIe链接进行设备到主机的复制，另一个链接进行主机到设备的复制，这可能会这可能会使PCIe链接出现瓶颈。将所有的PCIe链接用于设备到主机和主机到设备的拷贝，有助于将梯度传输到CPU内存快nPCIE倍（对于EC2，nP CIE=4P3dn.24xlarge实例）。
第3步。在运行nServerProc服务器进程的服务器节点中，每个服务器进程每次从N/nServerProc工作进程中接收msglen字节，并将其放在一个共享内存区域中。在从所有worker收到BFB的一部分进入服务器节点后，一个叫做NC的不同进程对梯度进行平均，并向服务器进程发出信号。关于为什么我们在每个服务器节点中使用多个服务器进程，请查看第III-3节。
第4步。服务器进程将平均梯度送回给工作者。当收到平均梯度时，它们被复制到GPU，使用所有的PCIe链接，类似于步骤1。在这一步结束时，每个GPU拥有融合缓冲区的1/nGPUth的平均梯度。
第5步。当一个GPU收到1/nGPU的更新梯度时，其他GPU可能还没有收到他们那部分的结果。立即安排ncclAllGather可能会导致等待其他GPU获得他们的那部分结果。此外，请注意，一些梯度可能仍然在减少散射步骤中，在CUDA流中立即调度allgather会延迟这些梯度的减少散射操作，降低性能。为了防止这种情况，工作进程使用MPI_Barrier来等待所有BFB的ReduceScatter完成。一旦MPI_Barrier成功，ncclAllGather就会被调用，NVLinks被用来与节点上的所有GPU共享小数点全还原结果。
第6步。最后，所有GPU在融合缓冲区中都有平均的梯度。然后，这个结果被移交给框架（TensorFlow或PyTorch）
通过www.DeepL.com/Translator（免费版）翻译
哎，机器翻译之后更看不懂了
贴个图
四、实验
对比对象：allreduce方案，PS方案中horovod和BytePS
We use NCCL built with EFA support
BytePS does not support EFA
实验一 ps和allreduce都用EFA，聚合参数的时间对比
herring的结果是horovod的1/3，这个加速来自于EFA
实验二，吞吐量和扩展性
吞吐好衡量呢，
扩展性的问题：这里我们以单节点吞吐量为基础，基于单节点吞吐量计算扩展效率
实验三：BERT training
实验四：不同GPU数量对训练bert的加速
实验五：花费实验
五、消融研究
EFA有什么用？
EFA将大的tensor切分成小包，使得可以多路径到达，避免了HOL问题
proxy的影响
增加了对网络带宽的利用，加速了训练速度
六、结论
Takeaway，在网络角度加速训练。
