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億人的大規模機器學習工作負載提供強大的動力,同時也體現了相關專家在跨越機器學習算法和系統設計方面所付出的努力。
-
Facebook
+關注
關注
3文章
1429瀏覽量
54754 -
機器學習
+關注
關注
66文章
8418瀏覽量
132635 -
深度學習
+關注
關注
73文章
5503瀏覽量
121162
原文標題:Facebook如何運用機器學習進行億級用戶數據處理
文章出處:【微信號:AI_Thinker,微信公眾號:人工智能頭條】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論