Lucid：非侵入、可扩展、可解释的深度学习训练调度器

论文存档：Lucid: A Non-Intrusive, Scalable and Interpretable Scheduler for Deep Learning Training Jobs（非必读）。本文只依据本目录原文存档、项目总索引和 Lucid 对应草稿整理；数字均保留其所属实验语境。

1. Lucid 的调度取舍

Lucid 面向多租户深度学习训练集群，主要目标是降低平均作业完成时间（Job Completion Time，JCT），同时提高 GPU 利用率并缩短调试反馈的等待。作业本身保持不变：调度器用短暂的 profiling 阶段读取 GPU 硬件指标，根据历史日志预测作业时长和未来提交负载，再以保守共置和无抢占的短服务优先策略安排资源。它不依赖频繁抢占，也不改变 GPU 数或训练超参数。

三个形容词对应三组明确设计。非侵入表示不修改用户训练代码、深度学习框架或 CUDA 库，不靠迭代进度回调，不改变 batch size、learning rate 或 worker 数，并且完整流程不抢占作业。可扩展表示调度决策不求解大规模线性规划或运行强化学习搜索，而由决策树、加性模型、排序和放置规则完成；即使队列里有 2,048 个作业，论文测得决策仍小于 3 ms。可解释表示模型的分裂路径和各特征的加性贡献可以直接查看，并被用于系统调参、单调约束和故障排查，而非只在论文中展示特征重要性。

这是一种部署取舍。Lucid 不承诺公平性、deadline 或 SLO，也不做异构 GPU、CPU、网络的联合优化。它在生产 trace 所呈现的条件下有效：训练作业大量重复、很多 GPU 没吃满、大量测试或调试作业很短、单机作业占多数。理解这些前提，比记住某个提升倍数更重要。

论文把这套取舍对应为五个结果：完整流程无需用户和框架配合，因而接入与版本维护成本较低；训练配置不被调度器篡改，模型质量由用户原方案决定；排序和模型推理能及时处理大队列；每个模块的预测依据可以检查；保守共享仍能追回闲置资源。这里的“保持模型质量”是机制保证，即 Lucid 自身不改训练超参数，并不是说硬件故障、随机性或用户代码不会影响精度。“可扩展”也专指调度计算与模型训练开销，不代表系统已经实现所有大规模集群目标。

2. 训练调度前置：作业、GPU 与 JCT

一个训练作业会重复执行许多 mini-batch 迭代。每次迭代大致读取一批数据，做前向计算，反向传播梯度，再更新权重。迭代结构重复，因此运行少量迭代往往就能观察到较稳定的 GPU 占用特征。完整训练则可能持续数小时或数天。传统方案可以通过 checkpoint 保存状态，之后抢占并恢复；但保存、搬运和恢复会产生额外开销，训练代码还必须正确支持这条路径。

多租户集群接收来自不同用户或产品组的作业。提交信息通常包含用户、作业名、GPU 数、CPU 数等；生产集群还可能划分为多个虚拟集群（Virtual Cluster，VC）。调度器决定哪个作业何时开始、放到哪些节点、是否和另一个作业共享 GPU。若一个长作业先占住全部可用 GPU，后面许多短作业只能等待，这就是队首阻塞（Head-of-Line blocking）。

对作业 J，可把完成时间写成：

JCT(J) = queue_time(J) + run_time(J)

若发生 profiling、抢占或共置，二者会进一步变化。profiling 可能增加一段排队与短时运行，却也可能让短调试作业直接结束；共置减少排队，但资源竞争会拉长运行；抢占给短作业腾出 GPU，却增加 checkpoint 与冷启动成本。因此“提高 GPU 利用率”本身不是最终目标：若把两个重作业塞在同一张 GPU 上导致双方速度大降，利用率数字更好，JCT 反而可能更坏。

GPU utilization 在本文语境中是采样区间内至少有一个 kernel 执行的时间比例，并不是计算单元真实活跃比例。GPU memory utilization 是采样期内显存被读写的时间比例，GPU memory footprint 则是占用的显存容量。三者分别描述计算忙碌、显存访问忙碌和容量安全，Lucid 只通过 NVIDIA-SMI 或 DCGM 获取它们。

3. 论文抓住的生产观察

第一项观察是 GPU 普遍未充分利用。论文引用的生产统计显示许多训练 GPU 留有计算或显存余量。硬件每代增长很快，训练负载却不必然同时把所有资源维度吃满，因此让两个合适作业共用 GPU 有机会把空隙填起来。

作者在 RTX 3090、PyTorch 1.10 上枚举表 1 中工作负载的两两组合。两作业累计 GPU utilization 与共置干扰有明显相关性：累计达到 100% 时，多数组合仍保有超过 0.8 的归一化速度，平均约 0.92。这里的归一化速度是共置速度除以独占速度；1 表示没有变慢。具体组合差别很大：ResNet-18 与 PointNet 或 PPO 共置时几乎不降速，与另一些负载共置则接近 40% 降速。仅知道“GPU 未满”不够，调度器还要区分轻重作业。

同一节点内，多 GPU 并行作业在不同 GPU 数下显示近似的共置表现，只要每张 GPU 的 mini-batch 保持一致。混合精度训练也会影响共置收益，所以 Lucid 允许用户在提交命令中可选地声明 AMP。三作业共置通常出现严重降速，系统因此最多只配对两个作业。超过 95% 的生产作业是单节点作业，这又使只覆盖单节点 packing 的策略仍有较大适用面。

第二项观察是作业具有重复模式。用户常反复提交相似脚本，例如先调试、再改参数、最后正式训练。作业名、用户、GPU 数、提交时间与短时资源画像可以帮助匹配历史任务，因此不必知道未来的精确迭代数，也能把短作业和长作业大致分开。第三项观察是提交率具有小时与昼夜周期。若未来一段时间集群仍空闲，强行共置只会让作业变慢；若马上出现高峰，提前释放共享余量才有价值。

4. 问题与基线：为什么已有路线难部署

论文把已有调度器的落地障碍概括为五类。第一，抢占、弹性或细粒度共享常要求用户代码加入 checkpoint、迭代回调或适配库，用户负担大且容易出错。第二，修改 PyTorch、TensorFlow 或 CUDA 相关路径会形成长期兼容成本；框架升级后调度系统也要跟着维护。第三，自适应改变 batch size、learning rate 或 worker 数可能改变优化轨迹和最终验证精度。商业训练中，小幅精度差异也可能不可接受。

第四是扩展性。Gavel 用线性规划处理 2,048-job 分配可耗时数千秒；论文在扩展性实验中还引用约 30 分钟的量级。Metis 的强化学习方案只能承担数十作业，而生产集群可能同时运行数千作业。Shockwave 和 Muri 的 solver 也可能用数秒到数分钟。训练调度不必像交互服务那样微秒响应，但分钟级求解会让状态在答案出来前已经变化。

第五是黑盒决策。RF、GBDT 或 RL 即使预测准确，运维者仍难知道某次时长预测为什么突然增大，也难安全调整阈值。错误的临时修改可能显著恶化性能。Lucid 因而选择直接可解释的模型，而不是先训练黑盒再用另一套工具解释。

实验基线覆盖不同能力边界：FIFO 按到达顺序，是常见但完全不看运行时的非侵入策略；SJF 假定知道真实时长，是无抢占平均 JCT 的理想参照，却无法实际部署；QSSF 根据历史预测短作业，非抢占但使用黑盒模型；Horus 通过用户代码取得 ONNX 图后预测资源并 packing，既侵入又数据驱动；Tiresias 按已获得服务量分队列并抢占，需要用户代码支持恢复；Pollux 弹性改变资源和训练参数。Lucid 要证明的是：不触碰训练语义，也能超过这些更激进机制，而不是证明所有目标上都胜出。

5. “Non-intrusive”究竟包含什么

Lucid 的非侵入边界有四层。其一，观测只依赖集群已有的提交日志与 GPU 硬件遥测，不读取模型图，也不要求训练循环报告 iteration time、loss 或剩余进度。其二，调度器不改用户代码和框架，不维护定制 CUDA。其三，它不改变 batch size、learning rate、模型结构或 GPU worker 数，用户提交的训练配置保持原样。其四，调度流程 preemption-free：作业一旦在主集群开始，就不靠周期性 checkpoint 把 GPU 抢给别人。

“非侵入”不等于“不观察”或“不控制”。Lucid 仍会把普通作业先送入独立 profiling 资源池，设定最长 profiling 时间，读取三类 GPU 指标；它也会决定是否共置、把作业放在哪些 GPU 上，并在检测到不稳定资源模式时拆开已共置作业。可选 AMP 标志由用户显式提供，但不是强制改代码的前提。大规模分布式作业超过 profiling GPU 数上限时不进入标准短测，而是在真实运行中在线采集指标。

这种边界保住了模型质量和接入成本，却主动放弃一部分优化空间。系统看不到精确训练进度，不能在运行中缩放 worker，也不能用抢占纠正一次严重的时长误判。它依赖历史重复性与安全 packing 来弥补这些损失。

6. 系统全景：三个调度模块、三个模型、两个优化器

新作业先进入 Non-intrusive Job Profiler。短测产生 GPU utilization、GPU memory utilization 和显存占用，并把作业分为 Tiny、Medium、Jumbo。大量测试、失败或不足一个 profiling 窗口的短作业会在这里结束，不再进入主集群队列。

仍需运行的作业交给 Affine-jobpair Binder。对应的 Packing Analyze Model 是决策树，根据资源画像预测 Sharing Score；Throughput Predict Model 则预测未来作业提交数和 GPU 请求量。Binder 综合作业类别、显存安全、GPU 数、运行稳定性、预计剩余时间与集群未来负载，决定当前是否开启 sharing，以及哪两个作业是 affine pair。

Resource Orchestrator 管理主队列。Workload Estimate Model 根据历史与 profile 特征预测时长；调度器将预测时长乘 GPU 数作为优先值，升序扫描。若允许 sharing，它先尝试把作业与可配对的等待或运行作业合并；失败则做独占、紧凑放置。若 sharing 被关闭，全部按独占方式处理。

模块间有三条关键依赖。Profiler 的特征让 Orchestrator 更准确匹配重复作业；吞吐预测同时控制 Binder 的 sharing 模式和 Profiler 的容量伸缩；时长估计也反馈给 Binder，避免把长作业错误共置后加剧队首阻塞。两个系统优化器位于闭环外层：Update Engine 用最新日志周期更新模型，System Tuner 用历史 trace 仿真和模型解释调整系统参数。

7. 二维 Non-intrusive Job Profiler

Profiler 给每个作业一个最长 Tprof 的短运行窗口。空间维度的难点是 profiling 池通常较小：若队首是需要很多 GPU 的作业，它可能暂时放不下，却挡住后面一批单 GPU 作业。算法 1 因此按 GPU demand 从小到大排序，逐个检查能否紧凑放置；能放就启动、出队并采指标，遇到第一个无法放置的作业就停止当前扫描。运行超过 Tprof 的 profiling 作业被移出短测阶段。

时间维度处理提交负载波动。固定的 profiling 池在低谷会浪费 GPU，在突发高峰又会排长队。Lucid 根据当前状态与 Throughput Predict Model 的未来负载，同时调整三个量：

• Nprof：允许进入标准 profiling 的最大作业 GPU 数；
• Tprof：单作业的 profiling 时间上限；
• Cprof：profiling 资源池容量。

突发提交时，Profiler 可从相对空闲的 VC 临时借节点，并缩短 Tprof 以提高周转；队列消退后归还资源。超过 Nprof 的大作业直接进入正常执行并在线采样。论文假定初始化和数据搬运不超过 Tprof，否则采到的只是冷启动而非稳定训练。对此只能由运维者延长窗口，或让用户把作业标为 Long Cold-Start。

profiling 并非纯开销。首先，短调试作业可直接得到反馈；其次，它过滤掉大量失败和短任务，缩小主调度队列及优化空间；最后，资源画像同时服务 packing 与时长估计。三条 trace 中有 23.3%–55.4% 的作业在 profiling 阶段结束，各 profiling 池平均排队约 1 分钟。

8. Binder：Sharing Score、Indolent Packing 与动态模式

Packing Analyze Model 不直接回归任意作业对的 slowdown，而把单个配置标成三类。若与其他作业共置后的平均归一化速度高于 Tiny 阈值，例如默认 0.95，则为 Tiny、SS=0；速度位于 Tiny 与 Medium 阈值之间则为 Medium、SS=1；更重的配置为 Jumbo、SS=2。默认 Medium 阈值是 0.85。分类输入是 GPU utilization、GPU memory utilization、显存占用和可选 AMP 标志。

每张 GPU 有 Sharing Capacity GSS。默认模式令 GSS=2，只允许同卡作业的 Sharing Score 之和不超过它。于是两个 Jumbo 的总分 4，不能共置；Tiny 与 Jumbo 的总分 2，可以进入下一步安全检查；两个 Medium 也等于 2。分数只是第一道筛选，Binder 还执行五条硬规则：总显存不得触发 OOM；不同 GPU demand 的作业不配对，避免并行训练的 straggler；最多两个作业；运行指标不稳定时拆开；分布式作业默认不 packing，以避开网络争用。

作者称它为 Indolent Packing，因为它宁可错过机会，也不冒明显干扰风险。枚举实验中，被判为可共置的组合有 98.1% 达到归一化速度至少 0.85，同时覆盖 87.0% 的 packing 机会。这个数字不表示任意生产作业都有 98.1% 准确率，而是表 1 工作负载组合上的配对质量。

packing 还会随负载切换。Throughput Predict Model 若判断当前吞吐低、未来也不会上升，Binder 从默认 GSS=2 降到 Apathetic Mode 的 GSS=1，甚至暂时关掉 sharing。这样空闲时作业独占 GPU、尽快结束；高峰时才用共置换容量。时长预测用于避免把剩余时间很少的作业再拿去配对，也防止长期共置拖慢短作业。

9. Orchestrator：时空联合优先级与放置

若真实时长已知，Shortest-Job-First 能在无抢占条件下降低平均 JCT，但真实系统没有未来信息。Lucid 用 Workload Estimate Model 给出 Pred(J)，再定义：

priority(J) = gpu(J) × Pred(J)

Pred(J) 是预计时长，gpu(J) 是请求 GPU 数。乘积近似预计 GPU-time，把时间与空间成本放进同一个排序键。优先值越小越先尝试分配。一个 1-GPU、2 小时的作业得分 2；一个 8-GPU、1 小时的作业得分 8，前者先走。公式不声称求得全局最优解，它是低成本的 service-time 启发式。

若新作业没有直接历史，模型先退回该用户的历史行为；若用户也是新的，则使用相同 GPU demand 作业的平均时长。作业结束后，Update Engine 将真实信息纳入后续更新。这种回退保证冷启动时系统仍能运行，但预测粒度明显变粗。

放置先检查当前是否允许 sharing。允许时，对按优先值排好的每个作业寻找 affine pair，候选可以来自等待队列和运行集合；若能在紧凑拓扑上共享，就共同放置并从队列删除，否则尝试独占放置。不允许 sharing 时，直接对队列做独占紧凑放置。紧凑放置把同一作业的 GPU 尽量集中，减少碎片并保持训练速度。

10. 三个可解释模型与公式变量

Packing Analyze Model 使用经过 minimal cost-complexity pruning 的决策树做三分类。图 6 所示树中，UG 表示 GPU utilization，MG 表示 GPU memory footprint，UM 表示 GPU memory utilization，A 表示是否启用混合精度。分裂路径直接说明为何一个作业被判成 Tiny、Medium 或 Jumbo；Gini importance 显示 UG 影响最大，其他指标用于细化边界。

Throughput Predict Model 与 Workload Estimate Model 都采用 GA2M，即含二阶交互的广义加性模型：

ŷ = μ + Σᵢ fᵢ(xᵢ) + Σᵢⱼ fᵢⱼ(xᵢ, xⱼ)

ŷ 是预测目标；μ 是训练目标均值形成的截距；xᵢ 是第 i 个输入特征；fᵢ 是单特征 shape function；fᵢⱼ 是特征 i 与 j 的二元交互贡献。一次预测是截距、各单变量贡献和少量二元贡献的加和，所以可以逐项解释。

吞吐模型分别预测作业提交数和 GPU 请求量。输入包含 hour、date、month 等周期编码，提交趋势，以及不同滚动窗口的 mean、median 和加权 soft sum。Saturn 的全局解释显示 hour 与一小时前相关特征贡献最大，hour 的 shape function 呈明显昼夜周期。这些预测控制 profiling 池扩缩和 packing 模式。

时长模型输入用户、作业标识或名称、GPU demand、提交时间、profile 特征和真实历史时长。高维稀疏的作业名先用 Levenshtein distance 转成较密集数值，再用 affinity propagation 将相似名称分桶；时间戳拆成 month、hour 等属性。对单个作业，预测值可展开为每个特征分数加截距，运维者能检查是用户历史、GPU 数还是时间特征推高了预测。

11. 两段伪代码与端到端数据流

下面保留论文算法 1 和算法 2 的控制关系，用中文变量注释重写，不增加原文没有的分支：

过程 SpaceAwareProfile(新作业 J, profiling 队列 Q):
  若 J.gpu ≤ Nprof:
    J 入 Q；Q 按 GPU 数升序排序
    检查运行中的 profiling 作业，移出超过 Tprof 者
    对 Q 中每个 Job:
      若当前 profiling 池能紧凑放下 Job:
        紧凑分配；Job 出 Q；非侵入采集硬件指标
      否则:
        停止本轮扫描

过程 LucidSchedule(等待队列 Q, 运行集合 R):
  对 Q 中每个 J:
    Pred ← WorkloadEstimateModel(J)
    J.priority ← J.gpu × Pred
  按 priority 升序排序 Q
  若当前 sharing 策略开启:
    对 Q 中每个 J:
      P ← 从 Q ∪ R 中检查 affine pair
      若 P 存在且 J、P 可紧凑共享:
        分配共享 GPU；J 出 Q
      否则:
        尝试独占放置 J
  否则:
    对 Q 尝试独占放置

以一次完整提交为例：用户提交一个 2-GPU 作业；它未超过 Nprof，进入 profiling 队列。小 GPU 作业优先策略让它在可用的相邻 GPU 上短跑，采到 UG、UM、MG。若它在 Tprof 内结束，用户已经得到调试反馈，流程终止。若未结束，决策树把它标为 Medium，时长模型根据用户、相似作业名、2-GPU 历史和画像预测 1 小时，因此 priority 为 2 GPU-hours。

假设吞吐模型预测高峰将至，Binder 保持 GSS=2。队列或运行集合里恰有另一个 2-GPU Medium 作业；两者分数之和为 2、显存总量安全、都不是分布式跨节点作业、资源曲线稳定，于是成为 affine pair，在同一组 2 张 GPU 上共置。如果另一个作业请求 4 GPU，即使资源很轻也会因 GPU demand 不同被拒绝；若预计低谷持续，系统可能关闭 sharing，让当前作业独占运行。作业结束后，真实时长与日志进入 Update Engine，供下一轮训练使用。

12. 实现、部署与维护闭环

论文原型约 4,700 行 Python。scheduler 与 worker 之间通过 gRPC 通信；可解释模型基于 Primo；工作负载用 PyTorch 实现。系统能接入 Slurm、Kubernetes 一类已有集群管理系统，因为它需要的是作业提交、放置控制、硬件指标和历史日志，而不是替换训练框架。

Update Engine 持续收集系统状态和作业日志，按日或按周 fine-tune 或 retrain 模型，以应对作业分布和集群环境 drift。它并不能消除新用户、新模型或突发分布变化的冷启动，只是让已有偏差不会永久积累。模型更新后，新的预测继续进入 Binder、Profiler 和 Orchestrator，构成观测—预测—决策—日志的闭环。

System Tuner 用历史作业和集群信息做 trace simulation，比较不同 Tprof、Nprof、Cprof、packing 阈值和更新周期。模型解释还能指导约束。例如运维者认为 GPU 数与时长贡献应满足单调关系，可以用 Pool Adjacent Violators（PAV）算法对 learned shape function 加单调约束。论文报告在 gpu_num 特征上这样处理后，时长模型 R² 提高 2.6%，排队时延降低 3.9%。

13. 实验设置、trace 与比较口径

物理集群有 4 台服务器、32 张 RTX 3090；每台含双路 Intel Xeon Gold 6326，共 64 CPU threads、256 GB RAM、8 张 24 GB GPU。软件为 Ubuntu 20.04、Python/PyTorch 1.10、CUDA 11.3、cuDNN 8。物理实验从 Venus 随机抽样，构造全部同时到达的 100-job static trace，以及按 Poisson 分布到达且长作业更多的 120-job continuous trace；这里每个作业最多 profile 60 秒并启用 packing。

大规模仿真保留原提交时间，不做时间缩放。三条生产 trace 是：

SenseTime 用 4–8 月作训练/验证、9 月测试；Microsoft 则用 10 月首周测试、10 月之后至 12 月训练/验证。Saturn、Venus 分成 20、15 个 VC；Philly 原 trace 没给 VC 配置，实验设为 108 个 8-GPU 节点且不再切 VC。trace 没有完整模型类型，作者参照生产 GPU utilization 分布并按作业规模分层抽样，把表 1 的模型配置映射给作业；长且大规模任务更可能映射 BERT、ResNet-50 等大负载。故仿真保留真实到达和时长分布，但具体 workload 类型是合成映射。

14. 端到端结果与准确数字

物理集群 static trace 上，FIFO、SJF、Tiresias、Lucid 的 makespan 分别为 11.56、11.27、9.23、8.45 小时；对应模拟值为 11.34、11.02、9.68、8.17 小时。continuous trace 的平均 JCT 分别为 8.17、4.59、4.03、3.64 小时；模拟值为 7.97、4.46、4.16、3.49 小时。Lucid 相对 FIFO 的 static makespan 约改善 1.4 倍，continuous 平均 JCT 约改善 2.3 倍。模拟与物理实验在 makespan、平均 JCT 上误差小于 4.6%。

大规模模拟的完整核心结果如下：

因此 Lucid 相对 FIFO 的平均 JCT 改善 5.2–7.9 倍，相对 Tiresias 为 1.1–1.3 倍；相对 Tiresias 的平均排队时延改善 1.8–9.1 倍。Philly 的平均 JCT 从 Tiresias 的 9.02 小时降到 6.84 小时，即 1.32 倍。论文还报告平均每个训练作业节省 2.2 小时，但这来自其整体实验口径，不能脱离 trace 当作固定收益。

P99.9 排队时延在 Venus/Saturn/Philly 上，Tiresias 是 55.39/26.62/98.80 小时，Lucid 是 26.15/19.28/71.22 小时，对应 1.4–2.1 倍改善。与 Tiresias 相比，GPU utilization 提高 9%–17%，GPU memory usage 提高 7%–24%；仍在排队且总时长不超过 60 秒的短作业数量减少 4.1–24.8 倍。

Venus 分尺度结果也没有显示大作业被饿死。大于 8 GPU 的作业平均 JCT，FIFO/Tiresias/Lucid 为 9.96/6.08/4.59 小时，平均排队为 6.22/2.34/0.86 小时；不超过 8 GPU 的作业对应 JCT 19.55/3.75/3.46 小时，排队 16.34/0.54/0.19 小时。

15. 消融、解释性、扩展性与运行开销

Binder 消融。在 Venus 上，Indolent Packing 相比朴素 bin packing 额外降低 1.4 倍排队时延。完全关闭 sharing 后，Lucid 仍比非侵入的 QSSF 降低超过 2 倍排队时延，说明收益不只来自共享，也来自 profiler 和时长预测。禁用 estimator 后，恢复运行时感知可再降低 2.2 倍排队时延；即便无 estimator，短作业在 profiler 结束和低利用作业 packing 仍让变体优于 QSSF。

Profiler 消融。关闭动态伸缩、固定 Tprof=500s、Nprof=36 时，space-aware 策略相对朴素 profiling 最多改善 11.6 倍排队。Tprof 从 100、200、300 到 600 秒时，profiling 阶段完成率为 27.65%、44.61%、53.73%、64.40%，该阶段排队为 21、73、175、509 秒；整体 JCT 为 13,087、12,886、13,160、13,270 秒，整体排队为 1,074、915、1,222、1,422 秒。默认选 200 秒，因为整体最好且短测排队不过重。

敏感性。作者生成 Venus-L/M/H 三种利用率分布，即使都比引用的 Alibaba PAI 分布更重，Lucid 相对 Tiresias 仍取得 1.8–4.2 倍排队时延降低。Medium 阈值在 0.75–0.85、Tiny 在 0.90–0.97 变化时，Venus 平均 JCT 差异小于 3.6%；默认取 0.85、0.95。周更模型比完全静态模型降低 4.8% 排队，日更在周更上再改善 1.6%。

解释模型准确度。Venus 上 Throughput Predict 的 MAE，RF/LightGBM/XGBoost/DNN/Lucid 为 4.607/4.491/5.807/5.132/4.125，越低越好；Workload Estimate 的 R² 为 0.101/0.230/0.332/0.181/0.413，越高越好。Packing 决策树准确率 94.1%，与更复杂基线相当。基于解释调整 Profiler，相对启发式 tuning 把 profiling 阶段平均排队降低 2.8–8.7 倍，且几乎不影响过滤与调试反馈。

扩展性与开销。生产 trace 中平均队列仅 10–12，最大 119–340；压力测试把待调度作业扩到 2,048，包含模型 inference 的策略计算仍小于 3 ms。半年数据含 10^5–10^7 样本，Workload Estimate 与 Throughput Predict 最多约 11 分钟完成训练；图 10 给出的三集群两模型训练时间组合为 168.3/2.8、653.9/2.7、92.3/1.4 秒。Packing Analyze Model 与集群 trace 无关，训练少于 1 秒。

与 Pollux。Pollux 在作者提供的 160-job、强度 1.0 trace 上，负载较轻时更适合；强度升高后，弹性 batch size 与资源缩放受集群饱和限制，Lucid 表现更好。一个 EfficientNet 作业的最佳验证精度为 Lucid 89.84%、Pollux 87.63%。这个单例证明自适应训练可能改变质量，不能外推成 Pollux 在所有模型上固定损失 2%。Pollux 处理 160-job trace 约需 30 分钟，320-job 超过 3 小时，论文因此没有让它跑 10^5–10^6 作业的大 trace。

16. 局限、适用边界与复现清单

Lucid 依赖 recurrent workload 与历史日志。新用户、新作业族、改名严重或 workload drift 时，预测只能退回用户历史或同 GPU 数平均时长。GA2M 的 R²=0.413 也说明它主要擅长区分调度所需的长短次序，并非精确预报每个时长。若集群作业几乎不重复，Estimator 的价值会下降。

Profiler 假定冷启动短于 Tprof；数据加载很慢时会把初始化误当稳态。大于 Nprof 的作业不走同样短测。Binder 默认不共置分布式作业，只处理同构 GPU 为主的资源，CPU、网络、存储与异构 GPU 选择都未联合建模。物理验证只有 32 GPU，大规模周/月结果来自 simulator；小实验误差低于 4.6% 能支持模拟器在该抽样与硬件条件下的可信度，不能证明所有生产环境都保持同样误差。

系统目标是平均 JCT，同时观察利用率、排队与调试反馈。公平性、SLO guarantee 是论文明确列出的未来工作。无抢占也意味着一旦长作业占住 GPU，系统不能像 deadline scheduler 那样强制纠正。若没有安全共置余量、作业时长不可预测或必须做异构资源优化，Lucid 的优势会缩小。

artifact appendix 给出的复现对象是 Venus 主要结果。公开材料包含 Python、Shell、Lucid 的决策树与 GA2M、SenseTime Helios 和 Microsoft Philly trace、表 1 工作负载及 README。环境为 Ubuntu 20.04、Python 3.9、PyTorch 1.10、CUDA 11.3、cuDNN 8；硬件条目对应每台双路 Xeon Gold 6326、256 GB、8 张 RTX 3090 24 GB。预计磁盘约 10 GB，准备约 1 小时，实验约 2 小时；指标是平均 JCT 与平均排队时延，输出含 Lucid 和 baselines 的性能与图。

复现时应分层核对：先验证单作业独占速度与三类硬件指标，再枚举共置得到归一化速度和标签；训练并检查决策树、吞吐 GA2M、时长 GA2M；用同一输入 trace 比较 FIFO、SJF、QSSF、Horus、Tiresias 与 Lucid；最后才比较表 4。还要记录随机 workload 映射、VC 划分、Tprof/Nprof/Cprof、Medium/Tiny 阈值、更新周期和是否启用 sharing。若无法获得同款硬件，不应照搬原论文 packing 标签，因为资源画像与 slowdown 会随 GPU 和软件栈改变。

最终应把论文贡献概括为一个闭环：用低成本短测把训练作业从黑盒变成资源画像，用保守分类把画像变成安全共享决策，用历史重复性把作业变成长短优先级，再让未来吞吐与持续日志调整资源池、sharing 模式和模型。它没有搜索最复杂的策略，而是把部署边界、决策延迟和可解释维护同时纳入调度器设计。