魏 宏 原，華 蓓，林 飛

(1.中國科學技術大學 計算機科學與技術學院，安徽 合肥 230027；2.中國科學院無線光電通信重點實驗室，安徽 合肥 230027)

0 引言

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

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

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

1 相關工作

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

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

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

2 模型訓練服務系統的資源分配與調度策略

2.1 資源分配與調度原則

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

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

為兼顧用戶和平臺兩方面的利益，并考慮到GPU的使用特點，本文基于以下原則進行資源分配和作業(yè)調度：

(1)GPU獨占使用：由于在同一塊GPU上同時訓練多個模型存在一些尚未克服的問題，本系統采用獨占GPU進行模型訓練的主流做法，即每次只將一個訓練作業(yè)調度到一個GPU上執(zhí)行。

(2)先來先服務：為保證公平性，系統按照用戶請求的先后順序進行服務。

(3)快速響應新請求：只要資源許可，系統為每個新到達的服務請求分配一塊GPU，并立即啟動訓練過程。

(4)最少資源保證：系統保證每個已經啟動的訓練作業(yè)至少擁有一塊GPU以確保訓練過程不中斷，該原則實際上確保了系統能夠同時服務最多的用戶請求。

(5)適時進行資源縮放：當沒有新的服務請求到來而系統中尚有空閑GPU時，增加部分作業(yè)的GPU分配以縮短作業(yè)完成時間；當新的服務請求到來而系統中沒有空閑GPU時，在不違背原則(4)的前提下，減少部分作業(yè)的GPU分配以滿足原則(3)。

隨著新請求的到來和當前作業(yè)的結束，資源分配方案通常需要調整才能實現平臺和用戶收益的最大化。然而，由于模型訓練過程中不能調整GPU的使用，調整資源分配意味著部分訓練作業(yè)要中止，在重新分配資源和部署后再恢復訓練，這會產生額外的開銷，并且其帶來的收益可能受到未來請求的影響而難以準確評估。因此，第5條原則是本系統要解決的關鍵問題。

2.2 分布式模型訓練架構的選擇

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

考慮到All-reduce架構可以獲得“可控”的訓練速度，本系統采用All-reduce架構進行分布式模型訓練。當前主流的學習框架如TensorFlow和PyTorch等均支持該架構。

2.3 自動資源縮放

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

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

下面針對資源擴放和資源縮減兩種情況分別進行討論。

2.3.1 資源擴放

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

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

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

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

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

算法1.Resource Expansion

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

輸出：inc[1..m]

2.3.2 資源縮減

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

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

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

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

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

算法2.Resource Reduction

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

輸出： dec[1..m]

2.4 作業(yè)放置策略

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

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

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

算法3.Job Placement

輸入：J，H

輸出：J

3 模型訓練服務系統的實現

本文實現的模型訓練服務系統具備以下功能：

(1)接收用戶的服務請求，包括要訓練的神經網絡模型和超參數、訓練模型需要使用的數據集等。

(2)為每個訓練作業(yè)分配資源，并部署到相應節(jié)點上執(zhí)行，根據需要對正在執(zhí)行的訓練作業(yè)進行資源調整。

(3)將訓練進度及結果返回給用戶。

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

圖1 模型訓練服務系統的整體架構

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

接口服務器接收用戶的HTTP請求，對請求內容進行合法性檢查后，將其制作成一個json對象發(fā)送給主控節(jié)點。

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

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

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

為方便系統部署作業(yè)和獲得作業(yè)相關信息，本文將模型運行環(huán)境及自定義函數庫封裝為基礎鏡像，用戶基于該鏡像調用編程接口完成訓練代碼的書寫。

4 實驗評估

4.1 實驗設置

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

選取深度學習中常見的5種圖像分類模型作為要訓練的模型，深度學習框架為TensorFlow，數據集為TensorFlow Datasets中的dogs_and_cats和tf_flowers。預先測得這些模型在一塊GPU上完成一輪(epoch)訓練的用時在1～2 min，如表1中前5行所示。為模擬一輪訓練用時較長(10 min以上)的作業(yè)，在AlexNet模型的基礎上增加了數量不等的卷積層，它們在一塊GPU上完成一輪訓練的用時如表1中后3行所示。

表1 訓練模型及每輪訓練用時

對于作業(yè)調度來說，不同的作業(yè)組成、作業(yè)到達順序和到達間隔均會影響測試結果，為此本文對以上變量設置不同的值，通過多組實驗來評估本文的資源分配和作業(yè)調度算法。Gandiva[8]對Microsoft云數據中心的作業(yè)完成時間進行了統計，發(fā)現約30%的作業(yè)在10 min內完成，62%的作業(yè)在100 min內完成，82%的作業(yè)在1 000 min內完成?？紤]到云數據中心不全是模型訓練作業(yè)，且還有大量訓練作業(yè)因為模型錯誤而提前中止，本文參考以上統計數據將模型訓練作業(yè)按照訓練時長分為四類，其中6 min～10 min內完成的為微型作業(yè)，11 min～60 min內完成的為小型作業(yè)，61 min～120 min內完成的是中型作業(yè)，大于120 min完成的是大型作業(yè)。

為了測量系統在不同工作負載下的表現，本文將各類作業(yè)按不同比例組成四種工作負載分布，如表2所示?？紤]到實際場景中申請使用真實數據集進行模型訓練的作業(yè)一般都不會很小，因此除workload1包含微型作業(yè)外，其余3種都不包含微型作業(yè)。

表2 實驗使用的工作負載分布 (%)

每次實驗時選擇一種工作負載分布，采用隨機的方法生成測試作業(yè)集，其中每個作業(yè)要訓練的模型、訓練輪數、到達順序均隨機產生，作業(yè)到達間隔服從泊松分布。

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

本文測試在不同的工作負載分布和作業(yè)到達密度下系統的性能表現。評估指標為作業(yè)完成時間和作業(yè)集完成時間。作業(yè)完成時間(Job Completion Time，JCT)指作業(yè)從到達系統開始至完成訓練所用的時間。作業(yè)集完成時間(makespan)指在沒有新的作業(yè)到來的情況下，第一個作業(yè)到達至所有作業(yè)完成訓練的用時。測量每個性能指標時做10組實驗，每組實驗隨機生成由20個作業(yè)組成的測試作業(yè)集，對10組實驗的結果求平均得到性能值。

4.2 系統在不同工作負載分布下的性能表現

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

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

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

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

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

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

4.3 系統在不同工作負載分布下的性能表現

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

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

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

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

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

對于圖6和圖7，在相同的工作負載下，隨著作業(yè)到達間隔的增大，本方法有更多的機會進行資源擴放，使得正在運行的作業(yè)能被分配到更多的GPU資源，盡快完成訓練，從而減少作業(yè)集完成時間的效果更明顯；而EF方法由于作業(yè)等待時間較長，和本方法相比沒有優(yōu)勢。

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

5 結論

本文設計與實現了基于數據共享平臺的模型訓練服務系統，通過在自有數據集上為用戶提供模型訓練服務實現數據可用不可見。系統的核心是以最小化請求響應時間和最大化資源效用為目標的一組資源分配和資源縮放策略，兼顧了用戶體驗和平臺收益兩方面因素。通過利用不同負載特性和不同作業(yè)到達密度的作業(yè)集在小型集群上進行的實驗表明，與常規(guī)作業(yè)調度方法相比，本系統在服務請求時間和作業(yè)完成時間方面都有上佳的表現?？梢灶A見，數據共享平臺及模型訓練服務系統的廣泛應用，將極大地促進數據的安全流通和使用。