Papers

待读论文 · 自包含完整解释

UniSched: A Unified Scheduler for Deep Learning Training Jobs with Different User Demands

多类用户需求、收益建模、lease MILP 和拓扑放置

论文：IEEE TC 2024 PDF

本文目录 · 21 节
  1. UniSched 统一了哪些需求
  2. 问题背景
  3. 核心设计与调度流程
  4. 关键机制
  5. 1. 三部分 Estimator 覆盖不同 stopping criteria 与抢占开销
  6. 2. Reward 把四类 job 放进同一目标
  7. 3. Lease-based MILP 联合选择时间与空间
  8. 4. Cell-based policy 同时考虑 GPU 数与拓扑
  9. 实验设置与准确数字
  10. 方法贡献
  11. 局限与适用边界
  12. 部署适用性完整判定：哪些集群能直接受益
  13. 与其他绿色论文的技术关系
  14. 从用户需求到数学目标：统一不是混在一起
  15. 必要前置知识：为什么普通队列规则不够
  16. 一次调度轮次的完整例子
  17. 估计误差怎样传到调度决策
  18. 消融与敏感性：改善究竟从哪里来
  19. 如何正确解读端到端实验
  20. 实现与复现：从论文到可核对结果
  21. 实际系统中的组件与状态流

UniSched 统一了哪些需求

UniSched 扩展了 CHRONUS，同时支持 strict/soft SLO 与 best-effort，也支持 iteration-based 和 performance-based stopping。统一 reward 与 MILP 共同处理作业选择、profiling、lease 分配和 topology-aware placement。

问题背景

共享 GPU 集群里的 job 至少有两个正交维度。延迟需求上，有必须在 deadline 前完成的 SLO job，也有越快越好的 best-effort job；停止条件上，有固定 iteration，也有达到 accuracy、mAP、F1 或 loss 目标就停的 performance-based job（PDF pp.1-3，Table I 与 Sec. II-A）。现有 scheduler 往往只覆盖其中一格。

只按用户给出的最大 iteration 估时会浪费资源。作者在多组模型/数据集上比较发现，按最大 accuracy 停止最多可少训练 22% epochs，按最大 accuracy 的 99% 停止最多可少 31% epochs（PDF p.3，Fig. 1）。另一方面，允许抢占虽能提高 SLO 可行性，却增加 checkpoint、suspend、resume 开销；忽略这部分会让 solver 以为某个 deadline 可达，实际却 miss。

CHRONUS 已能混排 SLO 与 best-effort，但 profiling、SLO 和 best-effort 分别使用资源预留、SRTF 与 MILP，且只支持 iteration-based stopping。它还用 round-up 强制 consolidated placement，可能因为一个 6-GPU job 占满 8-GPU node 而拒绝更多可行组合。UniSched 的目标就是把这些 ad hoc 分支压成同一套可求解模型。

核心设计与调度流程

新 job 先作为 profiler job 进入 Selector。Reward Generator 给它 reward，Policy Generator 枚举可行 GPU cell 组合，MILP 决定何时给最多 1-2 GPUs 做 profiling。Estimator 用约 5 分钟 profile 估计每 iteration 时间、性能达到目标所需 iteration，以及未来 suspend/resume 的期望开销（PDF pp.4-6，Fig. 2）。

Profiling 完成后，job 按用户需求进入 SLO 或 best-effort queue，但仍走同一条 Selector 路径。每个 job 被切成 lease；Reward Generator 把 profiler、best-effort、strict SLO、soft SLO 的完成时间偏好都映射到 0-100 的 step reward；Policy Generator 用层次化 GPU cells 表达 placement topology；MILP 最大化全体 reward，在每轮同时决定续哪些 lease、选哪些 job、采用哪种 cell allocation（PDF pp.6-8，Fig. 4-5 与 Eq. 4-14）。

关键机制

1. 三部分 Estimator 覆盖不同 stopping criteria 与抢占开销

Runtime Speed Estimator 对单卡 job 直接测 computation time；对多卡 job 分别用同节点两卡和跨节点两卡测 intra-/inter-node gradient communication，再近似外推任意 GPU 数下的 iteration time（PDF p.5，Eq. 2）。Profiling 最多只用 2 GPUs，避免大 job 在估时阶段先占满资源。

Training Iteration Estimator 对 performance-based job 使用 Weibull、log-power 等 probabilistic learning curve ensemble，从早期 validation metric 外推达到目标所需 iteration。由于 profiling 阶段样本少且 batch size 可能不同，系统在正式执行中继续更新曲线，而不是冻结首次预测（PDF p.5，Sec. III-B2）。

SR-Aware Estimator 把 suspend/resume 发生次数看成随机变量。对需要 n 个 lease、deadline 有 m 个 lease slot 的 SLO job，按组合概率计算期望 resume 次数；best-effort job 则按每个 lease 有 1/2 概率被切断近似（PDF p.6，Eq. 3）。实测各模型 suspension 通常在 4 秒内，resume 明显更贵；VGG19 从 2-GPU profile 外推到 16-GPU execution 时，组合开销差在 5 秒内（PDF p.6，Fig. 3）。

2. Reward 把四类 job 放进同一目标

Profiler job 需要尽快完成但不能压过 SLO，固定 reward 为 1；best-effort reward 与 estimated remaining time 成反比，等价于偏向短剩余作业；strict SLO 在 deadline 前 reward 为 100，错过后骤降；soft SLO 可有多个 deadline 和逐级下降的 reward（PDF pp.6-7，Fig. 5）。论文用 1:100 的量级隔开 non-SLO 与 SLO，避免 profiler/best-effort 抢走维持 deadline 必需的 GPU。

这个统一并不等于“所有用户偏好都被正确量化”。作者明确承认 reward scale 没有唯一答案：SLO reward 太高会让用户不愿提交 best-effort，太低又会诱导 solver 牺牲 deadline（PDF p.7，Sec. III-C2）。创新是给出统一接口与可优化表达，不是解决价值权重本身。

3. Lease-based MILP 联合选择时间与空间

Best-effort/profiler lease 固定 5 分钟，SLO lease 经验设为 10 分钟；SLO lease 长度必须是 BE lease 的整数倍（PDF pp.6,8，Fig. 4 与 Sec. III-C4）。短 lease 增加 preemption overhead，长 lease 降低重排机会。MILP 用二元变量表示 job 是否获得第 k 个 lease、是否命中某个 soft deadline、是否选择某个 allocation policy，并最大化总 reward（PDF pp.7-8，Eq. 4-13）。

若本轮 solver 未及时返回，系统先复用上一轮缓存方案缩小搜索和执行停顿，再重新调用 solver（PDF p.8，Sec. III-C4）。这种 fallback 很实际：lease 调度不能因为求最优解而让所有 GPU 等 solver。

4. Cell-based policy 同时考虑 GPU 数与拓扑

Policy Generator 借用 HiveD 的 buddy cell，把 1、2、4、8 GPU node 抽象成层级 cell。一个 6-GPU job 不只有“6”这一种表示，还可选择跨不同 cell 的组合；Estimator 给每个组合估 throughput，MILP 在 deadline 可行性与 consolidated placement 之间选择（PDF p.7，Sec. III-C3）。枚举只用于请求不超过 16 GPUs 的 job，以限制组合数。

这解决了 CHRONUS 的 round-up 问题：SLO 不紧时可以让某个 SLO job 使用稍分散、稍慢的 placement，把完整 node 留给 best-effort 或另一个紧急 SLO；deadline 紧时仍可选择 consolidated cell。job selection 与 placement 因而不再先后割裂。

实验设置与准确数字

模拟器有 11,978 行 Python，UniSched policy 另有 1,113 行，使用 Gurobi 9.1。Kubernetes prototype 包含 watcher、controller、scheduler，watcher 每 5 分钟汇报 validation metric 和 runtime speed（PDF pp.8-9，Sec. IV-A）。大规模模拟使用 Helios 与 Philly trace，集群 C120/C96 分别有 120/96 个八卡节点，即 960/768 GPUs（PDF p.9，Sec. IV-B）。

Strict SLO deadline 从 [1.1, 2.0] x job duration 随机生成；soft SLO 的首个 deadline 同样生成，后续 deadline 为首个的 1.1、1.2、1.5 倍，对应 reward 80、50、20。Iteration-based 与 performance-based job 占 80% 与 20%（PDF p.9，Sec. IV-B）。六种 workload 分别为全 strict SLO、strict SLO + best-effort、strict/soft SLO + best-effort，在 Helios 和 Philly 上各一套。

物理实验使用 16 个四卡 V100-32GB 节点，共 64 GPUs；每节点还有 64 CPU cores、256GB 内存和 200Gbps HDR InfiniBand，软件为 Kubernetes 1.18.2 与 CephFS 14.2.8（PDF p.10，Sec. V-A）。模型包括 ResNet18/50、MobileNetV2、VGG19、BERT，数据集为 CIFAR-10、ImageNet、WikiText-2。T[360] 与 T[720] 两种八小时提交负载下，模拟器和原型的 weighted deadline miss rate 差异最多 2.57%，average JCT 相对差异最多 5.38%（PDF p.10，Table III）。

端到端仿真中，UniSched 相比 deadline-aware baselines 在纯 SLO workload 上将 weighted deadline miss rate 降低 1.17-4.82 倍；mixed workload 的论文原文范围是 0.95-2.77 倍，其中下界 0.95 倍意味着个别配置并未改善，不能笼统写成“全部降低”；相比普通 DL schedulers 则降低 2.01-6.84 倍（PDF p.10，Fig. 6a）。Best-effort average JCT 相比全部 baselines 降低 1.18-4.02 倍，其中相对普通 DL schedulers 为 1.18-3.11 倍，相对 deadline-aware schedulers 为 1.66-4.02 倍（PDF p.10，Fig. 6b）。

Estimator 的平均 runtime-speed 预测误差在不同 GPU 数下小于 5%，但 BERT/local batch 12 在 16 GPUs 时误差达到 16.3%；执行中段的整体 duration 平均误差仍在 10% 内（PDF pp.11-12，Fig. 7）。统一 profiling 将最长 pending time 从 2,105 秒降到 840 秒；training-iteration estimator 让 weighted deadline miss rate 再降 0.7%-5.1%（PDF p.12，Fig. 9a-b）。Solver 在随 cluster scale 增长的实验中最大延迟小于 10 秒（PDF p.13，Fig. 10d）。

方法贡献

UniSched 把原来分别处理的四组问题放进同一资源-时间模型：profiling 与正式执行、SLO 与 best-effort、固定 iteration 与目标性能停止、job selection 与 topology-aware placement。Reward 表达用户需求，Estimator 估算 duration，cell policy 编码 topology，lease 把连续时间离散化，最后交给一个 MILP 联合求解。相比 CHRONUS，这套模型更容易扩展新 job type，也减少了多个独立策略之间的冲突。

局限与适用边界

部署适用性完整判定：哪些集群能直接受益

UniSched 最适合同时存在三种现象的集群：一是 SLO 与 best-effort 真实共享同一 GPU 池；二是作业可在不同 GPU 数上运行，且拓扑会明显影响 throughput；三是部分作业的真实停止条件是目标精度或 loss，而不是固定 iteration。在这种环境中，原有的独立队列、固定 profiling 份额和先排序后放置容易相互冲突，统一优化才有明确价值。

如果集群已按租户或业务将 SLO 和 best-effort 物理隔离，或所有作业都是不可抢占的固定卡数 gang job，UniSched 的大部分设计会退化为更复杂的装箱器。同样，小型集群中若只有少量长作业，MILP 的全局联合决策可能不比简单 earliest-deadline-first 加人工保留更值得。部署前应先用历史 trace 计算作业类型比例、卡数可伸缩范围、跨节点减速和抢占成本，再决定是否需要完整系统。

论文假设每个作业至少能在一张 GPU 上放下一个样本，主要执行 data parallel 与 all-reduce。对需要 tensor parallel 才能装入的大模型，“GPU 数”不再是可自由变化的单一维度；tensor、pipeline、data parallel 的组合决定内存可行性、每阶段计算和通信。此时 Policy Generator 需要枚举并行计划，Estimator 需要成为多维性能模型，原文的两卡通信外推不足以支撑可行性判断。

生产环境还要有可信的用户需求输入。如果用户可以无成本地把所有作业标成 strict SLO，固定的一百对一 reward 量级会激励虚报，最后每个作业都变成“紧急”。因此 operator 需要在调度器之上补充配额、付费等级、租户公平性或 SLO 准入控制。UniSched 解决的是已给定 reward 后如何联合分配，它没有证明 reward 由谁设置、用户是否诚实以及多租户之间的长期公平性。

最稳妥的引入方式是先做 shadow scheduling：保留现有调度器真正下发决策，同时让 UniSched 用同一到达流生成不执行的方案。用真实执行时间回放两组方案，检查 SLO 可行性、JCT、GPU 空洞、抢占次数和 solver 超时率。只有当估计误差、缓存 fallback 和 checkpoint 开销在本地负载下可控，才应逐步将小比例 best-effort 作业交给新调度器，最后再接管 strict SLO。

运维面的成功标准也不应只是平均值，尾部风险同样决定用户体验。需要按作业类型和租户分组观察 deadline miss 与 JCT 分位数，检查少数长作业是否被持续抢占，并为求解超时、预测突变、checkpoint 失败设置独立告警。若只监控整体 GPU 利用率，就可能在表面利用率上升时遗漏某类用户的服务恶化。这也是论文同时报告 SLO 与 best-effort 指标的工程含义。上线后还应保留旧调度器的紧急切换开关，并定期重放最差的超时作业，判断根因究竟是收益权重、速度估计、拓扑建模，还是集群故障。

与其他绿色论文的技术关系

从用户需求到数学目标：统一不是混在一起

UniSched 首先把每个作业的自然语言需求翻译成一条“完成时间→收益”曲线。对 strict SLO 作业，截止时间之前完成的收益保持在高位，超时后立即跌落；对 soft SLO 作业，多个截止点对应多个递减台阶，因此延迟一小段不会被当成与延迟很久完全相同。best-effort 作业没有截止点，其收益随估计剩余时间增大而减小，实际上将短作业优先的偏好写入目标。profiler 作业则得到低但正的固定收益，保证新作业不会永远等不到建模机会，同时又不会为了做 profile 而挤掉紧急 SLO。

统一的关键在于这些曲线最后都可被 MILP 计算，而不是要求四种作业共享同一个排序规则。每个作业在每个 lease 上都有二元决策：此时段是否运行、选哪个 GPU-cell 方案、在哪个截止台阶前完成。约束保证单个作业不会同时选多个 placement，每个时段的 GPU 占用不超过集群容量，且作业得到的 lease 总量足以覆盖其预测运行时间。目标函数对所有作业的完成收益求和。于是“该不该现在跑”、“用几张卡”和“卡放在哪些节点”成为同一个问题，避免先排优先级、后做放置时两个阶段互相推翻。

它仍然是离散时间近似，不是连续时间的真实最优解。lease 越短，模型越接近真实到达和完成时刻，但二元变量、求解时间与抢占次数也会增加；lease 越长，求解稳定但一个紧急作业可能要等到下一轮才能获得资源。论文设定的五分钟 best-effort lease 和十分钟 SLO lease 是经验折中，并不是从目标函数中推导出的普适常数。

必要前置知识：为什么普通队列规则不够

分布式数据并行训练会在多张 GPU 上复制模型，每张卡计算一部分 mini-batch，再通过 all-reduce 聚合梯度。增加 GPU 数不会线性缩短每步时间：计算量被分摊，但同步与通信增加，跨节点网络又比节点内互联慢。所以“分配几张 GPU”和“这些 GPU 在哪里”不能只用一个整数表示。同样是八张卡，单节点八卡、两节点各四卡、四节点各两卡的 throughput 可能完全不同。

训练作业也不是普通无状态任务。被抢占时，它需要将模型、优化器动量、学习率调度器和当前 iteration 写入 checkpoint；恢复时又要从共享存储读取并重建分布式进程组。suspend 和 resume 不仅消耗时间，还可能在存储上形成短时间峰值。调度器若每一轮都把作业换来换去，纸面 GPU 利用率可能很高，但实际完成时间反而变差。UniSched 因此用 lease 限制重排边界，并把预期 suspend/resume 时间加入 duration 估计。

SLO 与 best-effort 的冲突不能用单纯的 FIFO 解决。FIFO 保护到达顺序，但早到的超长作业可能让后到且很短的作业等待数小时；最短作业优先能降低平均 JCT，却可能让长作业饥饿，也不知道哪个 deadline 已逼近；最早 deadline 优先又会在资源需求不同、GPU 可伸缩且布局影响速度时遇到装箱问题。CHRONUS 已将 SLO 和 best-effort 放进同一集群，但它为 profile、SLO、best-effort 使用分开规则，且假设所有作业按固定 iteration 停止。UniSched 解决的正是这些规则之间没有共享目标的问题。

performance-based stopping 是最容易被忽略的第四个概念。用户可能写了最多一百个 epoch，但真实需求是 validation accuracy 达到某值就停止。如果调度器按一百个 epoch 保留资源，它会系统性高估这类作业的工作量；如果盲目按早期精度线性外推，又会忽略学习曲线逐渐饱和的形状。论文用 Weibull、log-power 等概率曲线组合来外推，且在执行中持续更新；它预测的是“还有多少 iteration 达到目标”，而不是预测最终模型的质量。

一次调度轮次的完整例子

假设集群剩余八张 GPU，队列中有三个作业。作业 A 是 strict SLO，还需要三个 SLO lease，而离 deadline 只有四个时段；作业 B 是 best-effort，剩余时间很短，两个 lease 就可完成；作业 C 刚到达，只需一到两张 GPU 做五分钟 profile。若只按短作业优先，B 会先占满资源，A 随后可能已无法在 deadline 前获得三段运行时间；若只按 SLO 优先，A 会被过度集中到整个八卡节点，B 和 C 都不得不等待。

UniSched 首先让 Estimator 为 A 生成多个 cell policy。一个方案是四张同节点 GPU，通信快、每个 lease 完成的 iteration 多；另一个方案是分散的四卡，通信稍慢，但能留出一个完整 cell 给其他作业。求解器计算发现，A 使用分散方案仍能在四个时段内完成，那么它可以在前三段续租四卡；B 在当前轮获得另外两卡，快速完成后释放；C 在剩余两卡上做 profile。这个解同时保留 A 的高额 SLO reward、获得 B 的短作业 reward，也获得 C 的低额 profiler reward。

下一轮不会照抄原计划。B 若已完成，其变量从模型中移除；C 的 profile 已经产生真实 iteration speed 和 learning-curve 观测，Estimator 更新预测；A 的实际速度若比预测慢，剩余 lease 数会上调。MILP 再以新状态求解。如果求解器在调度时限内没有返回，系统沿用上一轮可行方案，避免 GPU 空转。UniSched 因此是在 lease 边界用最新测量反复修正有限时域计划，不试图一次排出全局完美时间表。

估计误差怎样传到调度决策

系统需要的不只是每步运行时间。对 iteration-based 作业，剩余时间约等于剩余 iteration 数乘以预测每步时间，再加上预期 suspend/resume 开销。对 performance-based 作业，还要先由学习曲线外推出达到目标指标所需的 iteration 数。因此误差有三层：通信与计算速度外推误差、目标指标达到时刻误差、抢占次数与恢复时间误差。任何一层低估都会让 MILP 为 SLO 留出的 lease 过少，高估则会提前占用 GPU，延长 best-effort JCT。

论文不把 profile 预测当作一次性真值。作业进入正式训练后，watcher 每五分钟上报真实 runtime speed 和 validation metric，Estimator 据此重算剩余时间。这种闭环使早期误差不至于贯穿全部运行期，但它不能消除短 lease 内的突发抖动。例如共享存储突然拥塞，当前五分钟内的速度下降要到下次上报后才会反映到新方案中。

实验中“平均速度误差小于百分之五”不应被解释为所有模型、卡数和 batch 组合都精确。BERT 在十六卡与特定 local batch 下出现百分之十六点三的误差，说明两卡 profile 对更大并行度的通信拓展不总是线性。论文最有意义的结论是：即使局部配置有明显偏差，执行中的持续更新仍将整体 duration 的平均误差控制在百分之十以内。这是一个调度系统的闭环鲁棒性结果，不是通用性能模型的精度保证。

消融与敏感性：改善究竟从哪里来

端到端数字只能说明整套系统比 baseline 更好，不能区分是预测、reward、lease 还是 placement 起作用。论文的消融给出三个可分开理解的信号。第一，将 profiler 也纳入统一 reward 和 MILP，而不是固定保留资源，最长 profiling pending time 从两千一百零五秒降到八百四十秒。这说明固定 profile 配额在到达率变化时既可能空置，也可能成为瓶颈；动态决策让 profiler 与正式作业用同一容量约束竞争。

第二，training-iteration estimator 将 weighted deadline miss rate 额外降低百分之零点七到百分之五点一。它的直接作用是不再把 performance-based 作业的最大 epoch 当作必然工作量。学习曲线预测若判断目标精度可在更早时刻达到，调度器就不会为不会执行的后续 epoch 预留 lease。但这个改善范围也说明它不是全部增益的来源：在论文设置中，八成作业仍是 iteration-based，因此统一 selection 和 placement 同样重要。

第三，cell-based policy 允许系统有条件地不集中放置。完全 consolidated placement 通常能提高单作业 throughput，但 CHRONUS 式 round-up 可能把六卡需求上舍入为整个八卡节点，留下两卡空洞。UniSched 将多个拓扑方案及其估计速度一起交给 MILP。Deadline 宽松时，求解器可接受小幅通信损失以提高集群填充率；deadline 紧张时，则选择更集中的 cell。这里不是断言分散一定更好，而是把拓扑决定留给求解器比较。

如何正确解读端到端实验

论文同时报告 weighted deadline miss rate 和 best-effort average JCT，是因为只看任何一个指标都会隐藏牺牲。调度器可以把所有 GPU 给 SLO 来降低 miss rate，但 best-effort 作业会长时间饥饿；也可以用短作业优先来降低平均 JCT，但紧急长作业会超时。UniSched 在 mixed workload 中的证据是两类指标大体同时改善：对普通 DL scheduler，weighted miss rate 降低二点零一到六点八四倍；best-effort average JCT 对全部 baseline 改善一点一八到四点零二倍。

但“零点九五到二点七七倍”的 mixed-workload deadline-aware baseline 比较必须保留原意。当比值是零点九五时，UniSched 在那个配置并没有降低 miss rate，而是略差。所以结论应该是“在多数 workload 上兼顾两类目标，且总体显著改善”，而不是“对每个 baseline 和每个 workload 都严格支配”。另外，Helios 和 Philly trace 提供作业到达和资源需求，strict/soft deadline、reward 阶梯以及 stopping-criterion 比例是作者合成添加的。实验可以证明在这些假设下的相对性能，不能直接推断某个生产集群也会得到同样倍数。

原型与模拟器的对齐实验为大规模结果提供了必要但有限的校验。在六十四张 V100 的物理集群上，两种八小时 workload 中，weighted miss rate 的模拟与原型差异最多百分之二点五七，average JCT 相对差异最多百分之五点三八。这支持模拟器能捕捉主要调度行为，却不代表它已建模所有存储、网络和框架抖动。最终数字应连同平台、trace 改造方法和模拟假设一起理解。

实现与复现：从论文到可核对结果

复现应分为“调度算法”和“分布式训练原型”两层。第一层先不启动真实 GPU 作业，实现 trace-driven simulator。输入至少包含到达时间、GPU 需求、单步时间、总 iteration 或目标性能、SLO 类型与 deadline。然后实现四类 reward 曲线、lease 时间轴、cell 枚举和 MILP 约束。用人工构造的小例子先检查三个不变式：资源从不超配、strict SLO 在可行时不被低收益作业挤掉、求解超时后缓存方案仍可执行。

第二步才重建论文 workload。对 Helios 和 Philly trace 分别建立 C120 与 C96 的八卡节点集群，保留作业到达和 GPU 数分布；按论文规则生成 deadline，将作业分成百分之八十 iteration-based 与百分之二十 performance-based，构造六类 workload。指标必须同时输出 weighted deadline miss rate、best-effort average JCT、profiling pending time、solver latency 和 GPU utilization，并使用相同输入运行 CHRONUS 及其他 baseline。只比较利用率不足以验证论文的用户需求主张。

第三步是参数与消融。分别关闭 training-iteration estimator、将 profiler 恢复为固定资源保留、将 cell policy 恢复为 round-up consolidated placement，验证完整系统的改善不是来自某个未公平调优的默认参数。对 lease 时长、SLO 与 non-SLO reward 比例、profile 卡数、solver time limit 做敏感性扫描。每次扫描不仅记录目标指标，还要记录抢占次数、checkpoint/resume 开销与求解时间，因为过短 lease 可能在模拟中表现很好，却在真实系统中被恢复成本抵消。

最后是 Kubernetes 原型。watcher 定期获取 validation metric 和 runtime speed，controller 管理 job 状态、checkpoint 与 lease，scheduler 调用 Estimator、Reward Generator、Policy Generator 和求解器。复现者需要固定 Kubernetes、分布式文件系统、CUDA、训练框架和 Gurobi 版本，并单独校验 suspend 与 resume 时间。若没有与论文一样的 V100 集群，仍可先复现相对趋势，但不应要求速度误差、solver latency 和 JCT 倍数与原文完全一致。

实际系统中的组件与状态流

一个新作业提交后先进入 profiler 状态，而不是直接参与正式训练排队。Selector 为它分配一个低收益候选项，Policy Generator 只生成一到两卡的 profile 方案。得到 lease 后，运行时记录单卡计算时间、同节点两卡通信与跨节点两卡通信，同时收集早期 validation metric。Runtime Speed Estimator 将这些测量外推到候选 GPU 数和 cell 拓扑，Training Iteration Estimator 决定 performance-based 作业的预测停止点，SR-Aware Estimator 再补上调度期间可能发生的 checkpoint 与恢复时间。三者合成每个候选 placement 的 duration。

作业转入正式队列后，Reward Generator 根据用户类型生成完成时间收益，Policy Generator 从 buddy-cell 层次结构枚举资源方案。这里的 cell 不是实际 Kubernetes 对象，而是求解器可以理解的层次资源块：一卡块合并成两卡块，再合并成四卡和八卡块。一个六卡请求可以表示为四卡加两卡，而不必被简化成占用整个八卡块。每个方案都带有估计速度和需要的 lease 数，MILP 才能在单作业加速与集群整体填充率之间比较。

求解结果下发后，controller 不是无条件杀死未被选中的进程。已获得当前 lease 的作业运行到边界；需要续租且再次被选中的作业继续运行；未续租的作业先保存 checkpoint，再释放 GPU。watcher 报告的实际进度会更新作业状态，完成作业从下一个 MILP 删除。这种设计使求解器不需要持有运行时真实状态：它只产生下一个时域的离散计划，状态一致性由 watcher 与 controller 维护。

三类故障语义需要区分。第一类是求解器超时，系统可继续执行缓存方案；第二类是预测偏差，系统在下次测量后更新剩余时间，但紧急 SLO 仍可能因前期低估而变得不可行；第三类是节点、存储或作业失败，论文的主要模型没有把这些可靠性事件写入 MILP。因此实际部署仍需要 Kubernetes 重试、checkpoint 完整性检查、节点健康管理和超时后的 admission control。UniSched 是调度决策层，并不取代集群控制面的容错机制。评估时还要把求解器降级、预测更新和运行时重试分开记录，否则故障成本会被平均指标掩盖。