数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

深度学习基础设施

深度学习是一门依据经验的科学,基础设施的质量,能够对深度学习的效果起到非常大的作用。幸运的是,如今的开源生态系统,能让任何人都搭建起优秀的深度学习基础设施。

在这篇文章中,我们将会讲述深度学习的工作方式,以及它所依赖的基础设施。

使用场景


一般情况下,深度学习的作用是着手去让一个想法生效,然后你再用这个想法去解决某个小问题。在这个时候,你要立刻进行大量的ad-hoc实验。理想情况下,你只需要SSH进一台机器,在屏幕中运行一段代码,然后在不到一个小时的时间里,就可以获得结果。

要想让这个模式起作用,通常情况下需要看到它在哪种情况下无法起作用,然后再去寻找解决这些限制的方式(和开发新软件系统差不多,你需要多次运行代码,了解它的表现情况)。

你需要从多个角度来审视深度学习的模式,才能真正的了解它在学习些什么。

在你证明了模式有效之后,你就需要扩大其规模,为其配备更大的数据集和更多的GPU。这个工作需要你付出巨大的精力,还要好几天的时间。

早期的研究过程不成架构,但是速度快;之后的研究过程则更加有条理,但是过程却很痛苦。然而,要想获得好的结果,你必须要经历这种痛苦。

基础设施


  • 软件


我们的大多数研究代码都是用Python写的。在GPU计算方面,我们主要使用TensorFlow(在一些特别的时候还会使用Theano)。而在CPU方面,除了TensorFlowTheano之外,我们还使用了Numpy。有的时候,研究人员还会在TensorFlow之上使用一些更高级别的框架,例如Keras。与大多数深度学习社区一样,我们使用的是Python 2.7版本。

  • 硬件

在理想状态下,让clusternode的数量翻倍,能够让runtime所需的时间减少一半。然而,在深度学习领域,很多GPU却并非如此。要想获得最好的性能,你就需要使用最好的GPU。我们还需要很多的CPU,用作模拟装置,加强学习环境,或者降低模块的规模。


AWS为我们贡献了很好的计算能力,我们使用它们来当做CPU实例,减少GPU的负担。我们需要自己的实体服务器,主要用来运行Titan X GPU。从长期来看,我们还需要一个混合云:在使用不同的GPU、互联连接时,它会发挥重要的作用,对于未来的深度学习来说非常重要。


  • 供给

我们使搭建基础设施的方式,类似许多公司对待产品的方式:它必须要展示一个简单的界面,可用性和功能性一样重要。我们使用了多种工具来管理所有服务器,并且尽可能用相同的方式对它们进行配置。

 

 

在设置AWS云资源(实例、网络路由、DNS记录等)时,我们使用了 Terraform。我们的云端和物理node运行的是 Ubuntu,并且使用用Chef进行配置的。所有的cluster都使用了非重叠IP范围,在接入公共互联网的时候,都使用了用户笔记本上的OpenVPN,以及物理node上的strongSwan(它扮演的是AWS Customer Gateways的角色)。

我们会储存人们的home目录、数据集、以及 NFS(实体硬件上)和EFS/S3AWS上)的结果。

  • 组织

很多时候,可扩展基础设施会让一些简单的事情变得复杂。因此我们为此付出了很多的经历,我们不断使用新的工具,让使用分布式use-case变得和本地use-case一样简单。

我们提供了一个SSH nodecluster用来完成ad-hoc实验,并且为物理和AWS node运行 Kubernetes。我们的cluster覆盖了3AWS区域。

Kubernetes要求每一个job都是一个Docker容器,这给我们提供了依赖隔绝和代码快照功能。然而,打造一个新的Docker容器会让研究者花费更多本来已经非常宝贵的时间,因此我们提供了一个工具,它可以将研究者笔记本中的代码转化为一张标准图像。

 

TensorBoard中的模式学习曲线

我们将Kubernetesflannel网络直接暴露在研究者的笔记本上,允许用户将无缝通过网络接入正在运行的job,这对于接入TensorBoard等检测服务来说非常实用。

kubernetes-ec2-autoscaler


我们的工作充满了突发性和各种难以预料的事情:一个原本只需要一个核心的实验突然需要1000个核心。例如,在几周的时间内,一个本来只需要一个Titan X的实验,变成了需要60Titan X的实验,然后突然又需要将近1600AWS GPU。因此,我们的云端基础设施需要能够动态调节Kubernetes node的能力。

 Auto Scaling群组中运行Kubernetes node很简单,但是很难正确管理这些群组的数量。在batch job提交之后,cluster就能马上知道它所需要的资源,并且直接对资源进行分配。(对比之下,AWSScaling Policies会逐渐的增加新node,知道满足对资源的需求,这种做法需要经过多次迭代)。另外,在终止它们以避免丢失in-flight job之前,cluster还需要drain node

在进行大规模的batch job时,我们总是会倾向于使用原始EC2,然而Kubernetes生态系统却能给我们带来很多价值:简单易用的工具、登录、检测、在运行的实例中对物理node进行拆分管理等等。准确的让Kubernetes完成自动规模化,比使用原始EC2重建整个生态系统要简单的多。

因此,我们推出了kubernetes-ec2-autoscaler,这是一个针对Kubernetes推出的对批处理进行了优化的规模化管理工具。在Kubernetes上,它扮演了普通的Pod的角色,而且只需要将你的worker node放在Auto Scaling群组中。

 

Kubernetes clusterLaunch配置

只有在pollKubernetes master的状态后,自动规模化工具才会生效,如果有额外的计算能力存在,它会耗干相关的node,并且最终终止它们。如果需要更多的资源,它会计算哪些服务器需要被创建,然后根据计算结果增加适量的Auto Scaling群组。

kubernetes-ec2-autoscaler会处理多个Auto Scaling群组、CPU之外的资源(内存和GPU),以及Job的细微限制(例如AWS区域和实例体积)。

另外,突发的工作量会导致Auto Scaling群组超时和错误,这是由于AWS并不提供无线的容量。在这些情况下,kubernetes-ec2-autoscaler会探测错误,并且向次要的AWS区域进行溢出。

我们的基础设施,正在为深度学习研究人员提供最大化的效率,让他们专注于科研。我们正在打造更多的工具,继续改善这个基础设施,并且将会在未来几周或几个月内将最新进展分享给所有人。


掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
深度学习基础设施
发布:2016-09-05

深度学习是一门依据经验的科学,基础设施的质量,能够对深度学习的效果起到非常大的作用。幸运的是,如今的开源生态系统,能让任何人都搭建起优秀的深度学习基础设施。

在这篇文章中,我们将会讲述深度学习的工作方式,以及它所依赖的基础设施。

使用场景


一般情况下,深度学习的作用是着手去让一个想法生效,然后你再用这个想法去解决某个小问题。在这个时候,你要立刻进行大量的ad-hoc实验。理想情况下,你只需要SSH进一台机器,在屏幕中运行一段代码,然后在不到一个小时的时间里,就可以获得结果。

要想让这个模式起作用,通常情况下需要看到它在哪种情况下无法起作用,然后再去寻找解决这些限制的方式(和开发新软件系统差不多,你需要多次运行代码,了解它的表现情况)。

你需要从多个角度来审视深度学习的模式,才能真正的了解它在学习些什么。

在你证明了模式有效之后,你就需要扩大其规模,为其配备更大的数据集和更多的GPU。这个工作需要你付出巨大的精力,还要好几天的时间。

早期的研究过程不成架构,但是速度快;之后的研究过程则更加有条理,但是过程却很痛苦。然而,要想获得好的结果,你必须要经历这种痛苦。

基础设施


  • 软件


我们的大多数研究代码都是用Python写的。在GPU计算方面,我们主要使用TensorFlow(在一些特别的时候还会使用Theano)。而在CPU方面,除了TensorFlowTheano之外,我们还使用了Numpy。有的时候,研究人员还会在TensorFlow之上使用一些更高级别的框架,例如Keras。与大多数深度学习社区一样,我们使用的是Python 2.7版本。

  • 硬件

在理想状态下,让clusternode的数量翻倍,能够让runtime所需的时间减少一半。然而,在深度学习领域,很多GPU却并非如此。要想获得最好的性能,你就需要使用最好的GPU。我们还需要很多的CPU,用作模拟装置,加强学习环境,或者降低模块的规模。


AWS为我们贡献了很好的计算能力,我们使用它们来当做CPU实例,减少GPU的负担。我们需要自己的实体服务器,主要用来运行Titan X GPU。从长期来看,我们还需要一个混合云:在使用不同的GPU、互联连接时,它会发挥重要的作用,对于未来的深度学习来说非常重要。


  • 供给

我们使搭建基础设施的方式,类似许多公司对待产品的方式:它必须要展示一个简单的界面,可用性和功能性一样重要。我们使用了多种工具来管理所有服务器,并且尽可能用相同的方式对它们进行配置。

 

 

在设置AWS云资源(实例、网络路由、DNS记录等)时,我们使用了 Terraform。我们的云端和物理node运行的是 Ubuntu,并且使用用Chef进行配置的。所有的cluster都使用了非重叠IP范围,在接入公共互联网的时候,都使用了用户笔记本上的OpenVPN,以及物理node上的strongSwan(它扮演的是AWS Customer Gateways的角色)。

我们会储存人们的home目录、数据集、以及 NFS(实体硬件上)和EFS/S3AWS上)的结果。

  • 组织

很多时候,可扩展基础设施会让一些简单的事情变得复杂。因此我们为此付出了很多的经历,我们不断使用新的工具,让使用分布式use-case变得和本地use-case一样简单。

我们提供了一个SSH nodecluster用来完成ad-hoc实验,并且为物理和AWS node运行 Kubernetes。我们的cluster覆盖了3AWS区域。

Kubernetes要求每一个job都是一个Docker容器,这给我们提供了依赖隔绝和代码快照功能。然而,打造一个新的Docker容器会让研究者花费更多本来已经非常宝贵的时间,因此我们提供了一个工具,它可以将研究者笔记本中的代码转化为一张标准图像。

 

TensorBoard中的模式学习曲线

我们将Kubernetesflannel网络直接暴露在研究者的笔记本上,允许用户将无缝通过网络接入正在运行的job,这对于接入TensorBoard等检测服务来说非常实用。

kubernetes-ec2-autoscaler


我们的工作充满了突发性和各种难以预料的事情:一个原本只需要一个核心的实验突然需要1000个核心。例如,在几周的时间内,一个本来只需要一个Titan X的实验,变成了需要60Titan X的实验,然后突然又需要将近1600AWS GPU。因此,我们的云端基础设施需要能够动态调节Kubernetes node的能力。

 Auto Scaling群组中运行Kubernetes node很简单,但是很难正确管理这些群组的数量。在batch job提交之后,cluster就能马上知道它所需要的资源,并且直接对资源进行分配。(对比之下,AWSScaling Policies会逐渐的增加新node,知道满足对资源的需求,这种做法需要经过多次迭代)。另外,在终止它们以避免丢失in-flight job之前,cluster还需要drain node

在进行大规模的batch job时,我们总是会倾向于使用原始EC2,然而Kubernetes生态系统却能给我们带来很多价值:简单易用的工具、登录、检测、在运行的实例中对物理node进行拆分管理等等。准确的让Kubernetes完成自动规模化,比使用原始EC2重建整个生态系统要简单的多。

因此,我们推出了kubernetes-ec2-autoscaler,这是一个针对Kubernetes推出的对批处理进行了优化的规模化管理工具。在Kubernetes上,它扮演了普通的Pod的角色,而且只需要将你的worker node放在Auto Scaling群组中。

 

Kubernetes clusterLaunch配置

只有在pollKubernetes master的状态后,自动规模化工具才会生效,如果有额外的计算能力存在,它会耗干相关的node,并且最终终止它们。如果需要更多的资源,它会计算哪些服务器需要被创建,然后根据计算结果增加适量的Auto Scaling群组。

kubernetes-ec2-autoscaler会处理多个Auto Scaling群组、CPU之外的资源(内存和GPU),以及Job的细微限制(例如AWS区域和实例体积)。

另外,突发的工作量会导致Auto Scaling群组超时和错误,这是由于AWS并不提供无线的容量。在这些情况下,kubernetes-ec2-autoscaler会探测错误,并且向次要的AWS区域进行溢出。

我们的基础设施,正在为深度学习研究人员提供最大化的效率,让他们专注于科研。我们正在打造更多的工具,继续改善这个基础设施,并且将会在未来几周或几个月内将最新进展分享给所有人。


电话 0512-88869195