TensorFlow架构与设计:概述

TensorFlow是什么?

TensorFlow基于数据流图,用于大规模分布式数值计算的开源框架。节点表示某种抽象的计算,边表示节点之间相互联系的张量。

TensorFlow支持各种异构的平台,支持CPU/GPU,服务器,移动设备,具有良好的跨平台的特性;TensorFlow架构灵活,能够支持各种网络模型,具有良好的通用性;此外,TensorFlow架构具有良好的可扩展性,对OP的扩展支持,Kernel特化方面表现出众。

系统概述

TensorFlow的系统结构以C API为界,将整个系统分为「前端」和「后端」两个子系统:

  • 前端系统:提供编程模型,负责构造计算图;
  • 后端系统:提供运行时环境,负责执行计算图。

如上图所示,重点关注系统中如下4个基本组件,它们是系统分布式运行机制的核心。

Client

Client是前端系统的主要组成部分,它是一个支持多语言的编程环境。它提供基于计算图的编程模型,方便用户构造各种复杂的计算图,实现各种形式的模型设计。

Client通过Session为桥梁,连接TensorFlow后端的「运行时」,并启动计算图的执行过程。

Distributed Master

在分布式的运行时环境中,Distributed Master根据Session.runFetching(需要的到的参数,例a=1+2,a就是feching)参数,从计算图中反向遍历,找到所依赖的「最小子图」。

然后,Distributed Master负责将该「子图」再次分裂为多个「子图片段」,以便在不同的进程和设备上运行这些「子图片段」。

最后,Distributed Master将这些「子图片段」派发给Work Service;随后Work Service启动「子图片段」的执行过程。

Worker Service

对于每以个任务,TensorFlow都将启动一个Worker ServiceWorker Service将按照计算图中节点之间的依赖关系,根据当前的可用的硬件环境(GPU/CPU),调用OPKernel实现完成OP的运算(一种典型的多态实现技术)。

另外,Worker Service还要负责将OP运算的结果发送到其他的Work Service;或者接受来自其他Worker Service发送给它的OP运算的结果。

Kernel Implements

KernelOP在某种硬件设备的特定实现,它负责执行OP的运算。

组件交互

如上图所示,假设存在两个任务:

  • /job:ps/task:0: 负责模型参数的存储和更新
  • /job:worker/task:0: 负责模型的训练或推理

客户端

Client基于TensorFlow的编程接口,构造计算图。目前,TensorFlow主流支持PythonC++的编程接口,并对其他编程语言接口的支持日益完善。

此时,TensorFlow并未执行任何计算。直至建立Session会话,并以Session为桥梁,建立Client与后端运行时的通道,将Protobuf格式的GraphDef发送至Distributed Master

也就是说,当ClientOP结果进行求值时,将触发Distributed Master的计算图的执行过程。

如下图所示,Client构建了一个简单计算图。它首先将wx进行矩阵相乘,再与截距b按位相加,最后更新至s

Distributed Master

在分布式的运行时环境中,Distributed Master根据Session.runFetching参数,从计算图中反向遍历,找到所依赖的最小子图

然后Distributed Master负责将该子图再次分裂为多个「子图片段」,以便在不同的进程和设备上运行这些「子图片段」。

最后,Distributed Master将这些图片段派发给Work Service。随后Work Service启动「本地子图」的执行过程。

Distributed Master将会缓存「子图片段」,以便后续执行过程重复使用这些「子图片段」,避免重复计算。

如上图所示,Distributed Master开始执行计算子图。在执行之前,Distributed Master会实施一系列优化技术,例如「公共表达式消除」,「常量折叠」等。随后,Distributed Master负责任务集的协同,执行优化后的计算子图。

子图片段

如上图所示,存在一种合理的「子图片段」划分算法。Distributed Master将模型参数相关的OP进行分组,并放置在PS任务上。其他OP则划分为另外一组,放置在Worker任务上执行。

SEND/RECV节点

如上图所示,如果计算图的边被任务节点分割,Distributed Master将负责将该边进行分裂,在两个分布式任务之间插入SENDRECV节点,实现数据的传递。

随后,Distributed Master将「子图片段」派发给相应的任务中执行,在Worker Service成为「本地子图」,它负责执行该子图的上的OP

Worker Service

对于每个任务,都将存在相应的Worker Service,它主要负责如下3个方面的职责:

  • 处理来自Master的请求;
  • 调度OPKernel实现,执行本地子图;
  • 协同任务之间的数据通信。

Worker Service派发OP到本地设备,执行Kernel的特定实现。它将尽最大可能地利用多CPU/GPU的处理能力,并发地执行Kernel实现。

另外,TensorFlow根据设备类型,对于设备间的SEND/RECV节点进行特化实现:

  • 使用cudaMemcpyAsync的API实现本地CPUGPU设备的数据传输;
  • 对于本地的GPU之间则使用端到端的DMA,避免了跨host CPU昂贵的拷贝过程。

对于任务之间的数据传递,TensorFlow支持多协议,主要包括:

  • gRPC over TCP
  • RDMA over Converged Ethernet

Kernel Implements

TensorFlow的运行时包含200多个标准的OP,包括数值计算,多维数组操作,控制流,状态管理等。每一个OP根据设备类型都会存在一个优化了的Kernel实现。在运行时,运行时根据本地设备的类型,为OP选择特定的Kernel实现,完成该OP的计算。

其中,大多数Kernel基于Eigen::Tensor实现。Eigen::Tensor是一个使用C++模板技术,为多核CPU/GPU生成高效的并发代码。但是,TensorFlow也可以灵活地直接使用cuDNN实现更高效的Kernel

此外,TensorFlow实现了矢量化技术,使得在移动设备,及其满足高吞吐量,以数据为中心的应用需求,实现更高效的推理。

如果对于复合OP的子计算过程很难表示,或执行效率低下,TensorFlow甚至支持更高效的Kernle实现的注册,其扩展性表现相当优越。

技术栈

最后,按照TensorFlow的软件层次,通过一张表格罗列TensorFlow的技术栈,以便更清晰地对上述内容做一个简单回顾。

原文地址:https://www.cnblogs.com/callyblog/p/8367418.html

时间: 2024-10-08 13:43:15

TensorFlow架构与设计:概述的相关文章

Android存储系统的架构与设计

一.概述 本文讲述Android存储系统的架构与设计,基于Android 6.0的源码,涉及到最为核心的便是MountService和Vold这两个模块以及之间的交互.为了缩减篇幅,只展示部分核心代码. MountService:Android Binder服务端,运行在system_server进程,用于跟Vold进行消息通信,比如MountService向Vold发送挂载SD卡的命令,或者接收到来自Vold的外设热插拔事件.MountService作为Binder服务端,那么相应的Binde

Java开源生鲜电商平台-Java后端生成Token架构与设计详解(源码可下载)

Java开源生鲜电商平台-Java后端生成Token架构与设计详解(源码可下载) 目的:Java开源生鲜电商平台-Java后端生成Token目的是为了用于校验客户端,防止重复提交. 技术选型:用开源的JWT架构. 1.概述:在web项目中,服务端和前端经常需要交互数据,有的时候由于网络相应慢,客户端在提交某些敏感数据(比如按照正常的业务逻辑,此份数据只能保存一份)时,如果前端多次点击提交按钮会导致提交多份数据,这种情况我们是要防止发生的. 2.解决方法: ①前端处理:在提交之后通过js立即将按钮

微服务架构的设计和实践-培训感悟

这两天(4月8号,9号)我有幸参加了极客邦的培训课程-微服务架构的设计和实践,能够面对面倾听58架构师-孙玄的亲身授课,个人也是感到非常的荣幸.两天的时间,来回于广州和深圳,虽然不能说自己的技术有了一个质的提升,但至少也是一次很好的交流体现,这一趟不白走! 身为一个技术小白(虽然个人也有四年的开发经验,但大多的技术只是知其然而不知其所以然,而且接触面太狭隘),此次学习最明显的感受是,如果你只会写软件代码,了解与某种语言相关的语法,框架以及架构包括技术,那你肯定会"死的很惨".作为软件行

大规模分布式系统架构与设计实战摘录

大规模分布式系统架构与设计实战摘录 一位网站资深架构师曾经说过:在互联网公司呆一年,相当于在传统软件公司呆三年. 他的意思大概是在互联网公司一年遇到的问题比传统软件公司三年遇到的问题还多.而且 随着网站业务的快速发展,问题也层出不穷,没年遇到的问题都不同. 遇到问题,解决问 题,经历了这个过程,技术才能升华,人和技术才能融为一体,才知道什么技术是真正有 用的,什么技术是花拳绣腿.大型网站的技术本质都很简单,掌握起来也不难.大型网站 的架构师最有价值的地发不在于他们掌握了多少技术,而在于他们经历多

.NET应用架构设计—重新认识分层架构(现代企业级应用分层架构核心设计要素)

阅读目录: 1.背景介绍 2.简要回顾下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,很好的隔离静态数据) 4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型 5.两种独立业务层职责设计方法(可以根据具体业务要求来搭

App 后台架构设计方案 设计思想与最佳实践

转载请注明出处:http://blog.csdn.net/smartbetter/article/details/53933096 做App做的久了,就想研究一下与之相关的App后台,发现也是蛮有趣的.App后台的两个重要作用就是 远程存储数据 和 消息中转.这里面的知识体系也是相当复杂,做好一个App后台也是需要长期锤炼的.本篇文章从 App 后台架构 的角度介绍.好了,下面进入正题: 说起架构,我们先看一下何为架构,百度百科是这样说的:架构,又名软件架构,是有关软件整体结构与组件的抽象描述,

从MVC框架看MVC架构的设计

转自:http://blog.csdn.net/bluishglc/article/details/6690693 从MVC框架看MVC架构的设计 尽管MVC早已不是什么新鲜话题了,但是从近些年一些优秀MVC框架的设计上,我们还是会发现MVC在架构设计上的一些新亮点.本文将对传统MVC架构中的一些弊病进行解读,了解一些优秀MVC框架是如何化解这些问题的,揭示其中所折射出的设计思想与设计理念. MVC回顾   作为一种经典到不能再经典的架构模式,MVC的成功有其必然的道理,这个道理不同的人会有不同

hadoop分布式架构和设计

引言 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统.它和现有的分布式文件系统有很多共同点.但同时,它和其他的分布式文件系统的区别也是很明显的.HDFS是一个高度容错性的系统,适合部署在廉价的机器上.HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用.HDFS放宽了一部分POSIX约束,来实现流式读取文件系统数据的目的.HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的.HDFS是A

JNI设计概述

1.概述 本章概述JNI的设计.必要的时候,也会给出底层技术的实现的动机.设计概述讲解了JNI特有的关键概念:JNIEnv接口指针,局部和全局引用,域和方法ID等.讲述这些技术实现动机是为了帮助读者理解JNI设计的权衡取舍.在某些时刻,我们将会讨论某些特性可能的实现方式.这样的讨论的目的不是要提出一个切实可行的实施策略,而是要阐明微妙的语义问题. 桥接不同语言的编程接口的概念并不是新鲜事物.举例来说,c语言可以调用FORTRAN或者汇编所编写的函数.同样的,编程语言的实现如Lisp和Smallt