正文

请到「今天看啥」查看全文

表1 利用机器学习算法的产品或服务

Facebook中的ML-as-a-Service

为了简化在产品中应用机器学习的任务，我们构建了一些内部平台和工具包，包括FBLearner，Caffe2和PyTorch。FBLearner是三种工具（FBLearner Feature Store，FBLearner Flow，FBLearner Predictor）的套装，其中每种工具分别负责机器学习管道上不同的部分。正如前面图1显示的那样，它利用了一种内部作业调度程序在GPU和CPU的共享资源池上分配资源和调度作业。Facebook大多数机器学习模型的训练过程都是在FBLearner平台上进行的。这些工具和平台被设计来帮助机器学习工程师提高效率，从而能够专注于算法创新。

• FBLearner Feature Store。任何机器学习建模任务的起点是收集和生成特征。 FBLearner Feature Store本质上是一系列特征生成器的目录，其特征生成器可以用于训练和实时预测，当然它也可以作为多个团队可以用来共享和寻找特征的公共空间（market place）。这样以个特征列表对于刚开始使用机器学习的团队来说是一个很好的平台，同时也有助于在现有模型中应用新特征。

• FBLearner Flow是Facebook用于训练模型的机器学习平台。Flow是一个管道管理系统，它会执行一个可以描述模型训练和/或评估所需步骤及其所需资源的工作流程（workflow）。这个工作流程由离散单元或操作符（operators）构成，每个单元都有输入和输出。操作符之间的连接会通过跟踪一个操作符到下一个操作符的数据流自动推理，Flow则通过处理调度和资源管理来执行工作流程。Flow还拥有一个可以用于实验管理的工具和一个简单的用户界面，这个界面可以跟踪每个workflow或实验生成的所有构件和指标，从而方便对比和管理这些实验。

• FBLearner Predictor是Facebook内部的推理引擎，它可以使用在Flow中训练的模型来提供实时的预测。Predictor可以用作多租户服务，也可以用作集成在特定产品的后端服务中的库。Facebook的很多产品团队都在使用Predictor，而其中许多团队都需要低延迟解决方案。Flow和Predictor之间的直接集成还有助于运行在线的实验以及在生产中管理多个版本的模型。

深度学习框架

我们在Facebook上利用了两种截然不同的协同框架来进行深度学习：针对研究优化的PyTorch和针对生产优化的Caffe2。

• Caffe2是Facebook的内部生产框架，它用于训练和部署大规模的机器学习模型。Caffe2专注于产品所需的几个关键特性：性能，跨平台支持和基本的机器学习算法，如卷积神经网络（CNN），递归神经网络（RNN）和多层感知器（MLP）。这些网络都具有稀疏或密集的连接以及高达数百亿的参数。该框架的设计采用模块化方法，在所有后端实现（CPU，GPU和加速器）之间共享统一的图表示。为了在不同平台上实现最佳的运行时间，Caffe2还抽象了包括cuDNN，MKL和Meta在内的第三方库。

• PyTorch是Facebook在AI研究领域的首选框架。它的前端注重灵活性、调试以及动态神经网络，能够快速进行实验。由于依赖于Python来执行，它并没有针对生产和移动端部署进行优化。当研究项目产生了有价值的结果时，模型就需要转移到生产上。过去，在生产环境中，我们通过使用其他框架重写产品环境的训练管道来完成模型转移。最近Facebook开始构建ONNX工具链来简化这个转移过程。比如，动态神经网络虽然被用于尖端的人工智能研究，但这些模型需要更长的时间才能被应用于产品中。通过解耦框架，我们避免了的为满足性能而设计更复杂的执行引擎（比如Caffe2）的需求。此外，相比模型速度，研究人员在进行研究时更看重其灵活性。举个栗子，在模型探索阶段，性能下降30％是可以容忍的，尤其是在它具有易测验和模型可视化的优点时。但是相同的方法并不适合于生产。这种取舍原则在PyTorch和Caffe2的框架设计中也可以看到，PyTorch提供了良好的默认参数和合理的性能，而Caffe2可以选择使用异步图执行，量化权重和多个专用后端等特性来达到最佳性能。

虽然FBLearner平台本身不限制使用什么框架，无论是Caffe2，TensorFlow，PyTorch还是其他的框架都可以，但我们的AI软件平台（AI Software Platform）团队为了让FBLearner能够很好地与Caffe2集成还是进行了特定优化。总的来说，分离研究和生产框架（分别是PyTorch和Caffe2）使我们能够在两边灵活运作，减少约束数量的同时还能增加新特性。

• ONNX. 深度学习工具生态系统在整个行业还处于初级阶段。 对于不同的问题子集，不同的工具有着不同的优势，并且在灵活性，性能和支持平台方面有着不同的折衷，这就跟我们之前对PyTorch和Caffe2所描述的权衡一样。 因此，在不同的框架或平台之间交换训练模型的需求很大。 为了弥补这个缺陷，2017年末，Facebook与几个合作伙伴共同推出了开放式神经网络交换（Open Neural Network Exchange , ONNX）。ONNX是一种以标准方式表示深度学习模型的格式，以便在不同的框架和供应商优化库之间实现互操作。同时，它能满足在不同的框架或平台之间交换训练好的模型的需求。ONNX被设计为一种开放的规范，允许框架作者和硬件供应商为其做出贡献，并拥有框架和库之间的各种转换器。Facebook正在努力使ONNX成为所有这些工具之间的协作伙伴，而不是一种具有排他性的官方标准。

在Facebook内部，ONNX是我们将研究模型从PyTorch环境转移到Caffe2中的高性能生产环境的主要手段，它可以实现对模型的自动捕捉和固定部分的转换。

在Facebook内部，ONNX是我们将研究模型从PyTorch环境转移到Caffe2中的高性能生产环境的主要手段。 ONNX提供了自动捕捉和转换模型的静态部分的能力。 我们有一个额外的工具链，通过将它们映射到Caffe2中的控制流原函数或者以C ++作为自定义操作符重新实现它们，会有助于将模型从Python转移到动态图。

机器学习的资源需求

鉴于机器学习在训练和推理（inference）的阶段的资源要求、频率和持续时长不同，我们将分别讨论这两个阶段的细节和资源应用。

Facebook硬件资源概况

Facebook的基础架构部门（Facebook Infrastructure）很早之前就开始为主要软件服务构建的高效平台，包括针对每种主要工作负载的资源要求定制的服务器、存储以及网络支持。

 

图2 基于CPU的计算服务器。单插槽服务器底座上有4个Monolake服务器卡，双插槽服务器底座还一个双插槽服务器，因此在2U机箱中共有三个双插槽服务器。所以在2U形式的组合中共有12个服务器。

当前Facebook提供约八种主要的计算和存储架构，对应八种主要服务。这些主要架构类型足以满足Facebook主要服务的资源要求。例如，图2中展示了一个可以容纳三个计算Sleds模块的2U机架，这些模块可支持两种服务器类型。其中一种Sled模块是单插槽CPU服务器（1xCPU），多用于Web层——一种主要看重吞吐量的无状态服务，因此可以使用能效更高的CPU（Broadwell-D处理器）；它的DRAM（32GB）以及主板硬盘或闪存较少。

另一种Sled模块是较大的双插槽CPU服务器（2x高功率Broadwell-EP或Skylake SP CPU），它配有大量的DRAM ，常用于涉及大量计算和存储的服务。

 

图3. 搭载8个GPU的Big Basin GPU服务器（3U机架）

由于我们训练的神经网络越来越大，并且越来越深，我们开发出了Big Basin GPU服务器（如图3所示），这是我们2017年最新的GPU服务器。最初的Big Basin GPU服务器配置了八个互相连接的NVIDIA Tesla P100 GPU加速器，它使用NVIDIA NVLink形成了一个八CPU混合立方网格，后来，这种设计经过改进之后又应用到了V100 GPU上。

Big Basin是早前的Big Sur GPU的继承者，后者是Facebook数据中心首个广泛应用的高性能AI计算平台，用于支持于2015年开发并通过开放计算项目（Open Compute Project）发布的NVIDIA M40 GPU。

与Big Sur相比，V100 Big Basin每瓦电可实现的性能更高，这得益于单精度浮点运算单元——每个GPU的运算速度从7 teraflops（每秒万亿次浮点运算）增加到了15.7 teraflops，以及可提供900GB/s的带宽的高带宽显存（HBM2）。这种新的架构还使得半精度运算的速度快了一倍，进一步提高了运算吞吐量。

由于Big Basin的运算吞吐量更大，而且显存也从12 GB增加到了16 GB，因此它可以用来训练比先前模型大30%的模型。高带宽NVLink互连GPU通信还强化了分布式训练。在使用ResNet-50图像分类模型进行的测试中，Big Basin的运算吞吐量比Big Sur要高出300%，借助它我们可以以更快的速度训练比以往更复杂的模型。

Facebook通过开放计算项目（Open Compute Project）公布了所有这些计算服务器的设计以及几种存储平台。

离线训练的资源需求

当前，不同的产品会使用不同的计算资源来完成各自的离线训练步骤。有些产品（例如Lumos）在GPU上完成所有的训练。其他产品（例如Sigama）则在双插槽 CPU计算服务器完成所有的训练。诸如Facer这样的产品采用双阶段训练流程，先在GPU上以很小的频率（几个月一次）队通用的面部检测和识别模型进行训练，然后在数千个1xCPU服务器上以很高的频率对每个用户的模型进行特定训练。

在本部分，我们将围绕机器学习训练平台、训练频率和持续时长，具体介绍多种服务的细节，并在表II中进行了总结。另外，我们还讨论了数据集的趋势以及这些趋势对计算、内存、存储和网络架构的意义。

• 计算类型和相对数据来源的位置。离线训练既可以在CPU上完成，也可以在GPU上完成，这取决于服务本身。虽然在多数情况下，在GPU上训练出的模型在性能上要比在CPU上训练的模型好，但是CPU强大的现成运算能力使得它成为了一个非常有用的平台。这一点在每天的非高峰期中尤为明显，因为在这期间CPU资源本来就无法得到利用，后面的图4会对此进行说明。下面我们给出了服务和计算资源训练模型的对应关系：

• 在GPU上训练模型的服务: Lumos、语音识别、语言翻译

• 在CPU上训练模型的服务：News Feed、Sigma

• 在GPU和CPU上训练模型的服务：Facer （在GPU上每几年训练一次的通用模型，此类模型较为稳定；在1xCPU上训练的用户特定的模型，此类模型可以用于处理新图像数据）、搜索（利用多个独立的垂直搜索引擎，使用可以进行预测的分类器启动最合适的垂直搜索引擎）。

请到「今天看啥」查看全文