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

語言: CN / TW / HK

分享嘉賓 :呂鼕鼕 雲知聲 超聲平臺架構師

編輯整理:曾新宇 對外經貿大學

出品平臺:DataFunTalk

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

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

圖 1 分享題目

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

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

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

  • 基於Atlas全新架構的實驗

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

圖2 分享目錄

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

01

雲知聲  A tlas 超算背景

雲知聲是一傢俱有自主智慧財產權的語音公司。技術棧包括語音、語義理解、影象、文字理解等多模態的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: