paddle v2 api 支持分布式训练

[jacquesqiao]

现状

目前的v2 api只支持单机执行，而分布式任务依然使用以前的paddle train xxx的方式运行，启动trainer/ps 二进制，读取trainer_conf.py，然后通过data_provider读取数据进行训练。

需求

需要做一下升级，即在mpi node上通过python xxx.py的方式启动trainer进行训练，并且通过python的v2 api驱动整个训练进程。

需要做的点

1. 目前v2中的trainer只支持单机的gradient machine，所以现在需要做到能支持多机的gradient machine，接受合适的参数启动训练。
2. 修改之前的mpi提交程序receiver，切换成启动python版本的trainer和ps。
3. 之前的日志输出，也需要整理并兼容，方便调试。

[jacquesqiao]

#1680 和这个有一点关联

[typhoonzero]

初步的想法，求拍砖。
对于通用的MPI提交方式，可以由paddle API直接调用q_sub MPI client 提交任务。提交MPI集群的接口需要完成：

1. 寻找MPI client
2. 准备任务目录和配置文件
3. 提交
4. 获取日志

[Yancey1989]

我觉得会有两种路子：

1. 沿用receiver的思路（新reciver暂称为receiverv2），python的dist api调用receiverv2提交任务（维护只更新receiver，方便升级）
2. mpi client封装在paddle的dist api里（升级麻烦，需要用户升级paddle的package）

[jacquesqiao]

paddle集群管理(mpi/k8s)方案前置工作

1. 调研清楚目前paddle receiver的工作机制并分享。 @gongweibao @typhoonzero
2. python api支持分布式训练并分享。 @jacquesqiao
3. 调查清楚google cloud ml和其他类似服务的集群任务提交方式并分享。 @Yancey1989 @typhoonzero

[typhoonzero]

在k8s上启动一个测试用的MPI集群：

参考内容：https://hub.docker.com/r/dispel4py/docker.openmpi/

• 启动一个head Pod（使用了Deployment启动1个replica）:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mpi-header
  labels:
    app: mpi-header
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: mpi-header
    spec:
      containers:
      - image: dispel4py/docker.openmpi
        name : mpi-header
        resources:
          limits:
            cpu: 500m
            memory: 2Gi
          requests:
            cpu: 500m
            memory: 2Gi
        ports:
        - containerPort: 22

• 启动一组mpi-node，可以在resource下面修改配额的大小：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mpi-nodes
  labels:
    app: mpi-nodes
spec:
  replicas: 8
  template:
    metadata:
      labels:
        app: mpi-nodes
    spec:
      containers:
      - image: dispel4py/docker.openmpi
        name : mpi-header
        resources:
          limits:
            cpu: 500m
            memory: 2Gi
          requests:
            cpu: 500m
            memory: 2Gi
        ports:
        - containerPort: 22

• 使用ssh登录到head容器中：

  先找到head启动的IP地址：kubectl get po -o wide

git clone https://github.com/dispel4py/docker.openmpi.git
cd docker.openmpi
chmod 400 ssh/id_rsa.mpi
ssh -i ssh/id_rsa.mpi tutorial@[head的地址]

• 找到所有的mpi-node:

kubectl get po -a -o wide | grep mpi-nodes | awk '{print $6}' > machines

然后把`machines`文件scp拷贝到head容器中

• 提交mpi任务：

mpiexec -hostfile machines -n 16 python helloworld.py 

[moting9]

简单调研过enable paddlepaddle 运行在HPC/ mpi的环境。

1. 基于mpirun 去调度pserver ptrainer
   =========================
   pserver/ptrainer 进程能在两台测试节点上启动， 但是通信hang住了，具体还没有进一步debug

mpirun -n 2 -ppn 1 -machinefile hosts paddle pserver --num_gradient_servers=2 --nics=eno3 --port=7164 --ports_num=1 --ports_num_for_sparse=0 --comment=paddle_process_by_paddle

mpirun -n 2 -ppn 1 -machinefile hosts paddle train --num_gradient_servers=2 --nics=eno3 --port=7164 --ports_num=1 --comment=paddle_process_by_paddle --pservers=192.168.10.21,192.168.10.22 --ports_num_for_sparse=0 --config=./vgg_16_cifar.py --trainer_count=4 --use_gpu=0 --num_passes=1 --save_dir=./cifar_vgg_model --log_period=10 --dot_period=10 --saving_period=1 --local=0 --trainer_id=1

2. 在socket 通信基础上增加mpi 通信机制
   目前的socket 是基于tcp/rdma 接口，但是在HPC领域， IB（infiniband)/OPA(Omni-patch fabric arch)链路提供了更高的速度， MVAPICH2/OpenMPI/Intel MPI 这些library 能绕过 tcp 层，直接调用网络设备提供商提供的library 获得更好的网速。
   能否在socket 通信基础上 增加mpi 通信的接口。

此外还有一些问题：
snapshot 是否 只保留 在rank 0 的根节点， resume training的场景如何处理，是否需要把snapshot dispatch 到各个训练节点。

[Yancey1989]

FROM @moting9

snapshot 是否 只保留 在rank 0 的根节点

snapshot最好存储在一个分布式的存储引擎，有且不限于以下两点的原因：

• 保证snapshot数据的高可用性
• 实际集群训练中，节点由于意外情况需要重启时，不确定会启在哪个节点上。

resume training的场景如何处理，是否需要把snapshot dispatch 到各个训练节点。

实际上resume traininig会包含一系列的容错性处理，包括master,trainner,parameter server等等，snapshot是parameter server的一种容错机制。有一些comment在：#1696 (comment)

更多的关于集群训练design doc在 #1696 中，欢迎comment：）

[Yancey1989]

简单调研了一下TensorFlow On Google Cloud相关的操作流程

• 环境要求

  需要在本地安装Google Cloud SDK以及TensorFlow的package，如果不想安装SDK也可以使用Google Cloud Shell。

• 准备训练程序以及依赖包

  开发基于TensorFlow的应用，用户可以只需关心如何定义网络结构训练自己的模型，而不需要关心集群的环境等问题。

• 数据存储

  基于Google Cloud的训练，数据要存储在Google Cloud Storage上，并且保证Google ML Engine拥有相应的权限。

• 执行训练任务

  通过Google Cloud SDK中的ml-engine模块，可以提交本地或是云端的训练任务。执行本地任务的命令类似于:gcloud ml-engine local ...，提交云端任务：gcloud ml-engine jobs submit training ...。
  大致的结构如下：

• 提交到Google Cloud进行集群训练

  训练代码不需要修改，通过gcloud的scale-tier参数指定一个集群规模，来执行分布式的训练任务，命令类似于：gcloud ml-engine jobs submit training --scale-tier STANDARD_1 ...。集群会为每个训练任务分配多个节点，对于每个节点：

  • ML Engine会准备一个标准的Image（不清楚虚拟机还是Container）来运行用户提交的job
  • Load用户开发的训练程序并使用pip进行安装
  • 安装其他用户指定的依赖包

  多个节点组成一个集群，每个节点被称为一个replic并被分为以下三种角色：

  • master：负责管理其他replic，并且将job的状态汇报给ML Engine。（PS：还不了解master的实现细节，猜测就是控制worker和parmeter server数量以及启停的）
  • workers：负责执行用户定义的训练过程
  • parameter servers： 由一个或多个replic组成，每个parameter server会保存一部分parameter shard，workers会共享所有的parameter shard。
    worker和parmeter的概念参考：https://static.googleusercontent.com/media/research.google.com/en//archive/large_deep_networks_nips2012.pdf

• 大致结构如图：

• 其他：

  1. 使用Tensorboard可以将训练过程可视化。
  2. 无论本地、云端以及云端的集群训练，均不需要开发者修改代码。觉得这点很重要，方便移植到不同的集群节点

• 参考

  • https://cloud.google.com/ml-engine/docs/how-tos/training-steps
  • https://cloud.google.com/ml-engine/docs/concepts/training-overview

[typhoonzero]

更新了一个简单示例程序演示在openmpi上运行分布式paddle训练： https://github.com/typhoonzero/paddle-openmpi

[jacquesqiao]

done