介绍Facebook在机器学习方面的软硬件基础架构，来满足其全球规模的运算需求

2017年末，Facebook应用机器学习组发布最新论文，对整个Facebook的机器学习软硬件架构进行了介绍。纵览全文，我们也可以从中对Facebook各产品的机器学习策略一窥究竟。论文中涉及到机器学习在全球规模(上亿级数据处理)上的全新挑战，并给出了Facebook的应对策略和解决思路，对相关行业和研究极其有意义。

摘要

机器学习在Facebook的众多产品和服务中都有着举足轻重的地位。 本文将详细介绍Facebook在机器学习方面的软硬件基础架构，如何来满足其全球规模的运算需求。

Facebook的机器学习需求极其繁杂：需要运行大量不同的机器学习模型。这种复杂性已经深深刻在Facebook系统堆栈的所有层面上。此外，Facebook存储的所有数据，有相当大一部分会流经机器学习管道，这样的数据载荷为Facebook的分布式高性能训练流带来巨大的压力。

计算需求也非常紧张，在保持用于训练的GPU/CPU平台的同时平衡出大量CPU容量用于实时推理，也带来了异常紧张的。这些问题及其他难题的解决，仍有待我们在跨越机器学习算法、软件和硬件设计上持久而不懈的努力。

引言

Facebook的使命是“为人类构建社交关系赋能，让世界联系更加紧密”。截至2017年12月，Facebook已经连接了全球超过20亿的人口。同时，过去几年来，机器学习同样在这样一种全球尺度的实际问题上进行着一场革命，包括在机器学习算法创新方面的良性循环，用于模型训练的海量数据以及高性能计算机体系结构的进步。

在Facebook上，机器学习几乎在提升用户体验的所有层面都发挥着关键作用，包括诸如新闻推送语音和文本翻译以及照片和实时视频分类的排名等服务。

Facebook在这些服务中用到了各种各样的机器学习算法，包括支持向量机，梯度boosted决策树和许多类型的神经网络。本文将介绍Facebook的数据中心架构支持机器学习需求的几个重要层面。其架构包括了内部的“ML-as-a-Service”流，开源机器学习框架，和分布式训练算法。

从硬件角度来看，Facebook利用了大量的CPU和GPU平台来训练模型，以便在所需的服务延迟时间内支持模型的训练频率。对于机器学习推理过程，Facebook主要依靠CPU来处理所有主要的服务，而其中神经网络排名服务（比如新闻推送）占据着所有计算负载的大头。

Facebook所存储的海量数据中，有一大部分要流经机器学习管道，并且为了提高模型质量，这一部分的数据量还在随着时间推移不断增加。提供机器学习服务所需的大量数据成为了Facebook的数据中心将要在全球规模上面临的挑战。

目前已有的可被用来向模型高效地提供数据的技术有，数据反馈和训练的解耦操作，数据/计算协同定位和网络优化。与此同时，Facebook公司这样大的计算和数据规模自身还带来了一个独特的机会。在每天的负载周期内，非高峰期都会空闲出大量可以用来进行分布式训练算法的CPU。

Facebook的计算集群（fleet）涉及到数十个数据中心，这样大的规模还提供了一种容灾能力。及时交付新的机器学习模型对于Facebook业务的运营是非常重要的，为了保证这一点，容灾规划也至关重要。

展望未来，Facebook希望看到其现有的和新的服务中的机器学习使用频率快速增长。当然，这种增长也将为负责这些服务架构的团队在全球规模的拓展性上带来更加严峻的挑战。尽管在现有平台上优化基础架构对公司是一个重大的机遇，但我们仍然在积极评估和摸索新的硬件解决方案，同时保持对于算法创新的关注。

本文（Facebook对机器学习的看法）的主要内容包括：

机器学习正在被广泛应用在Facebook几乎所有的服务，而计算机视觉只占资源需求的一小部分。

Facebook所需的大量机器学习算法极其繁杂，包括但不限于神经网络

我们的机器学习管道正在处理海量的数据，而这会带来计算节点之外的工程和效率方面的挑战。

Facebook目前的推理过程主要依靠CPU，训练过程则是同时依靠CPU和GPU。但是从性能功耗比的角度来看，应当不断对新的硬件解决方案进行摸索和评估。

全球用户用来使用Facebook的设备每天都可达数亿台，而这会就会提供大量可以用于机器学习任务的机器，例如用来进行大规模的分布式训练。

Facebook的机器学习

机器学习（ML）是指利用一系列输入来建立一个可调模型，并利用该模型创建一种表示，预测或其他形式的有用信号的应用实例。

图1. Facebook的机器学习流程和架构示例

图1所示的流程由以下步骤组成，交替执行：

建立模型的训练阶段。这个阶段通常离线运行。

在应用中运行训练模型的推理阶段，并进行（一组）实时预测。这个阶段是在线执行的。

模型进行训练的频率要比推理少得多——推理的时间规模虽然在不断变化，但一般在几天左右。训练也需要相当长的时间来完成，通常是几个小时或几天。同时，根据产品实际需求不同，在线推理阶段每天可能运行达数十万次，而且一般需要实时进行。在某些情况下，特别是对于推荐系统，还需要以这样连续的方式在线进行额外的训练。

在Facebook，机器学习的一个显著特征就是有可用于模型训练的海量数据。这个数据的规模会带来很多涉及到整个机器学习架构的影响。

使用机器学习的主要服务

消息推送

消息推送排名算法能够使用户在每次访问Facebook时，最先看到对他们来讲最重要的事情。一般模型会通过训练来确定影响内容排序的各种用户和环境因素。之后，当用户访问Facebook时，该模型会从数千个候选中生成一个最佳推送，它是一个图像和其他内容的个性化集合，以及所选内容的最佳排序。

广告

广告系统利用机器学习来确定向特定用户显示什么样的广告。通过对广告模型进行训练，我们可以了解用户特征，用户上下文，以前的互动和广告属性，进而学习预测用户在网站上最可能点击的广告。之后，当用户访问Facebook时，我们将输入传递进训练好的模型运行，就能立马确定要显示哪些广告。

搜索

搜索会针对各种垂直类型（例如，视频，照片，人物，活动等）启动一系列特定的子搜索进程。分类器层在各类垂直类型的搜索之前运行，以预测要搜索的是垂直类型中的哪一个，否则这样的垂直类型搜索将是无效的。分类器本身和各种垂直搜索都包含一个训练的离线阶段，和一个运行模型并执行分类和搜索功能的在线阶段。

Sigma

Sigma是一个分类和异常检测通用框架，用于监测各种内部应用，包括站点的完整性，垃圾邮件检测，支付，注册，未经授权的员工访问以及事件推荐。Sigma包含了在生产中每天都要运行的数百个不同的模型，并且每个模型都会被训练来检测异常或更一般地分类内容。

Lumos

Lumos能够从图像及其内容中提取出高级属性和映射关系，使算法能够自动理解它们。这些数据可以用作其他产品和服务的输入，比如通过文本的形式。

Facer

Facer是Facebook的人脸检测和识别框架。给定一张图像，它首先会寻找该图像中所有的人脸。然后通过运行针对特定用户的人脸识别算法，来确定图中的人脸是否是该用户的好友。Facebook通过该服务为用户推荐想要在照片中标记的好友。

语言翻译

语言翻译是涉及Facebook内容的国际化交流的服务。Facebook支持超过45种语言之间的源语言或目标语言翻译，这意味着Facebook支持2000多个翻译方向，比如英语到西班牙语，阿拉伯语到英语。通过这2000多个翻译通道，Facebook每天提供4.5B字的翻译服务，通过翻译用户的消息推送，Facebook每天可为全球6亿人减轻语言障碍。目前，每种语言对方向都有其自己的模型，但是我们也正在考虑多语言模型[6]。

语音识别

语音识别是将音频流转换成文本的服务。它可以为视频自动填补字幕。目前，大部分流媒体都是英文的，但在未来其他语言的识别也将得到支持。另外，非语言的音频文件也可以用类似的系统（更简单的模型）来检测。

除了上面提到的主要产品之外，还有更多的长尾服务也利用了各种形式的机器学习。 Facebook产品和服务的长尾数量达数百个。

机器学习模型

所有基于机器学习的服务都使用“特征”（或输入）来产生量化的输出。Facebook使用的机器学习算法包括Logistic回归（LR），支持向量机（SVM），梯度提升决策树（GBDT）和深度神经网络（DNN）。

LR和SVM在训练和预测方面非常有效。GBDT可以通过增加计算资源来提高准确性。DNN是最具表达力的，能够提供最高的准确性，但利用的资源也是最多的（在计算量上，至少比LR和SVM等线性模型高出一个数量级）。

这三种模型的自由参数都在变得越来越多，必须通过使用带标签的输入示例来优化预测的准确性。

在深度神经网络中，有三类经常使用的网络：多层感知器（MLP），卷积神经网络（CNN）和递归神经网络（RNN / LSTM）。MLP网络通常运行在结构化输入特征（通常是排名）上，RNN / LSTM网络一般用来处理时域的数据，即用作序列处理器（通常是语言处理），相对的CNNs则是一种处理用来空间数据的工具（通常是图像处理）。表I显示了这些机器学习模型类型和产品/服务之间的映射关系。

表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上训练的用户特定的模型，此类模型可以用于处理新图像数据）、搜索（利用多个独立的垂直搜索引擎，使用可以进行预测的分类器启动最合适的垂直搜索引擎）。

目前，GPU主要被用于离线训练，而不是向用户提供实时数据。因为大多数GPU架构都针对运算吞吐量进行了优化，以克服延迟劣势。同时由于训练过程严重依赖从大型数据生成库中获取的数据，考虑到性能和带宽方面的原因，GPU必须靠近数据来源。由于训练模型所使用的数据量增长的相当快，GPU是否靠近数据来源变得越来越重要。

内存、存储和网络：从内存储器容量的角度看，CPU和GPU平台都能为训练提供充足的存储容量。即使对于Facer这样的应用，也可以在1xCPU上用32GB RAM训练用户特定的SVM模型。如果可以尽可能地利用高效平台以及多余的存储容量，则平台的总体训练效率会非常优秀。

服务	资源	训练频率	训练持续时长
News Feed	单插槽CPUs	每天一次	数小时
Facer	GPUs + 单插槽CPUs	每N张照片一次	几秒
Lumos	GPUs	每几个月一次	数小时
搜索	Vertical Dependent	每小时一次	几小时
语言翻译	GPUs	每周一次	几天
Sigma	双插槽CPUs	每天数次	几小时
语音识别	GPUs	每周一次	数小时

表II 不同服务的离线训练的频率、持续时长和资源

机器学习系统依赖于使用实例数据的训练。Facebook 使用了机器学习数据管道中的大量数据。这使得计算资源趋向于靠近数据库。

随着时间的推移，大多数服务会显示出利用累积的用户数据的趋势，这将导致这些服务更加依赖Facebook的其他服务，并且需要更大的网络带宽来获取数据。因此，只有在数据源所在地或附近部署巨大的存储，以便从偏远的区域大规模转移数据，从而避免为了等待获取更多样本数据而关停训练管道。

在部署训练机器的位置时，我们也可以使用这种方法来避免训练机群给附近的存储资源造成过大的压力。

不同的服务在离线训练期间使用的数据量有很大的差别。几乎所有服务的训练数据集都呈现出持续增长甚至大幅增长的趋势。例如，有些服务在ROI降低之前会使用数百万行数据，其他服务则使用数百亿行数据（100多TB），并且只受到资源的限制。

扩展（Scaling）考虑和分布式训练：训练神经网络的过程包含使用随机梯度下降法（SGD）对参数权重进行优化。这种方法用于拟合神经网络，通过评价标记实例的小子集（即“batch” 或“mini-batch”）来迭代更新权重。在数据并行中，网络会生成多个模型副本（并行实例），以并行的处理多批数据。

当使用一台机器训练模型时，模型越大或更深都会带来更好的训练效果，准确度也会更高，但是训练此类模型往往需要处理更多的样本。当使用一台机器进行训练时，我们可以通过增加模型副本的数量并在多个GPU上执行数据并行，来最大化训练效果。

当训练所需的数据量随时间增加，硬件限制会导致总体训练延迟和收敛时间增加。不过，我们可以使用分布式训练来克服这些硬件限制，减少延迟。这个研究领域在Facebook和整个AI研究界相当热门。

一种普遍的假设是，在不同机器上实现数据并行需要使用一种专门的互连机制。但是，在我们对分布式训练的研究中，我们发现基于以太网(Ethernet)的网络就可以提供近似线性的扩展能力。能否实现近似线性的扩展，与模型的大小和网络带宽有密切的关系。

如果网络带宽太小，执行参数同步所花的时间比执行梯度计算所花的时间还多，在不同机器上进行数据并行所带来的优势也会大打折扣。使用50G的以太网NIC，我们可以用Big Basin服务器扩展视觉模型的训练，而且机器间的同步完全不会造成问题。

在所有情况下，更新都需要使用同步（每个副本都看到相同状态），一致性（每个副本生成正确更新）和性能（子线性缩放）的技术来与其他副本共享，这可能会影响训练质量。 例如，翻译服务目前就不能在不降低模型质量的情况下进行大批量的小批量（mini-batches）训练。

相反，如果使用特定的超参数设置，我们就可以在非常大的mini-batch数据集上训练图像分类模型，并且可以扩展到256个以上的GPU上。

实验证明，在Facebook的某个大型服务中，在5倍的机器上执行数据并行可以实现4倍的训练效率（例如：训练一组训练时间超过4天的模型，以前总共可以训练100个不同模型的机器集群现在每天只能训练同样的20个模型，训练效率降低了20%，但是潜在的工程进度等待时间从4天减少到了1天）。

如果模型变得超级大，这时候就可以使用并行训练，对模型的层进行分组和分布，以优化训练效率，各机器间可以传递激活单元。优化可能与网络带宽、延迟或平衡内部机器限制有关。这会增加模型的端对端延迟，因此，每一时步（time step）内原始性能的增强通常与步长（step）质量的下降有关。这可能会进一步降低模型在每个步长的准确度。各步长准确度的下降最终会累积起来，这样我们就可以得出并行处理的最佳步长数量。

DNN模型本身的设计使得它只能在一台机器上运行，在推理阶段，在机器间分割模型图通常会导致机器与机器进行大量的沟通。但是Facebook的主要服务会不断地权衡扩展模型的利与弊。这些考虑可以决定网络容量需求的变化。

服务	相对计算能力	计算	内存
News Feed	100X	双插槽CPU	高
Facer	10X	单插槽CPU	低
Lumos	10X	单插槽CPU	低
搜索	10X	双插槽CPU	高
语言翻译	1X	双插槽CPU	高
Sigma	1X	双插槽CPU	高
语音识别	1X	双插槽CPU	高

表 III 在线推理服务的资源要求。

在线推理的资源需求

在完成离线训练之后的线推理步骤中，我们需要将模型载入到机器中，使用实时输入运行模型来生成网站流量的实时结果。

接下来我们将讨论，一种实际应用中的在线推理模型——广告排名模型。这种模型可以筛选成千上万条广告，在消息推送中显示排在1至5名的广告。这个过程是通过对依次减小的广告子集进行逐步复杂的排名运算循环（passes）来实现的。

每一轮运算都会用到类似于多层感知模型（MLP）的模型，这种模型包含稀疏嵌入层，每一轮运算都会缩小广告的数量。稀疏嵌入层需要大量的内存，因此当进行到靠后的运算时，模型的超参数数量更多，它将在独立于MLP运算轮的一个服务器上运行。

从计算的角度上看，绝大多数在线推理都是在大量1xCPU（单插槽）或2xCPU（双插槽）上运行的。由于1xCPU对Facebook的服务而言性能更高，而且性价比更高，因此Facebook提倡尽可能使用1xCPU服务器训练模型。

随着高性能移动硬件的诞生，Facebook甚至可以在用户的移动设备上直接运行某些模型，来改进延迟和降低通信成本。但是，某些需要大量计算和内存资源的服务仍然需要使用2xCPU才能实现最佳性能。

不同的产品在得出在线推理的结果时拥有不同的延迟要求。在某些情况下，得出的数据可能“十分优秀” ，也可能会在向用户返回初步快速评估后被重新输入到模型中。例如，在某些情况中将某个内容分类为合格是可以接受的，但是当运行更加复杂的模型时这个初步的分类结果就会被推翻。

广告排名和消息推送之类的模型配置有稳定的SLA，可以向用户推送合适的内容。这些SLA决定着模型的复杂性和依赖性，因此如果拥有更加强大的计算能力，我们就可以训练出更加先进的模型。

机器学习数据计算

除了资源需求外，在数据中心部署机器学习时还需要考虑一些重要的因素，包括对重要数据的需求以及面对自然灾害的可靠性。

从获取数据到模型

Facebook公司的许多机器学习模型，成功的主要因素就是广泛而高质量的可用数据。快速处理并将这些数据提供给机器学习模型的能力能够确保我们部署快速有效的离线训练。

对于复杂的机器学习应用程序，如广告和排名，每个训练任务所需的数据量都超过数百TB大小。此外，复杂的预处理逻辑的使用能确保数据被清理并归一化，以便高效地迁移和更轻松地学习。这些操作对资源的要求非常高，特别对存储量，网络和CPU的需求。

作为一个通用的解决方案，我们尝试对训练工作量中的数据进行解耦。这两个工作量都有非常显著的特点。一方面，它非常复杂，具有临时的，依赖业务性的，且变化快等特点。另一方面，训练工作量通常是固定的（例如GEMM），稳定的（核心业务相对较少），高度优化，且更偏爱于“干净”的环境下工作（例如，独占高速缓存使用和最小线程争夺）。

为了优化这两者，我们在物理上对不同的机器的不同工作负载进行隔离。数据处理机器，又名“readers”，从存储器中读取数据，处理和压缩它们，然后将结果反馈给一个叫做“trainers”的训练机器。另一方面，trainers只专注于快速有效地执行任务。readers和trainers可以分布以便提供更灵活性和可扩展性的应用。此外，我们还优化了不同工作负荷的机器配置。

另一个重要的优化指标是网络使用。训练过程产生的数据流量非常重要的，并且有时候会突然产生。如果没有智能化处理的话，这很容易就会导致网络设备的饱和，甚至干扰到其他服务。为了解决这些问题，我们采用压缩优化，调度算法，数据/计算布局等等操作。

利用规模

作为一家为用户提供服务的全球性公司，Facebook必须保持大量服务器的设计能够满足在任何时间段内的峰值工作负载。如图所示，由于用户活动的变化取决于日常负荷以及特殊事件（例如地区节假日）期间的峰值，因此大量的服务器在特定的时间段内通常是闲置的。

这就释放了非高峰时段内大量可用的计算资源。利用这些可能的异构资源，以弹性方式合理分配给各种任务。这是Facebook目前正努力探索的一大机会。对于机器学习应用程序，这提供了将可扩展的分布式训练机制的优势应用到大量的异构资源（例如具有不同RAM分配的CPU和GPU平台）的机会。但是，这也会带来一些挑战。在这些低利用率的时期，大量可用的计算资源将从根本上导致分布式训练方法的不同。

调度程序首先必须正确地平衡跨越异构硬件的负载，这样主机就不必为了同步性而等待其他进程的执行。当训练跨越多个主机时，调度程序还必须要考虑网络拓扑结构和同步所需的成本。如果处理不当，机架内或机架间同步所产生的流量可能会很大，这将极大地降低训练的速度和质量。

例如，在1xCPU设计中，四个1xCPU主机共享一个50G的网卡。如果全部四台主机同时尝试与其他主机的梯度进行同步，那么共享的网卡很快就会成为瓶颈，这会导致数据包下降和请求超时。因此，网络之间需要用一个共同的设计拓扑和调度程序，以便在非高峰时段有效地利用闲置的服务器。另外，这样的算法还必须具备能够提供检查指向停止及随着负荷变化重新开始训练的能力。

灾难后恢复能力

能够无缝地处理Facebook一部分全球计算，存储和网络足迹的损失，一直是Facebook基础设施的一个长期目标。Facebook的灾难恢复小组会定期在内部进行演习，找出并补救全球基础设施中最薄弱的环节和软件堆栈。干扰行动包括在几乎没有任何通知情况下，进行整个数据中心离线处理以确认我们全球数据中心的损失对业务造成最小的干扰值。

对于机器学习的训练和推理部分，容灾的重要性是不言而喻的。尽管驱动几个关键性项目的推理过程十分重要这一观点以并不让人意外，但在注意到几个关键产品的可测量退化之前发现其对频繁训练的依赖性依然是一个的惊喜。

下文讨论了三种主要产品频繁机器学习训练的重要性，并讨论为适应这种频繁的训练所需要的基础架构支持，以及这一切是如何耦合到灾难后恢复性的。

如果不训练模型会发生什么？我们分析了三个利用机器学习训练的关键性服务，以确定那些不能频繁执行操作来训练更新模型（包括广告，新闻）和社区诚信所带来的影响。我们的目标是理解在失去训练模型能力的一个星期，一个月，六个月时间内所带来的影响。

第一个明显的影响是工程师的效率，因为机器学习的进度通常与频繁的实验相关。虽然许多模型可以在CPU上进行训练，但是在GPU上训练往往能够显著地提升模型性能。这些加速效果能够让模型迭代时间更快，以及并带来探索更多想法的能力。因此，GPU的损失将导致这些工程师生产力下降。

此外，我们确定了这个问题对Facebook产品的重大影响，特别是对频繁刷新其模型的产品。 我们总结了这些产品使用旧模型时出现的问题。

社交安全：创造一个安全的地方让人们分享和连接是Facebook的核心使命。 迅速而准确地检测攻击性内容是这项任务的核心。我们的社交安全团队十分依赖使用机器学习技术来检测攻击性的内容文字，图像和视频。攻击性内容检测是一种垃圾邮件检测的专门形式。对抗者会不断地寻找新的、创新性的方法来绕过我们的标识符，向我们的用户展示令人反感的内容。Facebook经常训练模型去学习这些新的模式。每次训练迭代都要花费几天的时间来生成用于检测令人反感的图像的精确模型。 我们正在继续推动使用分布式训练技术来更快地训练模型的边界，但是不完全的训练会导致内容退化。

消息推送：我们的发现并不令人惊讶，像消息推送样的产品对机器学习和频繁的模型训练依赖很大。在用户每次访问我们网站的过程中，为其确定最相关的内容，非常依赖先进的机器学习算法来正确查找和排列内容。与其他一些产品不同，Feed排名的学习方式分两步进行：离线步骤是在CPU / GPU上训练最佳模型，在线步骤则是在CPU上进行的持续在线训练。陈旧的消息推送模式对消息质量有着可量化的影响。消息推送团队不断在他们的排名模型上进行创新，并让模型模拟自身，进行几小时的不间断的训练，以此来推进模型的进步。而如果数据中心离线一个星期，带来的训练过程的损失计算就可能会阻碍团队探索新的能力模型和新的参数的进度。

广告：最令人惊讶的是频繁的广告排名模式的训练的重要性。寻找和展示合适的广告极其依赖机器学习及其创新。为了强调这种依赖的重要性，我们了解到，利用过时的机器模型的影响是以小时为单位来衡量的。 换句话说，使用一个旧的模型比使用一个仅训练一个小时的模型要糟糕得多。

总的来说，我们的调查强调了机器学习训练对于许多Facebook产品与服务的重要性。在日益增长的工作负荷面前，容灾工作不应该被低估。

容灾架构支持：上图展示了Facebook数据中心的基础架构在全球的分布情况。如果我们关注在训练和推理过程中CPU资源的可用性，那么我们将有充足的计算适应能力来应对几乎每个地区的服务器的损失需求。为GPU资源提供平等冗余的重要性最初被低估了。然而，利用GPU进行训练的初始工作量主要是计算机视觉应用程序和训练这些模型所需的数据，这些训练数据在全球范围内都能被复制得到。当GPUs刚开始被部署到Facebook的基础设施中时，对单一区域进行可管理性操作似乎是明智的选择，直到设计成熟，我们都可以基于他们的服务和维护要求来建立内部的专业知识。这两个因素的结果就是我们将所有生产GPU物理隔离到了另一个数据中心区域。

然而，在那之后会发生了几个关键的变化。由于越来越多的产品采用深度学习技术，包括排名，推荐和内容理解等，GPU计算和大数据的重要性将增加。此外，计算数据托管并复杂化是朝向一个巨型区域战略枢纽的存储方式。大型地区的概念意味着少数数据中心地区将容纳Facebook的大部分数据。顺便说一下，该地区所有的GPU群并没有驻留在大型存储区域。

因此，除了共同定位数据计算的重要性之外，思考什么可能情况将使我们完全失去了搭载GPU的区域，就变得尤为重要。而这个考虑的结果驱使我们为机器学习训练部署多样化GPU的物理位置。

未来的设计方向：硬件、软件和算法

随着模型复杂度和数据集规模的增长，机器学习的计算需求也随之增加。 机器学习工作负载反映了许多影响硬件选择的算法和数值的属性。

我们知道，卷积和中等尺寸的矩阵乘法是深度学习前馈和后向过程的关键计算内核。在批处理量较大的情况下，每个参数权重都会被更经常地重用，因此必须进行这些内核在算术强度（每个被访问内存字节的计算操作次数）方面的改进。提高算术强度通常会提高底层硬件的效率，因此在延迟的限制之内，以更大的数据批量运行是可取的做法。计算机器学习负载的上下限将有助于更宽的SIMD单元的使用，及专门的卷积或矩阵乘法引擎、专门的协处理器的部署。

在某些情况下，对每个节点使用小批量数据，在并发查询低的实时推理中或在训练过程中扩展到大量的节点的情况，也是必需的。小的batch规模通常会有较低的算术强度（例如，全连接层中矩阵的矢量乘法运算，本质上是有带宽限制的）。当完整模型不适合片上SRAM单元或最后一级缓存时，这种small batch数据可能会降低几个常见情况的性能。

这个问题可以通过模型压缩，量化和高带宽内存来缓解。模型压缩可以通过和/或量化稀疏来实现。训练期间的稀疏修剪连接（Sparsification prunes connections）会导致一个更小的模型。量化使用定点整数或更窄的浮点格式来压缩模型，而不是用于加权和激活的FP32（单精度浮点）。目前已经有一些使用8位或16位的常用网络，被证明了相当的准确性。还有一些正在进行的研究工作是使用1或2位对模型权重进行压缩。除了减少内存占用量外，修剪和量化还可以通过降低带宽来加速底层硬件，并且允许硬件架构在使用固定点数进行操作时具有更高的计算速率，这比运行FP32值更有效。

缩短训练时间，加快模型传递需要分布式训练。正如在第四节B中讨论的那样，分布式训练需要对网络拓扑结构和调度进行仔细的协同设计，以有效利用硬件并实现良好的训练和质量。正如第III部分B节中描述的，分布式训练中最广泛使用的并行性形式是数据并行性，，这需要同步所有节点的梯度下降，要么同步要么异步。同步SGD需要全部减少操作（all-reduce operation）。 当使用递归加倍（和减半）执行时，全部减少操作呈现出来的一个有趣的属性是带宽需求随着递归级别呈指数级下降。

这鼓励了我们进行分层系统的设计，其中的节点在层次结构的底部形成超节点连接（例如，通过高带宽点实现点到点的连接或高位开关）；在层次结构的顶部，超节点通过较慢的网络（例如，以太网）连接。换句话说，异步SGD（不等待其他节点处理批处理）更难，通常需要通过共享参数服务器完成; 节点将其更新发送到参数服务器，该服务器聚合并将其分发回节点。为减少更新的陈旧程度并减轻参数服务器的压力，混合设计可能是个好的思路。在这样的一个设计中，异步更新发生在超节点内具有高带宽和低延迟连接性的本地节点，而同步更新发生在超节点之间。进一步增加扩展性需要增加批量的大小而不是以牺牲收敛性为代价。不管是在Facebook内部还是外部，这都是一个很活跃的算法研究领域。

正如第II部分所描述的，在Facebook上我们的使命是为那些基于机器学习的应用程序构建高性能，节能的机器学习系统。我们正在不断评估和构建新颖的硬件解决方案，并保持算法的变化及其对系统潜在影响的关注。

结论

基于机器学习的工作负载重要性的增加正在影响到系统堆栈的所有部分。对此，计算机体系结构社区如何做出最好的应对策略以及由此产生的挑战将成为大家越来越关注的一个话题。虽然以前我们已经围绕有效地处理ML训练和推理的必要计算进行了大量工作，但是考虑到解决方案在应用到大规模数据时将出现挑战，情况就会发生改变。

在Facebook，我们发现了几个关键因素，这些因素在规模化以及驱动数据中心基础架构的设计决策时非常重要：数据与计算机协同定位的重要性，处理各种机器学习工作负载（不仅仅是计算机视觉）的重要性，由非高峰期的每日循环产生的剩余容量而带来的机会。我们在设计包含定制设计的，易于使用的开源硬件的端到端解决方案，以及平衡性能和可用性的开源软件生态系统时，考虑了上述每一个因素。这些解决方案现在正在服务超过21亿人的大规模机器学习工作负载提供强大的动力，同时也体现了相关专家在跨越机器学习算法和系统设计方面所付出的努力。