魏 宏 原，华 蓓，林 飞

(1.中国科学技术大学 计算机科学与技术学院，安徽 合肥 230027；2.中国科学院无线光电通信重点实验室，安徽 合肥 230027)

0 引言

随着物联网、大数据、人工智能技术的发展，以及智慧城市、智慧医疗、电子商务等应用的广泛普及，每天都有海量的数据产生，这些数据蕴涵了大量有价值的信息。但是另一方面，数据不足正成为当下制约人工智能发展的一大瓶颈。例如，深度神经网络需要大量数据来训练，但现实中大多数领域只有少量数据集可用，如自动驾驶只有数个公开数据集，医学图像领域不仅数据集少，且每个数据集仅包含数十或数百个病例。造成这种现象的原因主要有两个方面，一是原始数据必须经过清洗和标注才能使用，而这一过程不仅费时费力，更可能需要专业人士的介入；二是目前各行各业的数据主要由政府和企业在收集，出于行业竞争、数据安全、管理制度等方面的考虑，这些数据不能被共享，形成了许许多多的数据孤岛。如何在保护数据和使用数据之间取得平衡，是当下迫切需要解决的问题[1]。

一些企业和机构已经或正在建设数据共享和交易平台来促进数据流通，如Exchange、数据堂、上海数据交易中心等。但目前这些平台多以交易数据为主，用户在付费之后拥有对数据的永久/指定期限访问权，可以在数据上执行任意计算来挖掘感兴趣的信息。这会带来两个问题，一是如果这些数据中包含敏感信息，直接开放给用户下载会带来数据安全问题；二是难以控制用户对数据进行非法复制和传播，数据可能被用于不正当用途。其实很多时候用户只想利用数据来训练他们需要的模型，对原始数据本身并不感兴趣，向用户提供数据的功能性服务而非直接提供数据，可以在一定程度上解决数据保护和数据使用之间的矛盾。比如，交通管理部门可在自有的城市出行数据上，为社会学研究人员训练用于分析人群移动规律的数学模型。

本文提出面向数据共享的模型训练服务系统，允许机构或企业利用自有数据集和自有计算资源，向用户提供模型训练服务(当然机构可以向用户收费，但这不在本文讨论的范围内)。用户只需指定需要的数据集并上传自定义的模型结构(本系统主要考虑深度学习模型)，系统可自动完成模型训练作业，并向用户返回训练好的模型，真正实现“数据可用不可见”。提供数据的功能性服务接口而非数据本身，对于消除数据孤岛、促进数据安全流通具有极为积极的作用。

1 相关工作

模型训练服务系统在响应多个用户的服务请求时，涉及集群资源管理和作业调度。当前云平台中主流的调度器有YARN、Mesos[2]、Brog、Kubernetes[3]等，这些通用调度器根据用户要求的资源数量(主要是CPU、GPU、内存等)，基于公平性或优先级等策略进行作业调度，且作业一经部署便不再调整，除非管理员手动调整资源组合或者用户重新提交作业。与通用云平台不同的是，本文考虑的数据共享平台主要提供数据集使用服务，其资源数量有限且不能任意扩放，如何充分利用有限的资源高效地为用户提供服务是关键。通用调度器的另一个问题是它并非针对深度学习作业而设计，Luo等人[4]发现，在云数据中心调度分布式机器学习作业时，由于作业随机放置造成跨主机通信带来的性能损失可能高达90%。因此，目前云平台中的通用调度器并不适合本文的模型训练服务系统。

近年来，大规模机器学习模型越来越受到业界的推崇，导致模型训练时间越来越长，分布式训练成为主流。分布式训练策略按照并行方式的不同分为数据并行和模型并行两种。数据并行方式在不同的GPU上保存模型的一份副本，数据集被分割成若干个数据子集，分配到不同的GPU上计算，并合并所有GPU计算的结果进行梯度更新。模型并行方式则是将整个神经网络模型拆解分布到不同的GPU上，每个GPU负责计算和更新网络模型中的一部分。数据并行由于具有较好的伸缩性和加速效果而在实际中运用最多。

GPU集群上的分布式机器学习调度是学术界和工业界的研究热点。Peng等人[5]、Venkataraman等人[6]基于对模型收敛时间的预测进行作业调度，在拟合模型训练曲线时需假设模型具有平滑的损失曲线，且模型最终能够达到目标精度(即模型收敛)，但在实际场景中损失曲线通常没有这么平滑，因此这类方法不具有通用性和实用性[7]。Xiao等人[8]、Rasley等人[9]、Sparks等人[10]针对自动机器学习场景研究高效的作业调度方法，允许多个作业分时复用或共享GPU来提高利用率，并在获取到模型训练的早期反馈时立即中止质量不佳的模型训练作业。然而，在同一个GPU上启动多个训练作业会引入资源竞争，导致所有作业的训练性能下降，甚至影响训练精度[11]，因而目前工业界的主流做法仍然是独占GPU进行模型训练[12]。也有一部分工作关注作业放置带来的通信问题，比如，Qiao等人[13]、Zhao等人[14]提出应将一个作业的所有任务放在同一台主机上，以减少跨主机通信带来的性能损失，而Gu等人[7]则指出激进的耦合会导致资源利用率下降(比如GPU资源不足的节点不会被分配作业)，应根据模型大小选择合适的作业放置策略。本文的模型训练服务系统同样需要关注作业放置带来的通信开销问题，以上研究工作对于本文设计高效的资源分配与作业放置具有借鉴作用。

2 模型训练服务系统的资源分配与调度策略

2.1 资源分配与调度原则

鉴于数据拥有方可能因担心数据隐私泄漏而不愿意将数据放置在云数据中心，本文考虑的数据共享平台为数据拥有方的自有平台。与云数据中心按资源使用量付费的商业模式不同，数据共享平台主要按使用的数据集付费，模型训练只是附加服务。与云数据中心拥有海量资源、满足每个租户的资源需求不同，数据共享平台的资源有限且不能任意扩放，无法满足用户的任意资源需求。因此，与云数据中心允许租户提出资源需求不同，数据共享平台只接受用户的服务请求，资源分配由数据共享平台来决定。

数据共享平台在分配资源和调度服务请求时，需要兼顾用户和平台两方的利益。站在用户的角度，用户希望看到自己的请求被立即响应(即看到训练过程立即开启)，并尽早获得训练结果；站在平台的角度，平台希望基于有限的资源更多更好地服务用户请求。然而，用户的服务请求可能在任意时刻到来，且不同请求的训练工作量可能差异很大，在请求的到达时间和工作量都难以预知的情况下，想要高效地分配资源是一个难题。从提升用户体验的角度，系统应同时运行尽可能多的训练作业，以快速响应新的服务请求。从平台提供优质服务的角度，平台应公平对待每个服务请求，并高效地利用系统资源来提升自己的服务能力。

为兼顾用户和平台两方面的利益，并考虑到GPU的使用特点，本文基于以下原则进行资源分配和作业调度：

(1)GPU独占使用：由于在同一块GPU上同时训练多个模型存在一些尚未克服的问题，本系统采用独占GPU进行模型训练的主流做法，即每次只将一个训练作业调度到一个GPU上执行。

(2)先来先服务：为保证公平性，系统按照用户请求的先后顺序进行服务。

(3)快速响应新请求：只要资源许可，系统为每个新到达的服务请求分配一块GPU，并立即启动训练过程。

(4)最少资源保证：系统保证每个已经启动的训练作业至少拥有一块GPU以确保训练过程不中断，该原则实际上确保了系统能够同时服务最多的用户请求。

(5)适时进行资源缩放：当没有新的服务请求到来而系统中尚有空闲GPU时，增加部分作业的GPU分配以缩短作业完成时间；当新的服务请求到来而系统中没有空闲GPU时，在不违背原则(4)的前提下，减少部分作业的GPU分配以满足原则(3)。

随着新请求的到来和当前作业的结束，资源分配方案通常需要调整才能实现平台和用户收益的最大化。然而，由于模型训练过程中不能调整GPU的使用，调整资源分配意味着部分训练作业要中止，在重新分配资源和部署后再恢复训练，这会产生额外的开销，并且其带来的收益可能受到未来请求的影响而难以准确评估。因此，第5条原则是本系统要解决的关键问题。

2.2 分布式模型训练架构的选择

目前工业界最具代表性的两种分布式训练架构是All-reduce和参数服务器(Parameter Server，PS)，均采用了数据并行的方式。PS架构包含参数服务器(ps)和工作服务器(worker)两种角色，每个worker使用一部分训练数据在本地计算梯度，并将它们发送到各自的ps，ps汇总梯度后对模型参数进行更新，并将更新后的模型参数发回给worker进行下一次迭代训练。研究发现，PS架构中worker和ps数量的不同组合会对训练速度产生显著影响，且增加GPU不会导致训练速度线性增加，有时甚至会减慢训练速度[6]。在All-reduce架构中，每个计算节点既是ps也是worker，各个计算节点独立计算梯度后，使用All-reduce通信进行梯度聚合，然后利用聚合的梯度各自更新模型参数。实验表明，在各个计算节点性能接近(同构且拥有相同数量的GPU)时，训练时长与计算节点的数目接近于反比关系。

考虑到All-reduce架构可以获得“可控”的训练速度，本系统采用All-reduce架构进行分布式模型训练。当前主流的学习框架如TensorFlow和PyTorch等均支持该架构。

2.3 自动资源缩放

本节讨论自动资源缩放策略。假设平台在某个时刻需要进行资源缩放决策，用job[1..m]表示当前参与调度的m个作业，其中job[i]为作业i剩余的训练轮数(epoch)，其初始值由用户在提交服务请求时给出。s[1..m]为当前的资源分配方案，其中s[i]表示分配给作业m的GPU数量，P为系统中的GPU总数。作业i在当前资源配置下完成一轮训练的耗时用fi(s[i])进行估计。需要说明的是，作业的训练速度与所分配的GPU数量和GPU的分布(如跨主机或不跨主机)都有关系，为简化计算，在估计一轮训练用时时忽略GPU的位置影响。可以有两种方法来获得fi(·)值，训练开始时可以使用预设的经验值，训练过程中可以实时记录各个作业在不同资源配置(GPU数量)下的训练用时，在积累了一定量的训练速度数据后通过最小二乘法进行拟合，得到不同GPU数量下一轮训练用时的估计值。

记所有资源分配方案s的集合为S，资源缩放决策是要得到一个最佳的资源分配方案s′∈S，使得所有作业的剩余完成时间之和最小，即：

下面针对资源扩放和资源缩减两种情况分别进行讨论。

2.3.1 资源扩放

当没有新的服务请求到来而系统中仍有空闲GPU时，系统执行资源扩放。假设当前的资源分配方案为s[1..m]，有K个空闲的GPU，用inc[1..m]表示一种增量分配方案，其中inc[i]为给作业i增加的GPU数量。用delta[i]表示作业i增加了GPU分配后得到的收益(即减少的训练时间)，有：

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

记所有资源增量分配方案inc的集合为I，资源扩放决策是要找到一个最佳的增量分配方案inc′∈I，使得所有作业的剩余完成时间之和减少最多，即：

如果把获得增量GPU分配的作业看作“物品”(获得不同增量GPU的同一作业看成是不同的物品)，增加的GPU数量看作物品的“重量”，作业为此得到的收益看作物品的“价值”，则求解以上问题可以规约为求解一个0-1背包问题，即在满足背包容量为K的前提下，使得包内物品的总价值最高。

该背包问题可用动态规划法进行求解。算法1为资源扩放算法的伪代码，其中第1～7行根据转移方程求出最大收益之和f[m][K]，第8～15行根据最大收益和反推作业i增加的GPU数量，即inc[i]。

算法1.Resource Expansion

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

输出：inc[1..m]

2.3.2 资源缩减

当有服务请求而系统中没有空闲GPU时，系统执行资源缩减。假设当前的资源分配方案为s[1..m]，有K个服务请求到来。根据第3条、第4条原则，当P-m≥K时回收K个GPU，当P-m＜K时回收(P-m)个GPU。用dec[1..m]表示一种资源缩减方案，其中dec[i]为从作业i收回的GPU数量。用nabla[i]表示作业i减少了GPU后的损失(即增加的训练时间)，如式(6)所示(未缩减GPU的作业损失为0)：

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

记所有资源回收方案dec集合为D，资源回收决策是要找到一个最佳的缩减方案dec′∈D，使得已有作业的损失和最少，即：

如果将从某个作业中一次收回的GPU资源看作“物品”，其包含的GPU数量看作物品的“重量”，作业为此遭受的损失为物品的“价值”，则求解以上问题同样可以规约为求解一个0-1背包问题，即在所选物品恰好等于背包容量的前提下使得包内物品的总价值最低。

该背包问题同样可以用动态规划法进行求解。资源缩减的伪代码如算法2所示，其中回收的GPU数量K′=min(K，P-m)，第1～7行计算从作业中回收GPU导致的损失值，第8～13行根据转移方程求出最小损失和f[m][K′]，第14～20行根据最小损失和反推作业i减少的GPU数量，即dec[i]。

算法2.Resource Reduction

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

输出： dec[1..m]

2.4 作业放置策略

在得到资源扩放或缩减的方案后，对于涉及的作业需要中止其训练过程，重新部署后再恢复训练。当分布式训练作业使用多块GPU时，不同的作业放置方法对于作业训练速度会产生不同的影响。通常来说，跨主机通信会产生较大的通信开销，因此一般倾向于将作业分布到尽可能少的服务器上。如果将包含空闲GPU的节点看作是一个空闲分区，空闲GPU数量为空闲分区的大小，则为作业寻找放置节点相当于为作业分配所需要的空闲分区。该问题可以采用最佳适应(best fit)算法进行求解。

对集群中的的节点、作业进行全局编号。包含空闲GPU的节点用元组node=(nodeId，gpuNum)表示，其中gpuNum为节点中空闲GPU的数量，用H表示由这些节点组成的且按照gpuNum升序排列的队列。每个需要重新部署的作业对象用job=(jobId，gpuNum，nodeList)表示，gpuNum其中为分配给作业的GPU数量，nodeList={(nodeId，gpuNum)}为作业的放置方案。需要重新部署的作业，在扩放过程中是指增加了GPU的作业，在缩减过程中是指减少了GPU的作业以及新到达可部署的作业，用J表示由这些作业对象组成的且按照gpuNum降序排列的队列。

算法3为作业放置的伪代码，其中第5～12行找到第一个能放下job的节点，将该节点添加到作业放置列表中；第13～16行为未找到能完整放下job的节点时，取拥有最多空闲GPU的节点添加到作业放置列表中，更新作业所需GPU值，重复第5～16行的过程直到作业所需GPU数为零。

算法3.Job Placement

输入：J，H

输出：J

3 模型训练服务系统的实现

本文实现的模型训练服务系统具备以下功能：

(1)接收用户的服务请求，包括要训练的神经网络模型和超参数、训练模型需要使用的数据集等。

(2)为每个训练作业分配资源，并部署到相应节点上执行，根据需要对正在执行的训练作业进行资源调整。

(3)将训练进度及结果返回给用户。

为方便用户使用，系统设计为前后端架构，前端提供基于Web的服务访问接口，后端完成服务请求。后端由服务器集群组成，负责为用户提交的模型训练作业分配资源，并部署到相应的节点上执行。考虑到不同的模型可能使用不同的深度学习框架或不同的软件环境，为方便训练作业的部署及迁移，系统采用容器作为运行环境。Docker是目前最流行的容器引擎，它将应用程序及依赖的运行环境打包为“镜像”，极大地简化了应用交付模式，实现一次构建多次使用，并且部署和启动容器的速度很快，因此本系统使用Docker来实现容器的部署与管理。模型训练服务系统的整体如图1所示。

图1 模型训练服务系统的整体架构

系统采用集中式资源管理和作业调度方法，服务器分为接口服务器、主控节点、工作节点、存储服务器四种角色。用户与接口服务器交互，主控节点从接口服务器接收用户请求，确定资源分配和作业放置方案，向工作节点发送作业调度指令，工作节点完成作业的部署和执行。为方便用户查看训练进度和获取训练模型，工作节点将模型训练的中间结果及最终结果保存到存储服务器，供接口服务器查询和下载。

接口服务器接收用户的HTTP请求，对请求内容进行合法性检查后，将其制作成一个json对象发送给主控节点。

主控节点包含预处理器、调度器、后处理器、训练速度预测器四个组件，并维护一个系统资源表。系统资源表在服务器启动时初始化，并在运行过程中实时保存每个节点的资源使用情况(主要为空闲GPU信息)。预处理器接收接口服务器推送过来的消息，根据json对象中的模型镜像、数据集、训练参数等内容创建job对象。调度器获取job对象并生成作业调度指令，在此过程中需要查询资源使用情况、作业训练速度和当前正在运行的作业信息。训练速度预测器保存每个作业在每种资源配置下的训练速度，该值由调度器从工作节点获得并更新；当调度器查询的资源配置不存在时，训练速度预测器通过拟合已有历史记录得到一个预测值。后处理器从工作节点获得作业结束的通知后释放资源，并更新系统资源表。

工作节点包含执行器和监视器两个组件。执行器接收调度器的作业调度指令，创建容器并启动作业。监视器组件监视容器状态，并将作业训练速度、训练轮次等信息推送给主控节点调度器，当有容器退出时通知主控节点的后处理器。容器若是被动退出(发生资源缩放)，会将当前训练状态保存到存储服务器；若是主动退出(模型训练完成)，则将训练结果保存到存储服务器。系统中各组件之间通信通过gRPC实现。

对正在训练的作业进行资源缩放需要保存训练的中间结果，当前主流做法是采用检查点(checkpoint)文件保存训练作业的中间状态。检查点文件是一个二进制文件，它将变量名映射到对应的tensor值，本质上存储的是当前训练得到的模型参数值。加载检查点文件会带来一些时间开销，为此Wu[15]、Or[16]等通过修改机器学习框架来减少该时间。本文通过实验发现(见4.2节)，该开销相对于减少的训练时间可以忽略，为此本文直接使用机器学习框架中的检查点函数，以保持系统较好的通用性。当前机器学习框架中的检查点函数要求用户指定检查点的保存地址和名称，为保护系统安全和方便管理，本系统不允许用户设定检查点的保存地址，而是由系统设置，并在调度过程中随调度指令一起发送到目的工作节点。

为方便系统部署作业和获得作业相关信息，本文将模型运行环境及自定义函数库封装为基础镜像，用户基于该镜像调用编程接口完成训练代码的书写。

4 实验评估

4.1 实验设置

测试平台是由3台服务器组成的小型集群，服务器之间通过万兆以太网连接。一台服务器同时承担主控节点、工作节点和存储服务器的功能，配置IntelXeon Gold 6230处理器，运行Ubuntu 16.04操作系统，配有4块NVIDIA RTX2080Ti GPU卡。另外两台服务器作为工作节点，配置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以上)的作业，在AlexNet模型的基础上增加了数量不等的卷积层，它们在一块GPU上完成一轮训练的用时如表1中后3行所示。

表1 训练模型及每轮训练用时

对于作业调度来说，不同的作业组成、作业到达顺序和到达间隔均会影响测试结果，为此本文对以上变量设置不同的值，通过多组实验来评估本文的资源分配和作业调度算法。Gandiva[8]对Microsoft云数据中心的作业完成时间进行了统计，发现约30%的作业在10 min内完成，62%的作业在100 min内完成，82%的作业在1 000 min内完成。考虑到云数据中心不全是模型训练作业，且还有大量训练作业因为模型错误而提前中止，本文参考以上统计数据将模型训练作业按照训练时长分为四类，其中6 min～10 min内完成的为微型作业，11 min～60 min内完成的为小型作业，61 min～120 min内完成的是中型作业，大于120 min完成的是大型作业。

为了测量系统在不同工作负载下的表现，本文将各类作业按不同比例组成四种工作负载分布，如表2所示。考虑到实际场景中申请使用真实数据集进行模型训练的作业一般都不会很小，因此除workload1包含微型作业外，其余3种都不包含微型作业。

表2 实验使用的工作负载分布 (%)

每次实验时选择一种工作负载分布，采用随机的方法生成测试作业集，其中每个作业要训练的模型、训练轮数、到达顺序均随机产生，作业到达间隔服从泊松分布。

由于模型训练服务系统工作在数据共享平台，作业资源由系统统一分配而非用户指定，因此无法与当前主流调度框架中的算法进行比较。为此，本文选择与经典的先来先服务(FCFS)和最早完成(Earliest Finish，EF)两种方法进行比较。在先来先服务方法中，每个到来的服务请求被分配一块GPU(如有)，在重负载时允许系统同时响应最多的服务请求。在最早完成方法中，每个到来的服务请求被分配最多的GPU，在轻负载时作业完成时间最短。在这两种方法中，作业一经部署便不再进行资源调整，直至作业完成。

本文测试在不同的工作负载分布和作业到达密度下系统的性能表现。评估指标为作业完成时间和作业集完成时间。作业完成时间(Job Completion Time，JCT)指作业从到达系统开始至完成训练所用的时间。作业集完成时间(makespan)指在没有新的作业到来的情况下，第一个作业到达至所有作业完成训练的用时。测量每个性能指标时做10组实验，每组实验随机生成由20个作业组成的测试作业集，对10组实验的结果求平均得到性能值。

4.2 系统在不同工作负载分布下的性能表现

本实验针对表2中的每种工作负载分布，测量作业完成时间和作业集完成时间。作业到达间隔服从均值为15 min的泊松分布。本文方法与FCFS、EF两种方法进行比较，实验结果如图2、图3所示。

图2 不同工作负载分布下的作业完成时间

图3 不同工作负载分布下的到达间隔作业集完成时间

图2为三种方法在四种工作负载分布下的归一化JCT，以FCFS的作业完成时间作为参照。可以看到本方法的作业完成时间最短，总体上比FCFS减少约40%，比EF减少约58%。与FCFS相比，本方法的优势是在有空闲GPU时，可以通过资源扩放来减少部分作业的完成时间。当小作业集中到来时，每个作业使用一块GPU就够了，此时资源扩放带来的收益有限；而当大作业集中到来时，每块GPU上都有一个大作业运行，此时本方法退化为FCFS。除以上两种情形外，本方法在减少作业完成时间方面均有出色表现。与EF相比，本方法的优势是在有较多作业到来时，可以进行资源收缩来运行最多的作业，通过减少作业等待时间来缩短作业完成时间。从图2可以看到，EF方法的作业等待时间远远超过了作业训练时间，这是因为在作业连续到来时，EF方法基本在串行执行，对许多中小作业来说等待时间远多于运行时间，成为影响作业完成时间的主要因素。

需要注意的是，相比于FCFS和EF方法，本方法进行资源缩放会带来额外的时间开销(缩放时间)。实验发现，一次资源缩放的时间大约为10 s，在作业完成时间中的占比不到1%，可以忽略。

图3为三种方法在四种工作负载分布下的归一化作业集完成时间，以FCFS的作业集完成时间为参照。作业集完成时间取决于最后一个离开系统的作业，最小化作业集完成时间相当于最大化资源效率[17]。与FCFS相比，本方法通过资源扩放充分利用了GPU资源；与EF相比，本方法通过资源收缩最小化了作业等待时间。从图3也可以看到，本方法的作业集完成时间最短，总体上比FCFS减少约30%，比EF减少约35%。

4.3 系统在不同工作负载分布下的性能表现

本实验改变作业到达密度，测量不同工作负载分布下的作业完成时间和作业集完成时间。作业到达间隔服从泊松分布，均值取10 min、15 min、20 min三种，取表2中的workload2(小作业多)和workload4(大作业多)为工作负载分布。将本文方法与FCFS、EF两种方法进行比较，实验结果如图4～图7所示。

图4 在workload2和三种作业到达间隔下的JCT

图7 在workload4和三种作业到达间隔下的makespan

对于图4和图5，在相同的工作负载下，随着作业到达间隔的增大，本方法有更多的机会进行资源扩放，减少作业完成时间的效果更明显；而对于EF方法，随着作业到达间隔的增大，下一个作业的等待时间缩短，总体上也起到减少作业完成时间的效果。

图5 在workload4和三种作业到达间隔下的JCT

对于图6和图7，在相同的工作负载下，随着作业到达间隔的增大，本方法有更多的机会进行资源扩放，使得正在运行的作业能被分配到更多的GPU资源，尽快完成训练，从而减少作业集完成时间的效果更明显；而EF方法由于作业等待时间较长，和本方法相比没有优势。

图6 在workload2和三种作业到达间隔下的makespan

5 结论

本文设计与实现了基于数据共享平台的模型训练服务系统，通过在自有数据集上为用户提供模型训练服务实现数据可用不可见。系统的核心是以最小化请求响应时间和最大化资源效用为目标的一组资源分配和资源缩放策略，兼顾了用户体验和平台收益两方面因素。通过利用不同负载特性和不同作业到达密度的作业集在小型集群上进行的实验表明，与常规作业调度方法相比，本系统在服务请求时间和作业完成时间方面都有上佳的表现。可以预见，数据共享平台及模型训练服务系统的广泛应用，将极大地促进数据的安全流通和使用。