在这篇文章中，我们将会讲述深度学习的工作方式，以及它所依赖的基础设施。
使用场景
一般情况下，深度学习的作用是着手去让一个想法生效，然后你再用这个想法去解决某个小问题。在这个时候，你要立刻进行大量的ad-hoc实验。理想情况下，你只需要SSH进一台机器，在屏幕中运行一段代码，然后在不到一个小时的时间里，就可以获得结果。
要想让这个模式起作用，通常情况下需要看到它在哪种情况下无法起作用，然后再去寻找解决这些限制的方式（和开发新软件系统差不多，你需要多次运行代码，了解它的表现情况）。
你需要从多个角度来审视深度学习的模式，才能真正的了解它在学习些什么。
在你证明了模式有效之后，你就需要扩大其规模，为其配备更大的数据集和更多的GPU。这个工作需要你付出巨大的精力，还要好几天的时间。
早期的研究过程不成架构，但是速度快；之后的研究过程则更加有条理，但是过程却很痛苦。然而，要想获得好的结果，你必须要经历这种痛苦。
基础设施
软件
我们的大多数研究代码都是用Python写的。在GPU计算方面，我们主要使用TensorFlow（在一些特别的时候还会使用Theano）。而在CPU方面，除了TensorFlow和Theano之外，我们还使用了Numpy。有的时候，研究人员还会在TensorFlow之上使用一些更高级别的框架，例如Keras。与大多数深度学习社区一样，我们使用的是Python 2.7版本。
硬件
在理想状态下，让cluster中node的数量翻倍，能够让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/S3（AWS上）的结果。
组织
很多时候，可扩展基础设施会让一些简单的事情变得复杂。因此我们为此付出了很多的经历，我们不断使用新的工具，让使用分布式use-case变得和本地use-case一样简单。
我们提供了一个SSH node的cluster用来完成ad-hoc实验，并且为物理和AWS node运行 Kubernetes。我们的cluster覆盖了3种AWS区域。
Kubernetes要求每一个job都是一个Docker容器，这给我们提供了依赖隔绝和代码快照功能。然而，打造一个新的Docker容器会让研究者花费更多本来已经非常宝贵的时间，因此我们提供了一个工具，它可以将研究者笔记本中的代码转化为一张标准图像。
TensorBoard中的模式学习曲线
我们将Kubernetes的flannel网络直接暴露在研究者的笔记本上，允许用户将无缝通过网络接入正在运行的job，这对于接入TensorBoard等检测服务来说非常实用。
kubernetes-ec2-autoscaler
我们的工作充满了突发性和各种难以预料的事情：一个原本只需要一个核心的实验突然需要1000个核心。例如，在几周的时间内，一个本来只需要一个Titan X的实验，变成了需要60个Titan X的实验，然后突然又需要将近1600个AWS GPU。因此，我们的云端基础设施需要能够动态调节Kubernetes node的能力。
在 Auto Scaling群组中运行Kubernetes node很简单，但是很难正确管理这些群组的数量。在batch job提交之后，cluster就能马上知道它所需要的资源，并且直接对资源进行分配。（对比之下，AWS的Scaling 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 cluster的Launch配置
只有在poll了Kubernetes master的状态后，自动规模化工具才会生效，如果有额外的计算能力存在，它会耗干相关的node，并且最终终止它们。如果需要更多的资源，它会计算哪些服务器需要被创建，然后根据计算结果增加适量的Auto Scaling群组。
kubernetes-ec2-autoscaler会处理多个Auto Scaling群组、CPU之外的资源（内存和GPU），以及Job的细微限制（例如AWS区域和实例体积）。
另外，突发的工作量会导致Auto Scaling群组超时和错误，这是由于AWS并不提供无线的容量。在这些情况下，kubernetes-ec2-autoscaler会探测错误，并且向次要的AWS区域进行溢出。
我们的基础设施，正在为深度学习研究人员提供最大化的效率，让他们专注于科研。我们正在打造更多的工具，继续改善这个基础设施，并且将会在未来几周或几个月内将最新进展分享给所有人。
转载自：SDK.cn
原 文：Infrastructure for Deep Learning
译 文：SDK.cn
作 者：Christian（编译）
来源：SDK.cn
