Papers

ACM Computing Surveys 56(6)，Article 146，2024 年 1 月

GPU 数据中心里的深度学习工作负载调度

训练、推理、超参数搜索与混合负载的目标、机制、决策模型和落地方法

导读从任务到达讲起：调度器为何需要预测，怎样沿两条分类轴选择机制，又如何下发并校正决策。综述作者的判断、被引系统各自的结果和用于解释的算例会分别标明。

本文目录 · 18 节
  1. 1. 这篇综述整理了什么
  2. 2. 背景与必要概念
  3. 3. 训练与推理各自怎样形成调度问题
  4. 4. 综述范围、纳入对象与排除边界
  5. 5. Taxonomy 的两条正交轴
  6. 6. 训练调度：时间、能源与费用效率
  7. 7. 训练调度：公平性与期限保证
  8. 8. 训练调度：异构资源、共享与弹性机制
  9. 9. 推理调度：准确率、延迟与成本
  10. 10. 推理调度：吞吐、缓存、共置与异构资源
  11. 11. HPO 与训练／推理混合负载
  12. 12. 关键公式与决策模型
  13. 13. 从作业提交到执行反馈的完整数据流
  14. 14. 一个数字化端到端算例
  15. 15. 实现与部署细节
  16. 16. 论文中的实验与统计数字该怎样解释
  17. 17. 消融、开销、敏感性与证据强度
  18. 18. 局限、适用边界与复现核查清单

1. 这篇综述整理了什么

Ye 等人的论文是一篇调度综述，不是一个新调度器。研究对象是以 GPU 为主要计算资源的数据中心，任务包括模型训练、在线推理、超参数优化（HPO），以及训练与推理共存的混合环境。作者试图回答三个问题：深度学习任务给调度带来了哪些传统 HPC 或大数据调度没有充分处理的困难；已有系统是否共享一组可复用的机制；模型、硬件和用户需求变化后，调度器还缺什么。

论文最有用的结论是：不能只按系统名字或“训练／推理”二分法理解调度。每个方案都应放进两个相互独立的维度。第一条轴是调度目标，回答“优化什么”，例如平均作业完成时间、公平性、期限违约率、准确率、尾延迟、吞吐量、能源或云费用。第二条轴是资源使用方式，回答“允许怎样使用资源”，例如异构设备分配、GPU 共享、弹性伸缩、请求批处理和任务共置。同一个系统可以同时处在多个格子里：一个异构感知、支持弹性训练的调度器，仍可把公平性或完成时间作为主要目标。

因此，本文给出的不是“最佳调度器排行榜”。它提供一套设计语言：先把约束和目标写清，再选择预测、优化、启发式、机器学习以及运行时隔离等机制。表 1 至表 3 汇总的是不同论文在不同硬件、数据集和指标上的证据，不能拼接成一场统一实验。

2. 背景与必要概念

作业、任务、请求和资源

训练作业通常持续数小时、数天甚至数周，由许多相似迭代构成。数据并行训练把一个批次切给多张 GPU，每个 worker 前向计算、反向传播，再通过参数服务器或 All-Reduce 同步梯度。gang scheduling 要求作业申请的全部 GPU 同时到位；若只分到一部分，原生训练程序往往无法启动。弹性训练则允许 GPU 数量运行中改变，但要处理 batch size、学习率、样本次序、检查点和进程组重建。

推理服务面对的是连续到达的请求。单次前向传播通常小于一次完整训练迭代，占用的计算和显存也较少；服务却必须应对流量突发，并满足延迟 SLO。平均延迟低不代表服务合格，因为少量慢请求会抬高 P95、P99 等尾延迟。批处理把多个请求合成一次 GPU 调用，减少启动开销并提高并行度，但最早到达的请求需要等待凑批。自动扩缩容能减少排队，却增加实例费用、冷启动与模型加载成本。

资源也不是一个简单的“GPU 数量”。同一代 GPU 上，不同模型对张量核、显存容量和带宽的利用不同；跨代 GPU 的相对加速比因模型而异。多卡训练还受 NVLink、PCIe、InfiniBand、以太网、CPU、主存、存储和数据输入管线影响。placement 表示任务被放到哪些设备及其拓扑位置。四张同机 GPU 与分散在四台服务器上的四张 GPU 数量相同，通信成本却可能相差很大。

几个容易混淆的指标

3. 训练与推理各自怎样形成调度问题

如果资源无限，每个训练作业可立即获得最适合的 GPU 与拓扑，每个推理请求也可独占一个已加载模型的实例，调度几乎没有难度。现实中 GPU 昂贵且稀缺，任务同时到达，需求量和持续时间不一，于是调度器至少要决定“谁先运行、分多少资源、放在哪里、运行多久后是否调整”。并行作业分配本身已是 NP-hard 的组合问题；深度学习又把决策变量和反馈环扩大了。

训练侧的推导链如下：GPU 稀缺，先产生排队；gang 约束和严格局部性使空闲卡因碎片化而无法凑齐；放宽局部性能更快启动，却增加跨机通信；抢占可以让短作业或高优先级作业先行，但检查点和恢复可能耗时数秒到数分钟，且大模型更严重；共享能填补单作业的空闲执行单元和显存，但共置干扰会拖慢双方；弹性能利用零散资源，却可能改变优化轨迹和可复现性。于是“多给卡是否更快”不能仅看卡数，必须同时估计拓扑、通信、干扰、重配置成本和训练统计效率。

推理侧从另一组矛盾出发：单请求难以吃满 GPU，所以需要批处理或共置；这两者提高吞吐，却引入等待和干扰，使尾延迟更难保证。扩容能降低排队，但云实例付费、冷启动和模型装载又抬高成本。选择更小模型可以快，准确率可能下降；模型集成常能提高准确率，却要执行更多模型。最终形成准确率、延迟和成本的三难权衡。论文指出在线服务通常优先保护延迟 SLO，再在可行解内优化费用或准确率。

因此，调度不是一次性的静态装箱，而是闭环控制：观测任务和集群状态，预测候选方案的结果，求出当轮分配，下发到运行时，测量实际性能，再用偏差更新模型。预测误差、求解时间和执行开销都是调度系统本身的一部分。

4. 综述范围、纳入对象与排除边界

作者纳入的是数据中心尺度、作业级、以 GPU 为主、面向一般深度学习训练或推理的调度系统。训练和推理分别形成主体，HPO 因为一个作业包含大量相似 trial 而单列；端到端模型开发平台以及训练／推理混合共置也单列。生产 trace 的刻画研究会在能解释调度动机时被引用。表中的系统按目标、方法、异构或弹性能力、是否开放代码、物理 testbed 规模等属性整理。

论文没有报告检索数据库、完整检索式、去重过程、系统化纳入数量或 PRISMA 流程。因此它是作者策展式的综合，而不是可按检索协议完整重做的系统综述。稿件于 2022 年 5 月收到，2023 年 2 月修订，2023 年 12 月接收，2024 年 1 月出版；文中包含若干 2023 年和少量早期 LLM 系统，但不应外推为覆盖后续所有大模型调度进展。

明确排除的内容有：

这些边界很重要。今天分析 LLM 时，prefill／decode 分离、KV cache 分页、张量／流水线／专家并行、token 级调度、跨节点推理状态迁移都可能主导设计，而原综述只能提供基础框架，不能替代相应的新证据。

5. Taxonomy 的两条正交轴

工作负载轴一：调度目标轴二：资源使用方式
训练效率：时间、能源与云费用；公平性；deadline 保证异构资源；GPU 共享；弹性训练
推理准确率、延迟、成本及其权衡；系统吞吐共置与资源共享；异构 CPU／GPU 或不同云实例
HPO／混合最终准确率、makespan、费用、利用率、在线服务质量trial 早停与融合；资源借用；训练和推理共用组件与容量

两条轴不能合并成一棵互斥分类树。“GPU 共享”本身不说明系统优化吞吐、公平还是成本；“deadline 保证”也不限定必须独占或弹性。评估新系统时，应先写出目标函数和硬约束，再写可用动作。例如，训练调度可把 deadline 作为硬约束、费用作为目标，同时允许异构卡与弹性 GPU 数；推理调度可把 P99 延迟作为硬约束、准确率为下界、成本为目标，同时允许动态 batch 和模型变体切换。

这套分类还揭示研究空白。论文观察到，训练侧对固定独占资源下的时间和公平研究较多，但在异构、共享或弹性环境中联合优化费用与 deadline 的工作不足。推理侧已有大量延迟和吞吐方案，能源优化、异构资源公平以及共享时的稳健 SLO 仍缺更全面证据。

6. 训练调度：时间、能源与费用效率

缩短排队与完成时间

最直接的办法是优先级。Tiresias 用 Least Attained Service（LAS）衡量已获得服务量，即 GPU 请求数乘以已执行时间；获得服务较少的作业优先。为了避免优先级细微变化导致频繁抢占，它借鉴多级反馈队列，把优先级离散化。E-LAS 改用实时 epoch 进度率，即已完成 epoch 占总 epoch 的比例。已知持续时间时也可采用最短剩余时间思想，但错误估计会导致长作业饥饿或反复抢占。

当任务信息缺失时，调度器可从历史或在线 profiling 预测。Sched² 和 MLFS 用强化学习根据作业状态与集群状态输出优先级或资源量；Helios 从生产历史预测作业优先级；JPAS 拟合准确率曲线，估计某个 trial 继续训练可能得到的最大精度增益，把资源给更有希望的探索任务。机器学习没有消除调度约束，它只是替代“已知持续时间、速度、利用率”等难以直接获得的输入。

placement 决定通信路径，也决定什么时候能启动。严格同机或同交换域放置可减少通信，却可能让作业等待一块完整区域；立即使用散落 GPU 能减少排队，却延长每个迭代。Philly 分析这种权衡并提出在必要时放宽局部性。HiveD 用 buddy cell 划分资源，减少碎片且可作为插件接入已有调度器。SPIN 把暂缓调度视为对未来更好局部性的投资，并用随机近似处理运行时间预测不准的情况。这里的正确目标是总 JCT，而不是只最小化排队或只最大化单作业吞吐。

能源与云费用

ANDREAS 假设作业可在一定窗口内推迟，把功耗写成混合整数非线性规划，再用贪心近似把作业集中到合适时段，尽量让已开启 GPU 忙起来。Helios 的 Cluster Saving Service 不要求推迟作业，而是根据历史预测未来资源利用率，决定开启或关闭多少 GPU 节点。PowerFlow 同时调整 GPU 分配和 GPU／作业级配置。

云环境的成本等于实例单价与占用时长的组合，并受吞吐影响。Cynthia 和 FC² 为参数服务器训练选择 worker、PS 与实例类型，在吞吐约束下减小费用；MLCloudPrice 在按需实例与便宜但可被回收的 spot 实例间迁移。便宜实例若使训练时间大幅增加并不一定省钱，spot 实例若频繁中断也要计入检查点、恢复和重算。

7. 训练调度：公平性与期限保证

同构 GPU 环境可在时间维度补偿不可分割的整卡资源。Themis 定义 finish-time fairness：比较作业在共享集群中的预计完成时间与其应得份额基准，优先帮助落后最多的作业；两级架构让作业对 placement 竞价，减轻错误放置造成的公平损失。Astraea 用长期 GPU-time 公平（LTGF）衡量租户和作业长期获得的共享收益，以两级 max-min 规则同时约束租户与作业。Shockwave 则把静态市场理论扩展到动态到达，以联合考虑效率与公平。

异构环境不能把一小时 A100 与一小时旧 GPU 当作等值。Allox 把 CPU 和 GPU 视为可替代资源，结合任务亲和性，将分配写成最小成本二分图匹配并用贪心求解。Dorm 把 GPU、CPU、内存视为互补资源，用混合整数线性规划优化资源利用公平。Gandivafair 通过 profiling 和自动定价让用户透明交换不同 GPU 的时间；Gavel 测量模型在不同 GPU 上的吞吐，按轮重新分配并支持 max-min、makespan、finish-time 等定义。Gavel 在大集群求解代价高，POP 通过分区把大问题拆成多个可并行的小问题。公平定义不同，输出自然也不同，不能只比较“公平性提升”这个标签。

deadline 目标关注是否按时完成，而不是平均快。GENIE 只需 profiling 少量训练迭代，就估计不同 placement 的吞吐，并为每个作业寻找能满足期限的方案。它没有完整处理 deadline 与 best-effort 混合队列。Chronus 先通过用户调查确认期限需求，再用 MILP 同时降低 SLO 作业的 miss rate 与 best-effort 作业延迟。ElasticFlow 进一步动态伸缩每个作业的资源。一个可部署的期限调度器必须保留安全余量：预测的完成时间若恰等于 deadline，任何排队抖动、节点故障或检查点都可能造成违约。

8. 训练调度：异构资源、共享与弹性机制

异构资源与瓶颈定位

Synergy 先实测不同 CPU 分配下的吞吐，再解析估计 CPU、内存和存储带宽组合，用多维贪心装箱减少碎片。CODA 处理共置 CPU 作业对训练输入管线的干扰；Muri 在 GPU、CPU、网络和存储之间交错分配关键资源；Cassini、Ada-SRSF、Liquid、Parrot 关注跨作业网络争用，其中 Liquid 用随机森林预测需求再结合 best-fit 与遗传算法，Parrot 用线性规划求参数服务器通信阶段的加权带宽缩放。共同原则是先找到瓶颈，再分配对应资源；只按 GPU 利用率扩容可能完全无效。

共享：用隔离和干扰预测填满单卡

Salus 提供快速作业切换和显存共享，使多个小任务能时间共享或空间共享一张 GPU。Gandiva 以显存与性能为约束做 profiling，发现干扰过大的组合后拆散。Antman 联合设计集群调度器与框架运行时，实现细粒度共执行。Horus 在提交时读取计算图并 dry-run，预测 GPU 使用量，降低会产生严重 JCT slowdown 或通信干扰的共置优先级；Co-scheML 与 Liquid 使用随机森林预测干扰，Harmony 用强化学习做装箱，Lucid 强调非侵入且可解释的 profiling。

共享的安全边界包括显存总量、峰值显存而非平均值、计算和带宽竞争、故障域扩大、租户隔离以及可重复性。MIG 提供硬件分区，MPS 或进程级共享通常隔离较弱。大模型场景中，Hydro 利用流水线 bubble 交错 HPO 工作，Titan 合并多个微调任务；这些例子提示空闲资源可能存在于时间片和流水线阶段内部，而不是整张卡。

弹性：资源数和 batch size 都可变

资源弹性动态增减 GPU。Gandiva 的 Grow-Shrink 根据 profiling 的进度率扩缩；Optimus 预测不同 placement 下的 loss 下降率；AFS 把未来资源竞争的代价摊入当前份额；GADGET 针对 ring-all-reduce 建模并用贪心最大化未完成作业效用。频繁调整会触发进程启动、通信组重建、状态保存和数据重分片。ELAN 用异步协调，SideCar 提前初始化，EDL 实现不停机扩容与优雅缩容；Singularity 用设备代理把训练程序与物理设备分离，让抢占、迁移和弹性对作业透明。

batch 弹性会同时改变系统吞吐与统计效率。Pollux 用 goodput 把硬件每秒样本数与训练统计效率合在一起，联合选择资源和 batch；ONES 用在线演化搜索，Sia 扩展到异构 GPU。EasyScale 则追踪影响一致性的状态，力图严格保持数据并行行为。论文的第 8 条洞见明确警告：弹性，尤其 batch 弹性，可能导致精度损失和复现危机，只应在模型已验证对这类变化稳健，或速度明确优先于精度时使用。

9. 推理调度：准确率、延迟与成本

准确率不是固定模型之外的禁区

固定模型和固定输入下，常规推理结果近似确定；调度器仍可通过模型选择改变准确率。Ease.ml 根据输入输出形状和预计精度增益选择候选模型，并用多臂老虎机与贝叶斯优化处理单租户或多租户下的成本感知选择。Clipper 对多个基础模型的结果做加权线性集成，权重由 bandit 或学习方法决定；Rafiki 用强化学习选择 ensemble 组合和 batch size。更多模型通常提高准确率，却消耗更多计算并增加响应时间。

延迟：扩容、确定性控制、抢占

Clipper 按请求量复制隔离的模型容器，并针对每个模型独立自适应批处理。MArk 组合 EC2 与 Lambda：常驻实例承担基础流量，监测到请求可能违约时用可快速扩展但更贵的 Lambda 补峰。InferLine 对多阶段推理管线分别监测访问频率并扩缩每个组件，避免只扩容非瓶颈阶段。

Clockwork 利用固定输入下执行较确定的特性，主动控制显存分配、释放和系统层配置，并禁止并发来消除不确定干扰，代价是吞吐和利用率下降。Abacus 在共置条件下离线 profile 算子组合，在线搜索执行次序以满足 QoS。Irina 在数据流图中加入退出节点，使正在运行的推理能安全抢占。Kube-Knots 同时预测跨资源的空间相关性与时间上的峰值，避免峰值同类资源需求重叠。ParM 用学习式编码计算加入冗余，以恢复尾延迟或失败请求；冗余本身也消耗资源。

成本与三难权衡

MArk 比较云服务层级、实例能力、价格与扩展速度，贪心选择配置并利用 spot 实例。AutoDeep 用贝叶斯优化寻找云配置、用深度强化学习寻找设备 placement，在 SLO 约束下减小总费用。Kairos 在费用预算和 SLO 下把请求分配到异构实例以最大化吞吐；iGniter 用轻量解析模型估计共置干扰并配置 GPU；SpotServe 针对自回归 LLM 按 token 而非整请求提交进度，以便在廉价可抢占实例上恢复。

Clipper、Model-Switching、Cocktail、Tabi 和 MOSEL 分别从模型集成、模型变体切换、小模型置信度升级到大模型、输入模态选择等角度权衡准确率与延迟。Tolerance Tiers 让用户声明可容忍的误差和优化目标；INFaaS 预先 profile 模型、batch、硬件等变体，用硬件实例级与模型变体级两层扩缩，在满足 SLO 时选择最低成本方案。这里没有无条件最优点，只有在用户约束下的 Pareto 可行方案。

10. 推理调度：吞吐、缓存、共置与异构资源

动态批处理是提高吞吐的基础手段。Clipper 和 Rafiki 用 AIMD：batch size 每轮加一个固定量，直到批处理延迟超过要求，再按固定比例缩小。MArk profile 无批处理速率，并在单请求最大可等待时间内搜索 batch。Nanily 用“请求距 deadline 的剩余时间减去最短排队时间”计算可留给执行的窗口，再选择执行时间接近该窗口的 batch。DyBatch 还约束不同工作负载的 slowdown 公平性。batch 上限必须由队列中最紧迫请求决定，不能只看平均到达率。

缓存用空间换计算。Clipper 缓存相同模型与相同输入的结果，并用 LRU 淘汰；实际输入相似度低时命中率会很差。另一层缓存把模型权重常驻 GPU。Gillman 等人的策略同时考虑模型大小、访问频率、准确率和速度，减少换入换出造成的冷启动；TrIMS 管理模型显存生命周期，并处理多节点、隔离、公平、miss 与 eviction。结果缓存和模型缓存的键、失效条件及一致性要求完全不同。

配置搜索解决硬件与运行时组合过多的问题。Morphling 把服务性能建模写成 few-shot 学习，以离线 MAML 元模型加少量在线样本预测新配置；RRL 用区域式强化学习调整请求间、算子间和算子内并行度；Shepherd 聚合请求流以提高可预测性；Symphony 使用非 work-conserving 策略，有意短暂等待以形成高效 batch，并配合扩缩容。非 work-conserving 不等于浪费，它用可控等待换取更高批效率，但必须受 deadline 约束。

共置与共享把多个请求或模型放到同一 GPU。Space-time 监控 kernel 延迟，以时间共享加空间共享融合小 kernel。GSLICE 基于 MPS 做空间复用；MIG-SERVING 利用 A100 MIG 的硬分区，把非线性的资源份额—吞吐关系写成可重配置搜索。INFaaS 可通过迁移或 VM 扩容缓解共享干扰。PERSEUS 发现模型混合比例、冷启动缓存和数据传输会改变共置成本。Gpulet 做时空共享；DeltaZip 压缩多个全参数微调模型的差量，Punica 跨 LoRA 模型批处理 GPU 操作，S-LoRA 用统一内存池管理不同 rank 的 adapter 与不同长度的 KV cache。

异构资源不能只按峰值算力选择。论文归纳 MArk 和 PERSEUS 的结论：较新的小 CPU 实例可能有更好性价比；GPU 在 batch 合适时可能同时取得更低单请求费用和更低延迟；高 GPU 利用模型在多 GPU 实例中也可能给邻居带来强干扰。实际决策必须使用特定模型、batch 与实例价格的 profile，而不是把这几条观察当成普遍排序。

11. HPO 与训练／推理混合负载

一个 HPO 作业包含许多超参数配置，每个配置对应一个含训练和验证的 trial。它与一般独立训练作业不同：trial 结构相似，可以共享算子、数据和参数；早期反馈可预测潜力；差 trial 可以终止，释放资源给好 trial。调度目标也不只是每个 trial 快，而是在时间、资源或费用预算内找到最高质量配置。

Hermes 提供低开销容器抢占和迁移，并按收敛迹象偏爱有希望的配置。HyperSched 在给定时间与资源预算下，给早期精度较好的 trial 更多资源并终止差 trial；SEER 把约束改成云费用预算。HyperDrive 拟合准确率曲线，外推后续迭代的精度。Fluid 通过装箱共享 GPU；HFTA 把多个 trial 水平融合到算子级并在一张 GPU 上训练；Retiarii 为神经架构搜索中的不可训练算子做类似批处理。Hydro 用小模型搜索后转移超参数，并结合 trial 间／trial 内融合、编译优化、bubble 交错与异构分配。RubberBand 建模资源方案下的吞吐和成本，在时间预算内寻找成本有效配置。

混合负载有两种形态。第一种统一整个生命周期：CMS 编排训练、推理、周期重训、验证与模型切换，以 trainer contract 统一训练接口；Rafiki 让训练和推理共享分布式数据存储、内存参数服务器、通信协议与计算资源。第二种共享空闲容量：Kube-Knots 把可预测的离线 batch 作业填入在线推理未用满的 GPU，并预测双方峰值；Lyra 在推理低谷把预留 GPU “借”给弹性训练，流量回升时收回，同时尽量减少代价不可忽略的抢占次数。

优先级边界应明确：在线 SLO 通常是硬约束，训练借用的是可撤回容量；训练的最小有用运行窗口必须大于启动、检查点与回收开销，否则表面利用率提高，实际有效工作反而减少。模型更新还要经过验证和原子切换，不能因为资源统一就让未验证权重直接进入在线服务。

12. 关键公式与决策模型

综述没有提出一套统一公式。下面把文中反复出现的决策量整理成一个通用模型，用来解释各系统在优化什么；它是对 taxonomy 的数学化表达，不是论文声称的新算法。

对训练作业 j，提交时刻为 a_j，结束时刻为 C_j，则：

JCT_j = C_j - a_j
Service_j(t) = ∫[a_j,t] g_j(τ) dτ
Cost_j = ∫[a_j,C_j] price(type_j(τ), τ) · g_j(τ) dτ
DeadlineSlack_j(t) = d_j - t - RemainingWork_j / PredictedRate_j(x)

g_j(τ) 是时刻 τ 分给作业的 GPU 数；type_j 是 GPU 或云实例类型；d_j 是 deadline；x 包含 GPU 型号、数量、拓扑、CPU、内存、网络、batch 和共置伙伴。LAS 近似使用离散的 GPU 数 × 执行时间 作为 attained service。期限余量若小于迁移、检查点和误差安全边际，调度器应扩容、换更快 placement 或拒绝承诺。

训练吞吐不能直接代表收敛速度。Pollux 一类系统使用：

Goodput_j(x) = Throughput_j(x) · StatisticalEfficiency_j(x)

Throughput 是每秒处理样本数；StatisticalEfficiency 表示这些样本对达到目标质量的有效程度，受全局 batch、学习率与优化器影响。GPU 增多使系统吞吐提高时，如果统计效率下降更多，goodput 仍会降低。

对推理请求 q，到达时刻为 r_q，完成时刻为 f_q，模型变体为 m_q：

Latency_q = f_q - r_q = Queue_q + BatchWait_q + Load_q + Execute_q
约束：P99(Latency) ≤ SLO，Accuracy(m_q) ≥ A_min
目标：min Σ InstancePrice_k · ActiveTime_k
      或 max CompletedRequests / TimeWindow

Load 包括冷启动和权重换入；Execute 依赖 batch、设备和干扰；A_min 是用户允许的最低准确率。三难权衡可写成加权目标 α·Latency + β·Cost - γ·Accuracy，但权重难以解释。部署中更稳妥的做法是把 SLO 和最低准确率写成约束，只在可行方案中最小化费用。

集群每轮可抽象为带约束的组合优化：

选择 x[j,k]、batch[j]、replicas[j]、preempt[j]
最小化 λ1·平均 JCT + λ2·deadline miss + λ3·费用 + λ4·公平损失
满足 每台机器的 GPU/显存/CPU/网络容量约束
     gang 与拓扑约束、模型兼容约束、SLO 与准确率约束
     迁移/扩缩/抢占冷却时间及租户隔离约束

x[j,k] 表示作业 j 是否占用设备 k。MILP、非线性规划和匹配尝试直接或近似求解；启发式快速构造可行解；ML/RL 预测未知参数或给出动作。无论哪种方法，在线求解时间必须短于调度周期，否则“更优”的结果到达时集群状态已经过期。

13. 从作业提交到执行反馈的完整数据流

while true:
    jobs     = ingest_and_validate_submissions()
    cluster  = collect_cluster_state()
    profiles = load_profiles_and_recent_metrics()

    for job in jobs:
        candidates[job] = enumerate_feasible_actions(job, cluster)
        for action in candidates[job]:
            pred[job, action] = predict_rate_latency_cost_interference(
                job, action, profiles)

    candidates = reject_capacity_topology_accuracy_slo_violations(candidates, pred)
    plan = solve_or_approximate(candidates, objective, fairness_state,
                                deadline_slack, decision_time_budget)
    plan = add_hysteresis_cooldown_and_safety_margin(plan)

    apply_atomically(plan)
    observe_actual_rate_tail_latency_cost_failures()
    update_profiles_and_accounting()
    wait_until_next_event_or_scheduling_tick()

准入阶段必须把“4 GPU”改写成可检查的资源范围，例如允许 2 至 8 张、限定型号、显存下限、是否接受跨机和抢占。预测阶段要返回置信区间而非只给点估计。约束过滤先保证安全与 SLO，再做目标优化。执行阶段要原子化：不能先停旧实例、后发现新实例无资源。反馈阶段同时更新性能模型与长期公平账本，防止短期最优反复伤害同一租户。

14. 一个数字化端到端算例

算例性质：以下数字为解释决策过程而设定的可复算假设，不是论文实验，也不是任何被引系统的测量结果。它不用于声称性能提升。

设集群有 8 张相同 GPU。在线推理服务常驻 4 张卡，SLO 为 200 ms；离线 profile 表明每张卡 batch 8 时可处理 80 请求／秒，执行时间 80 ms。当前流量为 160 请求／秒，所以两张卡就能覆盖平均流量，但为突发保留 4 张。此时训练作业 A 到达，允许 2 至 4 张卡，剩余工作量按 profile 折算为 7,200 个“单卡秒”；作业 B 稍后到达，固定需要 2 张卡，剩余工作量为 1,800 个“单卡秒”。为了把计算写清，暂时假设训练线性扩展且没有通信开销。

低流量阶段，调度器把推理保留容量中的 2 张借给 A，再把空闲的 2 张给 A，因此 A 用 4 张卡；余下 4 张继续服务推理。A 的预计剩余时间是 7,200 / 4 = 1,800 秒。十分钟后 B 到达。此时 A 已完成 4 × 600 = 2,400 单卡秒，还剩 4,800。若继续让 A 占 4 卡，B 要等待 1,200 秒后才能启动；B 的 JCT 为等待 1,200 秒加执行 1,800 / 2 = 900 秒，共 2,100 秒。

若 A 支持低开销缩到 2 卡，调度器可立即把另外 2 卡给 B。此后 A 需 4,800 / 2 = 2,400 秒完成，A 总 JCT 为前 600 秒加后 2,400 秒，共 3,000 秒；B 的 JCT 为 900 秒。两作业平均 JCT 是 (3,000 + 900) / 2 = 1,950 秒。保持 A 不变时，A 在第 1,800 秒完成，B 再运行 900 秒，平均 JCT 是 (1,800 + 2,100) / 2 = 1,950 秒，恰好相同。这个结果说明只看平均 JCT 无法选择；缩容方案让短作业早 1,200 秒完成，却让 A 晚 1,200 秒，需由优先级、公平或 deadline 决定。

现在第 1,200 秒发生推理突发，流量升至 400 请求／秒。按每卡 80 请求／秒的假设，至少需要 5 张推理卡。当前只有 4 张，因此控制器要收回 1 张训练卡，并留出安全余量。若从 A 的 2 卡缩到 1 卡不被训练框架支持，就必须暂停 A 或暂停 B；若 B 的 deadline 更紧，则保存 A 检查点、把卡交给推理。假设检查点与恢复合计 40 秒，那么借卡至少要持续超过 40 秒并产生足够训练收益才合理。这个开销必须计入新的 JCT 预测，不能只把 GPU 利用率上升当作收益。

推理侧也要检查 batch 等待。SLO 200 ms、执行 80 ms，忽略其他开销时，单请求最多可等待 120 ms。以 400 请求／秒的稳定到达率计算，凑齐 batch 8 的期望时间约为 8 / 400 = 20 ms，总延迟约 100 ms，在这个简化假设下可行；若到达率降到 20 请求／秒，凑 batch 8 约需 400 ms，必然违约，调度器应设置超时，小 batch 立即发车。完整系统还要把网络、队列抖动、模型加载和共置干扰计入 120 ms 预算。

15. 实现与部署细节

在线优化器还要有时间预算。大规模 MILP 若在一个调度周期内无法稳定返回，应保留当前安全方案，并用分区、滚动时域、贪心初解或并行子问题缩短求解。RL 策略必须做离线回放、动作约束和小流量灰度；不能让模型探索越过显存、SLO 或租户隔离边界。

16. 论文中的实验与统计数字该怎样解释

这篇综述没有搭建统一 testbed，没有运行统一 trace，也没有把被引论文的 JCT、吞吐、成本或准确率归一化做 meta-analysis。论文自己的量化内容主要是背景数值和表格口径：

文中出现的“Tiresias 显著优于 YARN-CS”“ModelKeeper 显著缩短完成时间”“TrIMS 进行广泛评测”等措辞没有在综述正文统一列出可直接比较的百分比。要引用具体提升，必须回到对应论文，核对数据集、硬件、基线、指标定义和置信区间。把多个系统各自最好的数字放在一张排名表中，会制造虚假的统一实验。

17. 消融、开销、敏感性与证据强度

综述本身没有新系统，所以没有作者自己的消融实验、调度器运行开销曲线、超参数敏感性分析或统计显著性检验。它会说明机制风险，例如优化求解耗时、抢占数秒到数分钟、共享干扰、batch 弹性影响准确率、缓存命中依赖输入重复、异构亲和性随模型变化，但没有在统一条件下测量这些因素。

被引系统各自可能包含消融和开销证据，综述表格却没有逐项编码。因而不能据此断言某种机制已被充分验证。严谨核查至少要问：

论文提出的 13 条 Insight 是作者对文献的定性综合。例如异构 GPU 扩大决策空间、低单卡利用率给共享留下空间、推理共享更需防 SLO 违约、HPO trial 相似性可用于优化。这些是可信的设计假设来源，不是带统一效应量和置信区间的统计结论。

18. 局限、适用边界与复现核查清单

综述与 taxonomy 的局限

第一，文献选择不是系统检索，可能遗漏负结果、工业内部系统和后续工作。第二，分类把复杂系统压缩成目标与功能标记，同一标签下的指标定义可能不同。第三，训练主体假设数据并行为主，对超大模型的模型并行、流水线并行和细粒度状态管理覆盖不足。第四，表格的实机规模分档很粗，没有表示集群利用率、故障、拓扑、工作负载真实性、部署时长和 baseline 强度。第五，ML/RL 调度被视为处理复杂预测与动作空间的方向，但论文也指出其模型结构、学习算法、损失设计和实用性仍需 benchmark 验证。

把结论迁移到新集群时，应先验证三类假设：任务是否真的有可预测迭代或固定输入执行；资源动作是否被框架安全支持；业务目标是否与论文系统一致。低利用率不自动证明共享有益，异构硬件也不自动证明复杂优化胜过简单队列。调度收益只有超过 profiling、求解、迁移、干扰与运维成本才成立。

可执行的复现与核查清单

  1. 固定研究问题：明确是平均 JCT、makespan、公平、deadline、P99、准确率、吞吐、费用还是能耗；写清硬约束和优化目标，避免事后挑指标。
  2. 固定工作负载：公开模型、数据或合成生成器、到达 trace、训练 epoch、batch、输入形状、SLO、deadline、租户份额及随机种子；区分生产 trace 回放与人为压力测试。
  3. 记录环境：GPU 型号和数量、MIG 配置、CPU、内存、存储、PCIe／NVLink／网络拓扑、驱动、CUDA、框架、容器镜像、精度模式和功率上限。
  4. 实现基线：至少包括 FCFS／静态配额、一个短作业优先策略、一个资源感知策略；确保所有方案使用相同准入、执行器和可用信息，避免给新方法额外未来信息。
  5. 校准预测：把 profiling 集和测试 trace 分开，报告吞吐、持续时间、干扰与到达率预测误差及分位数；测试硬件、模型或流量漂移后的退化。
  6. 端到端计时：JCT 从提交开始，推理延迟从请求到达到响应完成；计入排队、求解、冷启动、加载、检查点、迁移、恢复、重算和失败重试。
  7. 验证语义：弹性训练比较最终指标、收敛步数和重复运行方差；模型切换比较准确率；缓存验证版本失效；共享验证隔离、最坏干扰与 OOM 行为。
  8. 做消融和敏感性：逐个关闭预测、共享、弹性、缓存或优化器；扫描负载率、作业规模、SLO 松紧、异构比例、预测误差和重配置开销。
  9. 报告分布：给出均值、中位数、P95／P99、deadline miss、每租户结果及多随机种子区间，不只给总体平均；同时报告利用率、费用和服务质量，暴露转移成本。
  10. 检查扩展性：测量每轮候选数、求解时间、控制面 CPU／内存与最大稳定事件率；证明决策在状态过期前完成，并测试控制器故障回退。
  11. 区分证据来源：标注哪些数字来自本次实机、仿真、论文引用或解释算例。跨论文数字只有在硬件、trace、指标和 baseline 可比时才横向展示。
  12. 保留复现材料：发布调度配置、trace 处理代码、profile、原始日志、统计脚本和图表数据；若生产数据不能公开，给出匿名化规则与等价合成生成器。

最终判断标准很朴素：一个调度器应在明确约束下，把“任务特征 → 性能预测 → 资源决策 → 运行时动作 → 反馈校准”闭环跑通，并用端到端证据证明收益没有被精度下降、SLO 违约、不公平或控制开销抵消。论文的双轴 taxonomy 能帮助定位设计，却不能替代这套验证。