想独立开展深度学习研究，你准备好了吗？

深度学习是一门经验科学，具备优质的研发基础架构通常能令科研团队事半功倍。幸运的是，依托现有的开源生态，任何人都能构建出非常不错的深度学习基础架构。

在这篇文章中，我们会和大家分享如何开展深度学习的研究，也会一并介绍我们在研究中选用的基础架构和开源技术kubernetes-ec2-autoscaler，这是一种用于Kubernetes批处理任务的弹性伸缩管理器（batch-optimizedscalingmanager）。

用例

深度学习的演进通常源于一个能够在小问题上被验证的构想。在这个阶段，你需要快速地进行大量随机实验。理想情况下，只需远程登录到一台机器，运行一个脚本，不到一个小时就可以得到结果。

但是构建一个真正可用的模型通常会经历很多次失败，需要我们不停地去修复这些缺陷。（这和其他新建的软件系统一样，你需要多次运行代码才能判断它是如何运转的。）

你需要通过多个角度的计算来检测模型，从而意识到它是如何学习的。DarioAmodei的这种增强学习机制（控制右侧的球拍）可以在击球游戏中获得很高的分数，但你会发现，游戏中右侧的球拍完全没有移动。

因此深度学习的基础架构要能允许用户灵活地反观模型，仅仅展示一些统计结果是不够的。

当模型表现出一定的应用前景，你会希望将它扩展到更大的数据集和更多的GPU上运行，但这会花费大量的时间。而且你需要认真地管理实验并非常谨慎地去选择超参数（hyperparameters）的范围。

这种科研的过程在早期是快速且缺乏系统性的；到了后期，过程会逐渐有条理却很耗费精力，但为了获得完美的结果，这是必不可少的。

案例

论文ImprovedTechniquesforTrainingGANs开篇讲述了TimSalimans对于如何改进生成对抗网络（GAN）训练机制的一些看法。我们会挑其中较简单的一个进行介绍（这虽然不是最好的半监督学习案例，但它生成了最好看的样本）。

GANs由一个生成器网络和一个鉴别器网络构成。生成器会不停地去干扰鉴别器，而鉴别器会尽力地将生成器造出的数据和真实数据区分开来。通常来说，判断生成器的好坏，看它能不能骗过所有鉴别器就行了，但难题仍然存在：如果生成器一直输出完全相同的（几乎和真实的一样）样本会造成网络的崩溃。

Tim提出可以用小批次的样本数据代替原先的一整个样本提供给鉴别器。这样鉴别器就可以判断生成器是否一直在传同样的图像。当崩溃发生时，生成器将会进行梯度调整来修正这个问题。

下一步就是基于MNIST和CIFAR-10将构想转化为原型。这需要快速地构建出一个初步的模型，然后运行真实的数据并检测结果。在经过几次快速的迭代之后，Tim得到了CIFAR-10的样本，这次的结果十分振奋人心，几乎是我们见过的在这个数据集上跑出的最好样本了。

深度学习（以及常说的AI算法）如果要真正形成一定影响就必须扩大实验规模，一个小型神经网络可以验证概念，而大型的神经网络才能真正解决问题。因此IanGoodfellow开始把模型扩展到ImageNet进行验证。

模型学习生成ImageNet的图像

有了更大的模型和数据集，Ian就需要用更多的GPU来并行地运行模型。任务运行时机器的CPU和GPU利用率会飙升至90%，但是即使这样仍需要花费很多天才能完成模型训练。在这种模式下，每一次实验机会都显得无比珍贵，他也会非常细致地记录下每次实验的结果。

虽然实验最终得到了不错的结果，但仍没有达到我们的预期。为了找到原因我们做了很多尝试，但仍然攻克不了。这大概就是科学的本质吧。

基础架构

软件

TensorFlow代码的样例

我们绝大部分的研究代码是用Python完成的，详细内容可以在我们的开源项目中查看到。我们通常使用TensorFlow（在特殊情况下也会使用Theano）来进行GPU计算；使用Numpy或其他方法来进行CPU计算。研究人员有时也会使用更上层的框架，比如基于TensorFlow的Keras。

和多数深度学习社区一样，我们会使用Python2.7。Anaconda也经常会用到，它可以方便地给OpenCV打包，并对一些科学算法库进行性能优化。

硬件

对于理想的批处理任务，将集群计算节点的数量翻倍会减半任务执行时间。不幸的是，在深度学习中，机器人维修，GPU数量的增加只会引起任务亚线性的加速。因此顶级的计算性能只能依靠顶级的GPU来实现。我们也使用了许多CPU用于构建模拟器、增强学习环境或是小规模的模型（这类模型跑在GPU上时运行效率不会有明显的增加）。

nvidia-smi下满载的TitanXs

AWS慷慨地为我们提供了大量计算资源。这些资源被用于CPU实例以及GPU任务的水平扩展。我们也有自己的物理机，用的是TitanXGPU。我们期望之后可以使用混合云：对不同的GPU、连接以及其他技术开展实验是非常具有价值的，这对深度学习未来的发展也有着重要影响。

相同物理单元上的htop显示了大量空闲的CPU。我们通常将CPU密集型和GPU密集型的任务分开运行。

配置

我们对待基础架构就像许多公司对待他们的产品一样：它的界面必须简洁，必须兼顾功能性和可用性。我们会使用一致的工具来统一管理所有服务器，并且尽可能地对他们进行相同的配置。

用于管理弹性伸缩组的Terraform配置文件片段。Terraform可以创建、修改或销毁正在运行的云资源来匹配配置文件。

我们使用Terraform来创建AWS的云资源（实例、网络路由、DNS记录等）。我们的云端节点和物理节点都运行Ubuntu系统，并使用Chef来做配置。为了实现加速，www.zr-kuka.com，我们使用Packer来预先制作集群镜像（AMI）。我们的所有集群都使用非交叉的IP范围，用户可以通过笔记本上的OpenVPN及物理节点上的strongSwan（AWS的客户网关）连接到公网。

最后，我们将用户的home目录、数据集和结果存储在NFS（基于物理硬件）和EFS/S3（基于AWS）上。

编排

可扩展的基础架构通常会使原本简单的用例复杂化。我们在对不同规模作业的基础架构研究上投入了同等的精力，也在同步优化工具套件，使得分布式的用例能像本地用例一样好用。

我们为随机实验提供了SSH节点的（有些有GPU有些没有）集群，并且使用Kubernetes来调度物理节点和AWS节点。我们的集群横跨3个AWS域因为有时任务量会突然爆发，从而占满单个区域的所有资源。

Kubernetes要求每一个任务都是一个Docker容器，这样就可以实现依赖隔离和代码快照。但是创建一个新的Docker容器会增加迭代周期的时间，库卡机器人何服电机维修，这个时间十分宝贵，所以我们也提供工具，将研究人员笔记本上的代码转成标准镜像。

TensorBoard中的模型学习曲线