CN117707759A - 一种多租户gpu集群弹性配额调度方法和系统 - Google Patents

Abstract

本发明实现了一种多租户GPU集群弹性配额调度方法和系统。首先进行数据收集和预处理步骤，从任务历史数据库中抽取对任务执行时间有影响的关键指标，将数据输入预测模型模块；所述预测模型模块对每个用户分别构建和训练一个任务持续时间预测模型，而后输入训练好的所述任务持续时间预测模型得到时间预测结果；最后使用建立好的模型对新提交的任务的执行时间进行预测，并通过平均绝对误差MAE、均方误差MSE和决定系数R2指标来评估模型的准确性。该方案解决了目前多租户深度学习训练的GPU集群存在资源利用率低、多租户场景下资源使用的公平性和效率问题。

Description

一种多租户GPU集群弹性配额调度方法和系统

技术领域

本发明涉及云计算处理技术领域，尤其涉及一种多租户GPU集群弹性配额调度方法和系统。

背景技术

在多租户GPU集群资源管理和调度领域，已存在一些相关技术和方法。包括：

任务打包与共享GPU的调度：为了提高GPU资源的利用率，许多研究工作通过任务打包后调度到统一个GPU上共享资源。Gandiva利用在线分析来反思性地确定是否在加速器上共享资源。AntMan通过动态缩放技术实现更细粒度的GPU共享。Salus实现了两个原语快速任务切换和内存共享，以实现更高效的GPU共享。Horus将用户模型转换为ONNX图表示并提取工作负载特征以确定任务打包。Lucid支持以非侵入式调度范例进行任务打包。Muri利用多资源交错来提高资源利用率并减少。但这些技术并不能准确预估任务之间的干扰，从而指导调度决策。

基于队列或者固定配额调度系统：目前存在着一些固定配额调度系统，这些系统为GPU集群中的每个租户分配固定的资源配额，例如Slurm集群管理系统。这些系统通常基于静态的资源分配策略，无法根据实时需求和资源利用情况进行动态调整。因此，这种固定配额调度系统可能导致资源浪费或资源不足的问题。

集群管理工具：Kubernetes是一种流行的开源编排解决方案，适用于基于容器的工作负载。借助Kubernetes，可以通过类似于传统HPC集群方法的方式有效管理这些工作负载，但Kubernetes本身并不能提供Slurm的所有调度功能——例如批处理调度和群调度，所以需要一些拓展性的方案来实现这些功能。

GPU集群监控技术：现有技术中存在一些GPU集群监控的技术方法，如Prometheus和DCGM Exporter，用于收集GPU的资源利用情况和性能数据。这些工具可以监测GPU设备的温度、功耗、内存使用情况等硬件指标，以及作业的执行状态和性能指标。然而，目前的资源管理器和监控器通常在GPU硬件设备层进行指标的收集，缺乏对进程级别GPU利用率信息的收集和分析。

上述技术管理的集群可能存在如下问题：

资源利用率低下：用户往往无法准确预估自己任务的资源需求，导致申请的资源与实际使用不符，进而造成GPU资源的低利用率。这不仅意味着昂贵的硬件资源没有得到充分利用，也意味着其他可能需要这些资源的用户无法及时获取。

配额管理机制不足：传统的配额管理机制通常较为固定且缺乏弹性，未能根据集群实时状态调整资源分配。这种机制在资源空闲时不能有效利用，而在资源紧张时则可能导致长时间的任务排队等待，影响集群的吞吐量和用户体验。

用户特征挖掘不足：现有调度工作往往没有充分挖掘用户的使用模式和行为特征，这些信息如果被有效利用，可以预测用户的资源需求，动态调整资源分配策略，从而优化整个集群的运行效率。

针对上述不足，本申请希望解决多租户环境下的GPU集群调度系统需要更加智能化的配额管理和资源调度机制问题，以实现资源的高效利用，确保公平性和服务水平质量，并挖掘用户行为数据以进一步优化调度策略。

发明内容

为此，本发明首先提出一种多租户GPU集群弹性配额调度方法，首先进行数据收集和预处理步骤，从任务历史数据库中抽取对任务执行时间有影响的关键指标，通过数据预处理流程进行清洗和标准化后，进行文本特征提取，使用文本特征的TF-IDF转换和NMF降维方法，提取出能够代表用户任务特征的关键信息并将文本转化为模型可处理的数值向量，对于其余的数值特征，则进行标准化处理后，将数据输入预测模型模块；所述预测模型模块采用用户队列和集群队列共同作用的方法，优化任务调度过程对每个用户分别构建和训练一个任务持续时间预测模型，当用户历史信息不足以训练一个独立模型时，退回到使用基于集群全体任务训练的通用模型来进行预测，对于特征提取数据收集和预处理后的数据，首先通过文本向量化、数据归一化和特征聚合的方式进行特征处理，而后输入训练好的所述任务持续时间预测模型得到时间预测结果；最后使用建立好的模型对新提交的任务的执行时间进行预测，并通过平均绝对误差MAE、均方误差MSE和决定系数R2指标来评估模型的准确性。

所述任务持续时间预测模型需要进行周期性更新，具体而言：随着历史任务的逐渐增加，用户的使用习惯随之变化，或集群的硬件升级、系统软件更新或者工作负载的变化时，将模型进行定期的更新，确保数据的准确性和实时性。

本发明还提出一种多租户GPU集群弹性配额调度系统，包括任务管理模块、调度模块、性能分析模块、监控模块和历史负载数据库，每个模块之间通过gRPC进行接口调用和信息传输；

所述任务管理模块负责管理用户提交的任务，维护各用户的任务队列，支持根据任务的优先级进行排队，并管理弹性配额以保证公平性，与集群队列管理器协作，确保任务能够高效、有序地提交至调度模块；

所述调度模块集成性能干扰混部模型与任务时间预测模型，根据任务的资源需求、优先级和预测的运行时间来确定任务的调度顺序和节点放置，在高优先级任务到达时触发低优先级任务的抢占逻辑，以保障关键任务的服务水平；

所述监控模块通过进程级别的监控获取任务的实时运行信息；

所述性能分析模块利用监控数据，分析各项任务的性能指标，并将性能指标记录在任务的资源对象字段中，为性能干扰模型提供输入；

所述历史负载数据库存储历史监控数据的数据库，为性能分析模块和任务时间预测模块提供历史数据支持。

所述任务管理模块的具体实现方式为：用户提交任务至服务端，服务端收集任务的元数据写入到数据库中，任务的格式在上一小节已进行定义，接着提交的任务首先经过任务持续时间预测模块，任务的元数据被用作输入来预测任务的持续时间，如果用户没有历史数据，将等待任务的性能分析数据，当性能分析完成，任务的利用率信息被输入到预测模型中以估算任务的持续时间；

然后任务被提交到用户队列中进行排队，经过任务队列和配额模块的检查后通过集群交互模块创建具体的AIJob资源提交到Kubernetes集群；

任务完成后，集群交互模块将监测到任务的结束并请求性能数据，接着将将任务运行时的性能数据写入历史负载数据库，用于未来的预测和分析。

所述任务队列和配额模块的工作流程为：首先初始化队列，为每个用户创建一个独立的队列，用来存放用户提交的任务请求，这些队列按照用户的配额和任务的优先级来组织；之后设置配额：使每个用户都有一个固定的资源配额；之后进行性能分析：任务在队列中排队等待的时候，将其提交到性能分析模块进行利用率数据的收集，然后将利用率信息写回到任务中；之后实施轮询策略：控制器轮询用户队列，取出所有不超过用户资源配额的高优先级任务进行排队，按照配额的使用度和提交时间进行排序，提交到集群队列中。如果高优任务为空且集群队列为空，可以按照配额使用度取出低优的任务，提交到集群的队列中；最后提交任务：请求控制器模块，查看集群队列的紧张程度，逐个创建AIJob，并将提交到集群中，如果提交成功，更新用户的配额，将任务在排队队列中删除。

所述调度模块构建在Kubernetes调度器框架基础上，采用插件化的设计。

所述监控模块在节点上部署多个Exporter进行监控指标的暴露，经过Prometheus进行指标聚合及持久化，Grafana实现监控指标可视化。

所述性能分析模块的具体实现方式为：

用户任务在集群排队的时候，首先将任务提交到性能分析模块进行剖析，该模块通过提交用户的Pod到指定的性能分析节点，同时周期性的读取Promethues的监控指标，收集任务的利用率指标并和Kubernetes集群进行交互，返回给客户端；

性能分析模块提供四个接口，分别为：分析任务提交接口、取消任务分析接口、队列信息获取接口、分析结果请求接口；

其具体的工作流程为：步骤1，性能分析请求接收：接口接收来自用户的性能分析请求，并解析请求中包含的任务信息；步骤2，Pod任务提交：根据解析出的任务信息，在Kubernetes中创建对应的Pod，使用Job的字段配置Pod，并指定性能分析节点；步骤3，PodController启动：Controller监听Kubernetes中Pod的状态，等待Pod进入Running状态；步骤4，数据监控与收集：Pod运行后，Controller周期性地向Prometheus发送请求，获取监控数据步骤5，监控数据稳态判断：检测到Pod性能的平均数据连续几次读取的变化率低于阈值，满足稳态条件时，认为性能数据已可靠；步骤6，Pod停止与资源释放：停止Pod的运行，并释放它占用的资源；步骤7，利用率信息记录：将收集到的利用率信息写入Pod的annotations中；步骤8，结果反馈：将分析结果通过接口返回给用户并且存储于数据库供后续查询。

本发明所要实现的技术效果在于：

解决目前多租户深度学习训练的GPU集群存在资源利用率低、多租户场景下资源使用的公平性和效率问题，具体而言：

提升资源利用率：使用户准确预估自己任务的资源需求，进而提高GPU资源的利用率。

提升配额管理机制性能：根据集群实时状态调整资源分配，在资源空闲时能有效利用资源，提升集群的吞吐量和用户体验。

提升用户特征挖掘能力：充分挖掘用户的使用模式和行为特征，预测用户的资源需求，动态调整资源分配策略，从而优化整个集群的运行效率。

附图说明

图1任务持续时间预测算法示意图；

图2任务管理模块工作流程；

图3调度模块工作流程；

图4多租户GPU集群弹性配额调度系统示意图；

图5弹性配额调度算法示意图；

具体实施方式

以下是本发明的优选实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限于此实施例。

本发明提出了一种多租户GPU集群弹性配额调度方法。采用了机器学习的方法，对每个用户分别构建和训练一个模型，从而使得模型能够更精确地反映出用户的任务特征和执行行为。当用户历史信息不足以训练一个独立模型时，系统会退回到使用基于集群全体任务训练的通用模型来进行预测。这样的双层预测机制保证了预测的广泛适用性和个性化的准确性。

主要的算法流程如下：

数据收集与预处理：从任务历史数据库中抽取对任务执行时间有影响的关键指标：例如申请的资源数量，以及其他更细粒度的性能指标(如sm_active,cpu_usage,mem_copy_util,gpu_mem_max等)。这些数据会通过数据预处理流程进行清洗和标准化，以确保模型的准确性。对于文本特征提取，使用文本特征的TF-IDF转换和NMF降维方法，提取出能够代表用户任务特征的关键信息。这些方法能将文本转化为模型可处理的数值向量。对于其余的数值特征，使用标准化(Z-score normalization)来避免模型在训练时受到数值范围大的特征的过大影响。

模型建立：在用户历史信息层，对每个用户的任务历史数据应用文本特征的TF-IDF转换和NMF降维方法，提取出能够代表用户任务特征的关键信息。如果用户的历史数据量足够，将基于这些信息构建一个针对性的预测模型。对于新用户或历史数据不足的用户，则转向使用集群历史信息层，根据整个集群的历史性能数据来训练一个通用的预测模型。

预测与评估：使用建立好的模型对新提交的任务的执行时间进行预测，并通过MAE(平均绝对误差)、MSE(均方误差)和R2(决定系数)等指标来评估模型的准确性。

周期性更新模型：随着历史任务的逐渐增加，用户的使用习惯也可能会随之变化。此外，集群的硬件升级、系统软件更新或者工作负载的变化都可能影响任务的执行时间。所以本文会将模型进行定期的更新，确保数据的准确性和实时性。

多租户间GPU资源配额的弹性管理机制：

在现代多租户GPU集群环境中，资源管理和调度是确保高效率和公平性的关键。为了解决传统固定配额分配机制在资源利用率和公平性之间的矛盾，本发明提出了一种多租户间GPU资源配额的弹性管理机制。该机制的核心在于两个方面：首先，当集群存在空闲资源时，系统能够弹性地分配这些资源给排队任务，从而提高资源利用率；其次，在原配用户的任务到来时，系统可以通过精细化的抢占策略，确保用户固定配额的保护，同时考虑任务的大小、被抢占的次数等因素，避免过度抢占，保持公平性。

在本文提出的多租户间GPU资源配额的弹性管理机制中，队列的设计对于实现资源的高效利用与公平分配至关重要。机制涉及两级队列系统：用户队列和集群队列，它们共同作用以优化任务调度过程。

用户队列是第一级队列，每个用户拥有自己的用户队列。当用户提交任务时，这些任务首先进入各自用户的队列中。用户队列内的任务将根据其指定的优先级以及到达时间(遵循先到先服务，即FIFO的原则)进行排序。这样的设计既保证了用户内部任务的公平调度，也为之后的集群级调度提供了有序的输入。配额管理模块通过轮询用户的任务队列，检查是否有能进入集群队列的任务，检查是否超过自己的固定配额，以及集群中是否有空闲资源。并且在选择低优任务的时候，会考虑用户已使用的配额资源，保证相对的公平分配。

集群队列是第二级队列，它从各个用户队列中接收任务，并根据任务的优先级和集群的当前资源状态进行进一步的调度。集群队列分为高优任务队列和低优任务队列。当集群中存在空闲资源时，高优任务队列中的任务将优先被调度，以确保重要任务的及时处理。此外，当集群队列中存在高优任务而集群资源被低优任务占用时，系统会根据设定的策略抢占资源，确保高优任务的执行。这种二级队列的设计充分考虑了多租户环境下的资源竞争问题，并通过合理的排队和调度策略实现了资源利用率和公平性的平衡。

调度算法的描述如下：

首先配额管理模块轮询用户队列，判断是否有不超过用户固定配额的高优任务，提交到集群队列中。如果此时集群还有空余的资源，根据用户已使用配额从小到大排序，继续轮询用户队列，取出低优的任务提交到调度器中的集群队列中。

接着调度器进行任务的放置，会优先进行高优任务的放置。

在集群队列中有高优任务在等待，并且集群中有运行的低优任务时，会触发抢占机制，被抢占任务按照以下指标进行评估：

1.资源请求量和高优任务的请求量相匹配，避免抢占过多的任务。

2.选择用户配额超配最多的任务进行抢占，如果有多个超配的任务，选择已经运行时间较长的任务且被抢占次数较少的任务进行抢占，避免频繁的抢占。

性能干扰感知的训练任务混合放置策略：

为了建立精确的深度学习训练任务干扰模型，本发明通过将多个任务放在相同的计算环境下并行执行，获取混合放置后的性能下降速率，以此构建了一个任务间性能干扰的预测模型，该模型能够预测不同训练任务并行放置时相互之间的性能干扰程度。这个预测模型不仅为GPU集群资源的高效分配提供了理论基础，也为多任务调度系统的优化提供了实证支持。

为了实现高效的集群资源管理，本发明提出了一个综合性的任务放置算法，该算法旨在最大化集群利用率，增加吞吐量，并最小化资源碎片化的影响。此外，该算法通过细致平衡任务之间的资源共享，进一步减少了混部在同一个GPU上的任务的性能衰减。

首先进行数据集的构，本文选取了16个常见的深度学习模型，对每个模型选取不同的批次大小和混合精度。如表所示：

首先会进行每个模型单独的性能数据以及利用率数据的收集。对每个模型代码文件中训练部分的开始和结束做埋点，返回开始和结束时间，计算每个迭代运行的平均速度，然后根据开始结束时间访问Prometheus收集的利用率数据写入到数据表中，共收集了90条数据，单独性能的数据表如下所示：

接着进行任务混跑，对所有任务的组合，根据之前收集的单独性能数据，对选模型可能占用的总GPU内存进行了估算，如果超过了预设的阈值(30GB)，则不执行性能评估，因为会导致显存的OOM。为每个选中的模型创建了一个独立的进程，并且使用了multiprocessing库的Barrier来同步进程，确保它们在开始性能数据收集之前全部完成预热。一旦所有模型都完成预热，则记录下数据收集的起始时间。每个子进程结束后，主进程会通过访问Prometheus收集GPU相关的度量数据，最后将收集到的性能数据和GPU度量整合在一起，计算出每个模型的速度衰减率以及其它相关指标。通过两个任务和三个任务的混合部署，收集了7466条数据。相比前面的独占任务的性能利用率数据数据集，任务混跑数据集加入了以cosum_开头的列，代表了多组任务混跑时，利用率数据的加和，反映了不同模型并行运行时的资源共享效率，还加入了co_speed列，代表混跑之后的速度，以及用co_speed/speed计算出decay来代表训练的速度衰减。

为了建立一个可靠的干扰预测模型，本发明探讨了多种算法：

数学公式模型，如线性回归、二阶线性回归和贝叶斯网络，它们基于统计方法来预测依赖关系，能够提供模型的直观解释。

决策树模型，包括梯度提升决策树和随机森林，这些模型利用多个决策树的集合来提高预测的准确性和鲁棒性。

传统机器学习方法，如深度神经网络(DNN)、支持向量机(SVM)、卷积神经网络(CNN)和循环神经网络(RNN)，它们适用于处理复杂的非线性关系，并能够在大规模数据集上学习复杂的特征表示。

在测试了这些代表性模型后，本文通过比较均方误差(MSE)和决定系数(R²Score)两个评价指标来评估它们的性能。均方误差衡量了模型预测值与实际值之间的差异，而决定系数则表示模型在解释数据变异性方面的能力。在本项研究中，随机森林回归模型展现出最优的性能，表现在具有最低的MSE和最高的R² Score，这表明它在准确性和解释性方面均优于其他模型。因此，随机森林回归模型被选为最终模型，用以预测混合部署环境下的性能衰减。

在干扰预测模型的准确性上，本发明的模型达到了最高92％的准确率，并且与各调度算法相比，在调度模拟器上使用了真实集群的调度过程，得到的排队时间延迟等指标的性能提升。

同时多租户的配额也得到了99％时间的保证。

本发明还提供一种多租户GPU集群弹性配额调度系统，基于目前云原生领域最流行的资源管理框架Kubernetes开发，对用户的训练任务进行了自定义拓展资源的定义，通过Kubernetes的控制器机制进行任务的管理，拓展了Kubernetes的调度插件框架，同时开发了进程级别的细粒度监控Exporter进行资源利用率的监控。系统的整体架构如所示。主要分为以下模块：任务队列模块、调度模块、性能分析模块、在线监控模块，每个模块之间通过gRPC进行接口调用和信息传输。每个模块的功能如下：

任务管理模块：负责管理用户提交的任务。该模块维护各用户的任务队列，支持根据任务的优先级进行排队，并管理弹性配额以保证公平性。它与集群队列管理器协作，确保任务能够高效、有序地提交至调度模块。

调度模块：核心的决策引擎，集成了性能干扰混部模型与任务时间预测模型。它负责根据任务的资源需求、优先级和预测的运行时间来确定任务的调度顺序和节点放置。在高优先级任务到达时，该模块还能够触发低优先级任务的抢占逻辑，以保障关键任务的服务水平。

监控模块：通过进程级别的监控获取任务的实时运行信息。这些信息不仅对于管理员透明化集群的运行状态至关重要，也为任务的性能分析提供数据支持，并且定期地被存储至历史负载数据库中。

性能分析模块：利用监控数据，分析各项任务的性能指标，如GPU利用率、SM利用率、内存占用、显存占用等，并将这些性能指标记录在任务的资源对象字段中。这些分析结果为性能干扰模型提供了输入，帮助调度模块更精准地进行资源管理和任务调度。

历史负载数据库：存储历史监控数据的数据库，为性能分析模块和任务时间预测模块提供历史数据支持，使得预测模型能够基于实际的运行数据进行训练和优化。

通过上述模块的有机结合与协作，GPUSched能够在复杂多变的多租户环境中，实现更智能、更高效的GPU资源调度和管理。这不仅提高了整体的资源利用率，还提升了用户体验，通过降低任务等待时间和提高计算性能，最终促进了整个集群的运行效率。

监控模块：

监控模块作为性能分析模块以及集群利用率状态的基础，提供了多维度的监控指标收集，在节点上部署多个Exporter进行监控指标的暴露，经过Prometheus进行指标聚合及持久化，Grafana实现监控指标可视化。

性能分析模块：

用户任务在集群排队的时候，首先会将任务提交到性能分析模块进行剖析，该模块通过提交用户的Pod到指定的性能分析节点，同时周期性的读取Promethues的监控指标，收集任务的利用率指标，返回给客户端。

性能分析模块提供四个接口，分别为：分析任务提交接口、取消任务分析接口、队列信息获取接口、分析结果请求接口。

其中客户端通过分析任务提交接口提交需要分析的任务，由该模块去创建对应的分析Pod。如果需要取消，可以调用取消任务分析接口，模块会删除对应的分析Pod。同时还可以获取正在进行性能分析排队的任务队列信息，判断性能分析节点是否过载。

性能模块需要和Kubernetes集群进行交互，创建工作负载Pod进行性能分析，同时需要启动一个controller监听Pod的状态，还需要和监控模块进行数据的交互，具体的工作流程如下：

1.性能分析请求接收：接口接收来自用户的性能分析请求，并解析请求中包含的任务信息。

2.Pod任务提交：根据解析出的任务信息，在Kubernetes中创建对应的Pod，使用Job的字段配置Pod，并指定性能分析节点。

3.Pod Controller启动：Controller监听Kubernetes中Pod的状态，等待Pod进入

Running状态。

4.数据监控与收集：Pod运行后，Controller周期性地向Prometheus发送请求，获取监控数据。

5.监控数据稳态判断：检测到Pod性能的平均数据连续几次读取的变化率低于阈值。满足稳态条件时，认为性能数据已可靠。

6.Pod停止与资源释放：停止Pod的运行，并释放它占用的资源。

7.利用率信息记录：将收集到的利用率信息写入Pod的annotations中。

8.结果反馈：将分析结果通过接口返回给用户并且存储于数据库供后续查询。

任务管理模块：

用户提交任务至服务端，服务端收集任务的元数据写入到数据库中，任务的格式在上一小节已进行定义。接着提交的任务首先经过任务持续时间预测模块。这里，任务的元数据被用作输入来预测任务的持续时间。如果用户没有历史数据，将等待任务的性能分析数据。一旦性能分析完成，任务的利用率信息被输入到预测模型中以估算任务的持续时间。

然后任务被提交到用户队列中进行排队，经过配额管理模块的检查后通过集群交互模块创建具体的AIJob资源提交到Kubernetes集群。

任务完成后，集群交互模块将监测到任务的结束并请求性能数据，接着将将任务运行时的性能数据写入历史负载数据库，用于未来的预测和分析。

任务队列和配额模块的工作流程：

1.初始化队列：系统为每个用户创建一个独立的队列，用来存放用户提交的任务请求。这些队列按照用户的配额和任务的优先级来组织。

2.设置配额：每个用户都有一个固定的资源配额，确保单个用户不会占用过多的集群资源，影响其他用户的任务。

3.性能分析：任务在队列中排队等待的时候，将其提交到性能分析模块进行利用率数据的收集，然后将利用率信息写回到任务中。

4.轮询策略：控制器轮询用户队列，取出所有不超过用户资源配额的高优先级任务进行排队，按照配额的使用度和提交时间进行排序，提交到集群队列中。如果高优任务为空且集群队列为空，可以按照配额使用度取出低优的任务，提交到集群的队列中。

5.提交任务：请求控制器模块，查看集群队列的紧张程度，逐个创建AIJob，并将提交到集群中，如果提交成功，更新用户的配额，将任务在排队队列中删除。

通过以上策略，配额系统的引入避免单个用户对资源的过度占用，确保用户能在配额限定范围内公平地获取系统资源，同时在系统资源充足的时候能够将低优任务进行调度，可以提高集群的利用率。

调度模块：

系统的调度模块是构建在Kubernetes调度器框架基础之上，它采用插件化的设计，能够灵活地扩展和适应多样化的调度需求。本系统利用Kubernetes调度器的可插拔特性，引入了一系列自定义调度插件，以实现对Pod负载调度过程中的精细控制和优化。

Claims (9)

1.一种多租户GPU集群弹性配额调度方法，其特征在于：首先进行数据收集和预处理步骤，从任务历史数据库中抽取对任务执行时间有影响的关键指标，通过数据预处理流程进行清洗和标准化后，进行文本特征提取，使用文本特征的TF-IDF转换和NMF降维方法，提取出能够代表用户任务特征的关键信息并将文本转化为模型可处理的数值向量，对于其余的数值特征，则进行标准化处理后，将数据输入预测模型模块；所述预测模型模块采用用户队列和集群队列共同作用的方法，优化任务调度过程对每个用户分别构建和训练一个任务持续时间预测模型，当用户历史信息不足以训练一个独立模型时，退回到使用基于集群全体任务训练的通用模型来进行预测，对于特征提取数据收集和预处理后的数据，首先通过文本向量化、数据归一化和特征聚合的方式进行特征处理，而后输入训练好的所述任务持续时间预测模型得到时间预测结果；最后使用建立好的模型对新提交的任务的执行时间进行预测，并通过平均绝对误差MAE、均方误差MSE和决定系数R2指标来评估模型的准确性。

2.如权利要求1所述的一种多租户GPU集群弹性配额调度方法，其特征在于：所述任务持续时间预测模型需要进行周期性更新，具体而言：随着历史任务的逐渐增加，用户的使用习惯随之变化，或集群的硬件升级、系统软件更新或者工作负载的变化时，将模型进行定期的更新，确保数据的准确性和实时性。

3.如权利要求1所述的一种多租户GPU集群弹性配额调度方法，其特征在于：所述预测模型模块采用用户队列和集群队列共同作用的方法为多租户间GPU资源配额的弹性管理机制：

其中用户队列是第一级队列，每个用户拥有自己的用户队列，当用户提交任务时，这些任务首先进入各自用户的队列中，用户队列内的任务将根据其指定的优先级以及到达时间遵循先到先服务原则进行排序，配额管理模块通过轮询用户的任务队列，检查是否有能进入集群队列的任务，检查是否超过自己的固定配额，以及集群中是否有空闲资源，并且在选择低优任务的时候，会考虑用户已使用的配额资源，保证相对的公平分配；

集群队列是第二级队列，从各个用户队列中接收任务，并根据任务的优先级和集群的当前资源状态进行进一步的调度；集群队列分为高优任务队列和低优任务队列；当集群中存在空闲资源时，高优任务队列中的任务将优先被调度，以确保重要任务的及时处理；当集群队列中存在高优任务而集群资源被低优任务占用时，系统会根据设定的策略抢占资源，确保高优任务的执行；

其中资源调度的方法具体为：

首先配额管理模块轮询用户队列，判断是否有不超过用户固定配额的高优任务，提交到集群队列中；如果此时集群还有空余的资源，根据用户已使用配额从小到大排序，继续轮询用户队列，取出低优的任务提交到调度器中的集群队列中；

接着调度器进行任务的放置，会优先进行高优任务的放置；

在集群队列中有高优任务在等待，并且集群中有运行的低优任务时，会触发抢占机制，被抢占任务按照以下指标进行评估：

首先，资源请求量和高优任务的请求量相匹配，避免抢占过多的任务；

其次，选择用户配额超配最多的任务进行抢占，如果有多个超配的任务，选择已经运行时间较长的任务且被抢占次数较少的任务进行抢占，避免频繁的抢占。

4.一种多租户GPU集群弹性配额调度系统，其特征在于，包括任务管理模块、调度模块、性能分析模块、监控模块和历史负载数据库，每个模块之间通过gRPC进行接口调用和信息传输；

所述任务管理模块负责管理用户提交的任务，维护各用户的任务队列，支持根据任务的优先级进行排队，并管理弹性配额以保证公平性，与集群队列管理器协作，确保任务能够高效、有序地提交至调度模块；

所述调度模块集成性能干扰混部模型与任务时间预测模型，应用权利要求1、2或3所述一种多租户GPU集群弹性配额调度方法，根据任务的资源需求、优先级和预测的运行时间来确定任务的调度顺序和节点放置，在高优先级任务到达时触发低优先级任务的抢占逻辑，以保障关键任务的服务水平；

所述监控模块通过进程级别的监控获取任务的实时运行信息；

所述性能分析模块利用监控数据，分析各项任务的性能指标，并将性能指标记录在任务的资源对象字段中，为性能干扰模型提供输入；

所述历史负载数据库存储历史监控数据的数据库，为性能分析模块和任务时间预测模块提供历史数据支持。

5.如权利要求4所述的一种多租户GPU集群弹性配额调度系统，其特征在于，所述任务管理模块的具体实现方式为：用户提交任务至服务端，服务端收集任务的元数据写入到数据库中，任务的格式在上一小节已进行定义，接着提交的任务首先经过任务持续时间预测模块，任务的元数据被用作输入来预测任务的持续时间，如果用户没有历史数据，将等待任务的性能分析数据，当性能分析完成，任务的利用率信息被输入到预测模型中以估算任务的持续时间；

然后任务被提交到用户队列中进行排队，经过任务队列和配额模块的检查后通过集群交互模块创建具体的AIJob资源提交到Kubernetes集群；

任务完成后，集群交互模块将监测到任务的结束并请求性能数据，接着将将任务运行时的性能数据写入历史负载数据库，用于未来的预测和分析。

6.如权利要求5所述的一种多租户GPU集群弹性配额调度系统，其特征在于，所述任务队列和配额模块的工作流程为：首先初始化队列，为每个用户创建一个独立的队列，用来存放用户提交的任务请求，这些队列按照用户的配额和任务的优先级来组织；之后设置配额：使每个用户都有一个固定的资源配额；之后进行性能分析：任务在队列中排队等待的时候，将其提交到性能分析模块进行利用率数据的收集，然后将利用率信息写回到任务中；之后实施轮询策略：控制器轮询用户队列，取出所有不超过用户资源配额的高优先级任务进行排队，按照配额的使用度和提交时间进行排序，提交到集群队列中。如果高优任务为空且集群队列为空，可以按照配额使用度取出低优的任务，提交到集群的队列中；最后提交任务：请求控制器模块，查看集群队列的紧张程度，逐个创建AIJob，并将提交到集群中，如果提交成功，更新用户的配额，将任务在排队队列中删除。

7.如权利要求6所述的一种多租户GPU集群弹性配额调度系统，其特征在于，所述调度模块构建在Kubernetes调度器框架基础上，采用插件化的设计。

8.如权利要求7所述的一种多租户GPU集群弹性配额调度系统，其特征在于，所述监控模块在节点上部署多个Exporter进行监控指标的暴露，经过Prometheus进行指标聚合及持久化，Grafana实现监控指标可视化。

9.如权利要求8所述的一种多租户GPU集群弹性配额调度系统，其特征在于，所述性能分析模块的具体实现方式为：

用户任务在集群排队的时候，首先将任务提交到性能分析模块进行剖析，该模块通过提交用户的Pod到指定的性能分析节点，同时周期性的读取Promethues的监控指标，收集任务的利用率指标并和Kubernetes集群进行交互，返回给客户端；

性能分析模块提供四个接口，分别为：分析任务提交接口、取消任务分析接口、队列信息获取接口、分析结果请求接口；

其具体的工作流程为：步骤1，性能分析请求接收：接口接收来自用户的性能分析请求，并解析请求中包含的任务信息；步骤2，Pod任务提交：根据解析出的任务信息，在Kubernetes中创建对应的Pod，使用Job的字段配置Pod，并指定性能分析节点；步骤3，PodController启动：Controller监听Kubernetes中Pod的状态，等待Pod进入Running状态；步骤4，数据监控与收集：Pod运行后，Controller周期性地向Prometheus发送请求，获取监控数据步骤5，监控数据稳态判断：检测到Pod性能的平均数据连续几次读取的变化率低于阈值，满足稳态条件时，认为性能数据已可靠；步骤6，Pod停止与资源释放：停止Pod的运行，并释放它占用的资源；步骤7，利用率信息记录：将收集到的利用率信息写入Pod的annotations中；步骤8，结果反馈：将分析结果通过接口返回给用户并且存储于数据库供后续查询。