Facebook如何運用機器學習進行億級用戶數據處理

編譯 | AI科技大本營（微信搜索：rgznai100，獲取更多乾貨內容）

參與 | 劉暢、尚岩奇、林椿眄

審校 | reason_W

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，機器學習的一個顯著特徵就是有可用於模型訓練的海量數據。這個數據的規模會帶來很多涉及到整個機器學習架構的影響。

使用機器學習的主要服務

• 消息推送

消息推送排名演算法能夠使用戶在每次訪問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顯示了這些機器學習模型類型和產品/服務之間的映射關係。

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 ，常用於涉及大量計算和存儲的服務。

由於我們訓練的神經網路越來越大，並且越來越深，我們開發出了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模型。如果可以儘可能地利用高效平台以及多餘的存儲容量，則平台的總體訓練效率會非常優秀。

機器學習系統依賴於使用實例數據的訓練。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的主要服務會不斷地權衡擴展模型的利與弊。這些考慮可以決定網路容量需求的變化。

在線推理的資源需求

在完成離線訓練之後的線推理步驟中，我們需要將模型載入到機器中，使用實時輸入運行模型來生成網站流量的實時結果。

接下來我們將討論，一種實際應用中的在線推理模型——廣告排名模型。這種模型可以篩選成千上萬條廣告，在消息推送中顯示排在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億人的大規模機器學習工作負載提供強大的動力，同時也體現了相關專家在跨越機器學習演算法和系統設計方面所付出的努力。

原文：https://research.fb.com/wp-content/uploads/2017/12/hpca-2018-facebook.pdf