面向數(shù)據(jù)共享的模型訓(xùn)練服務(wù)系統(tǒng)*

魏 宏 原，華 蓓，林 飛

(1.中國(guó)科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，安徽 合肥 230027；2.中國(guó)科學(xué)院無(wú)線(xiàn)光電通信重點(diǎn)實(shí)驗(yàn)室，安徽 合肥 230027)

0 引言

隨著物聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能技術(shù)的發(fā)展，以及智慧城市、智慧醫(yī)療、電子商務(wù)等應(yīng)用的廣泛普及，每天都有海量的數(shù)據(jù)產(chǎn)生，這些數(shù)據(jù)蘊(yùn)涵了大量有價(jià)值的信息。但是另一方面，數(shù)據(jù)不足正成為當(dāng)下制約人工智能發(fā)展的一大瓶頸。例如，深度神經(jīng)網(wǎng)絡(luò)需要大量數(shù)據(jù)來(lái)訓(xùn)練，但現(xiàn)實(shí)中大多數(shù)領(lǐng)域只有少量數(shù)據(jù)集可用，如自動(dòng)駕駛只有數(shù)個(gè)公開(kāi)數(shù)據(jù)集，醫(yī)學(xué)圖像領(lǐng)域不僅數(shù)據(jù)集少，且每個(gè)數(shù)據(jù)集僅包含數(shù)十或數(shù)百個(gè)病例。造成這種現(xiàn)象的原因主要有兩個(gè)方面，一是原始數(shù)據(jù)必須經(jīng)過(guò)清洗和標(biāo)注才能使用，而這一過(guò)程不僅費(fèi)時(shí)費(fèi)力，更可能需要專(zhuān)業(yè)人士的介入；二是目前各行各業(yè)的數(shù)據(jù)主要由政府和企業(yè)在收集，出于行業(yè)競(jìng)爭(zhēng)、數(shù)據(jù)安全、管理制度等方面的考慮，這些數(shù)據(jù)不能被共享，形成了許許多多的數(shù)據(jù)孤島。如何在保護(hù)數(shù)據(jù)和使用數(shù)據(jù)之間取得平衡，是當(dāng)下迫切需要解決的問(wèn)題[1]。

一些企業(yè)和機(jī)構(gòu)已經(jīng)或正在建設(shè)數(shù)據(jù)共享和交易平臺(tái)來(lái)促進(jìn)數(shù)據(jù)流通，如Exchange、數(shù)據(jù)堂、上海數(shù)據(jù)交易中心等。但目前這些平臺(tái)多以交易數(shù)據(jù)為主，用戶(hù)在付費(fèi)之后擁有對(duì)數(shù)據(jù)的永久/指定期限訪問(wèn)權(quán)，可以在數(shù)據(jù)上執(zhí)行任意計(jì)算來(lái)挖掘感興趣的信息。這會(huì)帶來(lái)兩個(gè)問(wèn)題，一是如果這些數(shù)據(jù)中包含敏感信息，直接開(kāi)放給用戶(hù)下載會(huì)帶來(lái)數(shù)據(jù)安全問(wèn)題；二是難以控制用戶(hù)對(duì)數(shù)據(jù)進(jìn)行非法復(fù)制和傳播，數(shù)據(jù)可能被用于不正當(dāng)用途。其實(shí)很多時(shí)候用戶(hù)只想利用數(shù)據(jù)來(lái)訓(xùn)練他們需要的模型，對(duì)原始數(shù)據(jù)本身并不感興趣，向用戶(hù)提供數(shù)據(jù)的功能性服務(wù)而非直接提供數(shù)據(jù)，可以在一定程度上解決數(shù)據(jù)保護(hù)和數(shù)據(jù)使用之間的矛盾。比如，交通管理部門(mén)可在自有的城市出行數(shù)據(jù)上，為社會(huì)學(xué)研究人員訓(xùn)練用于分析人群移動(dòng)規(guī)律的數(shù)學(xué)模型。

本文提出面向數(shù)據(jù)共享的模型訓(xùn)練服務(wù)系統(tǒng)，允許機(jī)構(gòu)或企業(yè)利用自有數(shù)據(jù)集和自有計(jì)算資源，向用戶(hù)提供模型訓(xùn)練服務(wù)(當(dāng)然機(jī)構(gòu)可以向用戶(hù)收費(fèi)，但這不在本文討論的范圍內(nèi))。用戶(hù)只需指定需要的數(shù)據(jù)集并上傳自定義的模型結(jié)構(gòu)(本系統(tǒng)主要考慮深度學(xué)習(xí)模型)，系統(tǒng)可自動(dòng)完成模型訓(xùn)練作業(yè)，并向用戶(hù)返回訓(xùn)練好的模型，真正實(shí)現(xiàn)“數(shù)據(jù)可用不可見(jiàn)”。提供數(shù)據(jù)的功能性服務(wù)接口而非數(shù)據(jù)本身，對(duì)于消除數(shù)據(jù)孤島、促進(jìn)數(shù)據(jù)安全流通具有極為積極的作用。

1 相關(guān)工作

模型訓(xùn)練服務(wù)系統(tǒng)在響應(yīng)多個(gè)用戶(hù)的服務(wù)請(qǐng)求時(shí)，涉及集群資源管理和作業(yè)調(diào)度。當(dāng)前云平臺(tái)中主流的調(diào)度器有YARN、Mesos[2]、Brog、Kubernetes[3]等，這些通用調(diào)度器根據(jù)用戶(hù)要求的資源數(shù)量(主要是CPU、GPU、內(nèi)存等)，基于公平性或優(yōu)先級(jí)等策略進(jìn)行作業(yè)調(diào)度，且作業(yè)一經(jīng)部署便不再調(diào)整，除非管理員手動(dòng)調(diào)整資源組合或者用戶(hù)重新提交作業(yè)。與通用云平臺(tái)不同的是，本文考慮的數(shù)據(jù)共享平臺(tái)主要提供數(shù)據(jù)集使用服務(wù)，其資源數(shù)量有限且不能任意擴(kuò)放，如何充分利用有限的資源高效地為用戶(hù)提供服務(wù)是關(guān)鍵。通用調(diào)度器的另一個(gè)問(wèn)題是它并非針對(duì)深度學(xué)習(xí)作業(yè)而設(shè)計(jì)，Luo等人[4]發(fā)現(xiàn)，在云數(shù)據(jù)中心調(diào)度分布式機(jī)器學(xué)習(xí)作業(yè)時(shí)，由于作業(yè)隨機(jī)放置造成跨主機(jī)通信帶來(lái)的性能損失可能高達(dá)90%。因此，目前云平臺(tái)中的通用調(diào)度器并不適合本文的模型訓(xùn)練服務(wù)系統(tǒng)。

近年來(lái)，大規(guī)模機(jī)器學(xué)習(xí)模型越來(lái)越受到業(yè)界的推崇，導(dǎo)致模型訓(xùn)練時(shí)間越來(lái)越長(zhǎng)，分布式訓(xùn)練成為主流。分布式訓(xùn)練策略按照并行方式的不同分為數(shù)據(jù)并行和模型并行兩種。數(shù)據(jù)并行方式在不同的GPU上保存模型的一份副本，數(shù)據(jù)集被分割成若干個(gè)數(shù)據(jù)子集，分配到不同的GPU上計(jì)算，并合并所有GPU計(jì)算的結(jié)果進(jìn)行梯度更新。模型并行方式則是將整個(gè)神經(jīng)網(wǎng)絡(luò)模型拆解分布到不同的GPU上，每個(gè)GPU負(fù)責(zé)計(jì)算和更新網(wǎng)絡(luò)模型中的一部分。數(shù)據(jù)并行由于具有較好的伸縮性和加速效果而在實(shí)際中運(yùn)用最多。

GPU集群上的分布式機(jī)器學(xué)習(xí)調(diào)度是學(xué)術(shù)界和工業(yè)界的研究熱點(diǎn)。Peng等人[5]、Venkataraman等人[6]基于對(duì)模型收斂時(shí)間的預(yù)測(cè)進(jìn)行作業(yè)調(diào)度，在擬合模型訓(xùn)練曲線(xiàn)時(shí)需假設(shè)模型具有平滑的損失曲線(xiàn)，且模型最終能夠達(dá)到目標(biāo)精度(即模型收斂)，但在實(shí)際場(chǎng)景中損失曲線(xiàn)通常沒(méi)有這么平滑，因此這類(lèi)方法不具有通用性和實(shí)用性[7]。Xiao等人[8]、Rasley等人[9]、Sparks等人[10]針對(duì)自動(dòng)機(jī)器學(xué)習(xí)場(chǎng)景研究高效的作業(yè)調(diào)度方法，允許多個(gè)作業(yè)分時(shí)復(fù)用或共享GPU來(lái)提高利用率，并在獲取到模型訓(xùn)練的早期反饋時(shí)立即中止質(zhì)量不佳的模型訓(xùn)練作業(yè)。然而，在同一個(gè)GPU上啟動(dòng)多個(gè)訓(xùn)練作業(yè)會(huì)引入資源競(jìng)爭(zhēng)，導(dǎo)致所有作業(yè)的訓(xùn)練性能下降，甚至影響訓(xùn)練精度[11]，因而目前工業(yè)界的主流做法仍然是獨(dú)占GPU進(jìn)行模型訓(xùn)練[12]。也有一部分工作關(guān)注作業(yè)放置帶來(lái)的通信問(wèn)題，比如，Qiao等人[13]、Zhao等人[14]提出應(yīng)將一個(gè)作業(yè)的所有任務(wù)放在同一臺(tái)主機(jī)上，以減少跨主機(jī)通信帶來(lái)的性能損失，而Gu等人[7]則指出激進(jìn)的耦合會(huì)導(dǎo)致資源利用率下降(比如GPU資源不足的節(jié)點(diǎn)不會(huì)被分配作業(yè))，應(yīng)根據(jù)模型大小選擇合適的作業(yè)放置策略。本文的模型訓(xùn)練服務(wù)系統(tǒng)同樣需要關(guān)注作業(yè)放置帶來(lái)的通信開(kāi)銷(xiāo)問(wèn)題，以上研究工作對(duì)于本文設(shè)計(jì)高效的資源分配與作業(yè)放置具有借鑒作用。

2 模型訓(xùn)練服務(wù)系統(tǒng)的資源分配與調(diào)度策略

2.1 資源分配與調(diào)度原則

鑒于數(shù)據(jù)擁有方可能因擔(dān)心數(shù)據(jù)隱私泄漏而不愿意將數(shù)據(jù)放置在云數(shù)據(jù)中心，本文考慮的數(shù)據(jù)共享平臺(tái)為數(shù)據(jù)擁有方的自有平臺(tái)。與云數(shù)據(jù)中心按資源使用量付費(fèi)的商業(yè)模式不同，數(shù)據(jù)共享平臺(tái)主要按使用的數(shù)據(jù)集付費(fèi)，模型訓(xùn)練只是附加服務(wù)。與云數(shù)據(jù)中心擁有海量資源、滿(mǎn)足每個(gè)租戶(hù)的資源需求不同，數(shù)據(jù)共享平臺(tái)的資源有限且不能任意擴(kuò)放，無(wú)法滿(mǎn)足用戶(hù)的任意資源需求。因此，與云數(shù)據(jù)中心允許租戶(hù)提出資源需求不同，數(shù)據(jù)共享平臺(tái)只接受用戶(hù)的服務(wù)請(qǐng)求，資源分配由數(shù)據(jù)共享平臺(tái)來(lái)決定。

數(shù)據(jù)共享平臺(tái)在分配資源和調(diào)度服務(wù)請(qǐng)求時(shí)，需要兼顧用戶(hù)和平臺(tái)兩方的利益。站在用戶(hù)的角度，用戶(hù)希望看到自己的請(qǐng)求被立即響應(yīng)(即看到訓(xùn)練過(guò)程立即開(kāi)啟)，并盡早獲得訓(xùn)練結(jié)果；站在平臺(tái)的角度，平臺(tái)希望基于有限的資源更多更好地服務(wù)用戶(hù)請(qǐng)求。然而，用戶(hù)的服務(wù)請(qǐng)求可能在任意時(shí)刻到來(lái)，且不同請(qǐng)求的訓(xùn)練工作量可能差異很大，在請(qǐng)求的到達(dá)時(shí)間和工作量都難以預(yù)知的情況下，想要高效地分配資源是一個(gè)難題。從提升用戶(hù)體驗(yàn)的角度，系統(tǒng)應(yīng)同時(shí)運(yùn)行盡可能多的訓(xùn)練作業(yè)，以快速響應(yīng)新的服務(wù)請(qǐng)求。從平臺(tái)提供優(yōu)質(zhì)服務(wù)的角度，平臺(tái)應(yīng)公平對(duì)待每個(gè)服務(wù)請(qǐng)求，并高效地利用系統(tǒng)資源來(lái)提升自己的服務(wù)能力。

為兼顧用戶(hù)和平臺(tái)兩方面的利益，并考慮到GPU的使用特點(diǎn)，本文基于以下原則進(jìn)行資源分配和作業(yè)調(diào)度：

(1)GPU獨(dú)占使用：由于在同一塊GPU上同時(shí)訓(xùn)練多個(gè)模型存在一些尚未克服的問(wèn)題，本系統(tǒng)采用獨(dú)占GPU進(jìn)行模型訓(xùn)練的主流做法，即每次只將一個(gè)訓(xùn)練作業(yè)調(diào)度到一個(gè)GPU上執(zhí)行。

(2)先來(lái)先服務(wù)：為保證公平性，系統(tǒng)按照用戶(hù)請(qǐng)求的先后順序進(jìn)行服務(wù)。

(3)快速響應(yīng)新請(qǐng)求：只要資源許可，系統(tǒng)為每個(gè)新到達(dá)的服務(wù)請(qǐng)求分配一塊GPU，并立即啟動(dòng)訓(xùn)練過(guò)程。

(4)最少資源保證：系統(tǒng)保證每個(gè)已經(jīng)啟動(dòng)的訓(xùn)練作業(yè)至少擁有一塊GPU以確保訓(xùn)練過(guò)程不中斷，該原則實(shí)際上確保了系統(tǒng)能夠同時(shí)服務(wù)最多的用戶(hù)請(qǐng)求。

(5)適時(shí)進(jìn)行資源縮放：當(dāng)沒(méi)有新的服務(wù)請(qǐng)求到來(lái)而系統(tǒng)中尚有空閑GPU時(shí)，增加部分作業(yè)的GPU分配以縮短作業(yè)完成時(shí)間；當(dāng)新的服務(wù)請(qǐng)求到來(lái)而系統(tǒng)中沒(méi)有空閑GPU時(shí)，在不違背原則(4)的前提下，減少部分作業(yè)的GPU分配以滿(mǎn)足原則(3)。

隨著新請(qǐng)求的到來(lái)和當(dāng)前作業(yè)的結(jié)束，資源分配方案通常需要調(diào)整才能實(shí)現(xiàn)平臺(tái)和用戶(hù)收益的最大化。然而，由于模型訓(xùn)練過(guò)程中不能調(diào)整GPU的使用，調(diào)整資源分配意味著部分訓(xùn)練作業(yè)要中止，在重新分配資源和部署后再恢復(fù)訓(xùn)練，這會(huì)產(chǎn)生額外的開(kāi)銷(xiāo)，并且其帶來(lái)的收益可能受到未來(lái)請(qǐng)求的影響而難以準(zhǔn)確評(píng)估。因此，第5條原則是本系統(tǒng)要解決的關(guān)鍵問(wèn)題。

2.2 分布式模型訓(xùn)練架構(gòu)的選擇

目前工業(yè)界最具代表性的兩種分布式訓(xùn)練架構(gòu)是All-reduce和參數(shù)服務(wù)器(Parameter Server，PS)，均采用了數(shù)據(jù)并行的方式。PS架構(gòu)包含參數(shù)服務(wù)器(ps)和工作服務(wù)器(worker)兩種角色，每個(gè)worker使用一部分訓(xùn)練數(shù)據(jù)在本地計(jì)算梯度，并將它們發(fā)送到各自的ps，ps匯總梯度后對(duì)模型參數(shù)進(jìn)行更新，并將更新后的模型參數(shù)發(fā)回給worker進(jìn)行下一次迭代訓(xùn)練。研究發(fā)現(xiàn)，PS架構(gòu)中worker和ps數(shù)量的不同組合會(huì)對(duì)訓(xùn)練速度產(chǎn)生顯著影響，且增加GPU不會(huì)導(dǎo)致訓(xùn)練速度線(xiàn)性增加，有時(shí)甚至?xí)p慢訓(xùn)練速度[6]。在All-reduce架構(gòu)中，每個(gè)計(jì)算節(jié)點(diǎn)既是ps也是worker，各個(gè)計(jì)算節(jié)點(diǎn)獨(dú)立計(jì)算梯度后，使用All-reduce通信進(jìn)行梯度聚合，然后利用聚合的梯度各自更新模型參數(shù)。實(shí)驗(yàn)表明，在各個(gè)計(jì)算節(jié)點(diǎn)性能接近(同構(gòu)且擁有相同數(shù)量的GPU)時(shí)，訓(xùn)練時(shí)長(zhǎng)與計(jì)算節(jié)點(diǎn)的數(shù)目接近于反比關(guān)系。

考慮到All-reduce架構(gòu)可以獲得“可控”的訓(xùn)練速度，本系統(tǒng)采用All-reduce架構(gòu)進(jìn)行分布式模型訓(xùn)練。當(dāng)前主流的學(xué)習(xí)框架如TensorFlow和PyTorch等均支持該架構(gòu)。

2.3 自動(dòng)資源縮放

本節(jié)討論自動(dòng)資源縮放策略。假設(shè)平臺(tái)在某個(gè)時(shí)刻需要進(jìn)行資源縮放決策，用job[1..m]表示當(dāng)前參與調(diào)度的m個(gè)作業(yè)，其中job[i]為作業(yè)i剩余的訓(xùn)練輪數(shù)(epoch)，其初始值由用戶(hù)在提交服務(wù)請(qǐng)求時(shí)給出。s[1..m]為當(dāng)前的資源分配方案，其中s[i]表示分配給作業(yè)m的GPU數(shù)量，P為系統(tǒng)中的GPU總數(shù)。作業(yè)i在當(dāng)前資源配置下完成一輪訓(xùn)練的耗時(shí)用fi(s[i])進(jìn)行估計(jì)。需要說(shuō)明的是，作業(yè)的訓(xùn)練速度與所分配的GPU數(shù)量和GPU的分布(如跨主機(jī)或不跨主機(jī))都有關(guān)系，為簡(jiǎn)化計(jì)算，在估計(jì)一輪訓(xùn)練用時(shí)時(shí)忽略GPU的位置影響?？梢杂袃煞N方法來(lái)獲得fi(·)值，訓(xùn)練開(kāi)始時(shí)可以使用預(yù)設(shè)的經(jīng)驗(yàn)值，訓(xùn)練過(guò)程中可以實(shí)時(shí)記錄各個(gè)作業(yè)在不同資源配置(GPU數(shù)量)下的訓(xùn)練用時(shí)，在積累了一定量的訓(xùn)練速度數(shù)據(jù)后通過(guò)最小二乘法進(jìn)行擬合，得到不同GPU數(shù)量下一輪訓(xùn)練用時(shí)的估計(jì)值。

記所有資源分配方案s的集合為S，資源縮放決策是要得到一個(gè)最佳的資源分配方案s′∈S，使得所有作業(yè)的剩余完成時(shí)間之和最小，即：

下面針對(duì)資源擴(kuò)放和資源縮減兩種情況分別進(jìn)行討論。

2.3.1 資源擴(kuò)放

當(dāng)沒(méi)有新的服務(wù)請(qǐng)求到來(lái)而系統(tǒng)中仍有空閑GPU時(shí)，系統(tǒng)執(zhí)行資源擴(kuò)放。假設(shè)當(dāng)前的資源分配方案為s[1..m]，有K個(gè)空閑的GPU，用inc[1..m]表示一種增量分配方案，其中inc[i]為給作業(yè)i增加的GPU數(shù)量。用delta[i]表示作業(yè)i增加了GPU分配后得到的收益(即減少的訓(xùn)練時(shí)間)，有：

delta[i]=(fi(s[i])-fi(s[i]+inc[i]))×job[i](3)

記所有資源增量分配方案inc的集合為I，資源擴(kuò)放決策是要找到一個(gè)最佳的增量分配方案inc′∈I，使得所有作業(yè)的剩余完成時(shí)間之和減少最多，即：

如果把獲得增量GPU分配的作業(yè)看作“物品”(獲得不同增量GPU的同一作業(yè)看成是不同的物品)，增加的GPU數(shù)量看作物品的“重量”，作業(yè)為此得到的收益看作物品的“價(jià)值”，則求解以上問(wèn)題可以規(guī)約為求解一個(gè)0-1背包問(wèn)題，即在滿(mǎn)足背包容量為K的前提下，使得包內(nèi)物品的總價(jià)值最高。

該背包問(wèn)題可用動(dòng)態(tài)規(guī)劃法進(jìn)行求解。算法1為資源擴(kuò)放算法的偽代碼，其中第1～7行根據(jù)轉(zhuǎn)移方程求出最大收益之和f[m][K]，第8～15行根據(jù)最大收益和反推作業(yè)i增加的GPU數(shù)量，即inc[i]。

算法1.Resource Expansion

輸入：s[1..m]，job[1..m]，K

輸出：inc[1..m]

2.3.2 資源縮減

當(dāng)有服務(wù)請(qǐng)求而系統(tǒng)中沒(méi)有空閑GPU時(shí)，系統(tǒng)執(zhí)行資源縮減。假設(shè)當(dāng)前的資源分配方案為s[1..m]，有K個(gè)服務(wù)請(qǐng)求到來(lái)。根據(jù)第3條、第4條原則，當(dāng)P-m≥K時(shí)回收K個(gè)GPU，當(dāng)P-m＜K時(shí)回收(P-m)個(gè)GPU。用dec[1..m]表示一種資源縮減方案，其中dec[i]為從作業(yè)i收回的GPU數(shù)量。用nabla[i]表示作業(yè)i減少了GPU后的損失(即增加的訓(xùn)練時(shí)間)，如式(6)所示(未縮減GPU的作業(yè)損失為0)：

nabla[i]=(fi(s[i]-dec[i])-fi(s[i]))×job[i](6)

記所有資源回收方案dec集合為D，資源回收決策是要找到一個(gè)最佳的縮減方案dec′∈D，使得已有作業(yè)的損失和最少，即：

如果將從某個(gè)作業(yè)中一次收回的GPU資源看作“物品”，其包含的GPU數(shù)量看作物品的“重量”，作業(yè)為此遭受的損失為物品的“價(jià)值”，則求解以上問(wèn)題同樣可以規(guī)約為求解一個(gè)0-1背包問(wèn)題，即在所選物品恰好等于背包容量的前提下使得包內(nèi)物品的總價(jià)值最低。

該背包問(wèn)題同樣可以用動(dòng)態(tài)規(guī)劃法進(jìn)行求解。資源縮減的偽代碼如算法2所示，其中回收的GPU數(shù)量K′=min(K，P-m)，第1～7行計(jì)算從作業(yè)中回收GPU導(dǎo)致的損失值，第8～13行根據(jù)轉(zhuǎn)移方程求出最小損失和f[m][K′]，第14～20行根據(jù)最小損失和反推作業(yè)i減少的GPU數(shù)量，即dec[i]。

算法2.Resource Reduction

輸入： s[1..m]，job[1..m]，K′

輸出： dec[1..m]

2.4 作業(yè)放置策略

在得到資源擴(kuò)放或縮減的方案后，對(duì)于涉及的作業(yè)需要中止其訓(xùn)練過(guò)程，重新部署后再恢復(fù)訓(xùn)練。當(dāng)分布式訓(xùn)練作業(yè)使用多塊GPU時(shí)，不同的作業(yè)放置方法對(duì)于作業(yè)訓(xùn)練速度會(huì)產(chǎn)生不同的影響。通常來(lái)說(shuō)，跨主機(jī)通信會(huì)產(chǎn)生較大的通信開(kāi)銷(xiāo)，因此一般傾向于將作業(yè)分布到盡可能少的服務(wù)器上。如果將包含空閑GPU的節(jié)點(diǎn)看作是一個(gè)空閑分區(qū)，空閑GPU數(shù)量為空閑分區(qū)的大小，則為作業(yè)尋找放置節(jié)點(diǎn)相當(dāng)于為作業(yè)分配所需要的空閑分區(qū)。該問(wèn)題可以采用最佳適應(yīng)(best fit)算法進(jìn)行求解。

對(duì)集群中的的節(jié)點(diǎn)、作業(yè)進(jìn)行全局編號(hào)。包含空閑GPU的節(jié)點(diǎn)用元組node=(nodeId，gpuNum)表示，其中g(shù)puNum為節(jié)點(diǎn)中空閑GPU的數(shù)量，用H表示由這些節(jié)點(diǎn)組成的且按照gpuNum升序排列的隊(duì)列。每個(gè)需要重新部署的作業(yè)對(duì)象用job=(jobId，gpuNum，nodeList)表示，gpuNum其中為分配給作業(yè)的GPU數(shù)量，nodeList={(nodeId，gpuNum)}為作業(yè)的放置方案。需要重新部署的作業(yè)，在擴(kuò)放過(guò)程中是指增加了GPU的作業(yè)，在縮減過(guò)程中是指減少了GPU的作業(yè)以及新到達(dá)可部署的作業(yè)，用J表示由這些作業(yè)對(duì)象組成的且按照gpuNum降序排列的隊(duì)列。

算法3為作業(yè)放置的偽代碼，其中第5～12行找到第一個(gè)能放下job的節(jié)點(diǎn)，將該節(jié)點(diǎn)添加到作業(yè)放置列表中；第13～16行為未找到能完整放下job的節(jié)點(diǎn)時(shí)，取擁有最多空閑GPU的節(jié)點(diǎn)添加到作業(yè)放置列表中，更新作業(yè)所需GPU值，重復(fù)第5～16行的過(guò)程直到作業(yè)所需GPU數(shù)為零。

算法3.Job Placement

輸入：J，H

輸出：J

3 模型訓(xùn)練服務(wù)系統(tǒng)的實(shí)現(xiàn)

本文實(shí)現(xiàn)的模型訓(xùn)練服務(wù)系統(tǒng)具備以下功能：

(1)接收用戶(hù)的服務(wù)請(qǐng)求，包括要訓(xùn)練的神經(jīng)網(wǎng)絡(luò)模型和超參數(shù)、訓(xùn)練模型需要使用的數(shù)據(jù)集等。

(2)為每個(gè)訓(xùn)練作業(yè)分配資源，并部署到相應(yīng)節(jié)點(diǎn)上執(zhí)行，根據(jù)需要對(duì)正在執(zhí)行的訓(xùn)練作業(yè)進(jìn)行資源調(diào)整。

(3)將訓(xùn)練進(jìn)度及結(jié)果返回給用戶(hù)。

為方便用戶(hù)使用，系統(tǒng)設(shè)計(jì)為前后端架構(gòu)，前端提供基于Web的服務(wù)訪問(wèn)接口，后端完成服務(wù)請(qǐng)求。后端由服務(wù)器集群組成，負(fù)責(zé)為用戶(hù)提交的模型訓(xùn)練作業(yè)分配資源，并部署到相應(yīng)的節(jié)點(diǎn)上執(zhí)行。考慮到不同的模型可能使用不同的深度學(xué)習(xí)框架或不同的軟件環(huán)境，為方便訓(xùn)練作業(yè)的部署及遷移，系統(tǒng)采用容器作為運(yùn)行環(huán)境。Docker是目前最流行的容器引擎，它將應(yīng)用程序及依賴(lài)的運(yùn)行環(huán)境打包為“鏡像”，極大地簡(jiǎn)化了應(yīng)用交付模式，實(shí)現(xiàn)一次構(gòu)建多次使用，并且部署和啟動(dòng)容器的速度很快，因此本系統(tǒng)使用Docker來(lái)實(shí)現(xiàn)容器的部署與管理。模型訓(xùn)練服務(wù)系統(tǒng)的整體如圖1所示。

圖1 模型訓(xùn)練服務(wù)系統(tǒng)的整體架構(gòu)

系統(tǒng)采用集中式資源管理和作業(yè)調(diào)度方法，服務(wù)器分為接口服務(wù)器、主控節(jié)點(diǎn)、工作節(jié)點(diǎn)、存儲(chǔ)服務(wù)器四種角色。用戶(hù)與接口服務(wù)器交互，主控節(jié)點(diǎn)從接口服務(wù)器接收用戶(hù)請(qǐng)求，確定資源分配和作業(yè)放置方案，向工作節(jié)點(diǎn)發(fā)送作業(yè)調(diào)度指令，工作節(jié)點(diǎn)完成作業(yè)的部署和執(zhí)行。為方便用戶(hù)查看訓(xùn)練進(jìn)度和獲取訓(xùn)練模型，工作節(jié)點(diǎn)將模型訓(xùn)練的中間結(jié)果及最終結(jié)果保存到存儲(chǔ)服務(wù)器，供接口服務(wù)器查詢(xún)和下載。

接口服務(wù)器接收用戶(hù)的HTTP請(qǐng)求，對(duì)請(qǐng)求內(nèi)容進(jìn)行合法性檢查后，將其制作成一個(gè)json對(duì)象發(fā)送給主控節(jié)點(diǎn)。

主控節(jié)點(diǎn)包含預(yù)處理器、調(diào)度器、后處理器、訓(xùn)練速度預(yù)測(cè)器四個(gè)組件，并維護(hù)一個(gè)系統(tǒng)資源表。系統(tǒng)資源表在服務(wù)器啟動(dòng)時(shí)初始化，并在運(yùn)行過(guò)程中實(shí)時(shí)保存每個(gè)節(jié)點(diǎn)的資源使用情況(主要為空閑GPU信息)。預(yù)處理器接收接口服務(wù)器推送過(guò)來(lái)的消息，根據(jù)json對(duì)象中的模型鏡像、數(shù)據(jù)集、訓(xùn)練參數(shù)等內(nèi)容創(chuàng)建job對(duì)象。調(diào)度器獲取job對(duì)象并生成作業(yè)調(diào)度指令，在此過(guò)程中需要查詢(xún)資源使用情況、作業(yè)訓(xùn)練速度和當(dāng)前正在運(yùn)行的作業(yè)信息。訓(xùn)練速度預(yù)測(cè)器保存每個(gè)作業(yè)在每種資源配置下的訓(xùn)練速度，該值由調(diào)度器從工作節(jié)點(diǎn)獲得并更新；當(dāng)調(diào)度器查詢(xún)的資源配置不存在時(shí)，訓(xùn)練速度預(yù)測(cè)器通過(guò)擬合已有歷史記錄得到一個(gè)預(yù)測(cè)值。后處理器從工作節(jié)點(diǎn)獲得作業(yè)結(jié)束的通知后釋放資源，并更新系統(tǒng)資源表。

工作節(jié)點(diǎn)包含執(zhí)行器和監(jiān)視器兩個(gè)組件。執(zhí)行器接收調(diào)度器的作業(yè)調(diào)度指令，創(chuàng)建容器并啟動(dòng)作業(yè)。監(jiān)視器組件監(jiān)視容器狀態(tài)，并將作業(yè)訓(xùn)練速度、訓(xùn)練輪次等信息推送給主控節(jié)點(diǎn)調(diào)度器，當(dāng)有容器退出時(shí)通知主控節(jié)點(diǎn)的后處理器。容器若是被動(dòng)退出(發(fā)生資源縮放)，會(huì)將當(dāng)前訓(xùn)練狀態(tài)保存到存儲(chǔ)服務(wù)器；若是主動(dòng)退出(模型訓(xùn)練完成)，則將訓(xùn)練結(jié)果保存到存儲(chǔ)服務(wù)器。系統(tǒng)中各組件之間通信通過(guò)gRPC實(shí)現(xiàn)。

對(duì)正在訓(xùn)練的作業(yè)進(jìn)行資源縮放需要保存訓(xùn)練的中間結(jié)果，當(dāng)前主流做法是采用檢查點(diǎn)(checkpoint)文件保存訓(xùn)練作業(yè)的中間狀態(tài)。檢查點(diǎn)文件是一個(gè)二進(jìn)制文件，它將變量名映射到對(duì)應(yīng)的tensor值，本質(zhì)上存儲(chǔ)的是當(dāng)前訓(xùn)練得到的模型參數(shù)值。加載檢查點(diǎn)文件會(huì)帶來(lái)一些時(shí)間開(kāi)銷(xiāo)，為此Wu[15]、Or[16]等通過(guò)修改機(jī)器學(xué)習(xí)框架來(lái)減少該時(shí)間。本文通過(guò)實(shí)驗(yàn)發(fā)現(xiàn)(見(jiàn)4.2節(jié))，該開(kāi)銷(xiāo)相對(duì)于減少的訓(xùn)練時(shí)間可以忽略，為此本文直接使用機(jī)器學(xué)習(xí)框架中的檢查點(diǎn)函數(shù)，以保持系統(tǒng)較好的通用性。當(dāng)前機(jī)器學(xué)習(xí)框架中的檢查點(diǎn)函數(shù)要求用戶(hù)指定檢查點(diǎn)的保存地址和名稱(chēng)，為保護(hù)系統(tǒng)安全和方便管理，本系統(tǒng)不允許用戶(hù)設(shè)定檢查點(diǎn)的保存地址，而是由系統(tǒng)設(shè)置，并在調(diào)度過(guò)程中隨調(diào)度指令一起發(fā)送到目的工作節(jié)點(diǎn)。

為方便系統(tǒng)部署作業(yè)和獲得作業(yè)相關(guān)信息，本文將模型運(yùn)行環(huán)境及自定義函數(shù)庫(kù)封裝為基礎(chǔ)鏡像，用戶(hù)基于該鏡像調(diào)用編程接口完成訓(xùn)練代碼的書(shū)寫(xiě)。

4 實(shí)驗(yàn)評(píng)估

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

測(cè)試平臺(tái)是由3臺(tái)服務(wù)器組成的小型集群，服務(wù)器之間通過(guò)萬(wàn)兆以太網(wǎng)連接。一臺(tái)服務(wù)器同時(shí)承擔(dān)主控節(jié)點(diǎn)、工作節(jié)點(diǎn)和存儲(chǔ)服務(wù)器的功能，配置IntelXeon Gold 6230處理器，運(yùn)行Ubuntu 16.04操作系統(tǒng)，配有4塊NVIDIA RTX2080Ti GPU卡。另外兩臺(tái)服務(wù)器作為工作節(jié)點(diǎn)，配置Intel Xeon E5-2699 v4處理器，運(yùn)行CentOS 7操作系統(tǒng)，每臺(tái)服務(wù)器配有4塊NVIDIA Tesla P100 GPU卡。所有服務(wù)器部署Docker引擎，版本為1.15.3。

選取深度學(xué)習(xí)中常見(jiàn)的5種圖像分類(lèi)模型作為要訓(xùn)練的模型，深度學(xué)習(xí)框架為T(mén)ensorFlow，數(shù)據(jù)集為T(mén)ensorFlow Datasets中的dogs_and_cats和tf_flowers。預(yù)先測(cè)得這些模型在一塊GPU上完成一輪(epoch)訓(xùn)練的用時(shí)在1～2 min，如表1中前5行所示。為模擬一輪訓(xùn)練用時(shí)較長(zhǎng)(10 min以上)的作業(yè)，在AlexNet模型的基礎(chǔ)上增加了數(shù)量不等的卷積層，它們?cè)谝粔KGPU上完成一輪訓(xùn)練的用時(shí)如表1中后3行所示。

表1 訓(xùn)練模型及每輪訓(xùn)練用時(shí)

對(duì)于作業(yè)調(diào)度來(lái)說(shuō)，不同的作業(yè)組成、作業(yè)到達(dá)順序和到達(dá)間隔均會(huì)影響測(cè)試結(jié)果，為此本文對(duì)以上變量設(shè)置不同的值，通過(guò)多組實(shí)驗(yàn)來(lái)評(píng)估本文的資源分配和作業(yè)調(diào)度算法。Gandiva[8]對(duì)Microsoft云數(shù)據(jù)中心的作業(yè)完成時(shí)間進(jìn)行了統(tǒng)計(jì)，發(fā)現(xiàn)約30%的作業(yè)在10 min內(nèi)完成，62%的作業(yè)在100 min內(nèi)完成，82%的作業(yè)在1 000 min內(nèi)完成?？紤]到云數(shù)據(jù)中心不全是模型訓(xùn)練作業(yè)，且還有大量訓(xùn)練作業(yè)因?yàn)槟Ｐ湾e(cuò)誤而提前中止，本文參考以上統(tǒng)計(jì)數(shù)據(jù)將模型訓(xùn)練作業(yè)按照訓(xùn)練時(shí)長(zhǎng)分為四類(lèi)，其中6 min～10 min內(nèi)完成的為微型作業(yè)，11 min～60 min內(nèi)完成的為小型作業(yè)，61 min～120 min內(nèi)完成的是中型作業(yè)，大于120 min完成的是大型作業(yè)。

為了測(cè)量系統(tǒng)在不同工作負(fù)載下的表現(xiàn)，本文將各類(lèi)作業(yè)按不同比例組成四種工作負(fù)載分布，如表2所示?？紤]到實(shí)際場(chǎng)景中申請(qǐng)使用真實(shí)數(shù)據(jù)集進(jìn)行模型訓(xùn)練的作業(yè)一般都不會(huì)很小，因此除workload1包含微型作業(yè)外，其余3種都不包含微型作業(yè)。

表2 實(shí)驗(yàn)使用的工作負(fù)載分布 (%)

每次實(shí)驗(yàn)時(shí)選擇一種工作負(fù)載分布，采用隨機(jī)的方法生成測(cè)試作業(yè)集，其中每個(gè)作業(yè)要訓(xùn)練的模型、訓(xùn)練輪數(shù)、到達(dá)順序均隨機(jī)產(chǎn)生，作業(yè)到達(dá)間隔服從泊松分布。

由于模型訓(xùn)練服務(wù)系統(tǒng)工作在數(shù)據(jù)共享平臺(tái)，作業(yè)資源由系統(tǒng)統(tǒng)一分配而非用戶(hù)指定，因此無(wú)法與當(dāng)前主流調(diào)度框架中的算法進(jìn)行比較。為此，本文選擇與經(jīng)典的先來(lái)先服務(wù)(FCFS)和最早完成(Earliest Finish，EF)兩種方法進(jìn)行比較。在先來(lái)先服務(wù)方法中，每個(gè)到來(lái)的服務(wù)請(qǐng)求被分配一塊GPU(如有)，在重負(fù)載時(shí)允許系統(tǒng)同時(shí)響應(yīng)最多的服務(wù)請(qǐng)求。在最早完成方法中，每個(gè)到來(lái)的服務(wù)請(qǐng)求被分配最多的GPU，在輕負(fù)載時(shí)作業(yè)完成時(shí)間最短。在這兩種方法中，作業(yè)一經(jīng)部署便不再進(jìn)行資源調(diào)整，直至作業(yè)完成。

本文測(cè)試在不同的工作負(fù)載分布和作業(yè)到達(dá)密度下系統(tǒng)的性能表現(xiàn)。評(píng)估指標(biāo)為作業(yè)完成時(shí)間和作業(yè)集完成時(shí)間。作業(yè)完成時(shí)間(Job Completion Time，JCT)指作業(yè)從到達(dá)系統(tǒng)開(kāi)始至完成訓(xùn)練所用的時(shí)間。作業(yè)集完成時(shí)間(makespan)指在沒(méi)有新的作業(yè)到來(lái)的情況下，第一個(gè)作業(yè)到達(dá)至所有作業(yè)完成訓(xùn)練的用時(shí)。測(cè)量每個(gè)性能指標(biāo)時(shí)做10組實(shí)驗(yàn)，每組實(shí)驗(yàn)隨機(jī)生成由20個(gè)作業(yè)組成的測(cè)試作業(yè)集，對(duì)10組實(shí)驗(yàn)的結(jié)果求平均得到性能值。

4.2 系統(tǒng)在不同工作負(fù)載分布下的性能表現(xiàn)

本實(shí)驗(yàn)針對(duì)表2中的每種工作負(fù)載分布，測(cè)量作業(yè)完成時(shí)間和作業(yè)集完成時(shí)間。作業(yè)到達(dá)間隔服從均值為15 min的泊松分布。本文方法與FCFS、EF兩種方法進(jìn)行比較，實(shí)驗(yàn)結(jié)果如圖2、圖3所示。

圖2 不同工作負(fù)載分布下的作業(yè)完成時(shí)間

圖3 不同工作負(fù)載分布下的到達(dá)間隔作業(yè)集完成時(shí)間

圖2為三種方法在四種工作負(fù)載分布下的歸一化JCT，以FCFS的作業(yè)完成時(shí)間作為參照。可以看到本方法的作業(yè)完成時(shí)間最短，總體上比FCFS減少約40%，比EF減少約58%。與FCFS相比，本方法的優(yōu)勢(shì)是在有空閑GPU時(shí)，可以通過(guò)資源擴(kuò)放來(lái)減少部分作業(yè)的完成時(shí)間。當(dāng)小作業(yè)集中到來(lái)時(shí)，每個(gè)作業(yè)使用一塊GPU就夠了，此時(shí)資源擴(kuò)放帶來(lái)的收益有限；而當(dāng)大作業(yè)集中到來(lái)時(shí)，每塊GPU上都有一個(gè)大作業(yè)運(yùn)行，此時(shí)本方法退化為FCFS。除以上兩種情形外，本方法在減少作業(yè)完成時(shí)間方面均有出色表現(xiàn)。與EF相比，本方法的優(yōu)勢(shì)是在有較多作業(yè)到來(lái)時(shí)，可以進(jìn)行資源收縮來(lái)運(yùn)行最多的作業(yè)，通過(guò)減少作業(yè)等待時(shí)間來(lái)縮短作業(yè)完成時(shí)間。從圖2可以看到，EF方法的作業(yè)等待時(shí)間遠(yuǎn)遠(yuǎn)超過(guò)了作業(yè)訓(xùn)練時(shí)間，這是因?yàn)樵谧鳂I(yè)連續(xù)到來(lái)時(shí)，EF方法基本在串行執(zhí)行，對(duì)許多中小作業(yè)來(lái)說(shuō)等待時(shí)間遠(yuǎn)多于運(yùn)行時(shí)間，成為影響作業(yè)完成時(shí)間的主要因素。

需要注意的是，相比于FCFS和EF方法，本方法進(jìn)行資源縮放會(huì)帶來(lái)額外的時(shí)間開(kāi)銷(xiāo)(縮放時(shí)間)。實(shí)驗(yàn)發(fā)現(xiàn)，一次資源縮放的時(shí)間大約為10 s，在作業(yè)完成時(shí)間中的占比不到1%，可以忽略。

圖3為三種方法在四種工作負(fù)載分布下的歸一化作業(yè)集完成時(shí)間，以FCFS的作業(yè)集完成時(shí)間為參照。作業(yè)集完成時(shí)間取決于最后一個(gè)離開(kāi)系統(tǒng)的作業(yè)，最小化作業(yè)集完成時(shí)間相當(dāng)于最大化資源效率[17]。與FCFS相比，本方法通過(guò)資源擴(kuò)放充分利用了GPU資源；與EF相比，本方法通過(guò)資源收縮最小化了作業(yè)等待時(shí)間。從圖3也可以看到，本方法的作業(yè)集完成時(shí)間最短，總體上比FCFS減少約30%，比EF減少約35%。

4.3 系統(tǒng)在不同工作負(fù)載分布下的性能表現(xiàn)

本實(shí)驗(yàn)改變作業(yè)到達(dá)密度，測(cè)量不同工作負(fù)載分布下的作業(yè)完成時(shí)間和作業(yè)集完成時(shí)間。作業(yè)到達(dá)間隔服從泊松分布，均值取10 min、15 min、20 min三種，取表2中的workload2(小作業(yè)多)和workload4(大作業(yè)多)為工作負(fù)載分布。將本文方法與FCFS、EF兩種方法進(jìn)行比較，實(shí)驗(yàn)結(jié)果如圖4～圖7所示。

圖4 在workload2和三種作業(yè)到達(dá)間隔下的JCT

圖7 在workload4和三種作業(yè)到達(dá)間隔下的makespan

對(duì)于圖4和圖5，在相同的工作負(fù)載下，隨著作業(yè)到達(dá)間隔的增大，本方法有更多的機(jī)會(huì)進(jìn)行資源擴(kuò)放，減少作業(yè)完成時(shí)間的效果更明顯；而對(duì)于EF方法，隨著作業(yè)到達(dá)間隔的增大，下一個(gè)作業(yè)的等待時(shí)間縮短，總體上也起到減少作業(yè)完成時(shí)間的效果。

圖5 在workload4和三種作業(yè)到達(dá)間隔下的JCT

對(duì)于圖6和圖7，在相同的工作負(fù)載下，隨著作業(yè)到達(dá)間隔的增大，本方法有更多的機(jī)會(huì)進(jìn)行資源擴(kuò)放，使得正在運(yùn)行的作業(yè)能被分配到更多的GPU資源，盡快完成訓(xùn)練，從而減少作業(yè)集完成時(shí)間的效果更明顯；而EF方法由于作業(yè)等待時(shí)間較長(zhǎng)，和本方法相比沒(méi)有優(yōu)勢(shì)。

圖6 在workload2和三種作業(yè)到達(dá)間隔下的makespan

5 結(jié)論

本文設(shè)計(jì)與實(shí)現(xiàn)了基于數(shù)據(jù)共享平臺(tái)的模型訓(xùn)練服務(wù)系統(tǒng)，通過(guò)在自有數(shù)據(jù)集上為用戶(hù)提供模型訓(xùn)練服務(wù)實(shí)現(xiàn)數(shù)據(jù)可用不可見(jiàn)。系統(tǒng)的核心是以最小化請(qǐng)求響應(yīng)時(shí)間和最大化資源效用為目標(biāo)的一組資源分配和資源縮放策略，兼顧了用戶(hù)體驗(yàn)和平臺(tái)收益兩方面因素。通過(guò)利用不同負(fù)載特性和不同作業(yè)到達(dá)密度的作業(yè)集在小型集群上進(jìn)行的實(shí)驗(yàn)表明，與常規(guī)作業(yè)調(diào)度方法相比，本系統(tǒng)在服務(wù)請(qǐng)求時(shí)間和作業(yè)完成時(shí)間方面都有上佳的表現(xiàn)。可以預(yù)見(jiàn)，數(shù)據(jù)共享平臺(tái)及模型訓(xùn)練服務(wù)系統(tǒng)的廣泛應(yīng)用，將極大地促進(jìn)數(shù)據(jù)的安全流通和使用。