Characterization and Prediction of Deep Learning Workloads in Large-Scale GPU Datacenters

论文链接：PDF；arXiv 2109.01313

画像和预测怎样接起来

论文发布了 2020 年 SenseTime Helios 的大规模 DL 作业 trace，并检验历史作业与集群趋势是否足以预测。预测结果通过插件式框架用于作业排序和节点节能。

数据集与观测窗口

Helios trace 覆盖 2020 年 4 月至 9 月，共 6 个月、4 个独立集群、802 个节点、6,416 张 GPU、105 个 Virtual Cluster 和 3.363M 个作业，其中 1.58M 是 GPU 作业、1.78M 是 CPU 作业（PDF 第 2 至 3 页，表 1 与表 2）。Venus、Earth、Uranus 是同构 Pascal 或 Volta 集群，Saturn 混合 Pascal 与 Volta；节点内使用 PCIe 或 NVLink，节点间使用 InfiniBand，并禁止跨 RDMA domain 的分布式训练（PDF 第 2 至 3 页）。

Slurm 为每个 VC 维护独立 FIFO 队列，组内作业具有相同优先级，不支持 preemption；默认把作业压到尽可能少的节点，只有 0.15% 作业由用户指定 placement（PDF 第 3 页）。trace 由 Slurm sacct job log 和每日 VC 配置组成，包含作业时间、状态、资源请求、用户、VC 与节点分配，但没有 ICCD 那种 15 秒 GPU SM/显存序列。论文还使用 Microsoft Philly trace 做外部验证；Helios 的 3.36M 作业是 Philly 103K 作业的 32.6 倍，平均 GPU 请求为 3.72 张，对方为 1.75 张（PDF 第 3 至 4 页，表 2）。

关键统计发现

集群使用有日周期，但长训练把昼夜差异抹平了一部分。 四个集群平均利用率在 65% 到 90% 之间，夜间 0 点至 8 点仅下降 5% 到 8%；作业提交率则明显随睡眠、午餐和晚餐下降（PDF 第 4 页，图 2）。这正是后续 CES 能用时间特征预测节点需求的经验基础。

单卡作业数量多，多卡作业决定总资源。 每个集群超过 50% 的作业是单卡作业，Earth 达到约 90%，但单卡作业只占 3% 到 12% GPU time；少于 10% 的至少 8 卡作业却消耗约 60% 计算资源（PDF 第 6 页，图 6）。月度提交数中，单卡作业波动很大，却通常只贡献不足 6% 集群利用率；多卡作业数量与规模更稳定，是更值得预测和优化的对象（PDF 第 5 页，图 3）。

CPU 作业与 GPU 作业的时间尺度完全不同。 GPU 作业平均时长 6,652 秒，是 CPU 作业 629 秒的 10.6 倍；超过一半 CPU 作业不足 2 秒，GPU 作业时长中位数为 206 秒，约四分之三 GPU 作业少于 1,000 秒，很多是模型评测和调试（PDF 第 6 页，图 5）。这说明同一开发流水线里不能用一个统一的 runtime prior。

静态 VC 隔离同时制造排队与闲置。 Earth 的 vc6YE 与 vcLJZ 因大作业较多，利用率大部分时间超过 90%；vchbv 与 vccaA 因小作业较多，基本低于 65%。忙 VC 的平均排队时间也更长，而别的 VC 仍有闲置资源（PDF 第 5 页，图 4）。静态分区保障多租户隔离，却不能随需求快速搬动资源。

GPU 作业失败和取消明显多于 CPU 作业。 GPU 作业只有 62.4% 完成，22.1% 被取消，15.5% 失败；CPU 作业有 90.9% 完成（PDF 第 6 页，图 7(a)）。请求 64 张及以上 GPU 的作业完成率低于四分之一，取消率约 70%，原因包括长训练更容易被提前停止。论文还发现失败作业大多很快退出，却可能在与长作业混合的 FIFO 中等待很久（PDF 第 7 页，图 7(b)）。

资源与排队高度集中在少数用户。 平均只有约 25% 用户提交 CPU 作业，top 5% 用户消耗超过 90% CPU time；几乎所有用户都有 GPU 作业，top 5% 用户消耗 45% 到 60% GPU time。Uranus 中 top 1% 用户，也就是 3 人，承担超过 70% 总排队时间，却不在资源消耗 top 10 内（PDF 第 7 页，图 8 与图 9）。这说明 fairness 不能只按已获 GPU time 衡量，还要看等待伤害是否集中。

方法或预测模型

作者设计了一个位于 Slurm、YARN 或 Kubernetes 之上的集中式 prediction-based framework，包含 Model Update Engine 和 Resource Orchestrator。每个服务独立训练模型，orchestrator 在线预测并执行动作，update engine 定期或按事件抓取新日志并更新模型；单次预测和操作通常为毫秒级（PDF 第 7 至 8 页，图 10）。论文实现两个服务。

QSSF（Quasi-Shortest-Service-First） 不做 preemption，也不直接预测“最短时长”，而是预测 GPU time，也就是预计时长乘请求 GPU 数，以避免一个“运行短但占很多卡”的大作业阻塞多个小作业。机器学习部分采用 GBDT，特征包括 user、VC、GPU/CPU request、job name、month、weekday、hour、minute 等；job name 先按 Levenshtein distance 聚类并 bucketize（PDF 第 8 页）。最终优先级是 P = N * (lambda * P_R + (1-lambda) * P_M)：P_M 是 GBDT 时长估计，P_R 是相似历史作业的 rolling estimate。新用户回退到同 GPU 数作业的平均时长；老用户的新 job name 回退到该用户同 GPU 数作业；匹配到相似名字时使用指数衰减的历史时长（PDF 第 8 至 9 页，算法 1）。

CES（Cluster Energy Saving） 预测未来运行节点数，再结合 Dynamic Resource Sleep 关停闲置节点。特征包括小时、星期、日期等周期变量，不同 rolling window 的活跃节点均值与标准差、holiday indicator 和多时间尺度 lag。作者比较 ARIMA、Prophet、LSTM 与 GBDT 后选择 GBDT；Earth 上预测 SMAPE 约 3.6%（PDF 第 10 页）。系统在新作业到达时检查活跃节点是否足够，不足则唤醒缺口加 buffer；每 10 分钟左右同时检查过去约 1 小时和未来约 3 小时趋势，只有两者都显示需求下降时才把活跃节点压到当前运行节点数加 buffer（PDF 第 10 至 11 页，算法 2）。

实验数字

QSSF 使用 4 月至 8 月 Helios 作业训练 GBDT，以 9 月 trace 做 trace-driven simulation；模拟器复现真实 arrival、queue、run 和结束状态，只考虑瓶颈 GPU。基线包括生产 FIFO，以及拥有完美真实时长信息的理想 SJF 和 SRTF；实验没有 backfill（PDF 第 9 页）。

相对 FIFO，QSSF 在四个 Helios 集群把平均 JCT 改善 1.5 到 6.5 倍，把平均排队时间改善 4.8 到 20.2 倍（PDF 第 10 页，表 3 与正文）。具体地，Saturn 平均 JCT 从 55,984 秒降到 8,581 秒，Earth 平均排队从 13,699 秒降到 677 秒；四集群 queued jobs 数量下降 37% 到 82%（PDF 第 9 至 10 页，表 3）。短作业排队改善 9.24 到 33.51 倍，中等作业改善 2.49 到 13.39 倍，长作业仍改善 2.00 到 4.77 倍，说明优先小 GPU-time 没有在这组 trace 中牺牲长作业（PDF 第 10 页，表 4）。

对 Philly 的验证并不等价于原样迁移。由于 Philly 缺少 job name 和完整 VC 配置，作者假设 VC 在 2017 年 10 至 11 月静态不变，并随机生成与 Helios 误差分布相似的 priority。此条件下，QSSF 相比 FIFO 将平均 JCT 改善 2.3 倍、排队改善 7.3 倍，queued jobs 减少 27%（PDF 第 10 页，图 13 与表 3）。

CES 用 9 月 1 日至 21 日三周做 Helios 仿真，之前的记录用于训练。Earth 的 node utilization 从 82.1% 提升至 95.1%，增加 13.0 个百分点；Uranus 从 83.8% 提升至 96.4%，增加 12.6 个百分点。CES 每天只触发 1.1 到 2.6 次 wake-up，而只看当前负载的 vanilla DRS 平均每天触发 34.1 次。假设节点重启 5 分钟，CES 在 21 天、198K 作业中影响 251 个，vanilla DRS 影响近 6K 个（PDF 第 11 页，表 5）。按 idle DGX-1 约 800W 且制冷耗能约为服务器 2 倍的假设，四集群每年可节电超过 1.65M kWh（PDF 第 11 页）。Philly 上平均可关停 100.1 个节点，node utilization 从 69.0% 提升到 90.4%，平均每天仅唤醒 0.5 次（PDF 第 11 页，图 15 与表 5）。

数据与系统贡献

第一项贡献是 Helios trace 本身。它比当时最常用的 Philly 更新、规模更大，并同时包含 CPU 作业、四个集群、VC 和用户维度，降低调度器只在一个 2017 trace 上过拟合的风险。第二项贡献是把 characterization 与 action 连起来：日周期驱动 CES，job/user/name 的重复性驱动 QSSF，而不是分析完 CDF 后只留下一组泛化建议。

第三项贡献是一个很务实的预测目标选择。QSSF 不追求准确预测每个作业的真实完成时间，而只要求预测排序足够好；它将滚动历史与 GBDT 融合，并用 GPU time 同时表达空间和时间需求。这比假装拥有 oracle runtime 更接近生产环境。CES 也不是看到空闲就立即关机，而是用历史与未来趋势共同抑制频繁开关。

局限与外推边界

最大的边界是两个服务都通过 trace-driven simulator 评估，论文结论部分也把“在生产集群实施并评估”列为未来工作（PDF 第 12 页）。仿真没有 backfill，QSSF 不考虑 CPU、网络、显存和实际 preemption/checkpoint 开销；因此 6.5 倍是相对当时每 VC FIFO 的收益，不是相对成熟生产调度器的普遍收益。

QSSF 高度依赖 user、VC 和 job name 的稳定重复模式。新团队、自动生成名称、代码大改或工作负载分布漂移都会削弱 rolling estimate 与 GBDT；Philly 实验因缺字段而人为生成 priority，只能说明对类似误差有一定鲁棒性，不能证明跨机构即插即用。CES 的 1.65M kWh 也是基于 800W idle DGX-1 和“制冷为服务器两倍”假设的粗估，而不是电表实测节能。

trace 本身来自 2020 年、以 CV 等传统 DL 和 Pascal/Volta 为主。它不包含 LLM pipeline、H100 功耗、MoE 通信、在线生成式推理或多集群训练。后来的 Acme 结果也说明，LLM 集群的作业阶段和 GPU utilization 分布与 Helios 明显不同，不能把 Helios 的历史可预测性不加验证地移植过去。

与调度器论文的关系

这篇论文自己就是“trace study + scheduler service”的组合，也是 CSUR 综述中 ML-based timing scheduler 与 energy-aware scheduler 的代表：综述将 Helios 列为利用历史信息预测 job priority 的方法，并把 CES 归为预测未来资源利用后决定节点开关的成本优化（CSUR PDF 第 10 至 11 页）。

它与 ICCD 的关系是互补的。Helios 只有调度日志，因此优化的是队列排序、VC 不平衡和节点状态；CloudBrain-I 加入细粒度监控后，发现即使 QSSF 把卡更快分出去，作业内仍可能只有 21.24% 平均 GPU utilization。它与 Acme 的关系则是时代迁移：Helios 假设 job name 与用户历史能预测 GPU time，Acme 表明 LLM 评测可以进一步拆成模型加载、GPU inference 和 CPU metric，结构化的 stage prior 可能比单一 job runtime 更可靠。

研究背景：为什么要把画像与预测放在一起

工作负载画像通常停在“多少作业、运行多久、申请几张卡”的描述层；调度器论文则常直接假设运行时间已知或使用某个公开 trace 仿真。本文试图连接两者：先从 Helios 的重复行为中寻找可预测结构，再把这些结构做成不修改底层 Slurm 的插件服务。作业名称、用户、VC、提交时间和资源请求用于预测排序；日周期、历史节点数和节假日用于预测开关机。设计是否成立，取决于 trace 中的规律能否延续到未来，而不仅是训练集拟合误差。

Helios 的组织方式也决定了机会。每个 Virtual Cluster 有独立 FIFO 队列与固定资源边界，同组作业优先级相同，且不抢占。这个策略简单、隔离清楚，但忙 VC 即使排着大量作业，也不能立刻使用闲 VC 的卡；FIFO 还会让一个大作业挡住后续短任务。QSSF 针对队列内部排序，不解决 VC 间容量重分；CES 针对整台节点的活跃与休眠，不改变作业语义。两者都是“在已有调度器上加一个窄控制环”，不是重写完整集群管理器。

论文中的 prediction 也有两种完全不同的容错方式。QSSF 只需相对顺序大致正确：把短 GPU-time 作业排到长作业前，预测数值有偏仍可能改善队列。CES 的错误却会触发物理节点关机或唤醒，低估需求会让新作业等待五分钟启动，高估需求主要损失节能。因此 QSSF 可追求排序质量，CES 必须加入 buffer、长短窗口和低频动作来抑制风险。

Trace 方法：从调度日志能推断什么

每条 Slurm 记录包含提交、开始、结束、状态、用户、VC、资源请求和节点列表。由此可计算排队时间 Q=start-submit、运行时间 R=end-start、作业完成时间 J=end-submit=Q+R，以及 GPU time W=R*N_gpu。GPU time 同时表达空间与时间：一个一小时八卡作业的 W 与八小时单卡作业相同，适合作为“会阻挡多少卡时”的排序近似，但不代表二者 placement 难度相同。

日志无法说明已分配 GPU 是否真正执行 kernel，也看不到显存、功耗、网络、训练迭代和 checkpoint。因而论文中的 cluster utilization 是分配层面的活跃节点或 GPU 占用，不等价于硬件有效利用。一个运行八小时却忘记退出的容器会被视为长作业，一个快速失败前排队数小时的请求会显示极长 JCT。作者仍能可靠分析调度结果和请求模式，但不能从该 trace 单独诊断数据加载瓶颈或模型算子效率。

四个集群与 105 个 VC 提供了横向异质性。分析时必须区分按作业数和按资源量加权：单卡作业超过一半，却只占少量 GPU time；至少八卡作业数量不足一成，却消耗约六成资源。只看作业数量会把优化重点放到大量调试请求，只看 GPU time 又可能忽视这些短请求对用户交互体验和队列元数据的压力。论文同时报告数量、时长、等待和资源，是画像可信的关键。

QSSF 机制：历史规则与 GBDT 怎样融合

QSSF 的目标不是恢复精确运行时间，而是估计优先级。对作业 j，GBDT 使用用户、VC、GPU/CPU 请求、名称簇和日历时间预测运行量 P_M；rolling 分支从相似历史得到 P_R。两者按 lambda*P_R+(1-lambda)*P_M 融合，再乘 GPU 数 N，得到预计 GPU time 优先级 P。数值越小越先运行，因而“准最短服务优先”中的 quasi 表示它只拥有历史预测，不拥有 oracle 真值。

名称特征先用 Levenshtein 编辑距离聚类。研究者常把同一脚本以类似名称重复提交，例如只改变日期、学习率或试验编号；字符串相似度能把这些运行归入同一历史桶。对匹配桶，近期时长用指数衰减赋予更高权重，适应代码逐步变化。若是老用户的新名称，回退到该用户相同 GPU 数的历史；新用户则回退到全局相同 GPU 数均值。多级回退确保每个请求都能得到值，也意味着冷启动预测会更粗糙。

GBDT 与 rolling 的互补在于，前者能组合多维特征并泛化到未精确重复的作业，后者对同一实验的近期重复非常敏感。lambda 控制信任哪一边：名称稳定、重复多时可提高历史权重；分布变化或新作业多时模型特征更重要。论文给出框架与经验结果，但生产实现还应按用户或名称桶估计误差，动态调节权重，而非永远使用单一全局参数。

QSSF 排序例子：短时大作业为什么不一定先跑

假设队列头有三个作业。甲预测运行十分钟、申请八卡，预计 GPU time 为八十卡分钟；乙预测运行三十分钟、申请一张卡，GPU time 为三十；丙预测运行十五分钟、申请两卡，GPU time 也是三十。若只按运行时间 SJF，甲最短会先运行；QSSF 则优先乙和丙，因为它们消耗的总卡时更少，能更快释放资源给后续请求。这个例子解释公式，不是论文 trace 中的具体作业。

但 GPU time 相同也不代表调度影响相同。乙只需一个碎片节点，丙需要同时找到两卡；甲的八卡可能刚好占满整节点，placement 反而简单。QSSF 所在模拟器只考虑瓶颈 GPU 且没有 backfill，优先级变化的收益会被放大：FIFO 中大作业等待足够卡时会阻挡后续作业，而现实 backfill 可让不推迟队头预约的小作业先跑。因此与成熟 Slurm backfill 比较是落地前必须补的实验。

预测错误也会改变排序。若甲实际只需一分钟而模型预测十分钟，它本应是八卡分钟的优先作业，却被排后；若乙实际要十小时，低估会造成新的队头阻塞。因为系统不抢占，错误一旦让长作业启动，就不能立即修正。可行扩展是对高不确定预测使用保守分位数、设置短试运行后更新估计，或允许 checkpoint 作业有限抢占，但这些都不属于论文原方案。

表 4 中短、中、长作业等待都改善，说明在 2020 Helios 的实际重复模式下，没有观察到长作业被全面牺牲。不过平均改善不能证明不存在个体饥饿。评价时应增加最长等待、slowdown 高分位、按用户分组的变化，并对等待过久作业加入 aging。否则预测型最短优先可能持续把新到小任务插到一个被高估的大任务之前。

CES 机制：为何不能看到空闲就关机

CES 预测未来运行节点需求，底层 Dynamic Resource Sleep 执行节点电源状态变化。GBDT 特征包含小时、星期、日期、节假日、多窗口活跃节点均值和标准差，以及不同时间尺度 lag。日历变量捕捉人类提交周期，rolling 变量捕捉近期趋势，lag 变量表达同一时间段的重复性。Earth 上约 3.6% SMAPE 表明聚合节点数比单作业时长更平滑、更容易预测。

系统对扩容和缩容采用不对称策略。新作业到达发现活跃节点不足时，立即唤醒预测缺口再加 buffer；缩容则约每十分钟检查一次，并同时要求过去约一小时和未来约三小时都显示需求下降，才把活跃节点降到当前运行量加 buffer。这样避免在午餐前的短暂低谷立刻关机，又在晚间持续下降时逐步休眠。五分钟启动时间会伤害突然到达的作业，所以 buffer 是用少量待机能耗购买响应保险。

举例说，当前有一百台活跃节点、八十台运行，过去窗口均值持续下降，模型预测未来三小时只需七十五台，buffer 为十台。CES 可把目标设为九十台而不是七十五台：八十台承担现有作业，十台应对误差。若下一请求需要十五台，系统先使用十台余量，同时唤醒至少五台。若只看当前负载直接降到八十台，任何新请求都会等待启动；这解释 vanilla DRS 每天约 34.1 次唤醒，而 CES 仅 1.1 到 2.6 次。

节能估计必须区分 node utilization 与 GPU 有效利用。关掉没有运行作业的整机确实能省待机电，但把活跃节点从 82.1% 提到 95.1% 只是减少开机空节点，不保证运行节点上的 GPU kernel 更忙。每年 1.65M kWh 又使用 800W idle DGX-1 与制冷两倍假设，属于容量级估算。真实部署应采集机柜电表、PUE、启动能耗和硬件寿命影响。

Trace-driven simulation：如何构造反事实

仿真重放九月每个作业的原始到达时刻、资源请求和真实运行时，再用不同排序规则决定何时开始。FIFO 使用生产顺序，QSSF 只知道模型预测，理想 SJF/SRTF 则读取真实运行时，作为不可部署的上界。由于调度策略改变了开始时间，但仿真假设作业运行时不受 placement、并发、数据缓存或网络争用影响，反事实成立的前提是运行时对调度环境相对稳定。

取消和失败作业也需要一致处理。若使用 trace 中原始运行时和结束状态，改变排队时间后仍假设用户在相同运行阶段取消，相当于取消原因只与执行进度有关；若用户按墙钟时间手动取消，反事实会不同。论文模拟器复现 arrival、queue、run 和结束状态，但公开结果不足以回答所有行为因果。复现时应明确取消时刻是相对提交、相对启动还是按已运行时间定义，并做敏感性分析。

CES 仿真同样假设未来节点需求可由原 trace 的运行集合推导。若关闭节点导致作业等待，这些延迟又可能改变后续运行节点曲线，形成反馈；算法用启动延迟和受影响作业数量衡量代价，但真实系统还会有节点健康检查、镜像缓存、分布式 rendezvous 和文件系统重连。模拟结果适合作为上线前的容量预测，不能替代小规模影子控制和逐步放量。

部署控制环：模型更新、漂移和安全回退

Model Update Engine 应保留训练窗口、特征版本、误差分布和上线时间。QSSF 可按周或在排序误差上升时更新，CES 可按季节、节假日和项目周期更新。模型更新不能直接覆盖生产版本，应先用最近 trace 做离线回放，再以影子模式生成但不执行优先级或关机动作，比较它与现网决策。通过阈值后逐个 VC 或少量节点启用。

分布漂移的信号包括新用户比例上升、名称桶匹配率下降、预测 GPU time 与实际偏差变大、活跃节点 SMAPE 连续超阈值。QSSF 漂移时可以退回 FIFO 或只对高置信重复作业重排；CES 漂移时应扩大 buffer、暂停缩容但保留按需唤醒。两种回退都能在不改底层 Slurm 的情况下实现，符合论文插件式框架的价值。

安全与公平也需要治理。用户可能通过作业名称影响预测桶，或者把大作业拆成多个看似短小任务争取优先级；历史上常运行短任务的用户也可能因此持续优先。系统应限制可操纵特征的权重，记录每次排序理由，加入等待 aging 和租户份额约束。节能控制则要排除维护、保留或硬件异常节点，确保不会把关机动作误用于正在做后台数据服务的机器。

失败与取消作业：从画像到快速反馈通道

GPU 作业只有 62.4% 完成，22.1% 取消、15.5% 失败，而 CPU 作业完成率达到 90.9%。失败任务通常启动后很快退出，却可能先在 FIFO 中等待很久。这类作业的用户价值几乎全在“尽快暴露错误”：如果环境、路径、显存或参数配置有问题，让它排队数小时不会节省 GPU，只会延迟修复。QSSF 可能因为历史短时长把它们提前，但论文没有专门预测失败。

可部署的扩展可设置小规模验证通道。新作业先在一张卡或最小合法拓扑上执行短 preflight，检查镜像、数据、CUDA 可见性、模型能否装入和首个迭代是否成功；验证通过后再进入正式多卡队列。它与普通 profiling 的区别是目标不在预测完整运行时，而在快速排除必然失败。若作业需要完整卡数才能初始化，仍可设置较短启动租约，并在无训练进度时及时释放。

取消则不一定是错误。大于 64 卡作业取消率约 70%，可能因为研究者观察到模型不收敛后主动 early stop，也可能因为长作业更容易遭遇业务变化。trace 只有结束状态，无法区分理性停止、系统故障和用户不耐烦。若预测模型把所有取消作业的短运行时当作未来完成时长，会低估同类成功训练的成本。训练数据应把完成、失败和取消分开建模，至少在 rolling estimate 中只用语义一致的历史。

评价快速反馈通道应报告错误发现时间、额外验证 GPU-time、误判成功作业比例和正式队列 JCT，而不是只看失败作业提前多少。对 CES 还要确保 preflight 的短脉冲不会导致频繁唤醒：可以集中到少量常开节点，验证通过后再唤醒大规模训练容量。这样，作业级可靠性与节点级节能不会互相抵消。

复现清单与最终结论

1. 清洗 Slurm 或 Kubernetes 日志，统一提交、开始、结束和状态语义，按作业数与 GPU-time 两种权重重做时长、规模、失败、用户和队列分布。
2. 按时间切分训练与测试，禁止随机打乱未来信息；实现名称聚类、多级回退、rolling estimate 和 GBDT，分别报告数值误差、排序相关性及冷启动覆盖率。
3. 在同一仿真器比较 FIFO、启用 backfill 的现网基线、QSSF、oracle SJF 和 SRTF；报告平均与尾部 JCT、排队、slowdown、饥饿和分租户结果。
4. 对 CES 回放多个季节，扫描 buffer、检查周期、过去与未来窗口，报告节点利用率、实测能耗、开关次数、启动等待、受影响作业和预测漂移。
5. 先做影子部署，再对一个 VC 与少量节点逐步启用；任何模型异常都能回退到原 FIFO 和全节点活跃状态。

生产 trace 中的重复性可以服务两个层次的控制：作业级历史帮助调整队列顺序，集群级周期帮助减少空节点能耗。QSSF 的 1.5 至 6.5 倍 JCT 改善以没有 backfill 的每 VC FIFO 为基线，CES 的节电量则依赖功耗假设；两者都是离线反事实结果，不是已经测得的生产收益。迁移到现代 inference 或 LLM 集群前，需要重新验证特征稳定性、阶段结构和功耗模型。这里的结论并不是 GBDT 普遍优于其他模型，重点在于怎样把历史规律接入可回退的控制策略。