Atlas超算平臺基於 Fluid + Alluxio 的計算加速實踐

導讀： 雲知聲 Atlas 超算平臺作為底層基礎架構，支援著公司在 AI 各個領域的模型訓練與推理服務的開展。該計算叢集可為 AI 計算提供高效能運算和海量資料的儲存訪問能力。該平臺支援主流機器學習架構，開發者能夠實現語音、語言、大資料、多模態等核心技術的高效研發。

Atlas 利用 Fluid + Alluxio 提高了平臺模型生產效率，本次將會從雲知聲引入分散式快取的背景、引入快取遇到的挑戰與解決、如何基於全新的技術進行架構的設計與優化、如何在內部進行推廣與生產實踐以及平臺後續改進點進行分享。

圖 1 分享題目

今天的分享包括四個方面的內容：

• 雲知聲Atlas超算的背景，以及早期遇到的一些問題

• Atlas與Alluxio如何合作、探索和結合，如何進行適配

• 基於Atlas全新架構的實驗

• Atlas帶來的收益以及對未來的展望

圖2 分享目錄

️

 掃碼觀看本文視訊回放 :point_down: 

雲知聲是一傢俱有自主智慧財產權的語音公司。技術棧包括語音、語義理解、影象、文字理解等多模態的AI技術基礎，通過雲上、使用者端、AI晶片端三大解決方案支撐AI技術的落地。目前已經在醫療、教育、智慧酒店、智慧家居等都有落地的解決方案。 

Atlas作為公司AI模型研發與迭代的基礎架構，為AI生產提供了高效的計算能力以及海量資料的訪問能力。

圖3 公司技術架構

1. Atlas超算的架構

下面介紹Atlas超算的架構。

圖4 公司技術架構

上圖是Atlas的深度架構，支援深度學習模型端到端的訓練。深度學習的整個生命週期包含資料處理、模型訓練以及模型推理。架構上從上層支援各種各樣AI的應用，比如：語音語義、影象的處理。支援的計算包括資料的預處理、特徵提取以及資料的分析。具體的模型包括了深度學習模型、大資料計算。倒數第二層是核心控制層，基於雲原生的元件進行了二次開發以及早期自研的一些元件。具備的功能包括幫助使用者自動分配任務、排程到後端底層硬體節點等。

最底層是海量GPU卡，包括A100、V100、RTX6000等高效能運算卡。底層儲存包括多套分散式檔案系統，以Lustre分散式檔案系統為主。混部式網路包括100GB InfiniBand高效能網路以及40GB乙太網。

使用者提交作業流程，提供命令列及WebUI方式。使用者可以用命令列提交任務；Atlas核心層幫助使用者進行任務的分發與排程；最後到達底層硬體進行計算。

Atlas的模型訓練是基於Kubernetes的容器化方式，容器讀取儲存基於hostpath 方式，在每個儲存節點都安裝分散式儲存客戶端。GPU的埠直接通過hostpath與儲存客戶端進行互動，客戶端再與分散式儲存進行資料互動。

2. Atlas 早期遇到的問題

下面介紹Atlas在早期遇到的問題。

圖5 Atlas 早期遇到的問題

（1）儲存頻寬瓶頸

Atlas有上千塊GPU計算卡，每塊卡的計算能力非常強，儲存頻寬與IOPS要求比較高。但由於底層的分散式儲存系統頻寬有限，而且有些節點併發的頻寬就達到數 GB/s,整個叢集上千塊 GPU 計算卡所需要的總體頻寬非常大。頻寬與計算能力之間存在差距，因此出現了部分任務計算效率較低。

（2）同GPU節點的IO頻寬競爭

像TTS場景下鏈路是單機單卡、或單機雙卡或叄卡， 同GPU計算節點會有5-6個使用者鏈路。多個鏈路在同GPU節點上，出現了IO頻寬競爭。通過監控可以看到，由於IO沒有跟上，導致GPU利用率低。

（3）海量小檔案

大量的Wav格式語音以及JPG格式影象散檔案，這樣的小檔案太多會造成儲存系統元資料壓力大。

（4）資料冗餘

每個部門或組、合作單位，都以目錄形式儲存在分散式儲存中。不同目錄的許可權不同，造成相同資料集分佈在不同的目錄上，重複儲存，造成儲存冗餘和空間浪費。

3. 早期問題的解決方案

針對以上早期遇到的問題，提出了下面的解決方案。

圖6 Atlas 早期解決方案

（1）儲存資源限制

在每個計算節點上限制最高頻寬；儲存側基於使用者級別使用者的uid和gid對頻寬與IOPS進行限制。

（2）限制小檔案

限制使用者的檔案數，要求使用者將小檔案聚合成lmdb、tfrecord 大檔案的格式。但這種大檔案格式對音訊處理的模型降噪效果會產生影響；因此限制小檔案並不能解決所有的問題。

（3）重構任務排程器

優先將任務排程到空閒的節點，新增排程策略，從根本上避免同節點競爭。但由於整體資源緊張，還是很難徹底解決。

（4）多級快取

提供單節點的多級快取，任務提交與完成時，自動複製資料和刪除資料。但該方案缺 少自動化機制與元資料管理，且為單點實現，缺乏對快取的控制。

以上措施都未能從本質上解決所遇到的問題。

02

Atlas + Alluxio 適配

Atlas研發團隊從2019年接觸到Alluxio軟體，並經過數月功能、效能和穩定性的測試。從功能上與業務系統進行適配，包括上層與業務系統的適配和底層與儲存系統的適配。

1. Atlas + Alluxio

上層業務是基於Tensflow和Pytorch框架，它們全都用POSIX 進行檔案讀寫。Alluxio Fuse正好提供了POSIX的介面方式，與Atlas業務可以進行天然適配。Atlas的底層儲存與業界不同。大家通常是用PV/PVC方式訪問物件和分散式儲存，Atlas則是基於hostpath的方式。而Alluxio支援基於hostpath的儲存掛載方式。以上兩點是引入Alluxio的關鍵點。

Alluxio支援許可權的繼承，底層的許可權能繼承到快取上，功能上Alluxio能夠滿足業務端的要求。Atlas對業務端的效能進行了測試，包括語音、降噪等方面。

在部署方面，Alluxio支援二進位制、容器和Kubernetes方式進行部署。Atlas與Alluxio兩者的技術棧匹配度非常高，並能以廉價的方式解決頻寬與效能的瓶頸問題。  

圖7 Atlas + Alluxio 適配

2. 為什麼選擇Fluid

2020年Fluid早期開源時，Atlas作為第一批使用者加入Fluid社群。選擇Fluid主要有以下考慮：

圖8 選擇Fluid的收益

Alluxio有數百配置項，這樣的調優配置非常適合於Atlas繁雜的應用和資料型別，包括小檔案，中檔案和大檔案；但Alluxio的Docker方式並不適合。

Alluxio單套部署的爆炸半徑大；而Atlas需要Fluid的輕量級、爆炸半徑小，方便應對意外情況，盡力保證使用者的應用繼續進行。

在對效能方面進行測試時，發現把整套Alluxio作為快取資料集，放在某臺GPU節點上，會佔用較多資源。

Fluid使快取具有可觀測性和可操作性。在而Alluxio的Docker方式，快取會直接排程到機器，使用者無法觀察和管理。

通過Fluid可以新增更多排程策略。可以基於特定卡型別和網路型別，排程到特定節點，使排程會更加高效。

3. Atlas + Fluid + Alluxio

現在整體的架構如下圖所示。 現在是三層架構，核心控制層是Kubernetes + Kuberflow。 在資料快取的控制層部署了Fluid。Fluid有Dataset和Runtime的概念，用核心控制層部署相應Fluid元件。Fluid作為中間資料管控層管理、部署Alluxio叢集，部署Alluxio Worker、Fuse和Master，讓Alluxio做底層分散式儲存的互動。

流程也發生變化： 之前使用者提交任務請求直接到核心控制層，任務排程器幫著做排程，分發到GPU計算節點，GPU節點通過hostpath直接去讀取儲存。

現在全新的架構流程變化為 ：使用者首先建立一個快取，比如排程到A100、V100節點，通過新增相應的策略，明確所需的快取介質，交給API Server，之後請求會被轉交給Fluid控制。Fluid會幫助使用者進行排程，排程任務到相應的GPU節點。

下圖所示啟動了2個Alluxio Worker叢集，會排程到2個節點，準備好與底層UFS的互動、FUSE跟PV/PVC相應的元件。快取建立完成之後，再去提交帶有快取的任務，任務排程器會自動選擇帶有快取的節點，通過與FUSE的互動直接讀取資料，變成三層架構。

圖9 Atlas + Fluid + Alluxio新架構

4. 業務適配#1 – nonroot 與 hostpath 支援

Atlas在早期進行適配時遇到了一些 問題 ，主要是與底層儲存系統的適配：

（1）使用hostpath方式訪問儲存。

（2）整個超算的許可權控制體系基於LDAP。LDAP的運作方式是在所有CPU、GPU和儲存節點都部署LDAP客戶端，客戶端才與服務端進行互動。使用者資訊儲存在某個節點的SSSD資料庫中，而非傳統的/etc/passwd上，所以無法獲取使用者資訊。

（3）分散式檔案系統開啟了nonroot儲存功能，由於許可權管控，root無法訪問普通使用者的目錄。早期的許可權運作方式是：當任務交到節點時，會通過webhook自動注入使用者的uid和gid到training pod上。訓練節點上就有了使用者的uid和gid；然後再與儲存客戶端進行互動，通過uid和gid去讀取儲存系統。相當於使用者只能用自己的許可權，訪問僅限於自己的資料。

圖10 業務適配#1 - nonroot 與 hostpath 支援

通過與社群合作完成了以下儲存適配方案，解決了以上問題。

（1）Fluid支援hostpath掛載快取資料集。

（2）讀取使用者資訊的方式：在Fluid Fuse加入Init container，初始化時注入使用者資訊。Fuse掛載時以使用者uid和gid與使用者資料集進行繫結。Training pod也以同樣uid和gid讀取緩衝。上圖展示了訪問快取時的許可權所屬。

儲存適配是Atlas最大的適配部分，也是支撐後續進化的關鍵。

5. 業務適配#2 – 統一資源檢視

Atlas通過Alluxio提供了統一的資源檢視。

Atlas具有多套分散式儲存系統，每個使用者可以訪問多套儲存系統。如果使用者的資料集比較大（TB級），會分佈在不同的儲存系統上。為避免大量的無效資料遷移，通過Alluxio介面多套儲存系統，具備了統一資源檢視的能力。並具備了在主目錄下掛載不同儲存系統子目錄的功能。實現多套分散式儲存系統和資源的統一管理。

Fluid支援多掛載路徑，並聚合在統一的目錄下，實現統一訪問不同儲存系統下的快取資料集。

圖11 業務適配#2 – 統一資源檢視

6. 業務適配#3 – 資料預熱

在資料預熱方面， 基於Alluxio提供了distributed load功能 ，對於TB級海量小檔案，可以提前把資料集預熱好，而無需幾十個小時的資料載入過程，就可以很快享受到快取資料帶來的收益。

圖12 業務適配#3 – 資料預熱

7. 業務適配#4 – 自動化提交工具

早期使用者跑單節點的單機多卡和單機單卡。近期Atlas上了大量分散式訓練任務，例如 Pytorch DDP。在建立時，Fulid直接封裝為任務提交的介面，變成atlasctl cache create，只把必要的資訊暴露給使用者，如使用者想選擇的快取型別、快取大小、快取節點等必要資訊。 目前的流程變成：

（1）預先建立好快取資料集

（2）建立模型訓練任務

圖13 業務適配#4 – 自動化提交工具

03

基於Atlas全新架構的實驗

1.業務場景#1 – 語音降噪（小檔案）

上面介紹了主要架構和適配過程。下面介紹業務例項，如語音降噪。這些語音檔案都是非常小（小於1MB）的wav格式元檔案。之前直接讀取，IO會非常高，效率低。

圖14 業務場景#1 - 語音降噪

通過實驗，在小檔案場景下，採用10卡RTX6000、全部記憶體快取讀取資料，新的排程方式會有10倍速度的提升。

圖15 業務場景#1 - 語音降噪 測試結果1

從結果發現：

（1）訓練效率有提升。

（2）降低訓練時的底層儲存佔用頻寬；從監控上看，節點的頻寬基本為0。

（3）GPU利用率也有比較大的提升；原因是資料供給的充分，GPU利用率得以提升。

圖16 業務場景#1 - 語音降噪 測試結果2

2. 業務場景#2 – 影象分類（中等檔案）

這裡還做了Resnet50讀取ImageNet (tfrecord) 格式資料集。在RTX 6000節點上，模擬獨佔、7卡（3卡另外有任務）。配置如下圖所示。

圖17 業務場景#2 - 影象分類

結果如下圖所示，單位是每秒能處理圖片的張數。

從第一和第二行來看，Lustre獨佔方式是效果最好的方式；而對比組Alluxio緩衝方式，則直接提升了2.5倍的效率，中等大小檔案有著較大的收益。

圖18 業務場景#2 - 影象分類 測試結果

3. 實驗#3 – 大檔案

第三個實驗是大檔案測試，整個資料集是125GB的LMDB，進行文字識別。通過以下三種方式測試後發現，速度有30倍的提升。

（1）Lustre 讀取

（2）Alluxio讀取（未資料預熱）

（3）Alluxio讀取（資料預熱）

圖19 實驗#3 - 大檔案

圖20 實驗#3 - 大檔案 測試結果1

之前LMDB的頻寬是1GB以上，而這裡的收益是頻寬基本達到了0。節點頻寬佔用立刻下降。從後端的效能監控來看，頻寬明顯下降。

圖21 實驗#3 - 大檔案 測試結果2

4. 業務場景#4 – 語音識別（DDP+Alluxio）

第四個場景是最近和演算法團隊一起聯測的方案。 採用4機40卡、5 機50卡這種場景去做大量語音識別模型的訓練。採用原生Pytorch DDP方案，資料提前轉化為numpy格式 。測試時，由於已經實現了資料非同步讀取，此時頻寬利用率已經比較高。

實驗是對200GB資料集在2機20卡進行Pytorch 分散式訓練，在75 epoch 收斂 。通過DDP每個節點是100GB規模的資料快取。

圖22 業務場景#4 - 語音識別（DDP+Alluxio）

通過Alluxio 方案調優，時間由原來的20分鐘縮短為18分鐘，提速10%。

這說明在資料處理較好的情況下，依然能有10%的提速。

圖23 業務場景#4 - 語音識別（DDP+Alluxio）測試結果

04

收益與未來展望

1. 總體收益

通過Alluxio+Fluid方式幫助，獲取了以以下的收益：

（1）提高了模型的生產效率，小檔案場景有10倍的提速。

（2）降低底層分散式儲存系統的負載，單個節點有1-2GB頻寬。大量使用者使用時，對頻寬的佔用得以大幅下降。

（3）增加叢集GPU 利用率，提升使用者資料的讀取效率。

（4）更加高效的快取管理，通過視覺化方式觀察算法佔用快取數量及進度並加以度量，提升工作過程的可觀測性。

圖24 總體收益

2. 後續工作

目前在單機單卡、單機多卡有較多使用者，使用過程中依然發現一些問題並進行改進：

（1）使用者使用的是Atlas所提供的調優引數，希望通過與演算法團隊合作與測試，對特定場景的調優引數進行優化，把調優引數做成標準資料集，回饋社群。

（2）之前的資料集不是太大，TB或小於TB就直接用記憶體來做快取。現在每個節點上都部署了幾塊TB以上的SSD，計劃在以後的快取排程上，能更加高效的排程。Fulid社群一直在做這件事情，Atlas也一直在同步合作、跟進磁碟的排程能力。

圖25 後續工作

今天的分享就到這裡，謝謝大家。

在文末分享、點贊、在看，給個3連擊唄~

01 / 分享嘉賓

呂鼕鼕

雲知聲  超算平臺架構師

負責大規模分散式機器學習平臺架構設計與功能演進，負責深度學習演算法應用優化與 AI 模型加速。研究領域包括大規模叢集排程、高效能運算、分散式檔案儲存、分散式快取等。雲原生開源社群愛好者。

02 / 免費下載資料

03 / 報名看直播 免費領PPT

04 / 關於我們

DataFun： 專注於大資料、人工智慧技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章700+，百萬+閱讀，14萬+精準粉絲 。

  分享、點贊、在看 ，給個 3連擊 唄 ！ :point_down: