羅 磊，陳照云，王儷璇

(國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院，湖南 長(zhǎng)沙 410073)

1 引言

當(dāng)前，深度學(xué)習(xí)技術(shù)受到產(chǎn)業(yè)界和學(xué)術(shù)界廣泛關(guān)注。雖然以高速定制機(jī)器學(xué)習(xí)芯片TPU(Tensor Processing Units)為代表的深度學(xué)習(xí)專用硬件設(shè)備層出不窮，但通用圖形處理器GPU集群仍是開(kāi)展深度學(xué)習(xí)研發(fā)的主流平臺(tái)。如圖1所示，高校、科研院所和中小規(guī)模企業(yè)UIE(Universities,Institutes and small-and-medium-sized Enterprises)常構(gòu)建公共GPU集群向組織內(nèi)部的學(xué)生、研究人員提供服務(wù)。多個(gè)用戶會(huì)同時(shí)向GPU集群平臺(tái)提交不同類型的深度學(xué)習(xí)任務(wù)，每個(gè)任務(wù)具有自身的計(jì)算需求和相應(yīng)的預(yù)期服務(wù)質(zhì)量QoS(Quality of Service)。

相比于互聯(lián)網(wǎng)巨頭定制化的深度學(xué)習(xí)平臺(tái)，或面向公眾提供服務(wù)的云計(jì)算中心，UIE由于預(yù)算有限，更傾向于購(gòu)買或租賃高性價(jià)比的通用現(xiàn)貨GPU集群，并采用開(kāi)源集群管理系統(tǒng)來(lái)構(gòu)建多用戶共享的深度學(xué)習(xí)研發(fā)平臺(tái)。然而現(xiàn)有GPU集群任務(wù)調(diào)度主要關(guān)注高性能計(jì)算中心的需求，多基于歷史信息或啟發(fā)式進(jìn)行調(diào)度[1]，對(duì)UIE深度學(xué)習(xí)研發(fā)場(chǎng)景適應(yīng)性不強(qiáng)。以康奈爾大學(xué)的Gra- phite集群為例[2]，該系統(tǒng)采用傳統(tǒng)的Slurm(Simple Linux Utility for Resource Management)資源劃分，任務(wù)調(diào)度策略依靠用戶自主提出的需求，根據(jù)系統(tǒng)空閑狀態(tài)隨機(jī)分配。這種策略既不能利用深度學(xué)習(xí)計(jì)算特性挖掘有限計(jì)算資源的能力，也無(wú)法對(duì)用戶的服務(wù)質(zhì)量作出保證。同樣的情況在麻省理工學(xué)院(MIT)的MSEAS(Multidisciplinary Simulation, Estimation, and Assimilation Systems)集群和加利福尼亞大學(xué)伯克利分校(UC Berkeley)的Tiger集群上也有發(fā)生[3,4]。此外，由于深度學(xué)習(xí)研究的持續(xù)高熱度，UIE中需要使用GPU集群的用戶數(shù)量眾多，而GPU集群的規(guī)模又十分有限(GPU數(shù)量往往在幾十到一、兩百個(gè)之間[2 - 4])，導(dǎo)致任務(wù)沖突更為頻繁，而組織內(nèi)部用戶平等的關(guān)系使得云計(jì)算中心基于價(jià)格的調(diào)度策略不再奏效。

Figure 1 GPU cluster shared with multiple users for deep learning research and development purpose圖1 面向深度學(xué)習(xí)研發(fā)任務(wù)的多用戶共享GPU平臺(tái)

面向UIE深度學(xué)習(xí)研發(fā)場(chǎng)景，如何提高GPU集群任務(wù)吞吐率，是一個(gè)重要的研究課題。Chen等人[5,6]對(duì)深度學(xué)習(xí)任務(wù)計(jì)算特性進(jìn)行了評(píng)測(cè)與分析，對(duì)小規(guī)模GPU集群平臺(tái)上的深度學(xué)習(xí)任務(wù)的調(diào)度開(kāi)展了探索。Gu等人[7]針對(duì)大規(guī)模分布式深度學(xué)習(xí)任務(wù)，提出Tiresias調(diào)度器，相比Apache YARN任務(wù)完成時(shí)間提升了5.5倍。本文面向UIE深度學(xué)習(xí)研發(fā)場(chǎng)景，充分考慮深度學(xué)習(xí)任務(wù)的計(jì)算通信特性，提出一種用戶QoS感知的動(dòng)態(tài)任務(wù)調(diào)度方法，能夠在滿足多用戶QoS需求的同時(shí)，提高GPU集群資源利用率。

2 GPU集群深度學(xué)習(xí)任務(wù)調(diào)度模型

2.1 深度神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)與計(jì)算特性

從早期的LeNet網(wǎng)絡(luò)[8]，到現(xiàn)代的AlexNet[9]、VGGNet[10]、GoogleNet[11]和ResNet[12]等，以神經(jīng)網(wǎng)絡(luò)為代表的深度學(xué)習(xí)技術(shù)在各類應(yīng)用中取得了突破性進(jìn)展。為平衡計(jì)算效率和收斂速度，深度神經(jīng)網(wǎng)絡(luò)的訓(xùn)練和推理一般采用批處理方式，批次大小(batchsize)會(huì)顯著影響到訓(xùn)練性能和資源占用。當(dāng)batchsize較大時(shí)，由于GPU內(nèi)存的限制，常需要在GPU集群采用模型并行[13]或數(shù)據(jù)并行[14]進(jìn)行訓(xùn)練。

在深度學(xué)習(xí)研發(fā)過(guò)程中，為了獲得最優(yōu)的性能，研發(fā)者往往需要花費(fèi)大量時(shí)間對(duì)深度神經(jīng)網(wǎng)絡(luò)模型的超參數(shù)進(jìn)行調(diào)優(yōu)。在調(diào)整這些超參數(shù)的過(guò)程中，需要使用相同或相似的深度神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)，重復(fù)對(duì)同一批數(shù)據(jù)訓(xùn)練多次。另一方面，大量的深度學(xué)習(xí)開(kāi)發(fā)任務(wù)以微調(diào)(fine-tuning)的方式展開(kāi)，即以ImageNet等大規(guī)模數(shù)據(jù)集上訓(xùn)練得到的預(yù)訓(xùn)練模型為基礎(chǔ)，在目標(biāo)數(shù)據(jù)集上對(duì)模型的參數(shù)進(jìn)行fine-tuning。這種模式下，開(kāi)發(fā)任務(wù)使用的深度神經(jīng)網(wǎng)絡(luò)結(jié)構(gòu)與預(yù)訓(xùn)練網(wǎng)絡(luò)基本相同，一般只修改輸出層或少數(shù)特征層。深度學(xué)習(xí)研發(fā)中廣泛存在的超參數(shù)調(diào)整和模型fine-tuning，使得用戶提交到GPU集群的作業(yè)中存在大量網(wǎng)絡(luò)結(jié)構(gòu)相同或相似的任務(wù)，其計(jì)算特性也相似。對(duì)于這些相同或相似的任務(wù)，可以通過(guò)歷史信息預(yù)測(cè)其計(jì)算和通信性能，為集群作業(yè)調(diào)度提供依據(jù)。

2.2 GPU集群深度學(xué)習(xí)研發(fā)任務(wù)調(diào)度建模

面向圖1所示分布式GPU集群下的深度學(xué)習(xí)研發(fā)場(chǎng)景，本文采用式(1)所示的三元組描述GPU集群平臺(tái)：

P=〈N,G,Comm(·)〉

(1)

其中，N，G和Comm(·)分別表示該GPU集群結(jié)點(diǎn)數(shù)上限、每個(gè)結(jié)點(diǎn)內(nèi)的GPU數(shù)上限和與GPU集群內(nèi)部互連結(jié)構(gòu)相關(guān)的通信罰值函數(shù)。由于GPU集群內(nèi)結(jié)點(diǎn)間(結(jié)點(diǎn)間的互連網(wǎng)絡(luò))、結(jié)點(diǎn)內(nèi)(CPU Socket之間、不同的PCIeSwitch之間，PCIeSwitch下的GPU之間等)都具有層次化的互連結(jié)構(gòu)，而這個(gè)互連結(jié)構(gòu)也會(huì)對(duì)分布式任務(wù)的通信性能造成一定程度的影響，這些影響都通過(guò)Comm(·)來(lái)描述。

根據(jù)文獻(xiàn)[5,6]對(duì)GPU集群下深度學(xué)習(xí)任務(wù)的深入評(píng)測(cè)與分析，深度神經(jīng)網(wǎng)絡(luò)的計(jì)算特性主要與任務(wù)的類型、批次大小和迭代次數(shù)有關(guān)，因此深度學(xué)習(xí)任務(wù)可以抽象為如式(2)所示的三元組:

t=〈wtype,wbat,witer〉

(2)

其中，wtype,wbat和witer分別表示深度學(xué)習(xí)任務(wù)類型、批次大小和迭代次數(shù)。任務(wù)類型包括2個(gè)方面：(1)深度網(wǎng)絡(luò)模型的類型，例如Inception-v3或Seq2Seq；(2)計(jì)算類型，即屬于訓(xùn)練任務(wù)還是推理/驗(yàn)證任務(wù)。

深度學(xué)習(xí)任務(wù)的屬性由用戶提交的任務(wù)確定，GPU集群平臺(tái)一方面可以調(diào)整任務(wù)執(zhí)行的順序，另一方面可以改變?nèi)蝿?wù)的放置策略。本文采用對(duì)稱式放置，任務(wù)放置策略可以抽象為如式(3)所示的二元組:

s=〈dnode,dg/n〉

(3)

其中,dnode和dg/n分別表示任務(wù)所占結(jié)點(diǎn)的數(shù)量以及每個(gè)結(jié)點(diǎn)內(nèi)占據(jù)的GPU數(shù)目，任務(wù)將會(huì)平均分配到各結(jié)點(diǎn)及結(jié)點(diǎn)內(nèi)的GPU上。

給定分布式GPU集群平臺(tái)和一個(gè)深度學(xué)習(xí)任務(wù)隊(duì)列Γ=〈t1,t2,…〉，調(diào)度目標(biāo)是為每一個(gè)任務(wù)隊(duì)列中的深度學(xué)習(xí)任務(wù)在給定的集群平臺(tái)上找到合適的放置策略和執(zhí)行順序，能夠在滿足每個(gè)任務(wù)自身的服務(wù)質(zhì)量的同時(shí)，盡可能提高整個(gè)集群資源利用率。

為實(shí)現(xiàn)該目標(biāo)，本文采用離線評(píng)估和在線調(diào)度相結(jié)合的方式。離線評(píng)估模塊主要基于對(duì)深度學(xué)習(xí)任務(wù)的離線評(píng)測(cè)來(lái)分析其內(nèi)在特征并構(gòu)建性能預(yù)測(cè)模型。在線調(diào)度模塊基于前者構(gòu)建的性能預(yù)測(cè)模型，結(jié)合任務(wù)自身的預(yù)期服務(wù)質(zhì)量，來(lái)共同設(shè)計(jì)調(diào)度策略，包括任務(wù)放置策略和任務(wù)執(zhí)行順序。

3 基于離線評(píng)估的性能預(yù)測(cè)模型

深度學(xué)習(xí)任務(wù)具有顯著的迭代性，計(jì)算過(guò)程中保持相對(duì)穩(wěn)定的計(jì)算效率，因此任務(wù)的執(zhí)行時(shí)間可以用任務(wù)計(jì)算量和任務(wù)執(zhí)行吞吐率來(lái)進(jìn)行計(jì)算。任務(wù)t在放置策略s下的執(zhí)行時(shí)間如式(4)所示:

(4)

其中,PR(t,s)為任務(wù)的吞吐率，而wbat·witer為整個(gè)任務(wù)的計(jì)算量，v為任務(wù)啟動(dòng)開(kāi)銷，是一個(gè)常量。

深度學(xué)習(xí)任務(wù)的分布式性能受單GPU上子任務(wù)的計(jì)算性能，及多GPU間同步通信開(kāi)銷2方面影響。基于此建立深度學(xué)習(xí)任務(wù)吞吐率的性能預(yù)測(cè)模型，如式(5)所示:

PR(t,s)=(dnode·dg/n-Comm(s))·sPR(t′)

(5)

其中,sPR(t′)表示子任務(wù)t′在單GPU上的吞吐率，Comm(s)是放置策略s所帶來(lái)的通信代價(jià)開(kāi)銷。通過(guò)dnode·dg/n計(jì)算當(dāng)前放置策略s下該任務(wù)一共占用的GPU總數(shù)，是理想最大吞吐率。實(shí)際系統(tǒng)中的通信開(kāi)銷在式中用Comm(s)來(lái)表示。

在對(duì)稱式放置策略下，任務(wù)t在放置策略s下會(huì)依據(jù)全局批次大小batchsize平均劃分到各個(gè)GPU上，每個(gè)GPU上劃分到的子任務(wù)具有相同的局部batchsize。因此,每個(gè)GPU上的子任務(wù)t′如式(6)所示:

t′=〈wtype,w′bat,w′iter〉

(6)

其中w′bat=wbat/(dmode·dg/n)是指劃分到每個(gè)GPU上的局部batchsize，可通過(guò)全局batchsize計(jì)算得到。

單GPU上的任務(wù)吞吐率sPR(t′)和w′bat正相關(guān)，本文采用多項(xiàng)式擬合，如式(7)所示：

sPR(t′)=∑iki(w′bat)i

(7)

其中,ki是與w′bat的i次冪對(duì)應(yīng)的擬合系數(shù)，與任務(wù)類型wtype和集群平臺(tái)模型P有關(guān)。為簡(jiǎn)化性能模型，避免過(guò)擬合，應(yīng)盡可能選擇較低次數(shù)的多項(xiàng)式擬合。通過(guò)實(shí)驗(yàn)數(shù)據(jù)證明，二次多項(xiàng)式回歸擬合的結(jié)果(即i=2)已經(jīng)足夠描述單個(gè)GPU上的吞吐率性能曲線變化。

由式(5)知，同步通信開(kāi)銷與平臺(tái)的GPU互連層次化結(jié)構(gòu)以及每個(gè)深度學(xué)習(xí)任務(wù)的放置策略有關(guān)。利用任務(wù)所占GPU之間的平均通信路徑長(zhǎng)度來(lái)構(gòu)建同步通信開(kāi)銷的罰值函數(shù)，如式(8)所示：

(8)

以放置策略s中的任意一個(gè)GPU為例，(dnode-1)·dg/n和(dg/n-1)分別代表該GPU需要跨結(jié)點(diǎn)通信的GPU數(shù)目和在同一結(jié)點(diǎn)內(nèi)通信的GPU數(shù)目，需要通信同步的GPU總數(shù)是dnode·dg/n-1。系數(shù)γ主要體現(xiàn)該GPU集群平臺(tái)的層次化GPU互連結(jié)構(gòu)對(duì)通信開(kāi)銷的影響。同時(shí)，由于跨結(jié)點(diǎn)通信的路徑與代價(jià)和結(jié)點(diǎn)內(nèi)通信會(huì)有明顯差異，用λ平衡結(jié)點(diǎn)間和結(jié)點(diǎn)內(nèi)的通信帶寬差異。系數(shù)γ和λ通過(guò)平臺(tái)上具體任務(wù)的離線評(píng)測(cè)數(shù)據(jù)回歸得到。

4 QoS感知的深度學(xué)習(xí)任務(wù)調(diào)度

4.1 任務(wù)調(diào)度模型

在多任務(wù)的深度學(xué)習(xí)研發(fā)場(chǎng)景下，任務(wù)的預(yù)期完成時(shí)間ECT(Expected Completion Time)往往會(huì)成為一個(gè)衡量該任務(wù)用戶滿意度的指標(biāo)[15]。如果用戶提交的任務(wù)能夠在其預(yù)期完成時(shí)間前完成，則對(duì)用戶來(lái)說(shuō)是可以接受的，其滿意度比較高。如果任務(wù)的執(zhí)行超出了用戶的預(yù)期完成時(shí)間，那么用戶的滿意度會(huì)出現(xiàn)明顯的下降。由于不同深度學(xué)習(xí)任務(wù)的計(jì)算量和執(zhí)行時(shí)長(zhǎng)也具有明顯的差異，為了能夠統(tǒng)一進(jìn)行評(píng)測(cè)和對(duì)比，以該任務(wù)在單個(gè)GPU上的執(zhí)行時(shí)間作為一個(gè)標(biāo)準(zhǔn)化的基準(zhǔn)時(shí)長(zhǎng)[16]。對(duì)于普通用戶提交的深度學(xué)習(xí)任務(wù)，其預(yù)期完成時(shí)間設(shè)定為2倍的基準(zhǔn)時(shí)長(zhǎng)。而考慮到實(shí)際應(yīng)用場(chǎng)景下會(huì)出現(xiàn)不同優(yōu)先級(jí)的用戶和任務(wù)，因此對(duì)于更高級(jí)的優(yōu)先級(jí)用戶和任務(wù)，其預(yù)期完成時(shí)間也更短。因此，本文設(shè)置：Urgent、Prior和Normal 3種不同優(yōu)先級(jí)的用戶，分別表示最高優(yōu)先級(jí)(應(yīng)立即開(kāi)始的)任務(wù)、優(yōu)先任務(wù)和普通任務(wù)，其對(duì)應(yīng)的預(yù)期完成時(shí)間如式(9)所示:

(9)

其中，〈1,1〉表示放置策略為在單個(gè)GPU上，即dnode=dg/n=1的情況。對(duì)于最高優(yōu)先級(jí)的Urgent用戶，其任務(wù)的預(yù)期完成時(shí)間為0，表示這些深度學(xué)習(xí)任務(wù)具有最高的優(yōu)先級(jí)，需盡快執(zhí)行。當(dāng)任務(wù)隊(duì)列中存在最高優(yōu)先級(jí)的任務(wù)時(shí)，其用戶QoS一定會(huì)被違反，但可以通過(guò)違反的程度來(lái)評(píng)估調(diào)度的優(yōu)劣。采用用戶QoS的保證率，即以有多少任務(wù)能夠在用戶的預(yù)期完成時(shí)間前完成，來(lái)衡量用戶QoS的平均滿意度。

對(duì)指定任務(wù)，增加GPU資源可以獲得更好的執(zhí)行速度，但是不同類型的深度學(xué)習(xí)任務(wù)對(duì)于GPU放置策略的敏感性不同。因此，對(duì)不同類型的任務(wù)可以有針對(duì)性地選擇放置策略方案，在盡可能保證高性能的同時(shí)，降低資源占用和資源碎片化。為描述放置策略對(duì)資源占用和碎片化的影響，本文引入如式(10)所示的代價(jià)模型:

(10)

其中，N和G分別表示該GPU集群平臺(tái)上的放置策略dnode和dg/n可取值的上限。在式(10)中，第1項(xiàng)代表該放置策略所使用的GPU數(shù)占GPU總數(shù)的比例，第2項(xiàng)是反映所占用的GPU之間的拓?fù)潢P(guān)系影響，而θ是用來(lái)調(diào)整2項(xiàng)之間平衡的因子。放置策略占用的GPU越集中，其代價(jià)也就越小，對(duì)資源碎片化的影響也就越小。

基于式(5)和式(10)，可定義放置策略對(duì)任務(wù)的性價(jià)比CER(Cost-Effective Ratio)如式(11)所示:

(11)

給定GPU集群平臺(tái)P，其結(jié)點(diǎn)數(shù)為N,單結(jié)點(diǎn)內(nèi)GPU數(shù)為G,通信罰值函數(shù)為Comm(·)，特定的深度學(xué)習(xí)任務(wù)隊(duì)列Γ=〈t1,t2,…〉。隊(duì)列中任務(wù)的預(yù)期完成時(shí)間分別為e1,e2,…。對(duì)每一個(gè)任務(wù)ti，調(diào)度器需為其選擇放置策略si*，在滿足任務(wù)預(yù)期完成時(shí)間要求的同時(shí)，盡可能具有最高的性價(jià)比CER值。在為每個(gè)深度學(xué)習(xí)任務(wù)計(jì)算選擇放置策略之后，需要綜合考慮整個(gè)任務(wù)隊(duì)列中所有任務(wù)的不同緊急程度以調(diào)整任務(wù)的執(zhí)行順序。調(diào)度目標(biāo)中的用戶滿意度衡量指標(biāo)為不超過(guò)其預(yù)期完成時(shí)間的任務(wù)數(shù)百分比，而資源利用率指標(biāo)則是所有任務(wù)的完成時(shí)間。上述調(diào)度問(wèn)題的形式化建模如式(12)所示：

Given:P=〈N,G,Comm(·)〉,Γ=〈t1,t2,…〉,

find:S=〈s1*,s2*，…〉,O=〈t′1,t′2,…〉,

maximizing:Q,minimizing:M,

(12)

4.2 任務(wù)調(diào)度算法

由于不斷有任務(wù)完成和新任務(wù)到達(dá)GPU集群平臺(tái)，任務(wù)隊(duì)列是動(dòng)態(tài)變化的。因此，本文采用基于事件驅(qū)動(dòng)的調(diào)度方法，在新任務(wù)到達(dá)或現(xiàn)有任務(wù)執(zhí)行完成時(shí)進(jìn)行調(diào)度決策。在調(diào)度點(diǎn)上采用最短等待余量?jī)?yōu)先的原則作決策。假設(shè)當(dāng)前的時(shí)間點(diǎn)為tcurr，當(dāng)前任務(wù)等待隊(duì)列Qcurr有若干深度學(xué)習(xí)任務(wù)等待調(diào)度執(zhí)行，t1,t2,…,tn,n=|Qcurr|，其預(yù)期完成時(shí)間分別為e1,e2,…,en。根據(jù)式(4)和式(11)計(jì)算每個(gè)任務(wù)在不同放置策略下的執(zhí)行時(shí)間和性價(jià)比。例如，深度學(xué)習(xí)任務(wù)ti共有qi種不同的放置策略，分別為si1,si2,…,siqi,qi=|Mi|,其中Mi為任務(wù)ti的放置策略集合。該任務(wù)不同放置策略對(duì)應(yīng)的執(zhí)行時(shí)間l和性價(jià)比r分別如式(13)和式(14)所示：

l=〈li1,li2,…,liqi〉,qi=|Mi|

(13)

r=〈ri1,ri2,…,riqi〉,i∈[1,2,…,n]

(14)

為滿足用戶QoS，從集合中選擇放置策略sij∈Mi，該策略能夠滿足預(yù)期完成時(shí)間要求，如式(15)所示：

lij+tcurr≤ei,

i∈[1,2,…,n],j∈[1,2,…,qi]

(15)

滿足上述條件的放置策略sij形成子集M′i。選擇該子集中CER最高的策略si*作為任務(wù)ti的放置方案。

為衡量隊(duì)列中任務(wù)的緊急程度，本文引入等待余量w，任務(wù)ti在放置策略si*下的等待余量如式(16)所示:

wi=ei-(li*+tcurr),

i∈[1,2,…,n],si*∈M′i

(16)

根據(jù)每個(gè)任務(wù)的等待余量對(duì)任務(wù)隊(duì)列進(jìn)行重排序，等待余量小的任務(wù)擁有更高優(yōu)先級(jí)。某些任務(wù)(例如Urgent類別的用戶)如果不存在能滿足其用戶預(yù)期完成時(shí)間的放置策略，則直接從Mi中選擇CER最高的策略作為解決方案。

Figure 2 Scheduling process at time tcurr圖2 tcurr時(shí)刻的調(diào)度過(guò)程

Figure 3 Implementation of the proposed scheduling method圖3 本文調(diào)度方法實(shí)現(xiàn)架構(gòu)

調(diào)度器依據(jù)重排后的隊(duì)列依次將任務(wù)調(diào)度到集群上執(zhí)行，直到當(dāng)前資源無(wú)法滿足執(zhí)行需求。由于集群上不斷有新的任務(wù)到達(dá)和原有的任務(wù)完成，等待隊(duì)列中的任務(wù)放置策略和執(zhí)行順序也在動(dòng)態(tài)地不斷調(diào)整。上述特定調(diào)度點(diǎn)的動(dòng)態(tài)調(diào)度過(guò)程如圖2所示。

4.3 方法實(shí)現(xiàn)

本文以TensorFlow為基礎(chǔ)，通過(guò)插件模式實(shí)現(xiàn)提出的調(diào)度方法，如圖3所示，主要包括離線評(píng)估和在線調(diào)度2個(gè)模塊。離線評(píng)估模塊主要負(fù)責(zé)為各種深度學(xué)習(xí)任務(wù)構(gòu)建性能預(yù)測(cè)模型，在線調(diào)度模塊主要負(fù)責(zé)任務(wù)放置策略和執(zhí)行順序的選擇。

離線評(píng)估模塊主要包括預(yù)測(cè)模型數(shù)據(jù)庫(kù)和離線評(píng)估器2個(gè)部件。在系統(tǒng)運(yùn)行之前，先對(duì)典型的深度學(xué)習(xí)模型進(jìn)行評(píng)測(cè)，并將其對(duì)應(yīng)的性能預(yù)測(cè)模型保存在數(shù)據(jù)庫(kù)中。當(dāng)任務(wù)開(kāi)始提交后，首先會(huì)在數(shù)據(jù)庫(kù)中檢索，如果命中就可以直接載入已有的性能預(yù)測(cè)模型，不用重復(fù)進(jìn)行評(píng)測(cè)。如果未命中數(shù)據(jù)庫(kù)，則先根據(jù)模型PB(Protocal Buffer)序列化格式文件中計(jì)算圖(MetaGraph)的相似性，從數(shù)據(jù)庫(kù)中選取一個(gè)相似度最高的模型，作為當(dāng)前任務(wù)的臨時(shí)性能預(yù)測(cè)模型。當(dāng)GPU集群有足夠空閑的資源時(shí)，評(píng)估器再對(duì)該模型進(jìn)行離線評(píng)估，并將構(gòu)建的性能預(yù)測(cè)模型更新到數(shù)據(jù)庫(kù)中。

在線調(diào)度模塊主要包括任務(wù)等待隊(duì)列和調(diào)度器的實(shí)現(xiàn)。用戶提交的任務(wù)首先導(dǎo)入任務(wù)等待隊(duì)列，等待隊(duì)列采用堆結(jié)構(gòu)實(shí)現(xiàn)，在每個(gè)事件調(diào)度點(diǎn)，基于性能預(yù)測(cè)模型完成對(duì)放置策略的選擇和等待余量的計(jì)算，然后實(shí)現(xiàn)自動(dòng)排序。調(diào)度器負(fù)責(zé)監(jiān)控系統(tǒng)的負(fù)載，當(dāng)集群有足夠的空閑資源時(shí)，重排序后的任務(wù)隊(duì)列將依次彈出任務(wù)，由調(diào)度器將任務(wù)調(diào)度到GPU集群上執(zhí)行。

5 實(shí)驗(yàn)評(píng)測(cè)與討論

5.1 實(shí)驗(yàn)設(shè)置

實(shí)驗(yàn)平臺(tái)：實(shí)驗(yàn)采用的GPU集群詳細(xì)配置信息見(jiàn)表1。平臺(tái)包括4個(gè)結(jié)點(diǎn)，結(jié)點(diǎn)間通過(guò)56 Gbps的InfiniBand高速互連網(wǎng)絡(luò)相連接。每個(gè)結(jié)點(diǎn)包括雙路CPU(Intel Xeon E5-2660 v3 @ 2.60 GHz)，并配備64 GB的內(nèi)存和2塊GPU(NVIDIA Tesla K80)，由于Tesla K80是單卡雙核心，即每個(gè)結(jié)點(diǎn)配備4個(gè)GPU核心。結(jié)點(diǎn)運(yùn)行CentOS 7.0操作系統(tǒng)，并安裝TensorFlow 1.7.0深度學(xué)習(xí)實(shí)現(xiàn)框架。

Table 1 Configuration of distributed GPU cluster 表1 分布式GPU集群配置

任務(wù)隊(duì)列：參考文獻(xiàn)[17,18]生成任務(wù)隊(duì)列，不同類型的深度學(xué)習(xí)任務(wù)以泊松分布隨機(jī)產(chǎn)生并提交到GPU集群。生成任務(wù)隊(duì)列的具體設(shè)置信息見(jiàn)表2，包含AlexNet、GoogleNet、ResNet-50和Inception-v3共4種典型的卷積神經(jīng)網(wǎng)絡(luò)模型，以及Regularized LSTM和Seq2Seq 2種典型的循環(huán)神經(jīng)網(wǎng)絡(luò)模型。隊(duì)列中單個(gè)任務(wù)的模型類型、計(jì)算類型、應(yīng)用超參數(shù)設(shè)置(如迭代次數(shù)、批次大小等)都通過(guò)均勻分布來(lái)產(chǎn)生。根據(jù)文獻(xiàn)[19]中關(guān)于企業(yè)級(jí)任務(wù)負(fù)載的分析，將任務(wù)隊(duì)列中不同優(yōu)先級(jí)用戶的比例設(shè)定為Urgent∶Prior∶Normal=5%∶35%∶60%。任務(wù)隊(duì)列中任務(wù)提交的總時(shí)長(zhǎng)為24 h。為進(jìn)一步評(píng)測(cè)不同任務(wù)密度條件下的調(diào)度性能，設(shè)定每小時(shí)5,10,20等不同的任務(wù)到達(dá)數(shù)目。

基準(zhǔn)：Yarn、Mesos、Kubernetes等主流集群管理系統(tǒng)中常用的以下幾種調(diào)度策略作為基準(zhǔn)與本文方法進(jìn)行比較。

Table 2 Specifications of task queue generation表2 任務(wù)隊(duì)列設(shè)置

(1)FIFO調(diào)度策略：FIFO調(diào)度策略按照任務(wù)到達(dá)的順序來(lái)進(jìn)行調(diào)度執(zhí)行，每個(gè)任務(wù)的資源分配根據(jù)用戶指定，并結(jié)合當(dāng)前資源的空閑狀態(tài)。

(2)容量調(diào)度策略(Capacity Scheduler)：每種不同類型的任務(wù)都具有一定的資源容量保證，每個(gè)任務(wù)根據(jù)需求占用自身容量范圍內(nèi)的資源，但是不能超過(guò)限制占用其他類型任務(wù)的資源。

(3)Min-Min調(diào)度策略[20]：Min-Min調(diào)度策略依賴于用戶的QoS，即用戶預(yù)期完成時(shí)間越靠前，該任務(wù)的優(yōu)先級(jí)越高，調(diào)度器也會(huì)優(yōu)先執(zhí)行該任務(wù)。

(4)加權(quán)公平調(diào)度策略(Weighted Fair Scheduler)[21]：加權(quán)公平調(diào)度策略采用任務(wù)到達(dá)時(shí)間和預(yù)期完成時(shí)間的加權(quán)值作為任務(wù)執(zhí)行順序的標(biāo)準(zhǔn)。更小的加權(quán)值對(duì)應(yīng)的任務(wù)具有更高的優(yōu)先級(jí)。

(5)Tetris[22]+Perf調(diào)度策略：Tetris策略通?；谛阅茉u(píng)估來(lái)為任務(wù)分配資源。但是，在深度學(xué)習(xí)研發(fā)場(chǎng)景下該策略沒(méi)有自身的性能模型，因此本文將Tetris和所提出的性能預(yù)測(cè)模型相結(jié)合，并每次為任務(wù)選擇具有最高執(zhí)行性能的放置策略。

(6)Tetris+CER調(diào)度策略：和上述方案類似，但采用Tetris和性價(jià)比模型相結(jié)合的方式，每次為任務(wù)選擇性價(jià)比最高的放置策略，不考慮用戶自身的QoS。

可見(jiàn)從Tetris+Perf調(diào)度策略到Tetris+CER調(diào)度策略，再到本文基于用戶QoS感知的調(diào)度策略，其中包含關(guān)于深度學(xué)習(xí)任務(wù)自身特征的信息越來(lái)越多。整體而言，相比于上述對(duì)比策略，本文的調(diào)度策略同時(shí)將用戶的QoS以及資源占用性價(jià)比納入了調(diào)度決策，能夠更好地實(shí)現(xiàn)用戶滿意度和資源利用率之間的平衡。

評(píng)測(cè)標(biāo)準(zhǔn)：調(diào)度目標(biāo)在保證用戶QoS的同時(shí)，盡可能提高集群的資源利用率。因此，實(shí)驗(yàn)評(píng)測(cè)中采用的指標(biāo)為所有任務(wù)的完成時(shí)間makespan，以及用戶的QoS保證率Q。用戶QoS保證率的具體計(jì)算方式如式(17)所示:

(17)

其中,NUMcomp表示執(zhí)行時(shí)間未超過(guò)預(yù)期完成時(shí)間的任務(wù)數(shù)目，而NUMtask表示任務(wù)隊(duì)列中的任務(wù)總數(shù)，因此用戶QoS保證率是指不超過(guò)預(yù)期完成時(shí)間的任務(wù)百分比。

不同深度學(xué)習(xí)任務(wù)的執(zhí)行時(shí)長(zhǎng)差異極大，為公平展現(xiàn)深度學(xué)習(xí)任務(wù)性能和調(diào)度性能，本文采用平均標(biāo)準(zhǔn)化的執(zhí)行時(shí)間(average normalization of response latency)來(lái)統(tǒng)一進(jìn)行分析和對(duì)比。對(duì)于特定的任務(wù)隊(duì)列〈t1,t2,…〉，其平均標(biāo)準(zhǔn)化的執(zhí)行時(shí)間具體定義如式(18)所示:

L=avg(Lnorm(ti)),i∈[1,2,…],

(18)

其中,Lnorm(ti)表示任務(wù)ti標(biāo)準(zhǔn)化后的執(zhí)行時(shí)間，為其實(shí)際執(zhí)行時(shí)間Lwall(ti)與式(4)計(jì)算的該任務(wù)在單個(gè)GPU上的執(zhí)行時(shí)間Lat(ti,〈1,1〉)之比。為降低隨機(jī)性因素的影響，所有實(shí)驗(yàn)都取3次獨(dú)立測(cè)試取平均值后的結(jié)果。

5.2 性能預(yù)測(cè)模型實(shí)驗(yàn)

首先測(cè)試第3節(jié)性能預(yù)測(cè)模型的效果。深度學(xué)習(xí)任務(wù)的分布式性能主要由單GPU性能和多GPU通信2部分組成，本文采用式(5)進(jìn)行預(yù)測(cè)。對(duì)Inception-v3和ResNet50 2個(gè)典型訓(xùn)練任務(wù)的預(yù)測(cè)結(jié)果與真實(shí)性能的對(duì)比如圖4所示，其中方塊為表1所示實(shí)驗(yàn)平臺(tái)上測(cè)得的真實(shí)性能，三角形為模型的預(yù)測(cè)結(jié)果。橫坐標(biāo)表示不同的分布式放置策略，B、N、G分別表示batchsize、運(yùn)算所占用的結(jié)點(diǎn)數(shù)和每個(gè)結(jié)點(diǎn)占用的GPU數(shù)量，例如“64B1N1G”表示batchsize為64，結(jié)點(diǎn)數(shù)和GPU數(shù)均為1；縱坐標(biāo)為計(jì)算性能，單位為image/s，表示每秒訓(xùn)練完成的圖像樣本數(shù)量。從圖4中可以發(fā)現(xiàn)，不同放置策略下性能預(yù)測(cè)模型的結(jié)果與真實(shí)性能的趨勢(shì)相同，其平均預(yù)測(cè)誤差低于5%。對(duì)于推理任務(wù)，由于沒(méi)有同步通信的開(kāi)銷，其預(yù)測(cè)精度還要高于訓(xùn)練任務(wù)。由于深度學(xué)習(xí)任務(wù)具有迭代性特征，因此對(duì)每個(gè)任務(wù)只需要進(jìn)行大約100次左右的迭代執(zhí)行，每次迭代平均耗時(shí)約為0.5 min。預(yù)測(cè)精度和開(kāi)銷均能夠滿足調(diào)度任務(wù)的需求。

Figure 4 Measured and predicted performance of Inception-v3 and ResNet50 training tasks 圖4 Inception-v3 和 ResNet50 訓(xùn)練任務(wù)的 真實(shí)性能和預(yù)測(cè)性能對(duì)比

此外如2.1節(jié)所述，在深度學(xué)習(xí)研發(fā)的過(guò)程中廣泛存在超參數(shù)調(diào)整和網(wǎng)絡(luò)fine-tuning，使得用戶提交到GPU集群的作業(yè)中存在大量網(wǎng)絡(luò)結(jié)構(gòu)相同或相似的任務(wù)，其計(jì)算通信特性也相似。對(duì)于這些相同或相似的任務(wù)，每個(gè)深度學(xué)習(xí)模型只需要進(jìn)行1次離線評(píng)估，其對(duì)應(yīng)構(gòu)建的性能預(yù)測(cè)模型將會(huì)保存在數(shù)據(jù)庫(kù)中，后續(xù)相同類型的任務(wù)可以直接查詢，不需重復(fù)進(jìn)行評(píng)估。

5.3 調(diào)度策略性能對(duì)比實(shí)驗(yàn)

Figure 5 Performance comparison of diverse scheduling strategies圖5 不同調(diào)度策略的性能對(duì)比

首先本節(jié)將基于用戶QoS感知的動(dòng)態(tài)調(diào)度策略與其他幾種基準(zhǔn)策略進(jìn)行評(píng)測(cè)和對(duì)比。如圖5a和圖5b所示，隨著任務(wù)提交密度的增大，所有調(diào)度策略的用戶QoS保證率都在逐漸下降，因?yàn)槿蝿?wù)密度的增大意味著同樣規(guī)模的計(jì)算資源要處理更多的任務(wù)，從而導(dǎo)致用戶QoS的滿意度下降。具體來(lái)看，容量調(diào)度策略和Tetris+CER調(diào)度策略比其他基準(zhǔn)策略表現(xiàn)更好，因?yàn)檫@些策略更關(guān)注于資源共享而不是單個(gè)任務(wù)的性能。對(duì)于FIFO調(diào)度策略和Tetris+Perf，過(guò)度追求每個(gè)任務(wù)的性能最大化，導(dǎo)致其他任務(wù)的等待時(shí)間過(guò)長(zhǎng)或集群資源的利用率低。而Min-Min調(diào)度策略和加權(quán)公平調(diào)度策略只關(guān)注用戶的需求，忽略了對(duì)任務(wù)性能本身和資源占用的直接關(guān)系。相比于上述基準(zhǔn)調(diào)度策略，本文的用戶QoS感知策略能夠?qū)⒂脩粜枨蠛托阅芘c資源占用的關(guān)系同時(shí)納入調(diào)度設(shè)計(jì)的考量中，實(shí)現(xiàn)用戶滿意度和集群資源利用率的平衡。同時(shí)，該策略對(duì)不同任務(wù)密度的任務(wù)隊(duì)列具有良好的容忍度和魯棒性，這是因?yàn)檎{(diào)度策略基于當(dāng)前系統(tǒng)負(fù)載狀況和用戶的QoS需求可以動(dòng)態(tài)調(diào)整。從結(jié)果上分析，本文方法在用戶QoS保證率上和makespan上比最好的基準(zhǔn)策略也分別提高了67.4%和降低了28.2%。然而，如果任務(wù)密度過(guò)大(>20)，用戶的QoS需求很難滿足。此外，本文還對(duì)任務(wù)的平均執(zhí)行時(shí)間也進(jìn)行了評(píng)測(cè)，結(jié)果如圖5c所示。顯然Tetris+Perf調(diào)度策略從單任務(wù)性能出發(fā)，每次選擇能夠最大化任務(wù)性能的放置策略，因此在該項(xiàng)指標(biāo)中具有明顯優(yōu)勢(shì)，但是該策略會(huì)導(dǎo)致資源利用率低，其他任務(wù)等待時(shí)間過(guò)長(zhǎng)。相比于該策略，本文方法在不同任務(wù)密度下依然可以取得較好的單任務(wù)性能，同時(shí)還能兼顧資源共享。而其他調(diào)度策略只是將深度學(xué)習(xí)任務(wù)作為黑盒子，而忽略了資源占用和深度學(xué)習(xí)任務(wù)性能之間的關(guān)系。最后對(duì)不同調(diào)度策略下任務(wù)完成的累積分布CDF(Cumulative Distribution Function)進(jìn)行了統(tǒng)計(jì)，結(jié)果如圖5d所示。由于本文策略具有更高的資源利用率，因此任務(wù)完成的速率也高于其他調(diào)度策略。

5.4 任務(wù)敏感性測(cè)試

為評(píng)估生成任務(wù)隊(duì)列的各種設(shè)置參數(shù)具體會(huì)對(duì)調(diào)度策略有什么影響，本節(jié)分別針對(duì)每個(gè)參數(shù)進(jìn)行任務(wù)敏感性實(shí)驗(yàn)。首先考慮調(diào)度策略在不同任務(wù)密度下的性能對(duì)比。如圖6a和圖6b所示，當(dāng)任務(wù)密度比較稀疏時(shí)，大部分調(diào)度策略都能夠有較好的調(diào)度性能。而隨著任務(wù)密度的增大，由于計(jì)算資源優(yōu)先，用戶的QoS需求越來(lái)越難以保證，同時(shí)所有調(diào)度策略完成所有任務(wù)的時(shí)間都在不斷增長(zhǎng)。和其他基準(zhǔn)策略相比，本文基于用戶QoS感知的調(diào)度策略可以動(dòng)態(tài)考慮用戶需求和集群負(fù)載狀況，因此對(duì)任務(wù)密度具有更高的容忍度。該策略和其他最好的基準(zhǔn)策略相比在QoS保證率上提高了67.5%，在所有任務(wù)的完成時(shí)間上降低了39.3%。

其次考慮不同緊急程度的研發(fā)場(chǎng)景下調(diào)度問(wèn)題，即各種優(yōu)先級(jí)用戶比例不同的場(chǎng)景下的調(diào)度問(wèn)題。如圖6c和圖6d所示，圖中每列數(shù)據(jù)下方的3個(gè)數(shù)字分別表示3種不同優(yōu)先級(jí)用戶比例，分別是Urgent/Prior/Normal。從結(jié)果上來(lái)看，隨著優(yōu)先級(jí)越高的用戶所占比例增加，整體用戶QoS的保證率也在不斷下降。通過(guò)和其他基準(zhǔn)策略的對(duì)比，本文策略每次調(diào)度都嘗試為用戶選擇盡可能滿足需求的放置策略，同時(shí)盡可能縮短整個(gè)任務(wù)的完成時(shí)間。

最后考慮拉長(zhǎng)任務(wù)隊(duì)列提交時(shí)間長(zhǎng)度的影響。評(píng)測(cè)中的任務(wù)密度設(shè)置為每小時(shí)到達(dá)15個(gè)任務(wù)，其評(píng)測(cè)結(jié)果如圖6e和圖6f所示。隨著任務(wù)提交時(shí)間的拉長(zhǎng)，所有任務(wù)完成時(shí)間同樣也在增長(zhǎng)，本文策略在用戶QoS保證率上具有明顯的優(yōu)勢(shì)。

Figure 6 Sensitivity test of scheduling policy to task queue parameter setting圖6 調(diào)度策略對(duì)任務(wù)隊(duì)列參數(shù)設(shè)置的敏感性測(cè)試

5.5 調(diào)度器開(kāi)銷

系統(tǒng)調(diào)度開(kāi)銷主要來(lái)自于對(duì)系統(tǒng)運(yùn)行負(fù)載的監(jiān)控和反饋，以及每個(gè)任務(wù)放置策略的決策過(guò)程，而這些過(guò)程的大部分開(kāi)銷都是在主結(jié)點(diǎn)(Master node)上產(chǎn)生的。如圖7所示，隨著任務(wù)密度的增大，調(diào)度器需要對(duì)更多的任務(wù)放置策略進(jìn)行決策，因此也會(huì)導(dǎo)致更高的調(diào)度開(kāi)銷。相比于其他基準(zhǔn)策略，由于本文調(diào)度策略設(shè)計(jì)更加復(fù)雜，因此調(diào)度開(kāi)銷也要高于其他方法的。然而相比于所有任務(wù)的完成時(shí)間makespan(數(shù)十小時(shí)，甚至數(shù)百小時(shí))，即使在任務(wù)密度較大的狀態(tài)下(=20)，本文方法調(diào)度開(kāi)銷所占比例也低于主結(jié)點(diǎn)總開(kāi)銷。

Figure 7 Cumulative scheduling overhead on master node圖7 主結(jié)點(diǎn)上的累積調(diào)度開(kāi)銷

6 結(jié)束語(yǔ)

本文圍繞GPU集群平臺(tái)上的深度學(xué)習(xí)研發(fā)場(chǎng)景，提出一種用戶QoS感知的動(dòng)態(tài)調(diào)度方法，由離線評(píng)估模塊和在線動(dòng)態(tài)調(diào)度模塊2部分組成。通過(guò)離線評(píng)估器構(gòu)建深度學(xué)習(xí)任務(wù)的性能預(yù)測(cè)模型，然后動(dòng)態(tài)地為每個(gè)深度學(xué)習(xí)任務(wù)選擇最佳放置策略并在GPU集群上調(diào)度執(zhí)行。本文通過(guò)TensorFlow插件模式實(shí)現(xiàn)了該調(diào)度方法，在實(shí)際GPU集群上進(jìn)行的實(shí)驗(yàn)表明，該方法比其他基準(zhǔn)對(duì)比方法能夠?qū)崿F(xiàn)更高的QoS保證率和集群資源利用率。未來(lái)計(jì)劃進(jìn)一步將該方法合并到Kubernetes等主流集群管理器框架中。