深度学习基础设施

# 深度学习基础设施 来源：https://openai.com/index/infrastructure-for-deep-learning/ OpenAI 深度学习是一门经验科学，一个团队的基础设施质量对研究进展有很大的乘数效应。幸运的是，当今开源生态系统使任何人都能构建优秀的深度学习基础设施。 ## 摘要 在这篇文章中，我们将分享深度学习研究通常如何进行，描述我们为支持研究所做的基础设施选择，并开源 kubernetes-ec2-autoscaler（https://github.com/openai/kubernetes-ec2-autoscaler），一个为 Kubernetes 优化的批处理缩放管理器。我们希望这篇文章能帮助你构建自己的深度学习基础设施。 典型的深度学习突破始于一个想法，你在小问题上进行测试。在这个阶段，你希望快速运行许多临时实验。理想情况下，你可以直接 SSH 进入一台机器，在 screen 中运行脚本，并在一小时内获得结果。 让模型真正工作通常需要观察它在各种可能的方式下失败，并找到修复这些限制的方法。（这类似于构建任何新的软件系统，你需要多次运行代码来建立对其行为的直觉。） 因此，深度学习基础设施必须允许用户灵活地观察模型，仅仅暴露汇总统计数据是不够的。 一旦模型展现出足够的前景，你将扩展到更大的数据集和更多的 GPU。这需要消耗大量计算资源且持续多天的长期任务。你需要谨慎的实验管理，并对选择的超参数范围进行深思熟虑。 早期研究过程是非结构化和快速的；后期是有条理的，有些痛苦，但这一切都是获得优秀成果的绝对必要条件。 论文《Improved Techniques for Training GANs》（https://arxiv.org/abs/1606.03498）始于 Tim Salimans（http://timsalimans.com/）设想出几个改进生成对抗网络（https://openai.com/index/generative-models/#gan）训练的想法。我们将描述其中最简单的想法（碰巧产生最好看的样本，尽管不是最好的半监督学习）。 GAN 由生成器和判别器网络组成。生成器试图欺骗判别器，判别器试图区分生成的数据和真实数据。直观地说，能够欺骗每个判别器的生成器相当不错。但存在一个难以修复的失败模式：生成器可能会"坍塌"，始终输出完全相同的（可能看起来逼真的！）样本。 Tim 的想法是给判别器输入整个小批次（https://www.coursera.org/learn/machine-learning/lecture/9zJUs/mini-batch-gradient-descent）的样本，而不是仅输入一个样本。这样判别器可以判断生成器是否只是不断产生单一图像。一旦发现坍塌，梯度将被发送给生成器以修正问题。 下一步是在 MNIST（http://yann.lecun.com/exdb/mnist/）和 CIFAR-10（https://www.cs.toronto.edu/~kriz/cifar.html）上原型化这个想法。这需要尽快原型化一个小模型，在真实数据上运行它，并观察结果。经过一些快速迭代，Tim 获得了非常令人鼓舞的 CIFAR-10 样本（https://cdn.openai.com/infrastructure-for-deep-learning/cifar10samples-2.jpg）——基本上是我们在该数据集上见过的最好的样本。 然而，深度学习（以及一般的 AI 算法）必须进行扩展才能真正令人印象深刻——一个小神经网络是概念证明，但一个大神经网络实际上解决了问题并且很有用。所以 Ian Goodfellow（https://www.linkedin.com/in/ian-goodfellow-b7187213）开始着手扩展模型以在 ImageNet（http://image-net.org/）上运行。 基础设施图 1 我们的模型学习生成 ImageNet 图像 随着模型和数据集的扩大，Ian 需要在多个 GPU 上并行化模型。每个任务会将多台机器推送到 90% 的 CPU 和 GPU 利用率，但即使如此，模型也需要花费许多天来训练。在这种情况下，每个实验都变得珍贵，他会细致地记录每个实验的结果。 最终，虽然结果不错，但不如我们预期的那样好。我们已经测试了许多假设来解释原因，但仍然没有破解。这就是科学的本质。 基础设施图 2 我们的 TensorFlow 代码样本 基础设施图 3 nvidia-smi 显示满载的 Titan X AWS（https://aws.amazon.com/）慷慨地同意向我们捐赠大量计算资源。我们将其用于 CPU 实例和水平扩展 GPU 任务。我们也运行自己的物理服务器，主要运行 Titan X（http://www.geforce.com/hardware/10series/titan-x-pascal）GPU。我们预计将长期采用混合云模式：尝试不同的 GPU、互连和其他可能对深度学习的未来很重要的技术是很有价值的。 基础设施图 4 同一物理机器上的 htop 显示充足的空闲 CPU。我们通常将 CPU 密集型工作负载与 GPU 密集型工作负载分开运行。 我们像许多公司对待产品一样对待基础设施：它必须呈现简单的界面，可用性与功能一样重要。我们使用一致的工具集来管理所有服务器，并尽可能地将其配置为相同。 基础设施图 5 我们 Terraform 配置的片段用于管理自动扩展组。Terraform 创建、修改或销毁运行的云资源以匹配你的配置文件。 可扩展的基础设施往往会使简单的情况变得困难。我们对小规模和大规模任务的基础设施投入了相等的努力，并且正在积极完善我们的工具包，以使分布式用例与本地用例同样可访问。 我们为临时实验提供了一个 SSH 节点集群（带 GPU 和不带 GPU），并在物理和 AWS 节点上运行 Kubernetes（http://kubernetes.io/）作为我们的集群调度器。我们的集群跨越 3 个 AWS 区域——我们的任务突发性足够大，有时会达到各个区域的容量限制。 Kubernetes 要求每个任务都是一个 Docker 容器，这给了我们依赖项隔离和代码快照。然而，构建新的 Docker 容器会增加研究人员宝贵的额外秒数迭代周期，所以我们也提供工具来透明地将代码从研究人员的笔记本电脑传送到标准镜像。 基础设施图 6 TensorBoard 中的模型学习曲线 我们将 Kubernetes 的 flannel（https://coreos.com/flannel/docs/latest/）网络直接暴露给研究人员的笔记本电脑，允许用户无缝网络访问其运行的任务。这对于访问监控服务（如 TensorBoard（https://www.tensorflow.org/versions/r0.10/how_tos/summaries_and_tensorboard/index.html））特别有用。（我们最初的方法在严格的隔离角度来看更清晰——要求人们为每个想暴露的端口创建一个 Kubernetes Service（http://kubernetes.io/docs/user-guide/services/），但我们发现这增加了太多摩擦。） 我们的工作负载是突发性的和不可预测的：一条研究路线可以从单机实验快速发展到需要 1,000 个核心。例如，在几周内，一个实验从单个 Titan X 上的交互式阶段，发展到 60 个 Titan X 上的实验阶段，再到需要将近 1600 个 AWS GPU。我们的云基础设施因此需要动态配置 Kubernetes 节点。 在自动扩展（https://aws.amazon.com/autoscaling/）组中运行 Kubernetes 节点很容易，但正确管理这些组的大小更难。提交批处理任务后，集群准确地知道它需要什么资源，应该直接分配这些资源。（相比之下，AWS 的扩展策略（http://docs.aws.amazon.com/autoscaling/latest/userguide/policy_creating.html）将逐个启动新节点，直到资源不再耗尽，这可能需要多次迭代。）此外，集群需要在终止节点之前清空（http://kubernetes.io/docs/user-guide/kubectl/kubectl_drain/）它们，以避免丢失进行中的任务。 对大批量任务直接使用原始 EC2 很诱人，实际上这就是我们开始的地方。然而，Kubernetes 生态系统增加了相当多的价值：低摩擦的工具、日志、监控、能够分别管理物理节点和运行实例的能力等等。让 Kubernetes 正确自动扩展比在原始 EC2 上重建整个生态系统更容易。 我们发布了 kubernetes-ec2-autoscaler（https://github.com/openai/kubernetes-ec2-autoscaler），一个为 Kubernetes 优化的批处理缩放管理器。它作为 Kubernetes 上的普通 Pod（http://kubernetes.io/docs/user-guide/pods/）运行，只需要你的工作节点位于自动扩展组中。 基础设施图 7 我们 Kubernetes 集群的启动配置 自动缩放器通过轮询 Kubernetes 主节点的状态来工作，该状态包含计算集群资源需求和容量所需的一切。如果有过量容量，它会清空相关节点并最终终止它们。如果需要更多资源，它计算应该创建哪些服务器并相应地增加自动扩展组大小（或简单地取消隔离（http://kubernetes.io/docs/user-guide/kubectl/kubectl_uncordon/）已清空的节点，这避免了新节点启动时间）。 kubernetes-ec2-autoscaler 处理多个自动扩展组、超出 CPU 的资源（内存和 GPU）以及对你的任务的细粒度约束，例如 AWS 区域和实例大小。此外，突发工作负载可能导致自动扩展组超时和错误，因为（令人惊讶的是！）即使是 AWS 也没有无限容量。在这些情况下，kubernetes-ec2-autoscaler 检测错误并溢出到辅助 AWS 区域。 我们的基础设施旨在最大化深度学习研究人员的生产力，让他们专注于科学。我们正在构建工具以进一步改进我们的基础设施和工作流，并将在即将到来的几周和几个月内分享这些工具。我们欢迎帮助（https://jobs.lever.co/openai/f7801a92-1e2f-4656-a572-962b53ec34f6）以加快这一进程！