陳 培, 王 超, 段國棟, 王德奎, 王 斌, 王文瀟, 孫遼東, 荊榮訊,邢良占, 劉慧興, 姬貴陽

(浪潮電子信息產(chǎn)業(yè)股份有限公司, 濟南 250101)

近年來人工智能技術(shù)快速發(fā)展, 尤其是深度學(xué)習(xí)方面取得了諸多令人矚目的成就, 而Kubernetes作為下一代分布式系統(tǒng)的主流, 作為云原生的新生力量, 其發(fā)展也是十分迅速, Kubernetes有著完善的組件和工具生態(tài)系統(tǒng), 能夠減輕應(yīng)用程序在公有云或私有云中運行的負擔(dān), 并且可以和任何場景結(jié)合, 另外Kubernetes的插件化、組件化開發(fā)方式能夠支持更多定制化的設(shè)計開發(fā)工作, 這些優(yōu)點讓越來越多的開發(fā)者和互聯(lián)網(wǎng)企業(yè)將人工智能應(yīng)用部署在Kubernetes集群上. 但由于Kubernetes并不是主要針對深度學(xué)習(xí)設(shè)計, 對深度學(xué)習(xí)這個特定領(lǐng)域需要做定制優(yōu)化.

目前針對Kubernetes集群部署深度學(xué)習(xí)應(yīng)用已有很多優(yōu)化嘗試, 如國內(nèi)騰訊的Gaia調(diào)度系統(tǒng)[1,2]能夠細粒度使用GPU資源, 但是并沒有針對數(shù)據(jù)集使用和分布式訓(xùn)練進行優(yōu)化. 對于GPU虛擬化使用, NVIDIA推出了Multi-Process Service[3]和virtual GPU (vGPU)[4]兩種方案, 但MPS具有故障傳遞限制[5]而且vGPU需要授權(quán)使用, 其他的很多開源方案在具體實踐應(yīng)用上都有一定的局限性.

本文針對具有一定規(guī)模的Kubernetes集群上部署深度學(xué)習(xí)負載的場景, 設(shè)計和實現(xiàn)了一系列的優(yōu)化方案, 并且已經(jīng)在實際生產(chǎn)環(huán)境中實踐, 取得了良好的效果.本文從深度學(xué)習(xí)所要求的數(shù)據(jù)處理、graphics processing unit (GPU)計算、分布式訓(xùn)練等幾個方面進行優(yōu)化, 主要優(yōu)化方面有以下幾點: 針對目前人工智能應(yīng)用只能占用整數(shù)GPU卡資源, 難以實現(xiàn)GPU卡資源多任務(wù)復(fù)用的場景, 提出GPU多任務(wù)共享調(diào)度技術(shù),能夠?qū)崿F(xiàn)多種應(yīng)用共享同一張GPU卡資源, 極大限度的挖掘GPU計算力, 提升GPU的使用效率; 隨著訓(xùn)練數(shù)據(jù)集規(guī)模的快速增長, 提出訓(xùn)練數(shù)據(jù)集預(yù)加載技術(shù)能快速提高數(shù)據(jù)集讀取速度進而提高單機和分布式的訓(xùn)練速度; Kubernetes的原生調(diào)度系統(tǒng)和策略并不能很好的滿足目前人工智能場景, 因此提出了針對non uniform memory access (NUMA)特性[6]、數(shù)據(jù)集親和性的優(yōu)化調(diào)度技術(shù). 本文提出的優(yōu)化方案覆蓋了數(shù)據(jù)處理、計算等方面, 以上技術(shù)極大簡化人工智能負載在規(guī)?；圃脚_上的部署難度和提高運行效率,同時從實踐上來看也驗證以上技術(shù)對人工智能應(yīng)用有著顯著的提升作用.

1 基于緩存機制的數(shù)據(jù)讀取加速技術(shù)

云原生上部署深度學(xué)習(xí)應(yīng)用時, 會遇到對接不同底層存儲的情況, 諸多實驗表明, 不同存儲系統(tǒng)對深度學(xué)習(xí)訓(xùn)練性能是有著不同程度的影響. 訓(xùn)練開始時, 存儲系統(tǒng)的性能會極大的影響訓(xùn)練數(shù)據(jù)的加載和后續(xù)訓(xùn)練數(shù)據(jù)的持續(xù)讀取, 如network file system (NFS)[7]等傳統(tǒng)存儲系統(tǒng)對于海量數(shù)據(jù)和海量小文件數(shù)據(jù)的讀寫性能不是很高, 而在深度學(xué)習(xí)訓(xùn)練場景(圖片、視頻、語音等)中的訓(xùn)練數(shù)據(jù)大多是以文件形式而存在, NFS系統(tǒng)在很多實際場景都會使用, 這樣會很大程度上影響訓(xùn)練數(shù)據(jù)的讀取速度進而影響整體訓(xùn)練性能. 高性能存儲系統(tǒng)如BeeGFS[8]等, 如果在高并發(fā)、大數(shù)據(jù)量和網(wǎng)絡(luò)帶寬有限制情況下也會出現(xiàn)性能下降問題. 因此, 加速訓(xùn)練過程的數(shù)據(jù)前期讀取和簡化在云原生上對不同存儲的對接亦是業(yè)界熱門問題, 本文提出在Kubernetes集群上利用本地高性能存儲設(shè)備進行數(shù)據(jù)緩存進而提高訓(xùn)練過程前、中的數(shù)據(jù)讀取速率, 大大減少對存儲系統(tǒng)和網(wǎng)絡(luò)的依賴, 另外根據(jù)深度學(xué)習(xí)任務(wù)特性進行針對性優(yōu)化, 與直接使用傳統(tǒng)存儲系統(tǒng)的表現(xiàn)相比這些改進提高了訓(xùn)練性能.

Kubernetes集群上完成對數(shù)據(jù)集緩存需要對訓(xùn)練數(shù)據(jù)進行很多的針對性處理和設(shè)計, 本文對Kubernetes集群上數(shù)據(jù)集本地和節(jié)點緩存兩種情形設(shè)計了一套緩存系統(tǒng), 該緩存系統(tǒng)要求需要對數(shù)據(jù)集生命周期具有細粒度的管理特性. 數(shù)據(jù)集緩存系統(tǒng)共分為兩種方式, 即本地模式和節(jié)點緩存模式. 本地模式即直接使用從存儲系統(tǒng)中讀取和使用數(shù)據(jù)集, 不做任何緩存, 數(shù)據(jù)讀取速率則完全依賴于存儲系統(tǒng)性能或者網(wǎng)絡(luò)帶寬. 節(jié)點緩存模式即本文提到的數(shù)據(jù)緩存加速機制實現(xiàn), 在運行訓(xùn)練任務(wù)的節(jié)點上進行數(shù)據(jù)集緩存和管理, 這樣在訓(xùn)練時存儲系統(tǒng)性能和網(wǎng)絡(luò)帶寬就不會是瓶頸, 如果底層存儲介質(zhì)為高性能設(shè)備如SSD、NVMe則會有更大的增益.

本文針對訓(xùn)練使用數(shù)據(jù)集的過程做了主要以下優(yōu)化工作:

(1) 設(shè)計dataset-agent 實現(xiàn)在Kubernetes內(nèi)數(shù)據(jù)集的本地和節(jié)點緩存兩種使用模式.

(2) 針對大數(shù)據(jù)集和海量小文件數(shù)據(jù)緩存過程進行了優(yōu)化并提高效率.

(3) 簡化使用過程和能夠?qū)硬煌鎯? 使用者無需關(guān)注底層存儲系統(tǒng).

兩種數(shù)據(jù)集使用方式的架構(gòu)如圖1和圖2所示.

圖1 本地模式架構(gòu)圖

本地模式數(shù)據(jù)讀取為直接使用存儲系統(tǒng), 不在本文中詳述, 整體架構(gòu)如圖1所示, 實現(xiàn)邏輯為管理節(jié)點的Kubernetes API Server接收到用戶任務(wù)請求后下發(fā)訓(xùn)練任務(wù)數(shù)據(jù)集名稱、存儲位置等信息給Kubernetes,然后Kubernetes的調(diào)度器調(diào)度訓(xùn)練Pod到相應(yīng)節(jié)點上進行訓(xùn)練, 其中數(shù)據(jù)集的加載和管理則完全依靠集群內(nèi)的存儲系統(tǒng)進行管理, 如上所述, 性能和使用邏輯則完全依靠存儲系統(tǒng), 由于分布式和共享存儲的訓(xùn)練數(shù)據(jù)讀取很大程度上會與網(wǎng)絡(luò)環(huán)境強相關(guān), 因此對訓(xùn)練性能會有一定程度的影響, 取決于網(wǎng)絡(luò)設(shè)備性能和并發(fā)量, 節(jié)點緩存模式則避免上述問題.

節(jié)點緩存模式的架構(gòu)如圖2所示, 各個計算節(jié)點上都會部署dataset-agent服務(wù)即數(shù)據(jù)集代理服務(wù), 主要管控數(shù)據(jù)集緩存的生命周期, 包括數(shù)據(jù)集緩存創(chuàng)建、刪除、更新等信息. 其實現(xiàn)機制為在實際訓(xùn)練開始前提前將訓(xùn)練用數(shù)據(jù)集緩存到被調(diào)度使用的節(jié)點, 這樣在實際訓(xùn)練時, 訓(xùn)練數(shù)據(jù)則為本地數(shù)據(jù), 不再受存儲系統(tǒng)或者網(wǎng)絡(luò)性能的影響. 具體實現(xiàn)邏輯為Kubernetes管理節(jié)點接收到訓(xùn)練任務(wù)請求后, 在承載訓(xùn)練任務(wù)的Pod中通過init-container形式將訓(xùn)練所需的信息如數(shù)據(jù)集名稱等進行封裝, Kubernetes調(diào)度Pod成功后, initcontainer首先會將數(shù)據(jù)集信息下發(fā)到部署到該節(jié)點上的dataset-agent, 隨后dataset-agent進行校驗(數(shù)據(jù)一致性)決定是否訪問存儲系統(tǒng)進行數(shù)據(jù)集拉取進行緩存.

圖2 節(jié)點緩存架構(gòu)圖

如果該節(jié)點進行了節(jié)點數(shù)據(jù)緩存, 即在訓(xùn)練節(jié)點上的存儲設(shè)備上就會有相應(yīng)的訓(xùn)練數(shù)據(jù).數(shù)據(jù)緩存結(jié)束后, 隨即啟動訓(xùn)練程序Pod同時將緩存的數(shù)據(jù)集進行掛載, 這樣就能直接利用本地存儲介質(zhì)進行數(shù)據(jù)讀取和訓(xùn)練, 消除了存儲系統(tǒng)和網(wǎng)絡(luò)的影響, 提高訓(xùn)練速度, 經(jīng)測試該系統(tǒng)能夠支持多種存儲系統(tǒng)包括NFS、LusterFS[9]、BeeGFS、HDFS[10]等.

節(jié)點緩存技術(shù)在部署到Kubernetes集群生產(chǎn)環(huán)境中時遇到很多實際問題, 為此針對如下一些主要情況做了優(yōu)化處理.

(1) 實際過程中一個訓(xùn)練任務(wù)會出現(xiàn)掛載多個數(shù)據(jù)集的情況, 所以將這樣一對多的組合作為一個請求任務(wù)進行管理, 同一訓(xùn)練任務(wù)在多次中只會有一條任務(wù)數(shù)據(jù), 避免了由于init-container重啟導(dǎo)致多次發(fā)起數(shù)據(jù)集緩存請求造成重復(fù)數(shù)據(jù)的情況.

(2) 數(shù)據(jù)集一致性比對, 主要是針對緩存數(shù)據(jù)集前的校驗工作, 針對數(shù)據(jù)集名稱相同, 通過比對原始數(shù)據(jù)集文件摘要和節(jié)點中數(shù)據(jù)集緩存的文件摘要來確認數(shù)據(jù)集和需要的數(shù)據(jù)集緩存是否相同, 這種比對規(guī)則的前提, 即假定節(jié)點中的數(shù)據(jù)集緩存不會變更, 也就是在緩存前生成的文件摘要是準(zhǔn)確不變的, 詳細流程見圖3.

圖3 數(shù)據(jù)集一致性比對流程示意圖

(3) 數(shù)據(jù)集緩存和鏡像拉取并行處理, 在節(jié)點沒有即將加載運行的鏡像情況下, 被調(diào)度到該節(jié)點的Pod相當(dāng)一段時間是在進行鏡像拉取工作, 由于該段時間資源(CPU、內(nèi)存等)已經(jīng)分配, 但是并沒有在實際使用這些資源, 因此可以有效利用Pod調(diào)度成功并且運行前這一時間段內(nèi)Pod的空閑資源來提升拉取數(shù)據(jù)集的效率, 這樣相對較小的數(shù)據(jù)集在鏡像拉取完成的同時也緩存完成.

(4) 自動清理數(shù)據(jù)集緩存, 當(dāng)計算節(jié)點空間不足時,清理緩存數(shù)據(jù)釋放空間就變得十分必要, 系統(tǒng)根據(jù)既定的規(guī)則自動清除, 清除策略發(fā)生在新訓(xùn)練任務(wù)緩存數(shù)據(jù)集, 但緩存空間不足時, 系統(tǒng)亦會清除緩存空間中未在使用的數(shù)據(jù)集, 且長時間未使用的數(shù)據(jù)集也會作為清除對象被自動清除, 當(dāng)清除的空間能夠滿足新數(shù)據(jù)集緩存時候, 即停止清除, 這里需要清除空間的大小是所需數(shù)據(jù)集大小的1.2倍.

(5) 支持多種存儲系統(tǒng)下的數(shù)據(jù)集操作, 即將相關(guān)配置信息放到Pod的yaml的環(huán)境變量中來解決.

(6) 多個數(shù)據(jù)集緩存進程并發(fā), 一個節(jié)點上的datasetagent可以處理多個數(shù)據(jù)集緩存操作來提高效率, 同時每個dataset-agent也做了多線程處理, 提高處理速度.

(7) 海量小文件數(shù)據(jù)集緩存優(yōu)化處理, 采用對待緩存數(shù)據(jù)進行壓縮后再進行傳輸完成節(jié)點緩存, 這樣極大提高帶寬的利用率, 實際測試中能夠有效減少因為網(wǎng)絡(luò)傳輸帶來的數(shù)據(jù)緩存延遲, 聚合傳輸測試出文件個數(shù)為5萬打一個包, 每個包的大小約為800 MB左右, 該設(shè)置下效率較高, 性能比命令傳輸提高6-8倍.聚合傳輸可根據(jù)實際業(yè)務(wù)場景調(diào)整聚合傳輸相關(guān)參數(shù),解決機器資源占用、傳輸效率問題.

(8) 特別針對NFS系統(tǒng), 通過使用NFS-RDMA技術(shù)[11](如圖4所示)在小文件傳輸方面性能提升2倍左右.通過NFS-RDMA V3協(xié)議在小文件傳輸上提高約1.5倍.

圖4 NFS-RDMA技術(shù)應(yīng)用示意圖

2 vCUDA-GPU虛擬化技術(shù)

GPU有著強大的處理并行計算任務(wù)能力, 其單一芯片上集成大量的計算核心的架構(gòu)設(shè)計使得GPU對于計算敏感性任務(wù)尤其適用. 當(dāng)前GPU已經(jīng)廣泛應(yīng)用于視覺、自然語言處理等領(lǐng)域來加速處理過程.

CUDA (compute unified device architecture)是NVIDIA針對GPU架構(gòu)提供的一套針對GPU的通用API平臺, 用戶可以通過CUDA簡單和快速的使用GPU以達到加速效果. 無論在公有云或者私有云, GPU設(shè)備已經(jīng)廣泛部署并使用, 起到了顯著的效果. 實際使用中GPU使用實例的類型也是多種多樣, 對底層計算資源的要求也不同. 作為底層提供計算資源支持的平臺對于用戶來說應(yīng)該是透明的, 需要做到按需索取和使用. 隨著深度學(xué)習(xí)業(yè)務(wù)廣泛鋪開和GPU的架構(gòu)快速迭代, 對于GPU計算資源的需求也變的多樣, 從單卡訓(xùn)練到分布式訓(xùn)練, 從獨占使用到多任務(wù)共享. 但Kubernetes、GPU (除Ampere架構(gòu)[12])和CUDA原生并不支持GPU細粒度調(diào)度和使用. 基于容器的GPU虛擬化的技術(shù)在Kubernetes上容器化使用GPU也同時面臨如下一些具體問題: 需要指定GPU設(shè)備[13]; 只能獨享該整個GPU設(shè)備[14], 不能多任務(wù)共享; 單一GPU使用容器間只能共享主機內(nèi)存[15].

本文提出一種能夠在互相隔離的容器間進行共享同一GPU設(shè)備內(nèi)存的方法來提高GPU的利用率.該方法不需要更改用戶的鏡像或者訓(xùn)練代碼即可達到GPU虛擬化的目的. 通過自定義修改的Kubernetes device plugin可以實現(xiàn)按顯存大小來分配GPU資源,即GPU可按顯存大小粒度進行調(diào)度使用, 不再局限于整卡級別的粒度, 同時進程間可以做到隔離, 保證用戶應(yīng)用不會互相影響. 除此之外利用unified memory技術(shù)[16]實現(xiàn)顯存的超分使用, 即在實際訓(xùn)練過程中可以保證超出GPU總顯存量進行訓(xùn)練, 在適量超出GPU顯存容量后保障較大模型正常訓(xùn)練.

由于docker出于安全對權(quán)限做了限制導(dǎo)致NVML接口[17]在容器內(nèi)無法查詢正在GPU上運行的進程, 為此本文針對GPU上正在運行進程的查詢機制做了優(yōu)化, 實現(xiàn)在容器內(nèi)可以查詢正在GPU上運行的進程信息, 可以正確的顯示該容器內(nèi)運行進程而不是主機上的進程以保證進程安全和訪問安全.

本文針對GPU虛擬化主要做了以下工作:

(1) 通過GPU sharing device plugin 實現(xiàn)在Kubernetes內(nèi)細粒度調(diào)度GPU任務(wù).

(2) 封裝CUDA driver API 實現(xiàn)GPU虛擬化使用.

(3) 添加顯存超分使用, 即超出GPU總顯存量可以繼續(xù)進行訓(xùn)練.

(4) 優(yōu)化NVML查詢GPU進程機制使得在容器內(nèi)正確顯示GPU上運行的進程信息.

2.1 Device plugin

Kubernetes的device plugin插件的主要用途為將計算資源信息(如GPU, RDMA, FPGA[18]等)發(fā)布給集群并無需修改Kubernetes核心代碼, 圖5展示了基本的device plugin與kubelet通訊過程, 主要通過兩個步驟實現(xiàn).

圖5 Kubernetes device plugin和各組件關(guān)系

(1) 資源發(fā)現(xiàn): 首先每種擴展的資源類型都作為一個device plugin形式展現(xiàn). Device plugin通過gRPC服務(wù)注冊到kubelet上. 注冊成功后, device plugin將其所管理的設(shè)備列表發(fā)送給kubelet. 最后kubelet負責(zé)將這些擴展資源發(fā)布給Kubernetes master;

(2) 資源分配: 當(dāng)用戶申請資源時, 調(diào)度器會將相應(yīng)的Pod調(diào)度到具有所申請擴展資源的節(jié)點上. 所在節(jié)點的kubelet會將設(shè)備使用請求發(fā)送給device plugin.然后device plugin將相應(yīng)的擴展資源分配給Pod. 但針對GPU等設(shè)備, 直接使用開源device plugin并不能針對GPU內(nèi)存進行細粒度的使用和分配.

本文中將現(xiàn)有的一些擴展設(shè)備資源(如GPU等)的device plugin進行優(yōu)化, 實現(xiàn)了以下功能: 基于Kubernetes標(biāo)準(zhǔn)的device plugin機制, 支持接入多種AI計算資源; 多種可調(diào)度的資源在業(yè)務(wù)上統(tǒng)一建模, 以資源名稱、數(shù)量、類型等; 信息描述接入集群的異構(gòu)實現(xiàn), 實現(xiàn)統(tǒng)一的調(diào)度、運維管理; 實現(xiàn)多device plugin管理插件, 由一個device plugin實現(xiàn)多個異構(gòu)資源的注冊、分配等, 且plugin的資源使用僅需要0.1 CPU/0.3 GB內(nèi)存, 降低運維成本; 實現(xiàn)GB粒度的資源管理以及GPU復(fù)用場景下的資源管理.

2.2 GPU虛擬化設(shè)計和實現(xiàn)

整體vCUDA架構(gòu)設(shè)計和流程如圖6所示, 主要由3部分組成: GPU sharing device plugin (以下簡稱GS device plugin), 調(diào)度器scheduler和vCUDA library.

圖6 vCUDA架構(gòu)和流程示意圖

(1) GS device plugin

其中經(jīng)過修改和優(yōu)化的GS device plugin 在各個節(jié)點上運行負責(zé)建立虛擬GPU設(shè)備和與kubelet進行通訊. GS device plugin發(fā)現(xiàn)設(shè)備上報時將GPU顯存視為一種資源進行上報, 這樣GPU顯存也可以作為可調(diào)度的Kubernetes集群資源進行使用.

(2)調(diào)度器 scheduler

調(diào)度器為GS device plugin提供其所申請的調(diào)度服務(wù), 調(diào)度成功后調(diào)度器會返回包含所分配GPU信息的響應(yīng).

(3) vCUDA library

在運行的Pod中vCUDA負責(zé)實際的內(nèi)存控制.vCUDA庫通過掛載的方式與運行的Pod進行綁定. 當(dāng)容器中應(yīng)用開始運行時, vCUDA通過對訓(xùn)練過程中內(nèi)存相關(guān)的API進行劫持從而實現(xiàn)內(nèi)存大小的控制和隔離, 主要由以下幾個部分組成:

(1) vCUDAManager: vCUDA library的總控制, 對于CUDA的操作均需要通過該類對象, 單例運行只初始化一次. 其中主要包括cudaManager、nvmlManager、gpuMemoryManager和dlsym的map管理.

(2) cudaManager: 管理所有CUDA API的劫持, 主要是cuMalloc類似的函數(shù), 當(dāng)分配顯存時調(diào)用此類的接口來控制OOM問題.

(3) nvmlManager: NVML API的劫持管理類, 主要是獲取NVIDIA GPU卡上各個進程運行的詳細信息,如顯存和進程PID.

(4) gpuMemoryManger: 記錄各個GPU卡的顯存利用信息, 當(dāng)分配顯存時會調(diào)用此類API判斷是否OOM.

GPU虛擬過程主要通過GPU的顯存申請和分配來實現(xiàn). 本文中以1 GB顯存作為基本粒度, 一個最終的內(nèi)存分配單元作為一個虛擬GPU設(shè)備.當(dāng)用戶申請一個規(guī)定大小(GB粒度)的虛擬GPU調(diào)度請求后, 調(diào)度器會將請求發(fā)布到給個節(jié)點上的kubelet, 由于GS device plugin已經(jīng)將其所管理的設(shè)備列表和資源信息發(fā)送給kubelet, 因此GS device plugin 在收到所分配的Pod為虛擬GPU的請求后將Pod所要創(chuàng)建的allocateResponse返回給kubelet進行資源創(chuàng)建即可, 其中包括基本的Pod環(huán)境變量, Pod掛載卷配置 (例如NVIDIA驅(qū)動, CUDA庫, vCUDA庫)和相應(yīng)設(shè)備.

另外通過dlsym劫持函數(shù)的map對象中, 針對NVML庫設(shè)置單獨劫持進行處理主要是為了防止其他應(yīng)用通過dlsym來調(diào)用CUDA和NVML的API, 例如nvidia-smi命令, 在使用CUDA劫持庫時始終保持結(jié)果一致性. 具體使用到的CUDA和NVML API如表1和表2所示.

表1 CUDA driver API使用情況

API類別 NVML API 描述Device-related APIs nvmlDeviceGetComputeRunning-Processes Get information about processes with a compute context on a device.nvmlDeviceGetHandleByUUID Acquire the handle for a particular device, based on its globally unique immutable UUID associated with each device.nvmlDeviceGetIndex Retrieve the NVML index of this device.nvmlDeviceGetMemoryInfo Retrieve the amount of used, free and total memory available on the device, in bytes.nvmlDeviceGetComputeRunning-Processes Get information about processes with a compute context on a device.

基于不同場景, 本文中提到GPU虛擬化實現(xiàn)如下場景支持:

(1) 基于GPU顯存隔離的GPU虛擬化

資源調(diào)度模塊將多個GPU訓(xùn)練任務(wù)調(diào)度到同一張GPU卡, 通過設(shè)置的顯存粒度大小, 對GPU顯存進行切片, 來限制每個任務(wù)對GPU顯存大小的使用.GPU任務(wù)通過設(shè)置的顯存粒度切片, 來達到不同任務(wù)所用顯存互相隔離的效果.

設(shè)置好需要使用的顯存粒度大小后, 具體使用時就把GPU卡整塊顯存按預(yù)置顯存粒度大小分割為多個粒度切片進行隔離. 如圖7上半部分場景所示, 4個GPU卡, 每個GPU卡的顯存大小為24 GB, 系統(tǒng)設(shè)置顯存粒度大小為8 GB, 這樣, 每個GPU卡就可以分割成3個 8 GB細粒度的GPU切片. 當(dāng)作業(yè)運行時, 作業(yè)會按GPU切片請求GPU資源, 像圖中task1就是要求4個GPU切片, 每個切片大小為8 GB. 然后系統(tǒng)資源調(diào)度器會針對顯存隔離場景作業(yè)執(zhí)行相應(yīng)的調(diào)度策略, 給task1分配了GPU0、GPU4、GPU2、GPU3卡中各1個顯存切片. 再看單個GPU卡中運行的多個作業(yè), 各作業(yè)所使用的顯存是互相隔離的, 如圖中GPU0卡運行的task1、task3、task4.

(2) 基于unified memory (UM)顯存隔離的GPU內(nèi)存使用優(yōu)化

NVIDIA的Pascal[19]之后架構(gòu)均已經(jīng)支持UM技術(shù), 得益于啟用UM機制, 將主機部分內(nèi)存分配給UM管理, UM可以用來統(tǒng)一管理分配作業(yè)請求的GPU顯存資源, 此時UM就擴展了系統(tǒng)中GPU可用顯存大小, 可以滿足運行更多的作業(yè)和對較大模型的支持. 圖7下半部分場景所示顯存粒度大小為8 GB時, 如圖所示按UM管理系統(tǒng)UM顯存容量為24 GB(其中8 GB為系統(tǒng)內(nèi)存), 這樣在資源調(diào)度器可以執(zhí)行UM場景下的調(diào)度策略, 即16 GB顯存大小的GPU卡就可以同時運行3個GPU作業(yè)(如圖7中task1、task2和task3), 每個作業(yè)使用8 GB顯存粒度. 此時, UM擴展了系統(tǒng)可用顯存容量, 支持運行更多的GPU作業(yè).

圖7 vCUDA適用場景說明

3 基于AI訓(xùn)練特點深度優(yōu)化的調(diào)度策略

3.1 節(jié)點內(nèi)NUMA親和性調(diào)度

NUMA (非統(tǒng)一的內(nèi)存訪問)是一種在多CPU系統(tǒng)上可用的技術(shù), 允許不同的CPU以不同的速度訪問不同部分的內(nèi)存. 任何直接連接到CPU的內(nèi)存都被認為是“本地的”, 并且可以快速地訪問. 沒有直接連接到CPU的任何內(nèi)存都被認為是“非本地的”, 并且將有可變或較長的訪問時間, 這取決于必須通過多少個互連才能到達目標(biāo). 在現(xiàn)代系統(tǒng)中, “本地”和“非本地”內(nèi)存的概念也可以擴展到外圍設(shè)備, 如NIC或GPU. 為了實現(xiàn)高性能, 應(yīng)該在分配CPU和設(shè)備盡可能的使它們能夠訪問相同的本地內(nèi)存.

NUMA拓撲管理就是用來處理實現(xiàn)高性能下的CPU與GPU等設(shè)備資源分配. 云原生上的很多深度學(xué)習(xí)負載除了依賴GPU計算能力之外, 對于某些特殊的應(yīng)用同樣對CPU也有著較強的依賴, 如數(shù)據(jù)前處理、數(shù)據(jù)搬運等過程. 因此在調(diào)度任務(wù)時, 考慮到NUMA拓撲特性, 將最優(yōu)化的NUNA組合分配給任務(wù), 則能起到提升整體集群的運行效率和資源利用率的效果.

總體上, 節(jié)點內(nèi)NUMA親和性調(diào)度遵循以下流程,如圖8所示: 當(dāng)Pod創(chuàng)建的時候, 節(jié)點kubelet中的topology manager 根據(jù)配置的 policy 策略來調(diào)度Pod,其中有如下調(diào)度策略:

圖8 NUMA親和性示意圖

(1) none (默認): 無策略, 極容易產(chǎn)生所調(diào)度的Pod使用的CPU、內(nèi)存和網(wǎng)卡分別位于不同的NUMA node上.

(2) best-effort: 根據(jù)當(dāng)前Pod的資源請求, 盡量滿足Pod分配的資源, 不滿足的就隨意劃分.

(3) restricted: 嚴格保證Pod資源請求, 如果資源不滿足Pod的affinity需求, Pod就會進入terminated狀態(tài).

(4) single-numa-node: 滿足policy的 Pod請求都會從一個單獨的NUMA node內(nèi)進行分配, 如果不滿足,Pod會進入terminated狀態(tài). 這個跟前兩個的區(qū)別是,前兩個可以請求從兩個NUMA node都分配資源.

3.2 模塊交互

本文提出的NUMA 拓撲管理通過topology-Manager和deviceManager、cpuManager、GPU設(shè)備之間交互來完成, 具體各模塊功能描述和交互過程如下和圖9所示.

圖9 Kubelet與device plugin 交互示意圖

(1) NUMA拓撲管理器topologyManager: 運行資源分配算法, 進行CPU和GPU資源的分配候選集的構(gòu)造生成、合并優(yōu)選和輸出最佳分配結(jié)果; 同時更新維護CPU和GPU已分配狀態(tài)信息.

(2) CPU管理器cpuManager: 提供獲取NUMA節(jié)點信息接口; 按分配算法執(zhí)行具體的CPU分配操作;更新CPU分配狀態(tài).

(3)設(shè)備管理器deviceManager: 提供GPU設(shè)備的NUMA信息; 按分配算法執(zhí)行具體的GPU分配操作,選取包含必選設(shè)備中的最優(yōu)設(shè)備組合, 具體說明如下:如當(dāng)前節(jié)點kubelet傳遞可用設(shè)備是[GPU-0, GPU-1,GPU-2, GPU-3], 考慮NUMA親和性的必選集[GPU-2,GPU-3]作為候選, 而實際業(yè)務(wù)需求為3個GPU卡, 則GPU 插件會根據(jù)內(nèi)置GPU通信打分規(guī)則(見表3)(該規(guī)則基于GPU與GPU間最優(yōu)連接方式而確定, 由于NVLink具有GPU間最佳的傳輸效率, 因此該連接方式分數(shù)為100且隨鏈數(shù)依次累加, 其他連接方式依次遞減). 按照上述打分規(guī)則從[GPU-0, GPU-1]中選取最優(yōu)的一個GPU (如GPU-0 (具有與GPU2或GPU3 NVLink連接))之后, 即組合[GPU-0, GPU-2, GPU-3]為最終分配組合; 其他功能如實現(xiàn)與GPU插件之間的業(yè)務(wù)接口和更新GPU分配狀態(tài)等.

表3 Device plugin 內(nèi)置通信打分規(guī)則(GPU對)

(4)快照管理器checkpointManager: 提供進行CPU和GPU分配狀態(tài)信息的生成、更新和刪除接口.

3.3 針對AI訓(xùn)練的Kubernetes集群數(shù)據(jù)集親和性調(diào)度

在集群上運行大規(guī)模數(shù)據(jù)集訓(xùn)練時, 會遇到如網(wǎng)絡(luò)帶寬的限制影響數(shù)據(jù)集讀取速率、訓(xùn)練Pod所在計算節(jié)點沒有數(shù)據(jù)集緩存等情況導(dǎo)致需要重新進行緩存配置, 這些情況在大數(shù)據(jù)集和復(fù)雜(文件類型多樣、海量小數(shù)據(jù)等)情況下會極大延長訓(xùn)練時間和占用網(wǎng)絡(luò)帶寬, 因此本文針對數(shù)據(jù)集的使用提出一種數(shù)據(jù)集親和性調(diào)度策略來提高本文第一部分提到的數(shù)據(jù)集緩存技術(shù)使用效率和間接減輕集群間由于數(shù)據(jù)集傳輸帶來的帶寬占用.

基本的數(shù)據(jù)集親和性準(zhǔn)則為盡量選擇作業(yè)Pod所需數(shù)據(jù)集完全匹配命中節(jié)點緩存數(shù)據(jù)集的節(jié)點. 對于未命中或部分命中的節(jié)點則忽略數(shù)據(jù)集親和性策略,具體則由圖10舉例說明數(shù)據(jù)集親和性, 如集群中有Node1和Node2兩個節(jié)點, 其中Node1上已緩存有數(shù)據(jù)集A, Node2上已緩存有數(shù)據(jù)集B.如果作業(yè)需要數(shù)據(jù)集A, 則調(diào)度器需要在Node1滿足預(yù)選條件時, 并完全匹配作業(yè)所需數(shù)據(jù)集時才能將作業(yè)調(diào)度到Node1上. 如果作業(yè)需要數(shù)據(jù)集A, Node1不滿足預(yù)選條件,Node2滿足預(yù)選條件, 則調(diào)度器會將作業(yè)調(diào)度分配到Node2上, 即數(shù)據(jù)集親和性調(diào)度是一種優(yōu)選算法策略.

圖10 數(shù)據(jù)集親和性場景

在進行數(shù)據(jù)親和性調(diào)度時會對待選節(jié)點進行打分,具體的得分計算方法如下.

節(jié)點緩存數(shù)據(jù)集得分公式:

其中, node為集群節(jié)點選擇器, 根據(jù)節(jié)點名稱參數(shù)nodename選擇節(jié)點; clusterNodeList為集群節(jié)點列表;NodeMatchDataSet為當(dāng)前節(jié)點匹配作業(yè)要求數(shù)據(jù)集;dsname為數(shù)據(jù)集名; podRqDS為Pod所需的數(shù)據(jù)集;UpdateDatasetInUse表示使用中的數(shù)據(jù)集需要更新;nodeCacheDataSet為該節(jié)點上已經(jīng)緩存的數(shù)據(jù)集.

公式說明:

NodeMatchDataSet為當(dāng)前節(jié)點匹配作業(yè)要求數(shù)據(jù)集, 當(dāng)Pod請求的數(shù)據(jù)集和當(dāng)前節(jié)點緩存數(shù)據(jù)集的交集如果匹配則累計該數(shù)據(jù)集, 否則過濾;

如果節(jié)點已緩存數(shù)據(jù)集并未完全匹配作業(yè)數(shù)據(jù)集,則節(jié)點得分為0;

如果作業(yè)要更新節(jié)點上正在使用的數(shù)據(jù)集, 則得分為0;

如果作業(yè)所需數(shù)據(jù)集全部命中節(jié)點緩存數(shù)據(jù)集,且數(shù)據(jù)集可用, 則節(jié)點數(shù)據(jù)集得分為完全匹配數(shù)據(jù)集個數(shù), 即作業(yè)所需數(shù)據(jù)集個數(shù);

如果解析作業(yè)所需數(shù)據(jù)集和節(jié)點數(shù)據(jù)集參數(shù)異常,則節(jié)點得分為0.

此分值為節(jié)點數(shù)據(jù)集原始得分, 后面還需經(jīng)歸一化處理后, 才能跟其它優(yōu)選策略共同作用調(diào)度結(jié)果. 該得分值越高, 優(yōu)先級越高, 得分越低, 優(yōu)先級越低. 如果節(jié)點沒有或者只有部分作業(yè)Pod所需的數(shù)據(jù)集, 則其得分為0; 如果節(jié)點上有Pod所需要的全部數(shù)據(jù)集, 則得分為最高值. 如果出現(xiàn)多個節(jié)點的數(shù)據(jù)集親和性得分相同且都為最高分, 調(diào)度器可參考其它優(yōu)選策略進行優(yōu)選.

4 實驗與分析

文中提到的vCUDA、NUMA、數(shù)據(jù)集親和性調(diào)度策略已經(jīng)在具體的生產(chǎn)環(huán)境中得到驗證, 以下測試將具體展示其性能效果.

4.1 vCUDA實驗

分別采用YOLOv3[21]、ResNet50[22]、BERT[23]在視覺、自然語言處理領(lǐng)域的典型模型進行測試vCUDA性能效果.

實驗環(huán)境如下:

模型: 采用YOLOv3, ResNet50和BERT模型, 網(wǎng)絡(luò)模型包含了主要的圖像處理、自然語言處理且具有相對復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu)能夠充分利用GPU計算能力.

訓(xùn)練數(shù)據(jù): 采用COCO[24], ImageNet large scale visual recognition challenge (ILSVRC 2012)[25]訓(xùn)練數(shù)據(jù)集(約130 G, 120萬張訓(xùn)練圖片), SQuAD1.1[26].

訓(xùn)練框架: TensorFlow[27], Darknet[28].

GPU: Tesla V100S 32 GB.

實驗內(nèi)容如下:

在單GPU上進行單個任務(wù)和兩個任務(wù)測試, 采用直接在單GPU上調(diào)度訓(xùn)練任務(wù)(即不限制內(nèi)存使用和隔離)和使用vCUDA進行內(nèi)存限制和隔離進行對比.

實驗結(jié)果和分析如下:

如圖11所示單任務(wù)訓(xùn)練對比結(jié)果顯示在GPU上只有一個訓(xùn)練任務(wù)時, 與benchmark結(jié)果比較, 采用vCUDA library對訓(xùn)練沒有影響, 即CUDA的劫持方案并沒有造成訓(xùn)練性能上的損失; 在同一個GPU上同時運行兩個訓(xùn)練任務(wù)時, 采用vCUDA方案的訓(xùn)練效果和使用原生CUDA方案沒有較大差異, 以上結(jié)果顯示采用vCUDA方案可以進行細粒度顯存使用和隔離的同時并保證同一塊GPU上進行多任務(wù)的提交和訓(xùn)練, 以及性能保證.

圖11 單任務(wù)訓(xùn)練對比結(jié)果

4.2 NUMA親和性實驗

為驗證同NUMA內(nèi)計算資源對訓(xùn)練任務(wù)帶來相應(yīng)的影響, 設(shè)計如下實驗.

實驗環(huán)境如下:

GPU: A100 40 GB;

CPU: Xeon Platinum 8 268 @ 2.9 GHz, 2 Sockets,Cores per socket: 24;

存儲系統(tǒng): NFS.

實驗內(nèi)容如下:

(1) 采用TensorFlow框架和ResNet50使用ILSVRC 2012數(shù)據(jù)集進行測試, batch_size=418, steps=500,GPU與同NUMA node和不同NUMA node的CPU綁定進行測試.

(2) 采用PyTorch[29]和Transformer[30]使用wmt14_en_de數(shù)據(jù)集[31]進行測試, GPU與同NUMA node和不同NUMA node的CPU綁定進行測試.

采用TensorFlow和ResNet50使用ILSVRC 2012數(shù)據(jù)集在GPU與同NUMA node和不同NUMA node的CPU綁定條件下的測試結(jié)果如表4, 采用PyTorch和Transformer使用wmt14_en_de數(shù)據(jù)集在GPU與同NUMA node和不同NUMA node的CPU綁定條件下測試結(jié)果如表5所示.

表4 在ILSVRC 2012數(shù)據(jù)集上采用TensorFlow和ResNet50的Throughput測試結(jié)果(image/s)

表5 在wmt14_en_de數(shù)據(jù)集上采用PyTorch和Transformer的Throughput測試結(jié)果(image/s)

從表4和表5可以看出采用和CPU相同的NUMA的GPU0和GPU1進行測試時, NUMA 綁定在使用GPU數(shù)量不多的情況下訓(xùn)練方面提升有限, 多GPU訓(xùn)練時綁定會有一定提升, 且同NUMA內(nèi) GPU、CPU、內(nèi)存配合使用效果最好, 同時CPU和內(nèi)存也不要跨NUMA node使用.

4.3 數(shù)據(jù)集緩存和親和性調(diào)度實驗

針對數(shù)據(jù)集緩存和親和性調(diào)度采用海量小文件的訓(xùn)練場景, 即使用ILSVRC 2012數(shù)據(jù)集的原生JPEG格式數(shù)據(jù)和ResNet50模型進行訓(xùn)練性能測試, 具體實驗信息如下:

實驗環(huán)境:

GPU: A100 40 GB;

訓(xùn)練框架、模型: PyTorch, ResNet50;

數(shù)據(jù)集: ILSVRC 2012數(shù)據(jù)集(JPEG格式);

存儲系統(tǒng): Lustre;

網(wǎng)絡(luò): 100 Gb InfiniBand網(wǎng)絡(luò).

實驗內(nèi)容:

(1) 采用Horovod分布式訓(xùn)練框架[32], PyTorch作為后端進行訓(xùn)練, ResNet50使用ILSVRC 2012數(shù)據(jù)集進行測試, batch_size=256, 訓(xùn)練數(shù)據(jù)集讀取方式采用網(wǎng)絡(luò)讀取存儲系統(tǒng)中的文件方式和節(jié)點緩存模式進行對比.

(2) 采用PyTorch框架的DistributedDataParallel(DDP)[33]方式進行訓(xùn)練, ResNet50使用ILSVRC 2012數(shù)據(jù)集進行測試, batch_size=256, 訓(xùn)練數(shù)據(jù)集讀取方式采用網(wǎng)絡(luò)讀取存儲系統(tǒng)中的文件方式和節(jié)點緩存模式進行對比.

采用Horovod和ResNet50使用ILSVRC 2012數(shù)據(jù)集在數(shù)據(jù)集讀取方式采用網(wǎng)絡(luò)讀取存儲系統(tǒng)方式和節(jié)點緩存模式進行訓(xùn)練的對比結(jié)果如表6所示, 采用PyTorch的DDP和ResNet50使用ILSVRC 2012數(shù)據(jù)集在訓(xùn)練數(shù)據(jù)集讀取方式采用網(wǎng)絡(luò)讀取存儲系統(tǒng)方式和節(jié)點緩存模式進行訓(xùn)練的對比結(jié)果如表7所示.

從表6和表7數(shù)據(jù)可以看出在節(jié)點緩存模式下無論是使用Horovod還是PyTorch-DDP方式進行訓(xùn)練,其訓(xùn)練效果均要比直接使用網(wǎng)絡(luò)讀取存儲系統(tǒng)中的訓(xùn)練數(shù)據(jù)集好, 并且在多GPU任務(wù)下的表現(xiàn)更加明顯. 直接使用存儲系統(tǒng)中文件由于在網(wǎng)絡(luò)、CPU和GPU之前的數(shù)據(jù)拷貝操作會使GPU計算資源處于閑置狀態(tài),因此會影響訓(xùn)練效果, 降低訓(xùn)練速度, 圖12和圖13展示了在以上兩種測試中GPU使用情況, 其中圖12(a)為使用2個GPU訓(xùn)練的情況, 圖12(b)和圖13為使用8個GPU訓(xùn)練的情況. 可以看出節(jié)點緩存模式下訓(xùn)練框架較充分使用了GPU計算資源, 使得GPU一直處于比較平均且正常的使用率, 在PyTorch-DDP方式下尤為明顯, 而通過網(wǎng)絡(luò)使用存儲系統(tǒng)的情況下可以看到GPU使用有相當(dāng)?shù)目罩脿顟B(tài), 此種情況會在高并發(fā)讀取數(shù)據(jù)情況下變得尤為突出, 如分布式訓(xùn)練等.由此可見, 采用節(jié)點緩存方式能夠有效減小網(wǎng)絡(luò)上的傳輸壓力并同時提高訓(xùn)練效果.

圖12 在ILSVRC 2012數(shù)據(jù)集上采用Horovod-PyTorch和ResNet50的GPU利用率(縱軸為GPU利用率(%), 橫軸為時間(s))左: 直接使用存儲系統(tǒng); 右: 節(jié)點緩存模式

圖13 在ILSVRC 2012數(shù)據(jù)集上使用PyTorch-DDP和ResNet50的GPU利用率(縱軸為GPU利用率(%), 橫軸為時間(s))

表6 在ILSVRC 2012數(shù)據(jù)集上采用Horovod和ResNet50的測試結(jié)果

表7 在ILSVRC 2012數(shù)據(jù)集上采用PyTorch的DDP和ResNet50的測試結(jié)果

實際應(yīng)用環(huán)境中配合使用數(shù)據(jù)集調(diào)度策略可以充分利用大規(guī)模集群中節(jié)點上已緩存的數(shù)據(jù)資源, 進而提高訓(xùn)練性能和集群計算資源的利用率.

5 結(jié)束語

本文針對在Kubernetes集群上部署深度學(xué)習(xí)應(yīng)用所遇到的一些問題, 對數(shù)據(jù)、計算方面提出了一系列優(yōu)化方案和設(shè)計, 并結(jié)合實際場景進行了測試, 整體上達到了預(yù)期效果. 其中數(shù)據(jù)集緩存和親和性調(diào)度能夠極大的減少由于存儲系統(tǒng)和網(wǎng)絡(luò)環(huán)境限制帶來的數(shù)據(jù)讀取速率慢問題; vCUDA技術(shù)能夠解決部分場景下的GPU共享要求, 并且利用UM機制擴大顯存使用;另外NUMA親和性調(diào)度和針對海量小文件的優(yōu)化技巧在實際測試和生產(chǎn)場景中均能夠提供可觀的整體性能提升.