Lucid: A Non-intrusive, Scalable and Interpretable Scheduler for Deep Learning Training Jobs

摘要

• 虽然最近的深度学习工作负载调度器表现出很好的性能，但在实际应用中很难部署它们，是由于

  • 缺乏灵活的入侵方式、
  • 过高的集成和维护成本
  • 有限的可伸缩性
  • 不透明的决策过程

• Lucid: 基于可解释模型的非侵入式深度学习工作负载调度器 。

  • 它由三个创新模块组成。
    • 首先，为了有效地收集作业度量和及时调试作业反馈，引入了一个二维优化剖析器。
    • 其次，Lucid 利用一种惰性包装策略来规避干扰。
    • 第三，Lucid 基于估计的作业优先级值和共享分数来编排资源，以实现有效的调度。
  • 此外，Lucid 通过设计良好的系统优化器促进模型性能维护和系统透明调整。
  • 我们的评估表明，与最先进的抢占式调度器 Tiresias 相比，Lucid 将平均作业完成时间减少了1.3倍。此外，它为实际部署提供了明确的系统解释和优秀的可伸缩性。

Introduction

过往的GPU集群或者GPU集群调度器， 从两个方面看存在G1-G5五个鸿沟， 以致于无法实际部署。

• 大型多租户DL集群

  • [Tiresias, QSSF商汤集群, Antman,]

• 集群调度器

  • [ONES, Tiresias, QSSF（商汤）,Optimus, Pollux, Gandiva, Antman,, Horus]

• 首先，为了获得更好的系统性能，大多数现有的方法依赖于支持抢占的调度范例，如迁移[Gandiva ]、弹性[AFS ]和自适应训练[Pollux ]。然而，由于其不可避免的侵入机制，它们在部署方面遇到以下障碍:

  • G1: 不灵活和容易出错。为了实现弹性训练和作业检查点，现有的调度器要求用户导入特定的库并修改代码来实现这些机制[AFS,Gavel,Optimus,Pollux,Gandiva]。这种用户代码入侵方法不仅给用户带来了复杂的模型训练控制逻辑负担，而且还可能产生不确定性错误。此外，由于调度器接管了培训工作流，它们还极大地限制了用户定制代码的灵活性。正如微软[Singularity]所说，“当今大多数 DNN 培训工作量本身是不可检查点或可调整的。”泛化问题也阻碍了入侵调度器的实际应用。
  • G2: 整合和维护费用高。将研究原型转移到生产级系统中并非易事。通常，将调度程序设计集成到商业或开放源码集群管理系统中需要一个专家团队付出巨大的努力和成本来处理所有可能的问题。此外，为了支持高级调度特性，一些调度程序[AFS,Singularity,Gandiva]需要修改底层 DL 框架(例如 Pytch [Pytorch])或 CUDA 库[94]的源代码。它们需要持续维护，以适应 DL 生态系统的快速版本迭代。过高的集成和维护成本对大多数公司和研究机构来说是不切实际的。
  • G3: 适应性训练的模型质量退化。为了争取极端的培训效率，一些调度程序[11,Aryl,Pollux]分配的资源，适应性地调整工作批量和学习率。然而，就验证性能而言，这可能会降低最终模型的质量[51,108]。在商业应用中，微小的质量改进可以显著提高客户参与度和公司利润[43]。因此，由于退化问题，开发人员不倾向于采用这种机制。

• 其次，许多调度器采用基于机器学习(ML)的方法[QSSF,60,74,92,SLURM]或基于优化的方法[30,65,Gavel,107]来寻找最优调度策略。然而，它们在实践中也存在重大缺陷:

  • **G4: 可伸缩性有限。**随着工作负载变得更加密集，集群变得更大规模，这些调度器[Poster Abstract,30,66,Gavel,74,92,93]在部署到生产级系统时遇到了可伸缩性瓶颈。例如，Gavel [Gavel]花费数千秒通过线性规划解决2048年的工作分配问题，这需要很长时间才能满足实时需求。基于强化学习(RL)的调度器也面临同样的问题: Metis [93]只能处理几十个作业，而生产集群可以同时运行几千个作业
  • G5: 决策不透明，难以调整。大多数基于 ML- 的调度器是建立在黑盒模型之上的，比如随机森林(Random Forest，RF)[32,52]、梯度提升决策树(GBDT)[QSSF,SLURM]和 RL [74,92]。开发人员主要关注于改进关键的调度指标(例如，完成时间) ，而忽略了它们的可解释性。这些模型的预测过程对人类来说是难以理解的[33,55,81]。由于这种不透明性，系统操作员不能保证模型预测是可靠的，也没有足够的信心来部署它们。此外，即时调试和系统配置调优也是基于 ML- 和基于优化的调度程序面临的重大挑战。不适当的修改可能导致严重的性能降低[Primo]

我们设计了 Lucid，一个非侵入性和透明的调度器，它可以提供比抢占式和侵入式调度器更好的性能。

• Lucid 的核心设计源于以下三点见解。
  • 首先，以非侵入性的方式解决集群 GPU 利用率不足的问题是可行的。由于 GPU 在生产级 DL 培训集群中通常未得到充分利用[QSSF,48,95] ，现有的 DL 调度程序打包作业以通过侵入式方式提高利用率[10,Gavel,Gandiva,SLURM,Salus]。然而，通过全面分析工作配置，我们发现有可能实现有效的工作打包，而不会造成任何干扰。
  • 其次，可以根据以前的工作历史进行工期预测。由于大多数工作负载遵循循环模式，并且用户倾向于多次提交相似的任务[QSSF,95] ，因此我们可以根据新任务的概要特征和历史提交数据来估计其持续时间。
  • 第三，系统的可解释性是必不可少的，可以提高性能。对系统行为的全面了解可以增强操作员对实际部署的信心，并提供透明的性能调优。
• Lucid的三个核心调度模块
  • 我们提出了一个二维优化的非侵入性作业剖析器来收集作业资源的使用特征，包括 GPU 的利用率， GPU内存足迹和GPU内存使用。它实现了及时的调试作业反馈和高效的作业度量收集，其中以非侵入的方式进行分析只需要几分钟。
  • 在作业打包阶段，我们引入了仿射作业对绑定器的惰性和动态打包策略，以规避干扰，最大限度地提高集群范围内的作业速度
  • 工作负载评估模型为下列资源协调器的每个作业分配一个优先级值。此外，Lucid 集成了一个用于模型性能维护的更新引擎和透明调整和系统增强的系统调谐器。
• Lucid实现了以下几个特性
  • **A1: 高效率的非侵入性时间安排。**Lucid 的工作流程是无需抢占的，不需要侵入用户作业或 DL 框架的代码。同时，Lucid 的性能优于几个 SOTA 入侵调度器。
  • **A2: 部署费用低。**Lucid 可以很容易地集成到现有的商业或开源集群管理系统中(例如 Slurm [101] ，Kubernetes [15])。它也不需要持续维护 DL 框架或 CUDA 库更新。
  • **A3: 保留模范业绩。**用户完全控制他们的模型和 Lucid 从来没有篡改模型配置，完全保持他们的原始质量
  • **A4: 大规模集群的可伸缩性。**即使对于大量复杂的工作负载，系统也可以快速地获得最优的调度策略(在几毫秒内)。
  • **A5: 透明的系统调整。**所有的模块都是可解释的，帮助开发人员进行指导系统配置调整，并带来额外的改进。

背景与Motivation

背景

• DL 训练。DL 模型在迭代过程中学习它的参数(即权重)[58,Gandiva]。在每次迭代中，它都会处理一批带标签的数据，通过梯度下降法更新模型权重。整个训练过程通常由许多小批量迭代组成，可以持续数小时到数天，可以通过检查点进行抢占和恢复[Prague,Capuchin]。基于重复模式，操作员可以对几个迭代进行剖析，以获得作业的资源利用特征。与之前基于概要分析的 DL 作业调度程序[30,31,62]依赖于侵入式库来检查作业执行状态不同，Lucid 非侵入式地收集度量。
• DL集群调度。建立多租户 DL 集群以促进 DL 模型的开发是科技公司和研究机构的普遍做法。在许多公司[QSSF,48,95]中，集群通常被划分为几个虚拟集群(Virtual Clusters，VC) ，专门用于不同的产品组。用户通过相关配置(例如 GPU 需求、 CPU 需求、作业名称)向集群提交 DL 培训作业。

采用 DL 集群调度器调节资源和作业执行。为了提高资源利用率并使平均 JCT 最小化，大多数现有的 DL 集群调度器[11,31,Optimus,Pollux,Gandiva,Antman,SLURM]都是侵入性的: 它们通过修改 DL 框架或依赖于用户代码自适应来实现一些高级特性。有两个常见的高级功能: (1)作业打包(即，作业同位，图形处理器共享)允许多个任务使用 NVIDIA MPS [5]或 MIG [4]技术共享图形处理器。(2)弹性培训动态调整 GPU 工人的规模，甚至自适应地修改批量和学习率，以加快工作培训进度[11,Pollux]。然而，它们有几个明显的缺点，如1(G1 something G3)所述。

DL集群特性

• **低 GPU 利用率。**最近的研究[Gandiva,Antman,SLURM,Salus]显示了一个普遍的现象，即大多数 GPU 在 DL 集群中未得到充分利用。图1(a)显示从阿里巴巴数据中心收集的每周图形处理器使用量统计数据的累积分布函数。
• 高度倾斜的工作负荷分布。实际生产 DL 集群[QSSF,48,95]呈现类似的工作负载分布: (1)小规模。在 Microsoft [48]和 SenseTime [QSSF]中，超过95% 的作业是单节点作业(在4/8 GPU 内)。(2)循环。大多数作业(something 90%)是重复的超参数搜索作业[95,104]。(3)调试。大多数作业都是出于调试目的的短期作业，微软近70% 的资源被失败或取消的作业所占用。用户希望及时获得调试作业反馈。然而，现有工作往往忽视了工作负载的多样性，缺乏针对调试工作的具体设计。

非侵入调度的一些机会

• 工作装箱干扰的特征。为了了解工作包装的干扰效应，我们对不同工作量(表一)进行了广泛的分析，包括计算机视觉、自然语言处理、强化学习和推荐等不同领域的不同配置。
• 非侵入式干扰感知作业包装。所有现有的支持打包的 DL 调度程序都依赖于侵入式范例。具体来说，他们修改 DL 框架[Gandiva,Antman,Salus]或者需要用户代码适应[10,Gavel,SLURM]来实现内省作业打包。然而，我们发现无干扰地实现工件包装是可行的。根据我们的角色塑造，非侵入性的图形处理器利用率指标应该足以让调度程序做出打包决定(图2(a)) ，打包策略适用于所有单节点作业(图3(b)) ，覆盖超过95% 的工作负载(2.2)。值得注意的是，GPU 利用率定义为一个给定的采样间隔中一个或多个内核在 GPU 上执行的时间百分比，而不是活动单位百分比[6,SLURM]。除此之外，我们还采用了另外两个非侵入性的特性，它们也可以帮助我们做出更精确的决定: GPU 内存利用率(在过去的采样期间内存被读写的百分比)和 GPU 内存(GPU 上的内存占用率)。
• 工作时间估计。最近来自 SenseTime 和阿里巴巴的数据数据聚类发现，大多数工作负载都有反复出现的模式，用户往往会多次提交类似的任务。这启发我们利用历史日志数据来预测作业持续时间。此外，对作业资源利用率的特征分析还可以帮助我们更精确地将它们与以前的作业匹配，从而有助于更准确地预测和更好的调度策略。

系统设计

总览

• 原则及目标。对于实用和简单的系统采用，
  • Lucid 遵循三个设计原则:
    • 非侵入性。整个调度工作流遵循无抢占方式，不需要用户操作和 DL 框架修改(解决 G1 something G3)。
    • 可伸缩性。该系统可以快速获得大量复杂工作负载的调度策略(求解 G4)。
    • 可解释性。所有的模块都是透明的，可以由集群运营商进行清晰的调整(解决 G5)。我们的主要目标是最小化培训工作量的平均 JCT。这对于 DL 用户来说尤其可取。
  • 此外，Lucid 还提高了资源利用率，并提供了及时的调试反馈。我们未来的工作旨在为更多的调度目标服务，比如公平性和服务水平保证。
• 架构与工作流。

  • 

  • 图4说明了 Lucid 的架构以及调度工作流。它由用于工作负载调度的三个关键调度器模块(蓝色块)以及用于性能增强和维护的两个系统优化器(紫色块)组成。对于每个模块，都有相应的可解释模型(橙色块)负责预测关键指标，以协助调度。Lucid 的系统工作流以黑色箭头表示。具体来说，在分配给目标集群之前，需要首先分析作业(something)。我们采用非侵入性作业剖析器来过滤大部分的测试和调试作业。同时，该模块还记录了一般训练工作的资源使用情况的统计信息，并把它们分为不同的类别(something)。在分析之后，我们设计一个仿射作业对绑定器来确定是否以及如何打包各种作业。它根据未来集群吞吐量预测(something)动态改变打包策略。资源协调器根据概要分析和用户提供的特性，为每个作业分配一个优先级值，并选择要分配的作业(something)。
• 模块间依赖。通过所有系统模块的协作，Lucid 实现了预期的调度性能。没有其他模块的帮助，每个单独的模块不能提供所需的性能(4.5)。我们在图4中用红色箭头描述了它们之间的交互: 编配器使用 Profiler 中的特性来更好地估计持续时间。如果没有特征描述，Lucid 无法精确匹配以前的经常性工作。吞吐量预测模型不仅决定了 Binder 内部的打包策略，而且还有助于探查器集群扩展，从而有效地处理突发作业提交案例。在没有吞吐量预测模型的情况下，作业必须承受较高的分析排队延迟。粘合剂需要从编配器估计持续时间，以优化包装决策。因为长期的作业包装有时会恶化线头阻塞问题，延长 JCT，所以在作业包装过程中注意时间是非常重要的。

非侵入Job剖析器

Lucid 采用作业剖析机制优化后续的分配策略。非侵入性作业分析器为每个作业设置短期运行时限制 Tpro f，并收集与作业分析相关的硬件指标，包括 GPU 利用率、 GPU 内存占用率和 GPU 内存利用率。这些可以方便地通过 NVIDIA-SMI [6]或 DCGM [3]以非侵入性的方式进行测量。然后剖析器将这些特征发送到包装分析模型(3.5.1) ，该模型遵循非侵入性原则，主动预测包装的有效性，而不是在同位后测量吞吐量。为了方便随后的工作打包和资源分配，Lucid 不预测工作搭配的数值结果，而是将工作分为三个不同的类别(Tiny、 Medium 或 Jumbo) ，并为每个工作分配一个共享分数(SS)来表示其类别。具体来说，Tiny (SS = 0)作业指的是那些资源利用率极低的作业，它们几乎不会受到同地放缓的影响。相反，Jumbo (SS = 2)作业需要很高的资源利用率，关于它们的同位性的决策应该谨慎。中型(SS = 1)工作的打包对他们的培训速度影响相对较小。

为了提高剖析效率，我们提出了一种二维优化剖析策略，该策略结合了工作负载剖析的空间考虑以减少排队延迟，以及剖析器集群的时间考虑以最大限度地提高资源效率: 空间感知剖析。由于分析时间短 Tpro f，工作负载的时间尺度应该相似，所以我们可以专注于优化他们的空间尺度调度，这是以前基于分析的 DL 工作负载调度器从未考虑过的[30,31,62]。通过对请求较少资源的作业进行优先排序，可以有效地解决小规模剖析集群中的线头(head-of-line，HOL)阻塞问题。算法1显示了我们的空间感知分析算法的伪代码。由于有限的 GPU 资源是 DL 培训工作的典型瓶颈，我们根据它们的 GPU 需求对工作进行分类(第4行)。然后，我们采用独占和合并分配策略(第8行)来减少资源碎片化[QSSF]。时间感知缩放。为了保证分析的资源可用性，分析集群通常与主计算集群解耦。然而，由于作业提交的时变模式，静态分析配置可能导致严重的队列延迟和资源不平衡。为此，我们提出了基于当前状态动态调整作业规模限制 Npro f、分析时间限制 Tpro f 和分析集群容量 Cpro f 以及未来集群范围作业吞吐量预测的时间感知伸缩算法。例如，当一系列作业在短时间内发生时，分析器将暂时从相对闲置的 VC 中借出一些节点，并减少 Tpro f。当集群吞吐量降低，突发作业队列消除时，将返回资源。

注意，大多数作业都需要进行分析，除了超过作业规模限制的大型分布式作业。Lucid 在不进行分析的情况下即时收集这些大型作业的指标。此外，我们假设作业初始化或数据移动时间不超过 Tpro f，否则探查器无法获得正确的资源消耗特性。为了支持这些作业，运营商应该相应地延长 Tpro f 设置，或者赋予用户将其作业标记为“长冷启动”作业的权利，以扩展 Tpro f。

与分析带来额外的队列延迟和资源需求的普遍观点相反，我们的分析机制具有以下优势:

• (a)及时反馈。由于当前部署的集群的运行时不可知的调度范例，许多短期调试作业都会遭受严重的队列延迟(2.2)[QSSF,48,95]。同时 Lucid 的分析器可以很好地解决这个问题，提高工作的公平性。
• (b)轻而易举。Lucid不需要依赖于任何侵入性指标(例如，作业进度、每次迭代的时间) ，并且不需要修改任何代码。
• (c)提高系统性能。分析器可以过滤掉主集群的大多数失败或调试作业，从而通过减少优化空间来显著促进调度优化。

仿射工作绑定

与以前使用打包的调度程序[10,Gavel,Gandiva,Antman,,SLURM]不同，这些调度程序应用用户代码或 DL 框架侵入方法来识别具有干扰的作业对，Lucid 根据概要特征根据非侵入原则确定打包作业对。为此，Lucid 在仿射作业对绑定器中设计了以下两种策略。

• 懒惰包装。Lucid 只包含不会造成干扰的任务。虽然这种不活跃的方式可能会错过一些优化机会，但它可以有效地避免干扰，并为用户提供包装激励。具体来说，惰性打包为每个 GPU 设置 GPU 共享容量(GSS) ，它将打包作业的共享得分的总和限制在 GSS 以下(默认值 = 2)。此外，Lucid 为作业打包设置了以下规则:
  • (1)对 GPU 内存使用采取严格限制，以防止内存不足(OOM)问题;
  • (2)由于并行培训的滞后效应，它从不将不同 GPU 资源需求的作业打包;
  • (3)在一组 GPU 上合并多达两个作业，因为打包三个作业通常不会带来额外的好处[Gavel] ;
  • (4)如果检测到不稳定的资源利用模式，它会自省地驱逐打包的作业;
  • (5)由于网络争用，分布式作业不会默认打包。图5描述了表1中列出的所有可能的作业对组合的绑定决策。显然，Lucid 有效地识别了干扰很小的作业对，其中超过98.1% 的可打包作业对是无干扰的(阈值: 标准化速度的0.85) ，并且在这种非干扰策略下发现了87.0% 的打包机会。
• 动态策略。现有的工程[10,Gavel,Gandiva,Antman,,SLURM]通常在没有集群意识的情况下，对作业打包保持一个固定的策略。然而，大多数集群[QSSF,79]在作业提交率(吞吐量)和集群利用率方面呈现日常模式。当集群相对空闲时，忽视集群吞吐量可能导致不必要的作业打包，延长作业培训的进度。

因此，我们开发吞吐量预测模型(3.5.2)来对集群作业数量和 GPU 请求吞吐量进行时间序列预测。基于其预测和当前集群状态，当当前集群吞吐量相对较低(可定制)且未来不太可能增加时，我们可以动态调整打包策略从默认模式(GSS = 2)到无情模式(GSS = 1) ，甚至可以暂时禁用作业共享以提高作业完成速度。

资源调度器

为了使平均 JCT 最小化并提高资源利用率，Lucid 使用了资源协调器来管理集群资源和协调工作负载执行。主要的挑战是解决 HOL 阻塞问题，其中长时间运行的作业对 GPU 具有独占访问权，直到它们完成，将短期作业保持在队列中等待[Gandiva]。经验法则是优先考虑短期工作，如最短工作优先(SJF)政策[31] ，而在现实中不可能获得完美的工作持续时间信息。此外，由于 DL 培训工作的高取消率和失败率，以前的侵入性预测范式[Gavel,Optimus,Gandiva]即迭代时间测量可能会产生误导[QSSF,48]。然而，正如在2.3中提到的，大多数工作负载是重复的，我们可以利用先前的数据来训练工作负载估计模型(3.5.3) ，以提供调度的作业持续时间估计。

资源协调器综合考虑了 DL 作业的时间和空间方面。算法2说明了作业调度和资源分配过程。首先，Workload Estimate Model 预测每个作业的持续时间，然后将预测乘以 GPU 的数量作为作业的优先级值(第4行)。额外考虑作业资源消耗(GPU 需求)可以有效地提高调度性能[31,QSSF]。接下来，根据优先级值对作业队列进行排序。然后检查当前是否允许工作包装(第6行)。(1)如果没有，则以排他方式分配作业(第16行)。我们应用合并安置策略，以最大限度地提高每个工作的培训速度，并减少资源分散。(2)如果是，我们打包适合同位的作业，并消除剩余运行时很少的作业(第7行)。此外，对于没有历史信息的新作业，Lucid 可以根据用户的历史行为生成新作业的估计。如果它是由一个新用户提交的，Lucid 可以使用具有相同 GPU 需求的所有作业的平均持续时间作为持续时间预测[QSSF]。更多地，当新作业终止之后，UpdateEngine 将收集其信息并使用最新数据对模型进行微调。通过这种方式，可以在排队和干扰较少的情况下有效地调度作业。

可解释的模型

装箱分析模型

受 LinnOS [35]的启发，我们将 SSD 存储延迟预测建模为一个二进制分类问题，我们引入分享得分方案将干扰预测简化为一个三进制分类问题，以获得高可扩展性和可理解性。具体来说，对于每个工作负载组合(表1) ，我们测量独占和相互协同位置吞吐量，以获得标准化的速度。然后根据模型配置对其他配置的影响，给每个配置分配一个共享得分。如果一个作业的平均标准化速度大于可定制的小作业阈值(例如0.95) ，则该作业被视为 Tiny; 如果速度介于小作业阈值和中等作业阈值之间，则被视为 Medium。否则，作业将被标记为 Jumbo。我们采用决策树(DT)模型进行工作类别预测，以发现资源使用与工作共位特征之间的共同关系。DT 可以提供一个透明的决策过程和优秀的预测准确性对这一任务。此外，它需要较少的训练数据，并在动态系统环境下表现稳健[Primo]。我们利用最小的成本-复杂性修剪[14]来修剪学习树，以获得一个紧凑和准确的模型。

解释: 图6展示了学到的打包分析模型。除了资源使用模式(UG、 MG 和 UM)之外，Lucid 还支持一个可选的指标(A) ，允许用户指定是否在其作业提交命令中应用混合精度培训(例如 torch.cuda.amp)。从这个树中，我们可以清楚地理解 Lucid 是如何对每个作业进行分类的。我们还可以通过观察每个决策路径的深度(箭头线)和右侧图形(特征基尼重要性)来获得对整体模型行为的直观认知。显然，UG 对同居行为的影响最大。其他指标也有助于做出精确的预测

吞吐分析模型

我们采用了一种新的加性模型算法 GA2M [59,69]来进行聚类吞吐量预测。 $$ 𝑦 = 𝜇+\sum 𝑓_𝑖 (𝒙^𝑖) + \sum 𝑓_{𝑖𝑗}(𝒙^𝑖, 𝒙^𝑗), $$ 其中 μ 是截距(训练数据的平均目标值) ，fi (·)表示特征 i 和 j 的相互作用效应。由于每个形状函数是一元或二元的，它们的组合是可加的，因此它为预测过程提供了全面的解释。为了获得准确的未来吞吐量预测，我们通过特征工程提取了与时间相关的数据，如集群 GPU 需求和任务提交的趋势(增加或减少)和季节性(周期性模式)。具体来说，我们编码重复的模式(例如，小时，日期)来探索周期性的变化。此外，我们还计算了不同滚动窗口大小(如1小时)下的平均、中位数和加权软总和吞吐量值。

解释: 图7(a 和 b)给出了每个特征重要性和所学形状函数的全局解释。它描绘了从土星轨迹学习的模型，其表现优于一系列复杂的黑盒模型(表7)。从图7(a)中，我们发现与1小时前相关的小时和一系列增强特性在模型预测中起着最重要的作用。此外，图7(b)演示了小时特性的学习形状函数，其中每个 bin 表示一天中不同的小时，除了 bin 0被赋予一个默认值。该图显示了一个明显的日常模式，与我们的经验非常吻合，为集群配置调整提供了可靠和准确的建议。

负载时间预测模型

工期预测采用 GA2M 模型。具体来说，该模型从跟踪中提取所有特征(例如，用户名、作业 ID、 GPU 需求)和实际作业持续时间，并对这些分类特征进行编码。对于极其稀疏和高维的特征，如职位名称，我们利用莱文斯坦距离将它们转换为相对密集的数值，并利用亲和传播将类似的数值桶化。对于诸如工作提交时间之类的时间特性，我们将它们解析为几个时间属性，例如月或小时。

解释: 图7(c)展示了 SenseTime 中来自Venus集群的一个作业预测的特征解释[QSSF]。预测结果是每个特征得分和截距常数的总和。通过局部解释，开发人员可以清楚地检查每个预测的模型行为。

系统优化

系统调优

集群调度程序通常包含由系统操作员调整的多个参数，以提高性能或实现不同的调度目标。调优这些参数需要丰富的领域知识和手工操作。不适当的调整可能导致严重的性能下降。不同公司和研究所的 DL 集群有不同的工作负载类型和分布。因此，为了获得最佳的调度性能，必须进行相应的手动系统调整。由于数据驱动策略的特性，Lucid 可以通过以前的作业和基于集群信息的模拟进行明确的调整。此外，为了优化可解释模型的性能，我们采用了池相邻违反者(PAV)[8]算法来对学习提出单调约束[Primo]

更新引擎

在实际的生产级集群中，环境是动态变化的，会带来工作负载和集群分布的漂移。因此，需要频繁地对模型进行微调或再训练，以解决由于模型陈旧而引起的性能恶化问题。为此，我们设计了更新引擎以适应更改。它收集实时系统状态、作业日志，并使用最新数据定期微调 Lucid 模型。