CHRONUS：把 deadline 变成可分配的 lease 时间表

论文：Chronus: A Novel Deadline-aware Scheduler for Deep Learning Training Jobs

CHRONUS 怎样分配期限

CHRONUS 面向混合负载。调度器先判断哪些 SLO 可以保证，再用离散 lease 和 MILP 安排这些作业未来在哪些时间片运行；剩余资源留给 best-effort 作业。

问题背景

已有 DL 调度器通常优化吞吐、JCT 或公平，却不直接保证完成期限；传统大数据 deadline 调度又没有利用 DLT 作业的三个特征：迭代过程可预测、checkpoint 后可抢占、性能强依赖 GPU placement。论文的用户调查也说明问题不是“所有 deadline 都绝对刚性”：103 名参与者中，超过 60% 会提交带完成时间预期的训练作业，96% 提交过 best-effort 试错作业；约 3%、12%、21%、22% 的参与者分别可接受 0%、5%、10%、20% 的 deadline 延迟。与此同时，近 80% 的人估计作业完成时间时至少有 10% 误差，40% 的人至少有 25% 误差（PDF 第 3 页）。因此 scheduler 既不能完全相信用户报时，也不能只做 strict deadline 的二元判断。

调度模型与完整流程

CHRONUS 把集群逻辑划成 Profiling、Guaranteed、Spot 三部分，容量随负载变化。完整路径如下（PDF 第 4 页，图 1）：

1. 用户提交 GPU demand、训练迭代数和 deadline。Profiler 以 FCFS 运行作业一个固定窗口：短作业和故障作业可能直接在 profiling 阶段结束；长作业则测出单次迭代时间。
2. 对多节点作业，Profiler 最多只使用一节点和两节点各测一次。若单节点迭代时间为 t1 = tc，两节点为 t2 = tc + to，则估计 n 节点时间为 tn = t1 + log2(n)(t2 - t1)，避免按原规模占用大量 profiling GPU（PDF 第 4-5 页）。
3. Admission control 调 MILP 检查 SLO 是否存在可行安排。可行作业进入 guaranteed SLO queue；不可行作业会被明确告知无法保证，并降入 best-effort queue（PDF 第 5 页）。
4. Selector 把每个长作业切成固定长度 lease。对 guaranteed SLO 作业，MILP 用二元变量表示“作业是否取得第 k 个 lease”，在每个时间片不超集群容量的约束下，最大化所有作业的 deadline reward；strict SLO 的 reward 从按时完成时的 100 跌到逾期后的 1，soft SLO 则随延迟分段下降（PDF 第 5-6 页，图 3、式 1-5）。
5. Guaranteed cluster 采用 20 分钟 SLO lease；Spot cluster 对 best-effort 与 unguaranteed SLO 使用 SRTF 和 300 秒 BE lease。SLO 作业提前结束后，空出的资源会在下一次 BE cycle 转入 Spot cluster（PDF 第 6 页）。
6. Allocator 再把“何时运行”变成“放在哪些 GPU 上”。Guaranteed 作业优先 consolidated placement；不利于整齐装箱的 GPU demand 会向 {1, 2, 4, 8n} 上取整，确保存在紧凑放置。Spot 中的小作业则按 placement sensitivity 排序，只对搜索空间阈值内最敏感的前 K 个作业穷举，其他作业 quasi-consolidate；实现中的搜索空间阈值是 100,000（PDF 第 7、10 页，式 6-8、算法 1）。
7. lease 到期后，controller 触发 checkpoint，scheduler 根据新一轮结果续租或抢占。若 MILP 本轮超时，则从上一轮缓存解开始缩小搜索空间（PDF 第 6、11 页）。

关键机制

1. 两节点 profiling。 它利用数据并行 AllReduce 的简化通信模型外推任意节点规模，核心价值是把“为了做 deadline 决策先占满用户要求的 GPU”变成最多两节点的测量。但它成立的前提也很强：通信时间需大致符合 log2(n)，且论文不处理 model parallelism。

2. lease-based MILP。 连续运行时间被离散成多个可抢占 lease 后，MILP 可以把同一作业的执行片段放到 deadline 之前不同位置，搜索空间比不可抢占排程更灵活。15-30 分钟的 SLO lease 在实验中最好，论文最终取 20 分钟；短于 10 分钟会因抢占过频增加 miss，过长则失去重排机会（PDF 第 9 页，图 7a）。

3. strict/soft SLO 的统一 reward。 deadline 不再只是硬约束，而是一个 1 到 100 的分段 reward 函数。Admission control 先剔除根本不可保证的请求，MILP 再在可行作业间最大化总 reward，避免一个不合理 SLO 拖垮其他作业。

4. placement-aware allocation。 Selector 只决定 GPU 数和时间还不够；若实际 GPU 分散到更多节点，profiling 得到的速度就会失真。Round-up 用少量资源冗余换 guaranteed 作业的 topology 可实现性，local search 则在 Spot cluster 中权衡碎片与速度。

实验设置与准确数字

• 模拟使用两条真实 trace：Helios 对应 96 节点、每节点 8 GPU 的 C96，主要工作负载各含 6,599 个作业；Philly 对应 120 节点、每节点 8 GPU 的 C120，各含 30,940 个作业。另有 5,735 个 Helios 短作业用于 Profiler 实验（PDF 第 8 页，表 1）。
• 原 trace 没有 deadline。strict SLO deadline 被合成为 [1.2Ri, 2Ri] 内随机值；soft SLO 在首个 deadline 之外再设 1.1D、1.2D、1.5D 三档，reward 分别为 80、50、20。这一点很重要：deadline 结论建立在合成 SLO 上，而非 trace 中真实用户期限（PDF 第 8 页）。
• 对比六个 baseline：Yarn-CS、EDF、3Sigma、GENIE、Tiresias、Themis。论文报告，端到端模拟中 deadline miss rate 最多降低 14.7 倍，best-effort JCT 相比其他 deadline-aware 解法最多降低 19.9 倍（PDF 第 1-2 页；端到端结果见图 9）。
• 动态 Profiling cluster 在混合工作负载上把 profiling pending overhead 控制到 32 秒，并得到最低 5.0% wDMR；submission control 把最长 profiling 等待从 2,105 秒降到 960 秒。给预测时间加入高斯噪声时，噪声标准差小于 40% 的范围内表现仍较稳健（PDF 第 9 页，图 6）。
• MILP 扩展性实验中，即使集群与作业量一起扩大，观测到的最大求解延迟仍小于 10 秒（PDF 第 10 页，图 7d）。
• 原型部署在 Kubernetes 和 120-GPU 集群上；scheduler/controller 共 4,293 行 Go，客户端 watcher 为数百行 Python。原型抽样作业使用 VGG16、AlexNet、MobileNet、InceptionNet、ResNet、GAN、BERT、RL，单作业不超过 16 GPU、持续 5-180 分钟，提交过程持续 10 小时（PDF 第 11 页，图 10）。论文只说原型与模拟差距“可接受”，图中没有给一组统一的文字化误差百分比，因此这里不猜柱高。

CHRONUS 怎样闭合 SLO 控制回路

CHRONUS 把 profiling、admission、时间片选择和 topology placement 连成一个闭环，并用 DLT 可 checkpoint 的特性让 MILP 对未来时间作离散排程；soft deadline reward 也比只区分按时/逾期更接近实际用户容忍度。admission control 只承诺经过可行性检验的 SLO，拒绝无法兑现的请求，而不是无条件接受后再统计违约。

局限与适用边界

• 系统假设训练迭代数固定、每张 GPU 可容纳完整模型，不支持 model parallelism，并以同构 GPU 和物理网络为主要设定（PDF 第 3、13 页）。这与今天大模型训练的常见条件有明显距离。
• deadline 是从作业运行时间人工合成，不是生产 trace 的原生 SLO；14.7 倍这一结果应理解为该合成策略下的模拟结果。
• 抢占不是免费的。客户端 watcher、checkpoint 和 controller 通信都要求作业配合，属于侵入式部署；论文原型也将真实抢占开销视为模拟与实机差距来源。
• 两节点外推依赖简化性能模型。复杂网络争用、异构 GPU、模型并行或 input pipeline bottleneck 都可能让估计偏离。
• Round-up 可能额外申请 GPU，而且 consolidation-hostile 作业多时收益下降。它更适合 deadline 价值高、愿意用容量冗余换确定性的集群。

Deadline 语义：完成期限、承诺和奖励

deadline-aware 不等于简单地把最早期限排在最前。用户提交的完成时间可能不可行，也可能只是希望而非硬约束；作业运行时间本身还带预测误差。CHRONUS 因而把请求分成 strict SLO、soft SLO 与 best effort。strict 请求在期限内完成价值最高，逾期后价值骤降；soft 请求越晚完成价值逐级下降；best effort 没有期限承诺，目标是尽快利用剩余资源完成。系统先通过 admission 判断能否承诺，再对已承诺作业安排时间，这两个步骤不能合并理解。

可行性判断回答的是：“假设已接纳承诺保持不变，新请求是否存在一张不超容量且能在期限前得到足够 GPU 时间的时间表？”若不存在，系统应在提交时明确拒绝保证，而不是先显示 accepted、最终再统计 miss。被拒绝保证的作业仍可进入 Spot 队列运行，所以 admission 拒绝的是 SLO 契约，不是训练本身。这个设计让用户能选择延长 deadline、减少资源需求或接受 best effort。

reward 则用于多个已接纳请求竞争时决定哪段 lease 更有价值。把 strict 作业按时奖励设为 100、逾期奖励设为 1，会使优化器强烈保护期限，但不必用硬约束让整个 MILP 因偶发延迟无解。soft 作业在不同延迟段取 80、50、20 等梯度值，允许系统在容量紧张时做有损但可解释的权衡。奖励数值体现服务策略，不是自然常数；部署者应根据违约成本和用户合同校准。

Profiler：两次测量如何外推多节点时间

训练剩余时间约等于剩余迭代数乘以单次迭代时间。CHRONUS 要求用户或训练框架提供总迭代数，再在短 profiling 窗口测出当前配置的迭代速度。对单节点作业直接观测即可；对多节点作业，若按用户完整规模测量，会在决定是否接纳前占用大量 GPU。论文用一节点和两节点结果拟合简化的树形 AllReduce 开销。

设纯计算时间为 t_c，增加一层通信树的开销为 t_o。单节点没有跨节点归约，所以 t_1=t_c；两节点有一层通信，所以 t_2=t_c+t_o，由此得到 t_o=t_2-t_1。当节点数 n 为二的幂时，通信层数近似 log2(n)，于是 t_n=t_1+log2(n)(t_2-t_1)。例如一节点每步 0.8 秒、两节点 0.9 秒，则八节点估计为 0.8+3*0.1=1.1 秒。这个例子只演示公式，不是论文实测。

公式中的 t_n 是单步墙钟时间，不是作业总时间；增加节点虽然单步通信变慢，但数据并行时全局批量或每步处理量也可能增加。复现时必须与论文定义保持一致，明确迭代工作量是否随节点数变化。输入 pipeline、网络争用、非二次幂节点、梯度压缩、参数服务器和模型并行都会破坏简化关系。系统可以用实际运行误差持续更新估计，但论文没有展开复杂在线校准。

Profiler 本身也是资源消费者。CHRONUS 动态调整 profiling cluster，避免到达高峰时大量新作业排队；submission control 又限制过多请求同时进入 profiling。实验中 pending overhead 被控制到 32 秒，最长等待从 2105 秒降到 960 秒。这里展示的是“先测再排”系统必须优化测量排队，否则准确估计尚未产生，deadline 已经被 profiling 队列消耗。

Lease MILP：把连续时间离散成可求解日历

Selector 将未来划分为固定长度 lease。设 x(i,k) 表示作业 i 是否在第 k 个时间片运行，作业需要的 GPU 数为 g_i，集群可用于保证队列的容量为 G_k。每个时间片必须满足 sum_i g_i*x(i,k) <= G_k；一个作业在各时间片取得的 lease 数乘以每个 lease 可完成的迭代数，必须覆盖其剩余工作，才能获得相应 deadline reward。优化器选择这些二元变量，使所有作业总奖励最大。

离散化有两个相反效应。较短 lease 让调度器能更细地把作业片段塞入期限前的空隙，并更快响应新请求；但每次边界都可能 checkpoint、重启或改变 placement，执行开销和求解规模上升。较长 lease 减少抢占，却可能因为一个二十分钟空洞无法容纳三十分钟 lease 而浪费容量。论文的敏感性实验显示 15 至 30 分钟较好，最终使用 20 分钟；这不是所有集群的固定答案，应与 checkpoint 时间和作业长度共同选择。

系统每轮不必推翻全部未来日历。已执行时间片成为事实，剩余时间可随新到达、提前完成和预测修正重新求解。若求解器本轮超时，CHRONUS 从缓存的上一轮解出发并缩小搜索空间，保证控制面不会因为追求最优解而停止发放资源。这体现在线优化的重要原则：可行、及时的旧计划通常胜过迟到的全局最优计划。

奖励手算例子：strict 与 soft 请求怎样竞争

考虑一张 GPU 和四个二十分钟 lease。strict 作业甲需要两个 lease，期限在第二个时间片结束，按时奖励 100、逾期奖励 1；soft 作业乙也需要两个 lease，首个期限在第三个时间片结束，若按首期限完成奖励 100，再晚一个时间片奖励 80。若甲取得前两个 lease、乙取得后两个，甲得 100、乙得 80，总奖励 180。若乙先运行两个 lease，乙得 100，但甲只能逾期，甲得 1，总奖励 101，所以优化器会保护甲。

若再到达 strict 作业丙，也需要两个 lease且期限同为第二片，那么甲丙不可能都被满足。正确的 admission 应在接纳丙时发现日历容量不足，把丙标记为 unguaranteed，而不是让已承诺甲和新承诺丙在运行中相互违约。丙仍可在 Spot 队列争取剩余资源；若甲提前结束，释放的 lease 又能帮助丙。这一例子说明 admission control 保护的是承诺集合的一致性，reward 负责可行集合内的偏好。

实际问题还有多 GPU gang 约束。若甲每次需要四张卡，不能把四个不同时刻或不同节点的单卡空隙相加冒充一个 lease。时间 MILP 保证同一时间的 GPU 数量，Allocator 还必须找到满足拓扑的具体设备。若 Selector 给出数学上有容量但物理上分散的计划，真实迭代速度会低于 profile，deadline 仍会 miss，因此 CHRONUS 把 placement 放在闭环内而非事后随便装箱。

Allocator：从卡数日历到物理拓扑

深度学习作业的吞吐不仅取决于 GPU 数，还取决于这些卡跨多少节点、链路是否高速以及节点内是否连续。Guaranteed 队列优先 consolidated placement，把一个作业尽量放在少数节点，减少跨节点 AllReduce，并让实际拓扑接近 profiling 假设。对不便装箱的需求，系统将卡数上取整到 {1,2,4,8n} 等规则形状。例如每节点八卡时，申请六卡可能按八卡分配，以整节点换取可预测性能和后续低碎片。

上取整会造成容量冗余，但 deadline 服务关心的是确定性：多给两卡可能比把六卡分散到三台机器、导致迭代速度突降更安全。它的代价应进入 admission，不能假装仍只消耗六卡。如果大量用户申请三卡、五卡、六卡，冗余会显著压缩可承诺容量；论文更适合需求接近常见拓扑单位的环境。

Spot 队列没有硬承诺，可以更积极地利用碎片。Allocator 估计作业 placement sensitivity，即拓扑变化对速度的影响；先对最敏感的前 K 个作业做局部搜索，再对其他作业准紧凑放置。搜索空间上限为十万，避免 placement 组合爆炸。这个策略不是简单“保证作业优先、best effort 随便放”：Spot 的 JCT 仍是系统指标，只是在计算预算和碎片利用间采用近似。

端到端时间线：一个请求从提交到完成

用户提交一个八 GPU、两千次剩余迭代、四小时 strict deadline 的任务。Profiler 先在一节点和两节点短跑，估计目标拓扑的每步时间与总运行需求；若短跑中任务失败，系统可提早返回错误，而不是占用保证队列。Admission 将该需求加入现有日历，检查期限前是否有足够的二十分钟 lease。若可行，用户得到 SLO 接纳结果；若不可行，系统告知不保证，并把任务送往 best effort。

已接纳后，Selector 可能把所需运行分散到当前、两小时后和期限前的多个 lease，而不要求连续占卡。Allocator 为当前 lease 选择紧凑的八卡节点。lease 到期时 watcher 触发 checkpoint，controller 等待状态安全落盘后释放设备。下一轮若仍给同一作业 lease，则可继续执行；若更高价值作业到达，它会暂停到未来时间片。提前完成会释放日历容量，Spot 队列在更短的三百秒 cycle 中利用这些资源。

若实际每步时间比 profile 慢二成，剩余工作预测会上升，系统需要在后续重算中占用更多 lease。只要日历仍有裕量，承诺可维持；若误差过大，reward 优化只能减少损失，无法凭空创造 GPU。论文在高斯噪声标准差小于 40% 时表现仍较稳健，但这属于其 trace 和余量条件下的经验结果，不是所有接纳作业永不违约的形式证明。

实验解读：倍数、分母和合成期限

14.7 倍 deadline miss rate 改善和 19.9 倍 best-effort JCT 改善是“最多”结果，来自不同对照与工作负载点，不能理解为所有配置同时稳定获得这两个倍数。更关键的是，Helios 和 Philly 原 trace 不包含用户 deadline，论文用真实运行时 R_i 构造 strict deadline，随机取 1.2R_i 到 2R_i。这让期限与作业难度相关且总体具有一定松弛，适合可控比较，却未覆盖用户给出与真实时长无关、过紧或业务事件驱动的期限。

软期限同样是合成奖励：首期限之后再设 1.1、1.2、1.5 倍位置，奖励逐级为 80、50、20。因而实验更准确证明“在这套 reward 与到达模型下，CHRONUS 能联合改善保证作业和剩余作业”，而不是证明用户实际效用提高同样比例。若业务在期限后价值归零，应使用 strict；若价值随延迟平滑下降，分段点和奖励需要从服务数据估计。

论文同时有 120 GPU Kubernetes 原型，这是强于纯模拟工作的地方。实现包含 4293 行 Go 调度与控制代码以及 Python watcher，覆盖 CNN、GAN、BERT 和强化学习作业，说明 checkpoint 控制链能实际运行。不过原型作业最多 16 GPU、持续 5 到 180 分钟，不包含模型并行大模型；图示结果也没有统一文本误差数字。模拟负责规模，原型负责可实现性，两类证据互补但不能相互替代。

预测误差怎样沿调度闭环传播

Profiler 的误差首先影响 admission。若运行时间被低估，系统会把本来不可行的请求接纳进保证集合，日历看似有空位，实际每个 lease 完成的迭代却不足；若被高估，系统会拒绝本可满足的 SLO，降低容量利用。两种错误不对称：低估造成真实违约并可能连累其他承诺，高估主要损失收入或用户体验。因此生产系统可对 strict 请求采用保守上置信界，对 soft 和 best effort 使用中位预测，而不是所有作业共用一个点估计。

误差随后影响 lease 数。假设 profile 预计每个二十分钟 lease 完成两百次迭代，作业剩余一千次，Selector 会预留五个 lease；若真实只能完成一百六十次，就需要七个 lease，至少多占四十分钟。若这个偏差在第一个 lease 结束后被检测到，系统尚可重算；若直到 deadline 前才发现，已经没有足够的可移动空间。运行时应在每个 lease 内持续比较实际迭代进度与预测，而非只在 checkpoint 边界检查。

placement 偏差又会放大性能误差。Profiler 可能在单节点高速互联上测量，Allocator 却因碎片把作业放到多个节点；论文用 consolidation 和 round-up 降低这种不一致。如果节点同时承载网络密集作业，即使物理形状相同，通信争用仍会改变速度。由此可见，运行时间模型的输入至少应包含实际 placement 和共享网络状态，或者为 guarantee cluster 保留隔离余量。

用户报告的迭代数也可能变化，例如提前停止、动态数据增强、训练中调整 epoch 或故障重跑。CHRONUS 的固定工作量假设让 MILP 可求解，却要求 watcher 把变化视作新的剩余工作并触发 admission 复核。若用户无上限地增加迭代，原 SLO 契约应失效或重新协商，否则调度器无法对最初未承诺的工作负责。

Checkpoint、抢占和控制面故障的降级策略

lease 到期并不等于 GPU 立即可分配。训练进程要到达一致状态，写出模型、优化器、学习率调度器、随机数状态和数据迭代位置，控制器还要确认文件完整。如果 checkpoint 花三分钟，二十分钟 lease 的 15% 都用于交接；频繁抢占会使论文中较短 lease 的灵活性优势被系统开销抵消。复现时应把保存和恢复都计入 JCT 与期限，而不是只从训练迭代模拟。

存储故障可能产生“控制面认为已释放，作业实际不可恢复”的危险状态。安全协议应先写临时版本、校验完整性并原子发布，再向 scheduler 确认 lease 结束；确认超时则延长当前占用或将作业标为失败，不能直接让下一任务覆盖显存。恢复时也要验证数据版本和容器镜像，否则即使权重可读，训练轨迹仍可能改变。

若 scheduler 或 MILP 求解器故障，已发放的 lease 应继续到边界，controller 使用持久化日历而不是立即终止所有作业。缓存旧解提供一个可行回退，但新到达 SLO 在控制面恢复前不能得到保证。若 Profiler 堵塞，best-effort 作业仍可按简单策略运行；若 Guaranteed 与 Spot 之间的容量调整失败，则优先保护已有承诺。这样的优先级与 CHRONUS 的设计目标一致，但论文主要评估性能，没有给完整容灾协议。

用户主动取消或作业提前收敛是正向异常。系统应马上释放未来 lease，并在下一次短 Spot cycle 使用当前空余；这也是 guaranteed 区和 spot 区容量动态变化的来源。反之，作业反复崩溃不应无限占用保证日历，可设置有限重试预算，超过后撤销保证并通知用户。真正的 deadline 服务不仅要排出理想时间表，还要定义每种失败由谁承担以及何时重新协商。

复现步骤、验收指标与结论

实验设计应先固定三种分母。deadline miss rate 的分母是已接纳的 SLO 作业，不能把 admission 拒绝的请求删除后只报一个很低的违约率；同时必须另报接纳率，否则最保守的系统可以靠拒绝所有请求得到零 miss。best-effort JCT 要从提交时刻开始计入 profiling 和排队，不能只统计获得 GPU 后的运行时间。GPU 利用率则要包含 guarantee 为未来期限保留而暂时空闲的容量，才能看见确定性服务的真实成本。

还应分别构造宽松、临界和不可行期限。宽松组检验调度器是否在无需预留时仍伤害 Spot；临界组最能暴露 prediction 与 placement 误差；不可行组检查 admission 是否及时拒绝并给出可操作反馈。把所有期限都按真实运行时的一定倍数均匀生成，会弱化业务中集中到同一发布时点的 deadline burst，因此可增加多个作业共享同一截止时刻的压力场景。

公平性虽不是论文主目标，也不能完全忽略。reward 最大化可能反复推迟价值低或规模大的 soft 请求；Spot 中的 SRTF 又天然偏向短作业。复现时可报告最大 slowdown、等待时间分位数以及按租户分组的服务份额，确认 JCT 改善没有来自少数长作业长期饥饿。若存在这种现象，可在 reward 中加入等待年龄或最低服务约束，但这会改变原论文策略，应作为扩展实验单独标注。

最终验收还要保存每次调度决定的解释记录：采用了哪版运行时间估计、为何接纳或拒绝、哪些 lease 被保留、实际 placement 与预测拓扑是否一致。出现违约时才能区分估计错误、资源故障、checkpoint 超时和优化策略问题。对提供期限承诺的系统，可审计性与平均性能同样重要。

这些记录也能支持事后容量规划和服务规则校准。

1. 先实现 profiler，记录一节点、两节点和真实目标规模的单步时间；计算外推误差分布，并按模型、网络拥塞和输入管道分类。
2. 用极小日历手工枚举 admission 与 reward MILP，验证容量、作业完成、strict/soft 奖励和不重复占用约束；再逐步扩大到 trace 规模。
3. 实现二十分钟 SLO lease 和三百秒 Spot cycle，测量 checkpoint、重启、控制消息以及 placement 变化的实际开销，把这些开销计入剩余时间。
4. 在同一 trace 上比较 EDF、SRTF 和论文 baseline，分别报告 strict miss rate、soft reward、best-effort 平均与尾部 JCT、GPU 利用率、求解延迟和 admission rejection。
5. 对 deadline 松弛、预测噪声、lease 长度、作业规模与拓扑碎片做敏感性分析；真实期限和合成期限应分开报告。

CHRONUS 的核心贡献是一份可执行的 SLO 闭环：先测量，再决定是否承诺，把承诺转成未来 lease 日历，最后用拓扑感知 placement 落到设备。它适用于可准确计数迭代、可 checkpoint、模型能装入单卡且 deadline 有真实价值的训练集群。对模型并行、异构加速器或 checkpoint 极慢的大模型，不能直接照搬；但“只承诺经过可行性检验的请求”和“时间计划必须与物理拓扑一致”仍是通用系统原则。部署时，拒绝原因和预测误差也应向使用者可见。