用戶QoS感知的GPU集群深度學習任務動態(tài)調(diào)度*

羅 磊，陳照云，王儷璇

(國防科技大學計算機學院，湖南 長沙 410073)

1 引言

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

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

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

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

2 GPU集群深度學習任務調(diào)度模型

2.1 深度神經(jīng)網(wǎng)絡結構與計算特性

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

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

2.2 GPU集群深度學習研發(fā)任務調(diào)度建模

面向圖1所示分布式GPU集群下的深度學習研發(fā)場景，本文采用式(1)所示的三元組描述GPU集群平臺：

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

(1)

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

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

t=〈wtype,wbat,witer〉

(2)

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

深度學習任務的屬性由用戶提交的任務確定，GPU集群平臺一方面可以調(diào)整任務執(zhí)行的順序，另一方面可以改變?nèi)蝿盏姆胖貌呗浴１疚牟捎脤ΨQ式放置，任務放置策略可以抽象為如式(3)所示的二元組:

s=〈dnode,dg/n〉

(3)

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

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

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

3 基于離線評估的性能預測模型

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

(4)

其中,PR(t,s)為任務的吞吐率，而wbat·witer為整個任務的計算量，v為任務啟動開銷，是一個常量。

深度學習任務的分布式性能受單GPU上子任務的計算性能，及多GPU間同步通信開銷2方面影響。基于此建立深度學習任務吞吐率的性能預測模型，如式(5)所示:

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

(5)

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

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

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

(6)

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

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

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

(7)

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

由式(5)知，同步通信開銷與平臺的GPU互連層次化結構以及每個深度學習任務的放置策略有關。利用任務所占GPU之間的平均通信路徑長度來構建同步通信開銷的罰值函數(shù)，如式(8)所示：

(8)

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

4 QoS感知的深度學習任務調(diào)度

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

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

(9)

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

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

(10)

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

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

(11)

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

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

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

maximizing:Q,minimizing:M,

(12)

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

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

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

(13)

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

(14)

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

lij+tcurr≤ei,

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

(15)

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

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

wi=ei-(li*+tcurr),

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

(16)

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

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

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

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

4.3 方法實現(xiàn)

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

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

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

5 實驗評測與討論

5.1 實驗設置

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

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

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

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

Table 2 Specifications of task queue generation表2 任務隊列設置

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

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

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

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

(5)Tetris[22]+Perf調(diào)度策略：Tetris策略通常基于性能評估來為任務分配資源。但是，在深度學習研發(fā)場景下該策略沒有自身的性能模型，因此本文將Tetris和所提出的性能預測模型相結合，并每次為任務選擇具有最高執(zhí)行性能的放置策略。

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

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

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

(17)

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

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

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

(18)

其中,Lnorm(ti)表示任務ti標準化后的執(zhí)行時間，為其實際執(zhí)行時間Lwall(ti)與式(4)計算的該任務在單個GPU上的執(zhí)行時間Lat(ti,〈1,1〉)之比。為降低隨機性因素的影響，所有實驗都取3次獨立測試取平均值后的結果。

5.2 性能預測模型實驗

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

Figure 4 Measured and predicted performance of Inception-v3 and ResNet50 training tasks 圖4 Inception-v3 和 ResNet50 訓練任務的 真實性能和預測性能對比

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

5.3 調(diào)度策略性能對比實驗

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

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

5.4 任務敏感性測試

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

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

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

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

5.5 調(diào)度器開銷

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

Figure 7 Cumulative scheduling overhead on master node圖7 主結點上的累積調(diào)度開銷

6 結束語

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