天枢大规模分布式训练评测报告

[Zailiang]

天枢大规模分布式训练评测报告

1. 简介

本报告比较了多个深度学习框架在多个经典的深度学习模型训练任务上分布式训练的吞吐率、加速比、硬件使用率（如：GPU、CPU、内存、硬盘、网络等）。测试均采用相同的数据集、相同的硬件环境和算法，仅比较各个框架之间的速度差异。

结果表明（期望结果）：

• 分布式性能：在20台以上虚机或服务器组合时，线性加速比达到80%以上，与业界已有框架相比有突出的优势； 

• 资源利用率：大规模分布式训练计算时，在各大典型任务上训练的硬件资源平均利用率不低于80%。 

2. 背景介绍

2.1 评测平台

本次评测基于基于之江天枢平台，以下简要介绍平台使用流程：

1）平台地址：zjlab.dubhe.club

• 测试账号（详询俞再亮）

• 

2）选择资源总量（可扩容）

• 当前可支持 1机1卡 -> 4机32卡

  

• 单节点详细配置（单节点上限 8 卡）

• • Tesla V100S-PCIE-32GB x 8

  • Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz

• • Memory 754G

  • Ubuntu 18.04.5 LTS (GNU/Linux 4.4.0-142-generic x86_64)

• • CUDA Version: 11.1, Driver Version: 460.73.01

  • nvidia-smi topo -m

    

2.2 评测框架

本次评测包含了4个框架：

1. OneFlow

2. TensorFlow 1.x & 2.x

3. PyTorch

4. PaddlePaddle

其中 TensorFlow 1.x、PyTorch、MXNet采用的是NVIDIA深度优化后的版本，性能测试在NGC 20.03 镜像中复现。其余框架的性能测试在相同的物理环境中复现。

各个框架对应的模型训练脚本，从该框架的官方模型库中选取，或者从NVIDIA- DeepLearningExamples 仓库中选取。

2.3 评测模型

本次评测基于以上评测框架，选择了两个经典主流的深度学习模型：

1） ResNet-50 v1.5

2） BERT-Base

其中ResNet-50是计算机视觉（Computer Version）领域最主流的深度学习模型，而BERT是自然语言处理（Natural Language Processing）领域的进行预训练的主流模型。

同时为了验证OneFlow框架的易用性以及可拓展性，基于OneFlow单独测试了在人脸识别、大规模预训练、点击率预估任务中的经典的深度学习模型：

1）InsightFace

2）Wise & Deep

3）GPT2

2.4 评测环境

为保证能更好地测试框架本身的性能好坏，做到公平公正，本次测评所有的测试均在相同的物理集群中测试，使用相同的软件环境等。

测试环境共有1000张V100 GPU显卡。具体的硬件和软件配置描述如下（根据实验设备实际情况填写，包括型号、大小、速度、版本等）：

• 显卡参数

• 通信设备

• CPU参数

• 内存大小

• 系统版本

• CUDA版本

• nvidia-smi topo -m

2.5 评测配置

针对每个框架的每个模型，我们都测试了其分布式环境下的吞吐率，包含了不同的batch size、是否经过XLA优化加速、是否使用自动混合精度训练。下面简要介绍一下相关概念：

2.5.1 Batch Size

在本测试报告中，batch size表示深度学习训练过程中每个设备（GPU/卡）上的样例个数。简称bsz（batch size per GPU）。特别地，使用global batch size（global bsz）表示表示深度学习训练过程中所有设备（GPUs）上的样例个数。

由于各个深度学习框架的显存管理策略不同，内存优化程度也不一样，所以对于相同的深度学习模型，各个框架在同样显存大小的GPU上所能支持的最大batch size是不同的。通常来说，batch size越大，则性能评测结果越好。

2.5.2 XLA

XLA (Accelerated Linear Algebra)是一种深度学习编译器，可以在不改变源码的情况下进行线性代数加速。针对支持XLA的深度学习框架我们也会测试其开启或关闭状态下的性能表现。

2.5.3 AMP 自动混合精度

AMP(Automatic Mixed Precision) 自动混合精度，在GPU上可以加速训练过程，与Float32精度相比，AMP在某些GPU上可以做到3倍左右的速度提升。我们对支持AMP的深度学习框架会测试其开启或关闭AMP的性能表现。

2.6 评测规则

根据2.5小节介绍的评测配置，针对每个框架每个模型的一个测试（each test case），我们都会遍历如下可能的参数：

1） 机器数（1，2，4，8，16，32，64，125），GPU数（1，8，16，32，64，128，256，512，1000）

2） 每个设备上的batch size

3） 是否开启XLA

4） 是否开启AMP

注：

• 125和1000分别为此次测评的最大机器数和最多GPU数。

• 针对每个框架的每次性能测试，我们至少测试了 1机1卡、1机8卡、2机16卡、4机32卡直到64机512卡这些情况。用于评价各个框架在分布式训练情况下的横向扩展能力。

• 针对此次测评，我们会重复几次（5-7次），并选取这几次测试的中位数作为实际的测试结果。测试结果选取规则尽可能的屏蔽掉随机因素的干扰，使得测试结果接近真实值。

2.7 评测指标

我们选取吞吐率（throughput）、加速比（speedup）、硬件使用率（如：GPU、CPU、内存、硬盘、网络）等作为评测指标。

吞吐率表示了深度学习框架的处理速度，吞吐率越高，则训练一个深度学习模型所需的时间越短，深度学习框架的性能就越高。加速比表示了深度学习框架多机多卡的扩展性，加速比越高，则额外增加一个硬件设备所带来的收益就越高，深度学习框架的多机扩展性就越好。硬件使用率表示了深度学习框架的资源利用效率，数值越大，深度学习框架的性能就越高。

2.7.1 吞吐率

吞吐率表示训练过程中深度学习框架每秒处理的样例个数。对于图片分类任务而言，表示每秒处理多少张图片（images/sec）；对于自然语言处理任务而言，表示每秒处理多少个句子（sentences/sec）。

为了得到连续且稳定的吞吐率，我们会过滤掉训练一开始的几个step。在实际测试中，一般我们过滤了前20个step，并选取后续100个step的均值计算吞吐率。（有些框架在有些训练模型上的log是按照100的倍数输出的，这时我们会过滤掉前100个step，选取后面几百个step计算均值。）

2.7.2 加速比

通过加速比，可测试出深度学习框架在分布式训练环境下的横向扩展能力。加速比是针对该框架在某一分布式配置下（如n台机器，共m个设备）的吞吐率与该框架在相同配置下（相同的bsz per GPU，相同的参数）单机单卡的吞吐率的比值。理想情况下，加速比为m（m>1），但每个框架都只能尽可能接近m，而无法达到和超过m。

2.7.3 硬件使用率

通过硬件使用率，特别是GPU、CPU、内存、硬盘、网络的使用率。在实际测试中，我们取阶段性step（每阶段的选择参考2.7.1）硬件使用率的平均值。该数值越高，说明深度学习框架的效率越高，资源调度越优化。

3. ResNet-50 v1.5 性能测试

3.1 参与评测的各个框架和模型库介绍

参与本次评测的框架、版本、模型库、以及额外特性如表3-1（该表格中的各个版本需要再确认）所示：

​

表 3-1 参与ResNet50-v1.5 性能评测的各个框架介绍

​

Framework	Version	Docker From	DNN Model Sources	Features
OneFlow	0.*.0	-	OneFlow-Benchmark	-
NGC MXNet	1.6.0	nvcr.io/nvidia/mxnet:20.03-py3	DeepLearningExamples/MxNet	DALI+Horovod
NGC TensorFlow 1.x	1.15.2	nvcr.io/nvidia/tensorflow:20.03-tf1-py3	DeepLearningExamples/TensorFLow	DALI+Horovod+XLA
NGC PyTorch	1.5.0a0+8f84ded	nvcr.io/nvidia/pytorch:20.03-py3	DeepLearningExamples/PyTorch	DALI+APEX
MXNet	1.6.0	-	gluon-cv	Horovod
TensorFlow 2.x	2.3.0	-	TensorFlow-models	-
PyTorch	1.6.0	-	pytorch/examples	-
PaddlePaddle	1.8.3.post107	-	PaddleCV	DALI

8. 问题

• 【注】的内容需要根据具体实验情况进行修改

• GPT2实验中不同并行模式的参数根据具体实验情况修改

• 耗时（latency）需要在每个实验中增加吗？（目前在Wise & Deep、GPT2有）

[ShawnXuan]

使用ansible进行oneflow分布式训练

之前的DLPerf中使用了shell脚本通过ssh进行oneflow分布式训练，DLPerf关注性能，并且根据不同条件需要测试几十、几百、上千个测试案例，自动化测试、可回溯可复现是测试的基本要求。Ansible是一个大规模构建和运维 IT 自动化平台（工具），使用Ansible可以简化和自动化这些oneflow分布式训练测试。

inventory 文件

Ansible可同时操作属于一个组的多台主机，组和主机之间的关系通过 inventory 文件配置. 默认的文件路径为 /etc/ansible/hosts，除默认文件外,你还可以同时使用或者指定其他 inventory 文件。根据DLPerf的需求，我们的 inventory 文件按照节点数进行分组，组名以节点数为区分，例子如下：

[hosts_1]
10.244.111.4

[hosts_2]
10.244.111.4
10.244.1.14

[hosts_4]
10.244.111.4
10.244.1.14
10.244.1.15
10.244.1.16

其中hosts_*中的*指代节点数，方便选取使用。

自动化训练脚本

结合测试的需求，对下面的脚本进行说明。

脚本的主体是4重循环，每一重循环都代表了测试的一种需求，从外到内分别是：

1. for amp in 0 1代表了是否打开混合精度进行测试
2. for bsz in ${bsz_list[@]}因为混合精度的开关会影响显存使用，进而影响最大batch size，所以设置了不同的batch size列表进行测试
3. for (( i=0; i<$len; i++ ))我们会在不同的资源条件下进行测试，比如单机单卡、4机8卡（共计32卡）等等，所以定义了两个list用来表示希望测试的规模，num_nodes_list代表了将采用多少台服务器进行测试，num_gpus_list表示每台服务器有几块GPU卡。这两个list的长度必须一样，可以通过同时修改这两个list来确定测试的规模
4. for (( j=0; j<$REPEAT_TIMES; j++ ))每一个测试都可以重复多次，REPEAT_TIMES定义了重复的次数。

脚本的核心是命令cmd的生成，也就是给ansible命令设置参数然后运行，说明如下：

• hosts_$num_nodes表示要选取的节点组的名称，组的定义就在前面的inventory文件中
• -m shell表示选择的是shell 模块，后面的-a是shell模块将使用的参数
• chdir=${SHELL_DIR}指定了shell命令运行的初始位置
• "bash local_train.sh ${num_nodes} ${num_gpus} ${bsz} ${amp} ${j}"我们单独定义了一个local_train.sh脚本，该脚本的运行需要传入节点数、gpu数、批次大小等参数，而这些参数就是前面的各重循环确定的。

#ansible_launch.sh

REPEAT_TIMES=7
SHELL_DIR=/workspace/git-repos/DLPerf/OneFlow/Classification/ConvNets/resnet50v1.5

export PYTHONUNBUFFERED=1

declare -a num_nodes_list=(1 1 2 4)
declare -a num_gpus_list=(1 8 8 8)

len=${#num_nodes_list[@]}

for amp in 0 1
do
    if [[ $amp -eq 1 ]]; then
        declare -a bsz_list=(64 128 256)
    else
        declare -a bsz_list=(32 64 128)
    fi

    for bsz in ${bsz_list[@]}
    do
        for (( i=0; i<$len; i++ ))
        do
            num_nodes=${num_nodes_list[$i]}
            num_gpus=${num_gpus_list[$i]}

            for (( j=0; j<$REPEAT_TIMES; j++ ))
            do
                cmd="ansible hosts_$num_nodes -m shell "
	              cmd+="-a \""
                cmd+="chdir=${SHELL_DIR} "
                cmd+="bash local_train.sh ${num_nodes} ${num_gpus} ${bsz} ${amp} ${j}"
                cmd+=\"
                echo $cmd
                eval $cmd
                #sleep 130s
            done
        done
    done
done

注：

1. 目前脚本在DLPerf的dubhe_dist_eval分支中，还没有合并
2. 脚本以resent50为例，bert或者其他模型，需要恰当的修改bsz_list和local_train.sh文件
3. local_train.sh中需要处理日志
4. ansible支持playbook的方式运行，playbook可以定义多个task，不过考虑到目前的需求，利用多重循环的方式代码更少
5. 多重循环之间可以交换次序，比如把repeat放到最外层，这样同样参数的多次测试就会被拉开了测

TODO:

• 日志自动化处理
• bert的local_train.sh脚本