|
“雙11”了，對于廣大網購愛好者來說那絕對是不可錯過的狂歡時刻！當今網購之所以如此火爆，不僅僅是營銷策劃的作用，智能化的搜索推薦技術也可以說是功不可沒。它能把你日思夜想或者潛意識中動過購買念頭的商品通通推送到你的面前，甚至會讓人有一種冥冥自有天意、不買對不起上蒼的感覺。而這背后往往都會有深度學習領域中個性化推薦模型發揮著威力。為了能夠更準確的預知用戶的內心需求，快速訓練出效果良好的推薦模型并盡快部署上線，成為了各大網購業務相關企業的共同追求。 在搜索推薦領域中，通常推薦模型的網絡并不復雜，但是由于對應的特征空間大，所以通常會使用算力要求不高但是規模非常龐大的Embedding和FC層來將用戶及商品的高維稀疏特征向量轉化為低維的稠密特征向量，導致這類模型的參數維度可以達到千億甚至萬億級別，并且還伴隨著大規模稀疏的特點。同時各個企業為了模型效果，往往會使用盡可能多的數據來訓練模型，尤其是其中的點擊數據，如果來自一些帶有“選擇困難癥”的人，可能會非常的長，導致數據規模愈加龐大，甚至可以達到億級。因此，相比CV和NLP領域而言，在搜索推薦場景中，單次Batch訓練中前后向計算的時間遠低于數據讀取、拉取和更新參數等過程的時間，再加上龐大的數據和參數量，導致內存要求很高，甚至可以達到幾十T，而擁有這類特點的訓練任務通常都被稱為IO密集型訓練任務。 那么如何快速完成IO密集型訓練任務呢？ 單機訓練肯定無法承受這樣的任務，只有分布式訓練才是解決問題的方法。簡單來說，分布式訓練就是使用多個硬件設備共同完成訓練任務，可以分為All-ReduceCollective和Parameter Server?參數服務器兩種訓練架構。 在Collective架構中，集群中存在多個地位平等的Trainer（也可以叫Worker）。在數據并行的方式下，每個Trainer上都保存一份完整的模型網絡結構和模型參數，在前向和反向計算過程中，每個Trainer使用自己劃分的數據（shard）進行計算，得到對應的梯度；然后Trainer之間通過All-Reduce等通信方式同步梯度到所有Trainer，最后每個Trainer使用同步后的梯度獨立完成參數更新。
圖1?Collective架構 由于推薦搜索領域模型的Embedding層規模龐大以及訓練數據樣本長度不固定等原因，導致容易出現顯存不足和卡間同步時間耗費等問題，所以Collective架構很少被用于搜索推薦領域。 再來看看參數服務器架構。與Collective相比，參數服務器架構中除了Trainer之外還有一個角色叫Server。在執行前向與反向計算過程中，Server負責從各個Trainer收集匯總梯度，然后使用這些梯度信息計算更新參數，并向各個Trainer分發更新后的參數信息。
圖2傳統參數服務器架構 但是在應對IO密集型任務時，傳統參數服務器模式會出現以下問題： 如果使用的是CPU機器作Trainer，通常CPU核心數較多，且購置價格便宜，訓練中可以充分利用CPU多核的優勢，使用異步訓練模式，在簡單模型上可以極大提升數據吞吐量，對提升整體訓練速度有不俗的表現。但是AI開發者為了追求模型效果開始逐步在推薦模型中增加復雜網絡部分，CPU計算能力的弱勢便暴露無遺，訓練耗時會變得不可接受。
圖3傳統參數服務器架構（CPU機器）遇到算力瓶頸 如果更新集群硬件，改為使用的是GPU機器作Trainer，則可能會出現資源利用率低和網絡帶寬不足的問題： 資源利用率低：IO密集型任務主要還是數據讀取和模型讀取IO的性能對訓練速度更具決定性。在這方面使用GPU的集群如同“殺雞用牛刀”，并不會對整體的訓練速度產生多少幫助，而且硬件資源得不到充分利用。而如果加大batchsize提高單次前向后向計算占比，也會受到單機IO吞吐能力的制約，而且由于模型高度稀疏，模型效果也會受到影響。 網絡帶寬不足：由于一臺GPU機器可以頂替多臺CPU機器，必然會導致整個集群網卡數量降低。這樣在將數據和模型下載到Trainer階段就很容易出現帶寬瓶頸。尤其是當Server和Trainer都在一臺設備時，一旦每個Trainer劃分的訓練數據過大，訓練準備階段就會變得極為耗時，整個訓練過程直接輸在了起跑線上。
圖4傳統參數服務器架構（GPU機器）遇到IO瓶頸 也許有人會提出直接將IO任務交給GPU機器上的CPU不就可以解決了嗎？答案是否定的。一臺GPU機器上的GPU和CPU的硬件配比是固定的，且單臺GPU的多卡相比多臺CPU機器而言，每個GPU卡對應的CPU核數相對較少，這就導致?GPU前向后向訓練的越快，對CPU讀數據和模型參數的要求就越高，這樣CPU反而更容易成為瓶頸，而且不能解決網絡帶寬不足的問題。 新型算力接入成本較大。隨著AI芯片發展日新月異，各種高算力低成本的芯片已進入工業實用化階段。在參數服務器模式下，一旦更換新型算力硬件，需要完成計算集群的遷移，軟件棧變更，訓練速度及效果打平等一系列工作。 那么有沒有可以高效調整機器配比，快速支持新硬件的接入，使用GPU等高算力的同時還不用擔心IO瓶頸的方法呢？ 魚與熊掌可以兼得？——異構參數服務器訓練架構 上面的要求好像很多，其實核心問題就在于硬件的配置，傳統的參數服務器對硬件的統一性要求太嚴格，而現實是單一“兵種”是無法應對大部分“戰場”的。如果能同時使用不同的硬件同時參與到訓練中，讓它們各司其職，發揮各自優勢，很多問題就可以迎刃而解了！ 為了應對上述問題，飛槳框架2.0版本基于工業實踐，創新性地推出了大規模稀疏異構參數服務器功能，一舉解除了傳統參數服務器模式必須嚴格使用同一種硬件型號Trainer節點的枷鎖，使訓練任務對硬件型號不敏感，即可以同時使用不同的硬件進行混合異構訓練，如CPU、AI專用芯片（如百度昆侖XPU）以及不同型號的GPU如V100、P40、K40等。同時還可以解決大規模稀疏特征模型訓練場景下，IO占比過高導致的芯片資源利用率過低的問題。通過異構參數服務器訓練架構，用戶可以在硬件異構集群中部署分布式訓練任務，例如云服務器集群，實現對不同算力的芯片高效利用，為用戶提供更高吞吐、更低資源消耗的訓練能力。
圖5異構參數服務器架構示意圖 異構參數服務器架構的原理 如之前所述，在傳統參數服務器模式下，前向及反向步驟在Trainer端完成，參數更新在Server端完成。而在異構參數服務器架構中，原先那樣粗粒度的任務分工顯然不再適用，只有讓不同硬件參加到訓練任務中，并在自己最擅長的領域工作，才能各顯神通。因此飛槳的研發人員在傳統的CPU-Trainer之外，又部署了一類Heter-Trainer，并在Heter-Trainer上配置有Service。這樣CPU-Trainer便將Heter-Trainer視為特殊的Server，從而對Heter-Trainer的異構算力不敏感，使Heter-Trainer可以混部各類不同型號芯片（例如GPU或XPU等）。 為了讓CPU-Trainer和Heter-Trainer完成不同類型的任務，飛槳將整個計算任務做了進一步的拆分。CPU-Trainer繼續負責數據讀取、參數的讀取和更新、參數的網絡傳輸等IO任務，甚至在小BatchSize訓練時，使用CPU處理更快的網絡層計算；而對于復雜網絡的計算，則CPU-Trainer會交給Heter-Trainer處理?？傊?，所有CPU相對GPU或XPU更擅長處理的操作都放在CPU中，其它的放在GPU或XPU中。
圖6傳統參數服務器架構的異構改造 值得注意的是，異構參數服務器架構并不只是簡單的將計算任務拆分。拆分后，異構硬件間的通信代價高的問題也需要解決。為了解決這個問題，飛槳的整個傳輸通信過程得到了優化。該過程將不會完全依賴于硬件自身的吞吐，而是引入類協程任務調度機制，該機制采用了異步等待和多Queue流水線等方式對任務進行靈活調度，避免傳輸隊列阻塞，對任務進行靈活調度，并且還優化了Heter-Trainer的吞吐機制，高效的避免傳輸隊列阻塞。 此外，異構參數服務器訓練架構在各個硬件設備上還引入了異構存儲機制，將模型訓練所用到的參數，按照一定層級分別存儲到SSD、內存和顯存中，并且支持參數在SSD、內存、顯存之間的快速拷貝，使模型規模不再受限于內存或顯存的規格，可以進一步支持更大參數規模的模型訓練。 如果用戶希望將現有GPU機器上的傳統參數服務器架構改造為異構參數服務器架構，則用戶可以通過飛槳從機器上劃分出部分CPU資源形成CPU-Trainer，然后再將原有的GPU-Trainer改造為Heter-Trainer。但是通常在此場景下， CPU-Trainer所能處理的數據，僅需要使用少量GPU資源組成的Heter-Trainer處理，便足以完成訓練計算任務，從而可以節省大量的GPU資源。 而對于將CPU機器上的傳統參數服務器架構改造為異構參數服務器架構的需求，飛槳可以支持用戶根據任務所需的實際算力靈活引入異構硬件（GPU或XPU）成為Heter-Trainer，這樣不僅可以保障資源的利用率，而且可以利用用戶手中的舊型號硬件機器，大大節約用戶的成本。這一特點也使異構參數服務器架構非常適合部署在云上異構集群場景中。
圖6傳統參數服務器架構的異構改造（外掛硬件，CPU機器為例） 飛槳的異構參數服務器架構不僅可以支持CPU機器、GPU機器和XPU機器的混合模式，而且支持全部CPU-Trainer或GPU-Trainer的那樣的傳統參數服務器的硬件組合，甚至在GPU單類型機器的集群內采用Heter模式，可以達到訓練提速的效果。 異構參數服務器的優勢 異構參數服務器兼顧了傳統參數服務器架構的大規模稀疏及異步優勢，充分利用了GPU等AI芯片帶來的算力上的提升，在模型訓練速度上顯著提升。 我們基于飛槳和其它框架，在如下架構上進行測試： 使用4臺GPU機器作Trainer的Collective架構（Collective-GPU）。 使用4臺CPU機器作Trainer的非異構參數服務器架構（PS-CPU）。 使用4臺GPU機器作Trainer的非異構參數服務器架構（PS-GPU）。 使用4臺CPU機器和若干GPU機器作Trainer的異構參數服務器架構（PS-Heter）。 其中CPU機器型號為IntelR XeonR Gold 6148，GPU機器型號為IntelR XeonR Gold 6148+Tesla V100 32G。 首先我們在簡單的CTR-DNN模型（FC層維度分別為“400-gt;400-gt;400-gt;2”）和Criteo數據集進行測試，模擬簡單IO密集型訓練任務。如下圖所示，我們可以看到對于簡單模型，飛槳異構參數服務器架構（PS-Heter，4 CPU+1GPU）性能表現優于其它訓練架構。
當我們擴大FC層維度（FC層維度分別為“4096-gt;2048-gt;1024-gt;2”），模擬復雜網絡時的IO密集型訓練任務，如下圖所示，可以看到PS-CPU架構的性能下降顯著。
然后改為使用GPU的架構進行測試，且統一使用4臺GPU機器，可以看到常用于復雜網絡計算的Collective-GPU架構的表現一般，都遠不如PS-GPU和PS-Heter（4CPU+4GPU）架構，而其中PS-Heter性能依然保持著優異的性能。
此外，在一些真實業務模型上使用單臺GPU/昆侖芯片機器+10臺CPU機器，可以完成千萬數據千億參數點擊率模型的分鐘級訓練。 上手體驗 為了能讓廣大用戶快速上手異構參數服務器訓練架構，飛槳在操作方面做的也比較簡單，不僅配有成熟的腳本么，并且僅需要補充簡單的幾行代碼，就可以將傳統參數服務器訓練架構修改為異構參數服務器架構。 本示例需要運行在Linux環境下，Python版本不低于2.7，且飛槳開源框架版本為最新分支版本（Develop版本）。具體操作步驟如下所示： 1.數據下載 執行腳本sh download_data.sh，系統會從國內源的服務器上下載Criteo數據集，并解壓到指定文件夾。 全量訓練數據放置于./train_data_full/； 全量測試數據放置于./test_data_full/； 用于快速驗證的訓練數據與測試數據放置于./train_data/與./test_data/ 2.構建一個三層的CTR-DNN網絡，并將其中需要算力的網絡層配置給GPU處理。
3.調用Paddle分布式Fleet?API，添加運行策略，設置異構設備Heter-Trainer使用GPU作為運算設備，然后完成反向組網。
4.分別進入不同設備的運行邏輯 1啟動Server與Heter-Trainer?
2啟動CPU-Trainer，執行數據IO及總體訓練流程控制
5.啟動異構參數服務器 飛槳對分布式訓練的啟動代碼進行了易用性封裝，使用fleetrun命令即可快速啟動分布式訓練：
當訓練結束后可以看到任務成功的顯示信息，如下所示。
Server上的顯示信息
Heter-Trainer上的顯示信息
CPU-Trainer上的顯示信息 |
- 關注天氣:
