Tensorflow[架构流程]


1. tensorflow工作流程

如官网所示:
根据整体架构或者代码功能可以分为:


图1.1 tensorflow架构

如图所示,一层C的api接口将底层的核运行时部分与顶层的多语言接口分离开。
而根据整个的工作流程,又可以分为:

图1.2 不同系统组件之间的交互

而图1.2也是tensorflow整个工作的流程,其中主要分为四个部分:

1.1. 客户端client

  • 将整个计算过程转义成一个数据流graph
  • 通过session,将graph传递给master执行

ps:假设我们使用的是python作为客户端,则其中session文件在Anaconda3/lib/python3.6/site-packages/tensorflow/python/client/session.py

1.2. 分布式主节点Distributed Master

  • 基于用户传递给Session.run()中的参数来进行修剪整个完整的graph,提取其中特定subgraph;
  • 将上述subgraph划分成不同部分,并将其对应不同的进程和devices中;
  • 将上述划分的部分分布到worker services上;
  • 每个worker services执行其收到的graph块

1.3. 工作节点的服务Worker Services (one for each task)

  • 使用可用的硬件kernel(如cpu,gpu)计划执行接收到的graph块表示的计算部分;
  • 与其他work services相互发送和接收计算结果

1.4. 核的实现Kernel Implementations

  • 执行graph操作的计算部分

现在回到图1.2。其中的"/job:worker/task:0" 和"/job:ps/task:0" ,都是worker services上执行的任务。

  • "PS"表示parameter server:一个task负责存储和更新模型的参数
  • 其他worker会发送他们迭代优化的参数给PS。

当然如果在单机环境下,上述PS和worker不是必须的,不过如果是分布式训练,这种模式就很常见了。而且上述的 "Distributed Master","Worker Service"只存在于分布式tensorflow中,对于单进程的tensorflow(也就是单机版),一个特定的session就负责了Distributed Master的任何事情,且其自己负责本机的多进程或者说多devices之间的数据交互。

下面,通过一个graph例子详细的介绍下tensorflow的核心模块。

2 client

用户负责在client端编写tensorflow代码,以此行程一个计算graph。该程序可以直接通过底层API组成(如自己写每一层,每一个激活函数),或者使用google提供的如Estimators API等高阶API来完成整个NN的搭建。同时Tensorflow支持多种client端的语言,如Python,CPP。当然随着tensorflow本身的趋于完善,CPP的接口也会越来越多,用于提供更快速的执行效率,当然python接口还是最全的。

client创建一个session,该会话会将graph的定义通过一个tf.GraphDefprotocol buffer 发送给distributed master。当在run中指定了某个graph中的node或者某些nodes,该函数会触发distributed master 去执行所需要的计算。
假如我们的graph如图2.1,就是一个\[s+= wx+b\]


图2.1 基于client端建立的graph

ps:tf.Session

3 Distributed master

该部分的主要工作为:

  • 基于client在run中指定的节点,从整个完整的graph中截取所需要的subgraph;
  • 将subgraph进一步划分成多个pieces,使其可以将每个piece映射到不同的执行设备上;
  • 将划分好的pieces缓存起来,以备后面的其他run的触发。

因为一旦到了master的部分,master可以总揽整个graph,所以它可以使用标准的优化方法去做优化,如公共子表达式消除(common subexpression elimination )和常量的绑定。然后给优化后的subgraphs或者说pieces定义不同的坐标,每个坐标对应了不同的执行设备如"/job:worker/task:0" 和"/job:ps/task:0"


图3.1 client通过运行run,将graph发送给master


图3.2 master将所需要执行的subgraph划分成参数更新和迭代优化两部分


图3.1 master在划分好的subgraph上添加所需要的发送和接收接口,为真实任务分发做准备


图3.1 master将每个piece通过分布式task分发到真实的节点去运行

Ps:MasterService API definition
Master interface

4 Worker Service

在每个task中,该部分负责:

  • 处理从master发来的请求;
  • 基于接收到的subgraph,规划所需要执行的kernels;
  • 与其他task直接进行消息交换

google优化了该部分,使其就算面对large graph,其负载也很低。当前的版本可以执行每秒上万个subgraphs,这使得大量副本可以进行快速的,细粒度的训练。该部分会将所需要执行的kernels指派给本地的devices,并尽可能的并行执行kernels。例如使用多CPU核或者多GPU流。

该部分还负责具体化源和目标device的Send和Recv操作:

  • 使用cudaMemcpAsync()来进行本地CPU和GPU设备之间的数据传输操作;
  • 使用点对点的DMA进行GPU之间的传输,以避免需要通过host CPU主内存进行数据传输的高代价

为了在tasks之间进行传输,tensorflow使用多种协议:

  • 基于TCP的gRPC;
  • 基于Converged Ethernet的RDMA

同时tensorflow也支持NVIDIA的NCCL库来为多GPU之间进行数据交互(tf.contrib.nccl)


图4.1 worker端接收到的piece;对应的接收发送接口;task之间的交互

ps: WorkerService API definition
Worker interface
Remote rendezvous (for Send and Recv implementations)

5 Kernel Implementations

该运行时包含了超过200个标准操作,其中涉及数学,数组,控制流,和状态管理等操作。每个操作都有对应不同devices的优化后的实现。其中许多kernel是通过使用了CPP的模版的Eigen:Tensor去实现的,主要是为了能生成可以在多CPU和多GPU上运行的高效并行代码。不过如果cuDNN中已经实现了一些kernel,那么就用cuDNN的接口。同时google还实现了quantization,可以更快速的基于移动设备和高吞吐量的数据中心应用进行inference,并且可以使用低精确度的gemmlowp用于加速量化计算。

如果用户发现很难去将子计算组合成一个大计算,或者说组合后发现效率很低,那么用户可以通过注册额外的cpp编写的kernel来提供一个新的接口。例如,可以自己将一些性能敏感的操作如ReLU和Sigmoid等函数(或者其对应的梯度等)进行融合。XLA提供了一个实验性质的自动kernel融合实现

ps:OpKernel interface

参考资料:

猜你喜欢

转载自www.cnblogs.com/shouhuxianjian/p/9107539.html