待读论文

现有摘要支持哪些判断

UniTG 试图把文本属性图学习中原本分开的语言模型阶段和 GNN 阶段合成一次端到端训练，并在运行时、算法和执行调度三个层面共同消除规模与流水线效率问题。

两套训练流程为何彼此割裂

文本属性图同时有节点文本和图结构。常见做法先用语言模型生成或微调文本表示，再交给 GNN 学结构；摘要把现有方案的问题概括为四点：时间和资源效率低、解耦架构不灵活、可训练模型规模受限、没有充分利用图属性。这里的关键矛盾是：LM 和 GNN 各自可以优化，但两个阶段之间仍有中间表示、资源切换和执行空洞，最终 makespan 取决于整条链而不是某个 kernel。

摘要没有说明“现有系统”具体包括哪些方法，也没有披露是离线 LM embedding、交替训练还是某一种特定 textual graph learning 范式。不能据此断言 UniTG 淘汰了所有两阶段方法。

摘要能还原到哪一层

公开信息只足以还原下面这条高层路径：

1. 输入是带文本属性的图，训练同时涉及 LM 的文本建模和 GNN 的结构建模。
2. 运行时用 Affinity-aware Flow Parallelism 根据 graph affinity 扩展大图 GNN 训练。
3. 算法层用 Collaborative Learning 联合文本与图两种模态，使 LM 与 GNN 可以共同训练。
4. 执行层用 Streamlined Pipeline Schedule，把 LM fine-tuning 穿插进 GNN pipeline，压缩 pipeline bubble。
5. 输出是联合训练后的 textual graph learning 模型；摘要声称模型质量没有下降。

Flow 如何切分、affinity 如何定义、LM 参数何时更新、GNN pipeline 有几级、前反向依赖如何保持、跨阶段张量如何传递，公开摘要都没有给出。以上数据流不能再细化成可实现的执行图。

三个已公开组件

公开结果：17.3 倍

公开摘要声称：相对 state-of-the-art LM-based graph learning systems，UniTG 将 learning makespan 最多降低 17.3 倍，且不损害模型质量。这个结论来自作者主页摘要；当前没有 PDF 页码、图号或表号可核对。

实验设置证据不足：数据集、LM/GNN 型号、参数规模、GPU 型号与数量、网络、baseline 名单、makespan 定义、质量指标、平均值与方差、17.3 倍对应哪个 workload，均未公开。“without compromising model quality”也没有公开数值。这个 17.3 倍可以作为作者的总体结果陈述，不能用于复现预算或横向比较。

可能的贡献（等待全文验证）

如果全文证实摘要描述，UniTG 的贡献会是把图并行、联合学习和流水线放进同一端到端系统，让算法依赖与执行空洞共同影响并行计划。这样分析的是 textual graph learning 的整条临界路径，而不是彼此独立的 LM 和 GNN 加速阶段。

“first unified system”是作者在摘要中的优先权声明。缺少 related work 和系统定义时，现阶段不宜独立确认其“第一”。

公开材料没有回答什么

• 目前无法判断它适用于 node classification、link prediction、graph-level task 中的哪些任务。
• 无法判断 LM 与 GNN 是否必须同构部署，或是否支持异构 GPU、CPU offload、超大文本编码器。
• affinity-aware 并行可能依赖图结构或文本分布，但公开证据不足，不能判断对低局部性图是否仍有效。
• 17.3 倍没有实验上下文；全文公开前不应把它当成普遍速度上界。
• 没有代码、PDF 和消融，三层设计分别贡献多少无法核验。

与图训练系统的关系

UniTG 与本组另外三篇最直接的关系是“向上组合”。TorchGT 解决 Graph Transformer 的注意力和图并行，SYLVIE 解决消息传递 GNN 的边界消息通信，Lins 解决 LM 训练的模型状态分片；UniTG 则把 LM 与 GNN 两个阶段当成一条流水线。摘要没有说它复用了后三者，以下只能作为技术坐标，不是实现事实。

• 相对 TorchGT，UniTG 的对象多了文本模态和 LM fine-tuning；TorchGT 的 cluster-aware graph parallelism 可以帮助理解“graph affinity 如何进入运行时”，但两者 affinity/cluster 是否同义，证据不足。
• 相对 SYLVIE，UniTG 同样强调运行时反馈和流水线利用率，但 SYLVIE 的对象是分区边界消息，UniTG 还要处理 LM 与 GNN 跨阶段依赖。
• 相对 Lins，UniTG 的 LM 阶段理论上也会面对参数、梯度和优化器状态通信；摘要没有提 ZeRO 或独立状态分片，不能声称采用了 Lins。
• 在绿色论文全集中，它与 SPPO、Di-PS 同属大规模训练执行，与 Ymir/Titan/AutoSched 的集群调度层不同：UniTG 摘要描述的是单个联合训练作业内部的数据流与流水线，而调度论文通常决定作业之间如何分资源。

核对这篇时从哪里开始

现在只读作者页即可，顺序是问题四项缺陷 → 三层组件 → 17.3 倍结果。不要在机制名上停留太久，因为缺少定义。全文公开后，优先补读系统模型和执行时间线，再看 Collaborative Learning 的损失函数，最后核对实验中的 baseline、质量指标和三项消融；只有这四处齐全，才能判断 17.3 倍来自统一设计还是某个强单点优化。

TorchGT 串起哪三层

TorchGT 是一个面向长序列、大图 Graph Transformer 的算法-运行时-kernel 协同系统：用图拓扑稀疏注意力减少计算，用图社区重排和 all-to-all 扩展到多 GPU，再把不规则稀疏访问改造成可由 GPU cache 高效处理的 cluster-sparse 布局。

三个性能障碍

Graph Transformer 把节点当 token。标准 attention 允许任意节点对相互作用，计算和显存复杂度是 O(N^2)；真实图有百万节点时，FlashAttention 也只能优化 IO，不能消掉二次方节点对。论文的 profiling 显示 attention 在不同序列长度和 3090/A100 上都占训练时间的 80% 以上（PDF 第 4 页，图 2）。

直接按邻接矩阵做 sparse attention 又有两个问题。第一，只看局部邻边会丢高阶或全局关系，收敛可能低于 full attention。第二，真实图的度分布和边布局很不规则，稀疏算子会大量随机访存和原子操作，理论 FLOPs 下降不等于 GPU 吞吐上升。现有 LLM sequence parallelism 也没有图结构编码和节点可重排这一前提。

长序列不是单纯追求规模。论文用 Graphormer/AMiner-CS 和 NodeFormer/Pokec 说明更长序列可提高质量：4K 相对短序列最高提升约 0.9 个百分点，100K 相对 10K 提升约 12 个百分点（PDF 第 3 页，图 1）。

训练数据怎样流动

先看一次 Graph Transformer layer 在 TorchGT 中怎样走：

1. 预处理阶段用 METIS 识别社区并重排节点，使同社区节点 ID 邻近，同时保留原图连接关系。
2. 输入节点序列 S 和图结构编码 B 沿序列维分到 P 个 worker；每个 worker 先得到局部 Q_sub/K_sub/V_sub/B_sub。
3. attention 前执行一次 all-to-all：把完整序列维收集到本 worker，同时沿 attention head 维切分，形成 Q/K/V/B ∈ R^(S × d/P)。
4. Dual-interleaved Attention 根据局部拓扑计算稀疏 attention；不满足全局可达条件时插入 fully-connected attention，补回全局信息。
5. Cluster-aware Graph Parallelism 按社区重新组织 attention 布局，把高局部性的节点对放近。
6. Elastic Computation Reformation 把仍然不规则的稀疏 cluster 转成若干紧凑 sub-block；Auto Tuner 决定哪些 cluster 转、block 多大，并根据训练损失动态调整阈值。
7. attention 输出再经一次 all-to-all 变回各 worker 的局部子序列，然后进入 FFN 和 layer normalization。

两次 all-to-all 的每 GPU 通信量是 4Sd/P：attention 前 Q/K/V 共 3Sd/P，输出 Sd/P。相较通信复杂度 O(S) 的 all-gather，这一路径按 worker 数下降为 O(S/P)（PDF 第 7 页，图 4 及 §III-C）。

同一图结构如何贯穿三层

模型、数据与硬件

• 实现：PyTorch 2.1。
• 节点任务：Amazon、ogbn-arxiv、ogbn-products、ogbn-papers100M；图任务：ZINC、ogbg-molpcba、MalNet。最大数据集有 111,059,956 个节点和 1,615,685,872 条边（PDF 第 8 页，表 III）。
• 模型：4 层/64 hidden/8 heads 的 GraphormerSlim，12 层/768 hidden/32 heads 的 GraphormerLarge，4 层/128 hidden/8 heads 的 GT（PDF 第 8 页，表 IV）。
• baseline：原始 graph parallelism 的 GP-RAW、加入 FlashAttention 的 GP-FLASH、拓扑 sparse attention 的 GP-SPARSE。没有现成大图 Graph Transformer 系统可直接比较，因此 baseline 是作者复现的变体。
• 硬件：论文列出 3 台 8×RTX 3090、PCIe 4.0、跨机 1GbE，以及 2 台 8×A100、NVLink、跨机 200Gbps InfiniBand（PDF 第 8 页）。扩展实验又使用到 64 张 A100，即 8 台服务器（PDF 第 10 页，图 7）；论文没有解释这与前述“2 台 A100”的资源描述差异。

方法贡献

TorchGT 让同一份图结构贯穿三层实现：算法层决定哪些节点对需要 attention，运行时用节点可重排性和社区划分构造并行布局，kernel 再把 irregular sparse 改造成 cache 友好的 sub-block。三个层次共用一套图属性，算法稀疏、并行切分和 kernel layout 因而不会各自为政。

另一个重要点是把质量控制放进系统。它没有假设 sparse attention 永远等价于 full attention，而是用条件检查和 loss feedback 决定何时增加 dense 信息、何时减少 cluster 转换。

适用范围和未覆盖问题

• 收益高度依赖图稀疏度和社区结构。论文也承认 ogbn-arxiv 的 sparsity/cluster property 较弱，因此加速较小（PDF 第 9 页，表 V 后分析）。
• GP-RAW 和 GP-FLASH 是作者构建的变体，不是成熟的独立系统；62.7× 不能直接解释为相对所有图训练系统的优势。
• GP-FLASH 受 BF16 限制，而主要 TorchGT 结果用 FP32。表 VII 给了同精度控制，但整张表 V 的“速度和精度同时领先”仍需按精度拆开读。
• Elastic Computation Reformation 会重新安排 cluster 内边连接，论文依靠动态阈值控制误差，而不是保证变换严格保持原图。极端依赖精确边语义的任务要单独验证。
• METIS 和布局转换有离线成本；频繁变化的动态图、短任务或只跑少量 epoch 时，预处理可能不再可忽略。
• 论文声称 task-agnostic，但实验覆盖的是节点分类、图分类和回归中的若干模型，不等于所有 graph transformer 架构和任务都已验证。
• 硬件描述与 64-GPU 扩展实验的服务器数量口径不完全一致，复现者需要向代码或作者补证据。

与图训练论文的关系

• 与 SYLVIE 都利用图结构做系统决策。TorchGT 使用社区和稀疏 attention，处理的是节点对计算与显存；SYLVIE 使用边界节点入度，处理的是分区消息通信。二者不能直接互换，因为 Graph Transformer 和 message-passing GNN 的瓶颈不同。
• 与 UniTG 都采用算法、运行时、执行层协同。TorchGT 的完整实现可以作为理解 UniTG “graph affinity 进入 parallelism”时的参照，但没有证据表明 UniTG 复用了 METIS、all-to-all 或 cluster-sparse layout。
• 与绿色论文 DSA: Distributed Sparse Attention 的共同点是通过结构化稀疏减少 attention；差异是 DSA 面向视频生成推理，TorchGT 的稀疏来源是真实图拓扑且服务训练收敛。
• 与 SPPO 都处理超长序列训练，但 SPPO 面向 LLM token sequence，TorchGT 利用“节点顺序可交换”这一图特性，不能直接移植到语言序列。

核对机制时从哪里开始

先读 PDF 第 3-4 页的图 1、图 2，确认“长序列既影响质量又形成 attention 瓶颈”。随后连读第 5-8 页：先 Dual-interleaved Attention，再 Cluster-aware Graph Parallelism，最后 Elastic Computation Reformation；图 4 和图 5 是数据流主线。实验先看第 9 页表 V 和表 VII，把速度与精度控制分开，再看第 10 页图 9 的长度扩展，最后用第 11 页表 VIII 检查动态阈值是否真的必要。

Lins 改了 ZeRO 的哪项约束

Lins 不再强迫参数、梯度和优化器状态使用同一个 ZeRO 分片组，而是分别选择“全复制、全分片或部分分片”及其机内/跨机 device mesh，在显存约束下搜索通信时间最低的组合。

显存省下来后，通信为何变成瓶颈

混合精度 Adam 训练中，每个参数大致对应 2 字节参数、2 字节梯度和 12 字节优化器状态，LLaMA-7B 的模型状态合计约 112 GB，单张 80 GB A100/A800 放不下。ZeRO-1/2/3 逐步切分优化器状态、梯度和参数，但分得越彻底，越依赖 AllGather、ReduceScatter 和 AllReduce。

问题在大规模时被放大：机内 NVLink 与跨机网络带宽不同，collective 参与者越多延迟越高，固定 global batch 下每 GPU micro-batch 越来越小。论文测得 ZeRO-1 训练 LLaMA-7B 从 8 GPU 扩到 1024 GPU 时，MFU 从 63% 降到 36%；ZeRO-3 训练 LLaMA-13B 则从 47% 降到 4%（PDF 第 3 页，§III-A）。

MiCS 和 ZeRO++ 用更多副本换更小通信组，但它们仍要求 s_p = s_g = s_os。Lins 的判断是，参数 P、梯度 G、优化器状态 OS 的大小、访问时机和 collective 并不相同，不该绑定成同一个分片因子。

规划与执行的数据流

Lins 的离线规划和在线执行是一条清晰链路：

1. 用户输入模型结构与训练超参数，包括层数、序列长度、micro-batch 大小和数量，以及 GPU 数量、节点数和显存容量。
2. Communication Profiler 在目标集群上测量 AllGather、ReduceScatter、AllReduce、Broadcast 在不同消息大小和 机内 GPU 数 × 节点数 mesh 下的有效带宽；未测点用插值估算。
3. Pre-Filter 用依赖规则去掉明显产生冗余存储或跨机通信的方案。
4. Solver 在显存约束下最小化 T_p + T_g + T_os^0 + T_os^1，得到 P/G/OS 各自的机内和跨机分片因子。
5. Executor 通过 PyTorch hook 执行选定计划。参数按 module 粒度 AllGather，反向后 ReduceScatter；梯度按 bucket AllReduce 后 select-and-drop；持有不同 optimizer shard 的 GPU 更新各自参数，再 Broadcast 给同参数副本组。
6. 这些 collective 尽量与相邻 module 的前反向计算重叠，并优先把通信限制在节点内。

这里 s_i = s_i^0 × s_i^1，s_i^0 是节点内参与 GPU 数，s_i^1 是参与节点数。Lins 强制 s_p ≤ s_g ≤ s_os ≤ s_dp，分别在机内和跨机维度成立，避免某张卡维护与本地参数无关的梯度或优化器状态（PDF 第 5 页，§IV-B）。

从 ZeRO stage 到状态级搜索

模型、集群与对照

• 实现：PyTorch 2.1 hook、FlashAttention-v2、BF16。
• 模型：LLaMA-7B、13B、30B。
• 集群：128 台服务器，每台 8 张 80 GB A800，共 1024 GPU；机内 NVLink，跨机 4 张 Mellanox HDR InfiniBand NIC，不启用 SHARP（PDF 第 8 页）。
• baseline：DeepSpeed ZeRO-1、ZeRO-3、ZeRO++、MiCS。ZeRO++ 关闭量化以保持模型质量一致。
• 所有实验 sequence length 为 4096，micro-batch 为 1 条 4096-token 序列，global batch 固定 4M tokens；8 GPU 时有 128 个 micro-batch，1024 GPU 时每 step 只剩 1 个。实验只保留 data parallelism，不使用 tensor parallelism 或 pipeline parallelism（PDF 第 8 页）。

方法贡献

Lins 把 ZeRO stage 从离散的“1/2/3 级”改写成一个模型状态级别的布局优化问题。参数、梯度、优化器状态有不同容量和生命周期，独立 mesh 让系统能用显存冗余换取恰好需要的通信缩减，而不是统一复制或统一分片。

另一个实用创新是把通信算法和网络拓扑的不确定性留给 profiler，而不是假设理论带宽。这样搜索问题仍然简单，集群特性却能进入决策。

适用范围和代价

• 评估刻意不使用 tensor/pipeline parallelism，尚未证明独立状态分片与完整 3D parallelism 联合搜索时仍能得到同样收益。
• 固定 4M-token global batch 使 1024 GPU 时每 step 仅 1 个 micro-batch，通信/计算比非常不利。它能突出问题，但不代表所有生产训练的 batch 与扩展策略。
• 只测 7B-30B LLaMA 架构、4096 长度和 A800 集群；更大模型、MoE、长上下文或异构网络需要重新 profile 并验证内存模型。
• profiler 依赖目标集群的 NCCL 和网络状态。拓扑变化、拥塞或 SHARP 等 in-network aggregation 会让旧 profile 失准。
• ZeRO++ 为保持质量关闭量化，Lins 又为公平关闭 Broadcast-forward overlap。比较回答的是“独立分片策略”而不是各系统开启全部功能后的绝对最优值。
• 主实验没有给训练 loss/下游精度，因为各方案在同一 BF16 计算路径下主要改变状态布局；这支持语义等价预期，但不能替代长时间训练收敛验证。

与训练通信论文的关系

• 与 UniTG 互补：Lins 优化 LM 阶段的模型状态，UniTG 摘要描述 LM-GNN 联合流水线。能否把 Lins 作为 UniTG 的 LM runtime 仍是组合设想，不是论文证据。
• 与 TorchGT 都做 device mesh 和通信优化，但数据依赖不同。TorchGT 沿 sequence/head 做 all-to-all，Lins 沿 P/G/OS 副本组做 AllGather、ReduceScatter、AllReduce 和 Broadcast。
• 与 SYLVIE 都以“多占一点显存/副本换更少通信”为核心权衡。SYLVIE 压缩边界 embedding，Lins 不近似数据而是改变精确模型状态的放置，因此 Lins 不引入量化误差。
• 与绿色论文 Di-PS、SPPO 同属训练并行层；与 Ymir/Titan/ICEFROG 等调度器不同，Lins 决定单个作业内模型状态放在哪些 GPU，调度器决定多个作业怎样获得 GPU。

核对数字时从哪里开始

先读第 2-4 页：ZeRO 状态大小、图 2/图 3 的扩展问题、MiCS/ZeRO++ 为什么仍受统一分片限制。再读第 5-6 页图 4/图 5，把 P、G、OS 的 collective 分开追踪；随后读第 7 页表 III 和式 1-7，理解 solver 到底选择什么。实验先看第 8 页图 8，再回表 III 对照三种 LLaMA 的布局，最后看第 9 页图 10，确认速度来自主动使用显存余量。

SYLVIE 压缩哪类消息

SYLVIE 是面向分布式 full-graph GNN 训练的自适应通信系统：离线用节点入度判断哪些边界消息更怕量化误差，在线按收敛速度调整每个节点的 bit-width，并在同步与跨 epoch 异步流水线之间切换。

边界消息为何主导通信

full-graph 训练先用 METIS 把图分到多张 GPU。一个 partition 中的节点要聚合其他 partition 的邻居，因此每层 forward 要收 boundary embeddings，backward 要回传 boundary embedding gradients。论文在 ogbn-products、4 GPU 的例子中，4-layer GraphSAGE-128 每 epoch 传 1.56 GB embedding 和 1.55 GB embedding gradient，但 weight gradient 只有 0.40 MB；4-layer GCN-256 则是 6.20 GB 对 0.65 MB（PDF 第 3 页，表 II）。

DGL profiling 中通信最多占 epoch 时间 89.23%（PDF 第 3 页，图 2）。静态 1-bit 量化可以把通信时间降 89.8%、epoch 时间降 84.2%，却会伤害精度；例如 8-layer JKNet/Reddit 从 FP32 的 92.75% 降到 INT1 的 90.91%（PDF 第 4 页，图 3、表 IV）。异步 pipeline 可隐藏剩余通信，但边界消息会陈旧，误差随层数累积，深 GNN 更容易不收敛。

一次训练轮次的数据流

SYLVIE 分成 offline 和 online 两阶段：

1. 图先由 METIS 分区。Graph Extractor 统计整个图中的 boundary node 全局入度，按入度排名生成 0-1 importance factor 和 node mask。
2. 每个 epoch 开始时，Quant Orchestrator 根据历史 loss 和 epoch time 选基础 bit-width b_t ∈ {1,2,4,8}，再用 node mask 为每个 boundary node 上调或保持 bit-width。
3. 每层 forward/backward 中，只对需要跨 partition 的 embedding 和 embedding gradient 做 stochastic integer quantization；每个向量同时传 min/scale。
4. 量化消息通过 torch.distributed ring all-to-all 发送，接收端恢复为 FP32，再参与本地聚合和更新。
5. Pipeline Adaptor 根据同一个 loss descent rate 决定下一 epoch 同步执行，还是让当前通信与计算重叠、到下一 epoch 使用一轮陈旧的 boundary message。
6. Coordinator 汇总各 partition loss，更新 bit-width 和执行模式，并继续监控吞吐与收敛。

“3D-adaptive”指 data、time、execution 三个维度，不是 LLM 训练中的 data/tensor/pipeline 3D parallelism。

三个自适应维度如何控制误差

图数据、模型与硬件

• 实现：DGL 0.9、PyTorch 1.10、torch.distributed ring all-to-all、METIS 最小通信量分区。
• 数据集：Reddit、Yelp、ogbn-products、Amazon、ogbn-papers100M；后者有 111,059,956 节点、1,615,685,872 边和 172 类（PDF 第 9 页，表 V）。
• 模型：浅层 GraphSAGE/GCN，深层 GCNII/DAGNN/SGC/JKNet，特殊 aggregator GAT；层数最高 8（PDF 第 9 页，表 VI）。
• baseline：DGL、SAR、PipeGCN、BNS-GCN。原 baseline 没有实现深 GNN，作者自行补了兼容版本，并只报告各自能支持的模型。
• 硬件：每台 8×RTX 3090、PCIe 4.0、跨机 1GbE；另有每台 8×A100、NVLink、跨机 200Gbps InfiniBand（PDF 第 9 页）。

方法贡献

SYLVIE 用同一个训练反馈信号约束量化噪声和异步陈旧。节点入度提供“哪条消息更敏感”的数据维先验，LDR 估计当前训练阶段能承受多少误差，Pipeline Adaptor 据此决定是否允许陈旧消息。三个机制共享一份收敛预算，调整时会彼此牵制。

它还准确抓住 GNN 与普通 DNN/LLM 的通信差异：瓶颈是每层 boundary embeddings 和 embedding gradients，不是小得多的 weight gradients。因此传统 gradient compression 不是这里的主要解法。

适用范围和误差边界

• 它只面向 distributed full-graph training。图 partition 必须能放入各 GPU/服务器的合计显存；采样式超大图训练是另一条路线。
• 重要性只由全局入度排名近似。低度但语义关键的节点、异配图、动态边或 attention 权重主导的任务未必服从这一误差模型。
• 量化和异步都是近似。表 VII 中部分任务仍有 0.2-0.4 个百分点下降，不能把摘要的“without compromising accuracy”理解成严格等精度。
• 两台 3090 的跨机网络只有 1GbE，会放大通信压缩收益。A100/200Gbps 实验提供了更可信的强网络对照，但不少速度数字会缩小到 4.3× 左右。
• 深模型 baseline 是作者移植，不是各系统原生实现；不收敛既反映方法局限，也可能受移植质量影响。
• 论文验证到 8 层和所列六类 GNN。“universal/model-agnostic”表示接口和策略不绑定 GCN，不等于任意 GNN、动态图或异构图已经验证。
• METIS、入度统计和 node mask 是离线步骤。动态图或短训练任务中，重做这些步骤的成本需重新计算。

与图训练论文的关系

• 与 TorchGT 是图系统中的互补分支。SYLVIE 的核心张量是跨 partition 的 embedding/gradient，TorchGT 的核心张量是 Q/K/V 和 attention map；前者优化 message passing，后者优化 all-pairs attention。
• 与 UniTG 的联系在 GNN 阶段和 pipeline。SYLVIE 证明量化后通信更短，pipeline 才更容易覆盖剩余延迟；UniTG 摘要也强调把 LM fine-tuning 插进 GNN pipeline，但是否使用边界量化和 staleness control 未知。
• 与 Lins 都先建立通信-显存/精度权衡再动态选策略。Lins 通过精确复制状态使用更多显存，不改变数值；SYLVIE 通过量化和陈旧消息减少字节，会引入受控误差。
• 与绿色调度论文 ICEFROG/AutoSched/Ymir 的层级不同。SYLVIE 在作业内按 epoch 和 node 改执行；调度器在作业间分配 GPU。两层可组合，但一个不能替代另一个。

核对机制时从哪里开始

先读第 3-4 页表 II、图 2、表 IV，建立“传的是什么、静态 INT1 为什么不够”的直觉。然后按第 5 页图 4/图 5 走一次数据流，再读第 6 页 Graph Extractor、第 7 页 Quant Orchestrator、第 8 页 Pipeline Adaptor。实验不要从 17.2× 摘要开始，先看第 10 页表 VII 的速度与准确率成对数字，再看第 11 页表 X/XI 的消融，最后看第 12 页表 XII，确认加速确实来自通信量下降。

Ymir 调度哪些决定

Ymir 是一个面向基础模型微调（FMF）的集群调度器：它预测两个下游任务做 temporal/spatial transfer 是否能更快收敛，把“是否合并任务”和“分多少 GPU”放进同一个 ILP，并复用微调运行时来压低频繁切换的代价。

基础模型微调有哪些可复用结构

传统 DLT scheduler 往往通过共置或弹性扩缩容提高利用率，但 FM 微调有三个不一样的条件。第一，模型大、显存占用高，共置容易 OOM；第二，多 GPU 运行时初始化、权重装载和数据准备很重，频繁扩缩容可能得不偿失；第三，数据中心里大量作业实际共享少数热门 backbone。作者统计 Hugging Face 下载量时，热门前 10 个模型占 top-100 vision FM 下载量的 83%，占 language FM 的 89%（PDF p.2，Fig. 1）。这意味着同一个 backbone 上的下游任务不是完全独立的，它们可能共享已经学到的任务知识，也可以共享已经启动的运行时。

论文把 transfer 分成三种执行方式（PDF pp.2-3，Fig. 2）：

• Normal transfer：每个任务都从预训练 backbone 独立开始微调。
• Temporal transfer：先完成任务 A，再以 A 的微调权重初始化任务 B，记为 A -> B。
• Spatial transfer：A、B 作为多任务训练共同微调，记为 A || B。

动机实验不是只说“迁移可能有效”。在 RoBERTa-Base 上，先做 STSB 再做 QQP，可把 QQP 达到目标精度所需 epoch 数减少 2.3 倍；在 ViT-Base 上把 FOOD101 与 ImageNet75 联合训练，可把后者所需 epoch 数减少 2.0 倍（PDF p.3，Fig. 3）。跨全部测试组合，temporal 和 spatial transfer 的 TTA 最多可加速 10 倍，而且超过一半组合有正收益（PDF p.3，Fig. 5）。难点在于负迁移同样存在，所以调度器必须先估计，不能见到相同 backbone 就直接合并。

从任务到 ILP 的数据流

Ymir 的在线路径分三段（PDF p.4，Fig. 6）。用户提交 YAML，给出模型、数据集、超参数、停止条件、是否允许参数共享以及是否使用 pipeline parallelism。新作业先获得少量 profiling 资源，YmirEstimator 采集 loss、gradient 等统计信息，预测 normal、temporal、spatial 三种模式在不同 GPU 数量下的完成时间。YmirSched 随后联合求解任务配对、迁移模式与 GPU 分配。YmirTuner 按求解结果实例化任务，并提前准备 dataloader 或流水化搬运参数。完成后返回用户需要的权重。

YmirEstimator 的预测链是：迁移收益 -> 收敛迭代数 -> 单迭代时间 -> 作业完成时间（PDF p.4，Fig. 7）。YmirSched 每 120 秒重算一次，用 ILP 在公平性目标上加入 transfer speedup 权重；不值得合并的组合会先被过滤。YmirTuner 则负责让这一调度频率在大模型微调中真正可执行，而不是让重启和装载吞掉收益。

四个调度机制

任务、硬件与对照

物理集群有 8 个节点，每节点 4 张 V100 SXM2 32GB、64 CPU cores、256GB 内存和 200Gbps HDR InfiniBand；Vicuna-7B 因显存需求改用 A100 SXM4 80GB。系统基于 Transformers 2.4.1、PyTorch 1.7、Kubernetes 1.18.2 和 CephFS 14.2.8，共 5,967 行 Python（PDF p.8，Sec. 7.1）。测试覆盖 ViT-Base、RoBERTa-Base、Vicuna-7B，各自 9 个数据集，共 27 个 FMF task。物理 workload 从上海 AI Lab trace 抽样 120-240 jobs；仿真抽样 1,500-3,000 jobs，集群规模为 60 个四卡节点，即 240 GPUs（PDF pp.8-9，Sec. 7.1）。

基线包括 Tiresias、Optimus、Pollux，公平性比较另加 Themis 和 preemptive SRTF。物理实验中，Ymir 的 average JCT 相对基线加速 1.11-4.34 倍，99th-percentile tail JCT 加速 0.89-3.56 倍（PDF p.9，Fig. 10）。在 240-GPU 仿真、1-2 倍负载下，JCT 加速为 1.66-22.3 倍（PDF pp.9-10，Fig. 11）。约 20%-30% 作业最终采用了 temporal 或 spatial transfer（PDF p.9，Table 5）。

任务合并没有以牺牲指标换速度。相对 normal transfer，三个 FM 上报告的最小指标提升均不低于 0；Vicuna-7B 的 spatial transfer 在 SAMSUM BLEU 上出现最大 68.82% 的相对提升，但平均提升是 14.74%，不能把这个极值泛化到所有任务（PDF p.9，Table 4）。模拟器与物理实验的 average JCT 差异为 3.24%-8.77%，tail JCT 差异为 0.74%-10.82%（PDF p.9，Table 3）。

方法贡献

迁移学习加速微调本身并不新。Ymir 把过去由模型开发者判断的任务关系变成 scheduler 可估计、可优化、可撤销的决策变量。系统同时改变了三层抽象：作业不再是独立黑盒；完成时间除了吞吐和剩余 iteration，还取决于 partner 与 transfer mode；preemption 也可以保留运行时。相比只优化单 job PETL 或 pipeline 的工作，这是一种 cluster-wide algorithm-system co-design。

适用范围和预测风险

• 主设计和评测假定集群内作业共享一个 FM backbone。多 backbone 只提出按 FM 分 quota 的设想，没有完成联合调度评测（PDF p.11，Sec. 9）。
• 每次最多合并两个任务。三任务及以上缺少可靠的 transfer-gain estimator，ILP 变量也会进一步膨胀（PDF p.11，Sec. 9）。
• Spatial transfer 只适合尚未产生进度、仍共享初始 backbone 权重的任务（PDF p.7，脚注 3）。
• 用户需要允许共享任务参数。虽然不直接共享数据，参数仍可能泄露 membership 信息；系统只能让用户关闭 sharing，并没有提供隐私保护协议（PDF p.11，Sec. 9）。
• 收益依赖 workload 中确实有可迁移任务对，也依赖 PETL 能减轻 catastrophic forgetting。若任务高度异质、backbone 分散或用户普遍拒绝共享，Ymir 会退化成带 profiling/LUT 的普通弹性调度器。
• Pipeline Switch 的收益依赖 PCIe 带宽和可重叠空间；参数搬运本来就很快时，它不会带来同样比例的收益（PDF p.8，Sec. 6.2）。

与微调调度论文的关系

• 与 Hydro：两者都利用“模型结构重复”做跨作业优化，但边界正好相反。Hydro 在同一数据分布上缩小并融合 HPO trials，理论上不支持 fine-tuning；Ymir 专门处理不同下游数据集的 fine-tuning，通过 task transferability 判断能否共享知识。
• 与 UniSched/CHRONUS：UniSched 把 job type、deadline、profiling 和 placement 统一到 reward-based MILP；Ymir 把 transfer mode 和 task pair 加进相似的联合优化框架。前者的语义来自用户需求，后者的语义来自任务梯度关系。
• 与 ICEFROG：ICEFROG 让“冻结多少层”成为影响吞吐、显存和精度的弹性维度；Ymir 的 LUT 也显式把 frozen layers 放入配置键。两篇都在突破 scheduler 只看 GPU 数和剩余时间的黑盒模型。
• 与 PromptTuner：PromptTuner 面向有 SLO 的短时 prompt tuning，并强调 warm GPU pool 和 prompt reuse；Ymir 面向更一般的 FM fine-tuning，以 task transfer 和低成本 context switch 为中心。二者都说明微调不能直接套普通长作业调度模型。
• 与 Titan、SchedMate：Titan 关注 FM fine-tuning 的 pipeline scheduling，但不利用跨任务 transfer；SchedMate 从代码、日志提取作业语义，而 Ymir 从 loss/gradient 提取可迁移性。它们分别扩展了执行层、观测层和优化变量。

核对收益时从哪里开始

先看 Fig. 2-5，确认三种 transfer mode 和 FMF 的特殊性；再看 Fig. 6-7，把三个组件及预测链串起来；随后重点读 Sec. 5 的 Eq. 7、12、13，理解迁移收益怎样进入调度目标；Sec. 6 只需抓住 data/pipeline 两种 switch；最后用 Fig. 10-14 和 Table 4、6、7 区分端到端收益、迁移收益和运行时复用收益。Sec. 4 的曲线公式可以第二遍再细读。

AutoSched 改的是哪一层

AutoSched 是运行在现有 DLT scheduler 旁边的自动配置服务：它预测下一时段将存在和到达的作业，用模拟器、因果模型和 trace aggregation 快速搜索配置，再在线更新 Tiresias、Themis、Lucid 这类调度器的参数。

固定配置为何会过时

GPU scheduler 的性能不只由算法名称决定，还高度依赖 queue 数量、priority、starvation threshold、lease term、placement threshold、profiler capacity、packing knob 等配置。生产实践通常用一段历史 trace 找一次“最佳参数”，部署后长期不动。但 GPU workload 的提交密度、资源需求和运行时长都在变，固定参数很快过时。

论文在 Helios 上展示，同一天里的 cluster utilization 和每 5 分钟提交量明显变化（PDF p.2，Fig. 1）。三条生产 trace 的作业持续时间从秒到数十天；Helios 的提交周期约为 23 小时；PAI 中约 60% 作业会以同一 task semantic 重复超过 10 次（PDF pp.2-3，Fig. 2）。这些现象带来两个困难：刚收集完的“上一小时 trace”仍可能漏掉长期未完成作业和下一小时到达；而在庞大的混合离散/连续配置空间里逐个仿真也来不及。

动机实验中，固定配置的 average JCT 最坏可达按上一小时动态调参的 3.8 倍；但后者使用过时历史 trace，相比知道真实未来 workload 的 oracle 又会慢到 1.4 倍（PDF p.4，Fig. 4b-c）。因此 AutoSched 同时解决“拿什么 workload 调”和“怎样在时限内调完”两个问题。

预测、搜索与更新的数据流

离线阶段，operator 提供配置空间、参数依赖约束、优化目标和中间性能指标。系统从历史 workload 训练 Local Predictor，并用模拟器样本学习配置、中间指标和最终目标之间的因果图。

在线阶段每轮先由 Generation Engine 生成未来窗口：Global Generator 预测 future-arrival jobs，Local Predictor 补上 existing-unfinished jobs。Search Controller 对这段合成 trace 搜配置：BlueFin 采样，约束投影修正非法组合，因果模型淘汰明显差的候选并缩小下一轮搜索范围，Trace Aggregator 则减少模拟器需要处理的 job 数。找到配置后，Scheduler Controller 调用现有 scheduler 的 API 更新参数，并持续把新状态写回 workload repository（PDF pp.4-5，Fig. 5-6）。

默认每小时更新一次配置，最大搜索轮数为 40；后台 causal tuner 可每 5 分钟运行，只有候选目标比当前配置好到预设阈值时才切换，论文示例阈值为 1.1（PDF p.7，Sec. 4.2）。

四个配置机制

Trace、调度器与对照

评测使用三段各两周的生产 trace：Philly 为 2017-09-22 至 2017-10-06，Helios 为 2020-07-26 至 2020-08-09，PAI 为第 84-98 天。模拟容量分别设为 100、70、100 台八卡服务器，即 800、560、800 GPUs（PDF p.7，Sec. 5.1）。目标 scheduler 为 Tiresias、Themis、Lucid；基线是全程固定参数的 Fixed、按历史 trace 动态调参的 SelfTune，以及直接知道真实未来 workload 的不可实现 Optimal。

Local Predictor 的 XGBoost 分类准确率在 Philly、Helios、PAI 上分别为 88.21%、90.41%、82.68%，每 1,000 样本推理和 fine-tuning 延迟分别为 0.0331 秒和 0.3291 秒（PDF p.7，Table 3）。去掉 user information 后，Helios 和 PAI 的准确率分别下降 3.77% 和 7.18%（PDF p.8，Sec. 5.2）。因果性能模型在三条 trace 上的平均相对误差为 14.23%、11.17%、15.16%，每 1,000 样本推理 0.0927 秒、在线 fine-tuning 1.4731 秒（PDF p.7，Table 4）。

端到端结果需要按 scheduler 分开看：

• Tiresias：AutoSched 相比 SelfTune 的 average JCT 加速 1.10-1.36 倍（PDF p.8，Fig. 9）。Causal Tuner 将搜索开销降低 9.5-22.7 倍，Trace Aggregator 再降低 2.6-5.8 倍，两者合计最高 132 倍，多数搜索在半分钟内完成（PDF p.9，Fig. 11-12）。
• Themis：相对 Fixed，满足 finish-time fairness <= 1 的作业数提升 1.07-1.12 倍；Search Controller 在 Philly、PAI 上分别改善该比例 4% 和 5%（PDF pp.9-10，Fig. 13-14）。Causal Tuner 与 Aggregator 分别降低 4.8-5.5 倍、1.9-3.9 倍搜索开销（PDF p.10，Fig. 15-16）。
• Lucid：论文正文报告 AutoSched 相比 SelfTune 的 JCT 加速最高为 1.15-1.17 倍；Search Controller 自身会让 average JCT 增加不超过 5%，但 causal tuner 和 aggregator 可把配置延迟分别降低最多 3.4 倍和 5.7 倍（PDF pp.10-11，Fig. 18-20）。

方法贡献

AutoSched 将未来 workload 构造与配置搜索分开，并针对 DLT 作业的时间尺度设计控制路径。Global/Local 两路预测区分“尚未到达”和“已经占着 GPU 但不会在 trace 窗口内结束”的负载；因果图按参数依赖与 trade-off 剪枝，trace aggregation 则压低单次评估成本。组合后的重配置周期可以缩短到小时乃至分钟级，每个模块也能单独校准并在失效时回退。

漂移、预测与仿真的限制

• 主评测全部基于 trace simulator，没有真实 GPU 集群上的配置切换实验。结果证明的是 trace-driven scheduling outcome，不包含真实 control-plane 抖动、配置热更新失败或 profile 偏差。
• Global Generator 强依赖周期性和历史相似片段；真正的新业务、节假日或异常事件没有可匹配历史。论文的应对方式是后台重新调参，而不是提前准确预测（PDF p.11，Sec. 6）。
• Local Predictor 只预测时长区间，再从历史分布采样，适合重复性高的 workload；对首次出现的大模型训练或代码大改后的 job，误差可能更大。
• Operator 仍要给出配置空间、依赖约束和中间指标。AutoSched 自动的是搜索与更新，不是自动理解任意 scheduler 源码。
• 小于等于 32 GPUs 的小集群里，配置对宏观调度结果的影响可能太小，论文明确认为收益有限（PDF p.11，Sec. 6）。
• 搜索压缩可能牺牲最优性。Lucid 的配置空间较小时，Search Controller 反而使 JCT 增加不超过 5%，说明剪枝不是免费午餐（PDF p.11，Fig. 19 与 Sec. 5.5）。

与调度论文的关系

• 与 UniSched：UniSched 决定 job selection、lease 和 placement；AutoSched 可以位于它的上层，调 SLO lease、reward ratio、profiling quota 或 solver 触发参数。前者是 data-plane scheduling policy，后者是 scheduler control loop。
• 与 Lucid、Tiresias、Themis：这三者不是普通 baseline，而是被 AutoSched 直接增强的对象。AutoSched 的贡献必须通过它们的 queue、fairness lease、packing/profiler knobs 才能体现。
• 与 SchedMate：AutoSched 主要从 trace 的时间与资源属性预测未来，SchedMate 从源代码、日志和历史任务抽取语义。后者可补足 Local Predictor 面对代码变化和新任务时的信息缺口；前者则提供配置搜索与闭环更新。
• 与 Characterization and Prediction of Deep Learning Workloads in Large-Scale GPU Datacenters：AutoSched 直接建立在 recurrence、duration 和 resource-demand characterization 上，可视为把 workload prediction 真正接进 scheduler reconfiguration。
• 与 Ymir/ICEFROG：Ymir 和 ICEFROG 都给 scheduler 增加了新的算法级状态与 knob。若要长期部署，它们的 scheduling interval、fairness weight、profiling quota、layer/transfer threshold 同样会随 workload 漂移，AutoSched 提供的是更高一层的自动调参思路。

核对配置收益时从哪里开始

先读 Fig. 2-4，确认为什么“上一小时最优参数”仍然不够；再用 Fig. 5 理解离线/在线闭环；重点读 Sec. 3.2 的两类 workload 与 Algorithm 1 的六步 causal tuning；Trace Aggregator 只需抓住 service preservation。实验按 Tiresias、Themis、Lucid 三个 case 分别读，不要把 JCT、FTF 和搜索加速混成同一个指标。最后读 Sec. 6，那里直接说明小集群、弱周期和小配置空间的边界。

Hydro 怎样重组 HPO 作业

Hydro 是一个同时改造 HPO 作业和集群资源分配的服务：它把目标模型缩成可迁移超参数的 surrogate，把大量同构 trials 融成一个高利用率执行单元，再利用 pipeline bubble、旧 GPU 和动态拆分扩展可用资源。

Trial 为什么浪费资源

传统 HPO 要完整训练大量配置。模型越大，直接 sweep 越不可承受；模型越小，单 trial 又越难吃满现代 GPU。论文引用的生产观察是，约 90% 模型需要 HPO，每个 tuning job 的 trial 中位数为 75（PDF pp.1-2，Introduction）。作者所在集群和 Alibaba trace 中，GPU utilization 超过 50% 的 GPU 只占 35% 和 16%（PDF p.4，Fig. 2a）。同时，多保真算法会不断淘汰 trial，资源需求随时间下降；集群 scheduler 却通常把整个 HPO 当固定资源的普通训练 job。

Hydro 的出发点是 MU parametrization：如果按层调整初始化与优化器超参数，较窄模型上表现好的超参数可迁移到较宽模型。于是 HPO 不必在最终模型上完成全部搜索。但缩小模型后 FLOPs 下降近似 1/S^2，显存只近似 c1/S + c2 下降，单个 surrogate 更容易让 GPU 空转（PDF p.4，Fig. 3）。因此 surrogate scaling 必须与 trial fusion 配套，不能只做模型缩小。

代理、融合与迁回的数据流

用户沿用 Ray Tune 风格定义 search space 和 training function，只需用 Hydro API 包装 model、dataloader 和 optimizer，并指定 scaling ratio。Hydro Tuner 先 trace 目标模型，生成并参数化 surrogate；再把 operator shape 相同的 trials 分组融合；Trial Planner 根据显存 profile 和当前 trial 数决定 fusion count，并在资源空出时提前启动目标模型验证。

Hydro Coordinator 与 cluster scheduler 交互。若集群里存在 pipeline-parallel 大模型预训练，它把各 stage 的 bubble 暂时标成 ephemeral GPU time 给 HydroTrial；若有不同代 GPU，则按 SM utilization 和 tuning stage 把 trial 放到更合适的设备；资源变化时，Elastic Executor 优先拆开 fused trial，避免无谓的分布式通信，再对无法融合的大 trial 启用 data parallel/FSDP（PDF pp.5,9-10，Fig. 4 与 Sec. 5）。

四个执行机制

HPO 工作负载与硬件

系统基于 Ray 实现，约 12K LoC；Model Shrinker 使用 torch.fx 与 mup，Trial Binder 使用 HFTA 与 nvFuser，Coordinator 原型修改 DeepSpeed，Elastic Executor 使用 Ray Train 与 PyTorch FSDP（PDF p.10，Sec. 6）。测试节点每台有 8 张 A100 80GB、2 颗 AMD EPYC 7742（共 128 cores）、1TB 内存，节点内 NVLink/NVSwitch，节点间 200Gbps HDR InfiniBand（PDF p.10，Sec. 6.1）。

六个 workload 是 GPT-3 XL/OpenWebText、Transformer/WikiText-103、WideResNet-50/ImageNet、MobileNetV3-Large/Flowers102、VGG-11/CIFAR-100、ResNet-18/CIFAR-10。单保真评测分别使用 128、8、32、16、8、8 GPUs，trial 数为 100、200、200、500、500、1,000（PDF p.11，Table 2）。调优算法覆盖 Random 与 ASHA；基线是 Ray 和加入 MPS GPU sharing、elastic allocation 的 Ray+ES。

单保真 Random 下，Hydro 相比 Ray 的 tuning makespan 加速分别为 78.5、8.7、20.3、12.3、10.8、16.2 倍，并且最终质量差异为 GPT-3 XL -0.48 ppl、Transformer -0.15 ppl，四个视觉模型分别 +1.18%、+0.05%、+0.09%、+0.02% accuracy（PDF p.11，Table 2）。这里 XL 模型的 Ray 时间来自 simulation，质量基线使用官方超参数，不是完整 Ray 实跑（PDF p.11，Table 2 脚注）。

多保真 ASHA 使用一半 GPU，参数为 bracket=1、grace=3、reduction=3；六个 workload 的 makespan 加速为 33.4、5.8、9.7、8.0、9.4、14.5 倍，最终质量仍略优于 Ray（PDF p.12，Table 3 与 Sec. 6.3）。15 分钟 deadline、4 GPUs 下，Hydro 将 VGG-11 accuracy 从 Ray 的 65.42% 提到 68.68%，将 ResNet-18 从 89.66% 提到 91.32%（PDF p.12，Table 4）。

Coordinator 原型在 32 张 A100、4 nodes、4 pipeline stages 的 GPT workload 上测试。Bubble 内原 GPT 的 SM activity 约 2%，加入 F=16 的 ResNet-18 HydroTrial 后约 50%；trial 得到约独占运行 15% 的吞吐，未观察到明显 GPT slowdown。直接共置则让 GPT 慢约 12%（PDF pp.13-14，Fig. 15 与 Sec. 6.5）。在 tuning job 只有 1 张独占 GPU 的模拟中，bubble 资源把 makespan 缩短 2.7 倍（PDF p.14，Sec. 6.5）。2 个 A100 nodes 加 2 个 V100 nodes、共 32 GPUs 的异构实验中，20 个一小时内随机到达的中型 HPO jobs 的 average JCT 改善约 1.3 倍（PDF p.14，Sec. 6.5）。

方法贡献

Hydro 把 MU parametrization、operator fusion 和 bubble filling 接成一条完整的 HPO 生命周期。Surrogate scaling 降低单 trial 成本，但会留下低利用率；inter-trial fusion 填补这部分空闲。multi-fidelity 让资源需求随 trial 淘汰而递减，后半程便交给 eager transfer、dynamic split 和旧 GPU 分配；pipeline bubble 则提供不侵占大模型吞吐的临时资源。各个机制处理前一环节留下的问题，单看某个局部加速数字无法解释系统收益。

代理模型和迁移的限制

• MU parametrization 要求同一数据分布上的 i.i.d. samples，因此 Hydro 明确不支持 fine-tuning（PDF p.14，Sec. 7）。
• Weight decay、dropout 等 regularization hyperparameter 不能可靠迁移；实验 search space 也主动排除了 weight decay。需要时仍要在 target model 上做小范围二次搜索（PDF pp.7,10，Sec. 4.1 与 Sec. 6）。
• 不允许用户自定义初始化，因为 Hydro 必须接管逐层 re-initialization（PDF p.14，Sec. 7）。
• 特殊架构如 MoE 可能需要额外规则；Transformer 也依赖 attention logit、query initialization、sequence length 等 heuristic adaptation，理论并不保证任意模型排名保持（PDF p.6，Sec. 4.1）。
• Inter-trial fusion 要求 operator shape 相同；不同 batch size 只能分组，架构有增删改的 trials 尚不能部分融合（PDF pp.8,14，Sec. 4.3 与 Sec. 7）。
• Bubble Squeezer 是场景化机制，不是一般 GPU sharing。没有长期 pipeline job、bubble 太短、剩余显存不够时都无法启用。
• 最大的 78.5 倍结果含模拟的 Ray 时间；Coordinator 与 Tuner 又是分开评测，论文没有给出“全部机制同时开启”的完整生产 trace 端到端结果（PDF pp.10-12，Sec. 6-6.3）。

与调优调度论文的关系

• 与 Ymir：两者都跨作业复用共同模型结构。Hydro 合并的是同一 HPO job 中同构、不同超参数的 trials，Ymir 合并的是同 backbone、不同下游任务的 fine-tuning jobs。Hydro 的理论边界明确排除 fine-tuning，Ymir 正好覆盖这一缺口。
• 与 PromptTuner：两者都优化 tuning workload，但 PromptTuner 重点是分钟级 SLO、warm pool、prompt reuse 和成本；Hydro 重点是 HPO 的 surrogate transfer、trial fusion 与 datacenter spare capacity。前者把历史 prompt 当算法资产，后者把模型宽度和 trial 同构性当系统资产。
• 与 SPPO：Hydro 从 pipeline bubble 中“借时间”跑 trial，SPPO 则重新安排长序列训练的 activation offload 与 sequence pipeline 来减少 bubble。两篇都把 bubble 当可管理资源，但 Hydro 是跨 job interleaving，SPPO 是单个长序列 job 内部调度。
• 与 UniSched/ICEFROG：Hydro Coordinator 暴露了 diminishing demand、fusion count、target/surrogate stage 和 GPU generation 等新状态。通用 scheduler 若看不到这些信息，只能把 HPO 当固定黑盒；这与 ICEFROG 将 layer freezing 暴露给 scheduler 的思路一致。
• 与 Di-PS：Di-PS 解决跨集群异构和异步训练，Hydro 解决单数据中心内异构卡和临时 bubble。二者都不假定资源整齐同构，但控制粒度分别是训练集群和 HPO trial。

核对收益时从哪里开始

先看 Fig. 1、3，理解“超参数可迁移”和“缩小后 GPU 更空”这对矛盾；再看 Fig. 4 的 Tuner/Coordinator 分层。Sec. 4 重点读 Model Shrinker、Inter-trial Fusion、Adaptive Fusion，MU 的推导可第二遍再看；Sec. 5 先看 Fig. 9，再核对 Bubble Squeezer 的三个适用条件。实验先读 Table 2-4，再读 Fig. 12 的消融，因为它直接证明 scaling 必须和 fusion 联用；最后用 Sec. 7 校正适用范围。

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 分支压成同一套可求解模型。

收益、画像与 lease 的数据流

新 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）。

四个调度机制

Trace、集群与基线

模拟器有 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，也减少了多个独立策略之间的冲突。

估计误差和求解开销

• 假设同构 GPU 与同构网络，只评测 data parallel + all-reduce。Tensor/pipeline parallel、NVLink/GPUDirect 的非统一通信成本都留作未来工作（PDF pp.4-5，Sec. III-A/B）。
• 每个 job 至少能在单 GPU 上放下一个样本；超大 foundation model 不满足这一前提。
• Runtime model 线性外推通信，忽略 computation/communication overlap 和 PCIe saturation。前者会保守高估时间，后者只能在执行中再更新（PDF p.5，Sec. III-B1）。
• Policy enumeration 只覆盖请求不超过 16 GPUs 的 job；更大 job 的拓扑选择没有同样细粒度（PDF p.7，Sec. III-C3）。
• Deadline 与 soft reward 在 trace 中是合成的，不是 Helios/Philly 原始用户字段；80/20 stopping-criterion 比例也由实验构造（PDF p.9，Sec. IV-B）。因此结果能比较 scheduler，但不能证明真实集群一定有相同 SLO 分布。
• Reward 量级依赖 operator 与用户约定，论文没有机制防止用户虚报高 reward，也没有给出经济定价或 admission control。
• Autoscaling 只在未来工作中提出；加入 GPU 数范围会增加二元变量和 solver 成本（PDF p.14，Sec. VIII）。

与 deadline 调度论文的关系

• 与 CHRONUS：UniSched 是直接扩展。Estimator 修正 performance-based stopping 和 suspend/resume，Selector 以统一 reward/MILP 替代 CHRONUS 的固定 profiling reservation、SRTF 与 round-up placement 分支。
• 与 AutoSched：UniSched 仍有 lease 时长、reward ratio、solver fallback 等配置；AutoSched 解决的正是这些参数随 workload 漂移后如何自动重调。两者是 policy 与 meta-configuration 的关系。
• 与 Ymir：两者都用 Estimator + solver 联合时间和资源，但 UniSched 的未知量是 job duration、deadline 和 placement，Ymir 额外把 task pair 与 transfer mode 变成决策变量。Ymir 可视为在 FMF 语义下把 UniSched 式资源-时间模型再向算法层扩展。
• 与 PromptTuner：PromptTuner 也以 SLO violation 为核心，但它利用 prompt reuse、warm pool 和快速 elastic allocation处理短时 LLM prompt tuning；UniSched 是更通用、但启动与模型语义更弱的训练 scheduler。
• 与 ICEFROG、SchedMate：ICEFROG 增加 layer-freezing state，SchedMate 增加代码/日志语义，二者都能为 UniSched 的 Estimator/Policy Generator 提供更丰富输入。UniSched 提供的是把这些信息最终转成 reward 与 allocation constraint 的统一骨架。

核对目标函数时从哪里开始

先读 Table I 与 Fig. 1，建立四类需求组合；再读 Fig. 2 的两阶段 workflow。Estimator 部分按 Eq. 1、Eq. 2、Eq. 3 顺序读，分别对应总时长、每步时长和抢占开销。Selector 先看 Fig. 5 的 reward，再看 cell policy，最后读 Eq. 4-14；不要一开始陷入全部符号。实验优先看 Fig. 6 的端到端结果、Fig. 7/9 的估计误差与消融、Fig. 10/11 的 lease 和 joint placement，最后用 Fig. 12 判断相对 CHRONUS 的增量来自哪里。

CHRONUS 怎样分配期限

CHRONUS 是一个面向混合负载的 deadline-aware GPU 调度器：它先判断哪些 SLO 真能保证，再用离散 lease 和 MILP 安排这些作业未来在哪些时间片运行，剩余资源则服务 best-effort 作业。

Deadline 为什么不能只靠用户估时

已有 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 的二元判断。

从 profiling 到 lease 日历

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 页）。

保证队列、Spot 队列与放置

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、期限与对照

• 模拟使用两条真实 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 把 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 价值高、愿意用容量冗余换确定性的集群。

ASTRAEA 怎样记公平账

ASTRAEA 用 Long-Term GPU-Time Fairness（LTGF）同时核算 tenant 和 job 的历史欠账，再按“先选最欠资源的 tenant、再选其内部最欠资源的 job”发放 lease。

Gang scheduling 如何改变公平

传统 instantaneous fairness 很难直接移植到 DLT：gang scheduling 要求 GPU 全给或全不给，placement topology 会改变训练速度，频繁抢占还会产生 checkpoint/cold-start 开销。Themis 的 finish-time fairness 虽然已经使用 lease，却只看完成时间，不看作业一次占多少 GPU。论文用一个 6-GPU 例子说明：若一个 6-GPU 作业和两个 3-GPU 作业轮流获得相同运行时间，前者实际拿走一半 GPU-time，后两者各只有四分之一；这还会诱导用户虚报 GPU demand（PDF 第 4-5 页，图 6）。

生产 trace 也显示为什么要同时考虑大小作业。SenseTime Venus 的 6 个月数据包含 133 台 8-GPU 服务器、16 个 tenant、109,734 个 DLT 作业；其中 52.2% 正常完成、27.9% 被取消、19.9% 失败。52.5% 的作业只需 1 GPU，但这些作业仅消费 4.7% 总 GPU service time；需求不少于 8 GPU 的作业消耗了 85.7% GPU service time（PDF 第 3 页，图 1-3）。只看 job count、运行时间或瞬时份额，都会漏掉一部分公平性。

两级 LTGF 与 lease 流程

LTGF 的基本量是 GPU service time，即 GPU 数乘运行时间。对作业 i，在区间 [t1,t2] 内：

r_job = 实际累计 GPU-time / 按权重和活跃作业数计算的应得 GPU-time。

tenant 层同理：

r_tenant = tenant 实际累计 GPU-time / 按 tenant weight、quota 与 demand 计算的应得 GPU-time。

r >= 1 表示至少获得了 sharing incentive 所承诺的份额，r < 1 表示存在 sharing loss（PDF 第 5-6 页，式 1-15）。系统运行流程如下：

1. 每个 tenant 有独立 pending queue。新作业与 lease 到期的运行中作业都进入本轮候选集（PDF 第 6-7 页，图 7-8）。
2. ASTRAEA 在每轮开始更新所有 tenant 的 r_tenant 和所有作业的 r_job，统计窗口从 tbegin 到当前时刻。
3. Phase 1 选择 r_tenant 最小、即长期 GPU-time 欠账最多的 tenant。若它没有可放置作业，就跳到下一个 tenant，避免整个集群卡住。
4. Phase 2 在该 tenant 内选择 reward 最大的作业；基本 reward 是 -r_job，因此 r_job 越低优先级越高。实现还会适当提高新提交短作业、已运行很多 lease 的长作业和紧急作业的优先级（PDF 第 8-9 页，算法 1-2）。
5. 若资源与 placement 都满足，作业获得一个固定 lease 和其完整 GPU demand；tenant 的累计分配量随即按“该作业将运行整个 lease”更新，调度器继续选择，直到没有可放置作业。
6. lease 到期时，作业先产生 checkpoint，再申请续租。续租成功则原地继续；失败则被抢占，GPU 回收后按 consolidated placement 分给新选中的作业。

欠账、续租与 placement

1. 两级 LTGF。 Tenant quota 解决不同团队之间的资源贡献与回收，job-level ratio 再防止同一团队里的大作业或长作业压住小作业。它只依赖已经发生的 GPU-time，不需要像 Themis 那样预测 remaining time；对取消率和失败率高的探索型训练更稳妥。

2. Lease 将长期公平变成可执行动作。 LTGF 本身只是度量。固定 lease 让调度器周期性纠偏，而不是为了瞬时公平随时抢占。论文根据历史 trace 选择 900 秒：它的 JCT 接近最优的 1,200 秒设置，但公平性更好（PDF 第 9-10 页，图 9）。

3. On-demand checkpoint 与 last store。 每次迭代更新内存 snapshot；收到 POSIX signal 后，daemon 先把最近完整 snapshot 刷盘。如果当前迭代来得及结束，再写更新版本，否则下次从前一个 snapshot 恢复。这避免资源回收时等待一个很长的 iteration（PDF 第 7 页）。

4. 欠账优先但保持 work conservation。 最不公平 tenant 当前没有可放置作业时，系统会跳过它继续找其他 tenant；未用 quota 可被借出，未来该 tenant 有 burst demand 时再通过较低 fairness ratio 取回。实验实现把 tenant fair share 直接改为 quota（式 16），正是为了更快反映这种借出与回收（PDF 第 8 页）。

Venus trace 与模拟设置

• 评估是 trace-driven simulation。Venus 两周快照有 11,304 个作业、16 个 tenant，原集群 1,064 GPU；Philly 两周快照有 44,329 个作业、15 个 VC，原集群 2,490 GPU。为提高模拟负载，实验分别缩成 100 个和 210 个 8-GPU 节点，即 800 与 1,680 GPU；Philly 没有 VC size，论文假设 VC 大小正比于该 VC 全部作业请求的 GPU 总数（PDF 第 9 页）。
• lease 是 900 秒，调度 interval 是 10 秒，placement 使用 consolidated strategy。baseline 共六个：YARN-CS、HiveD、Allox、Tiresias-L、Themis、Gandivafair（PDF 第 9 页）。
• 若把 r_job < 0.95 定义为 sharing-loss job，Venus 上 ASTRAEA 的比例为 7.1%，Themis 为 19.7%，YARN-CS 为 73.6%；后两者分别是 ASTRAEA 的 2.8 倍和 10.3 倍（PDF 第 10 页，图 10）。
• Tenant 层把 r_tenant < 1 视为 sharing loss。ASTRAEA 的不公平区间比例为 5.2%，Allox 6.9%，Gandivafair 8.0%，Tiresias-L 49.0%，YARN-CS 44.6%，对应 1.3-9.42 倍改进（PDF 第 10 页，图 11）。
• 900 秒 lease 下，checkpoint 与 cold-start 带来的额外平均 JCT 开销约 0.8%（PDF 第 11 页；对应图 9）。图 13 显示 ASTRAEA 的平均 JCT 低于各 baseline，但 PDF 正文没有逐项列出柱值，这里不从低分辨率柱图猜数字。

方法贡献

ASTRAEA 最重要的贡献是把“公平”从抽象口号变成可审计的累计账本。GPU-time 同时编码空间维度的 GPU demand 和时间维度的占用时长，tenant/job 两级 ratio 又对应共享集群的两层治理。它还指出 finish-time fairness 的激励漏洞：若不把 GPU 数算进公平度，虚报大 demand 反而可能占便宜。

公平定义和模拟证据的边界

• 论文只有 trace-driven simulator，没有 Kubernetes 或生产原型；checkpoint 机制虽然设计得具体，但端到端工程成本和故障恢复行为没有实机验证。
• On-demand checkpoint 需要修改用户侧 DL library 并运行 daemon，仍是侵入式方案。不能稳定 checkpoint 的作业不适用。
• LTGF 是回顾性的长期指标。突发负载下反应可能慢，论文实现为此把理论定义中的 demand-aware fair share 改成 quota（式 16），说明理论 metric 与实验调度规则并非完全同一形式。
• 目标是公平，不是 deadline。新作业、长作业和紧急作业的附加 priority 也意味着严格的纯 LTGF 次序可被局部修正。
• placement 不是论文贡献，实验固定使用 consolidated placement；异构 GPU、网络差异和弹性训练没有进入公平账本。

Titan 利用哪些微调特征

Titan 利用 foundation model 结构固定、多个下游任务可能共享参数、训练普遍使用 pipeline parallelism 这三个条件，把运行时间估计、任务合并和 context switch 一起纳入 fine-tuning 调度。

微调负载为何值得单独调度

普通 DLT 调度器往往假设作业可轻量 checkpoint、可做 data-parallel elasticity，或者要在线 profiling 后才知道扩展效率。Fine-tuning 有另一组特征：模型结构固定，最佳并行 plan 可复用；单次任务相对短，但模型参数大，切换成本相对突出；多个语义相近下游数据集可能合并训练。论文指出，一个有效的并行执行 plan 可把 throughput 提高最多 10 倍，但搜索通常要几分钟；若模型结构、batch size 和输入 shape 相同，就可以缓存结果（PDF 第 1 页）。

估时、合并与切换流程

Titan 是事件驱动的非抢占调度器，在作业提交或完成时求解资源分配。它把待运行作业 ji 在分配 a 张 GPU 时的单位时间进度记为 Ti,a，用二元变量 xi,a 表示是否采用该分配，MILP 在 GPU 总量约束下最大化所有作业的单位时间总进度。允许的 GPU 数集合是 {1, 2, 4m}（PDF 第 2 页，式 1-4）。完整流程如下：

1. 用户提交 fine-tuning dataset。系统根据数据规模确定 batch-size 范围和 epoch 数。
2. Time Estimator 查询离线 LUT。键包括 GPU 数 a、gradient accumulation steps s、global batch size m、冻结层数 l、是否 mixed precision、是否 gradient checkpoint；值是对应 throughput。未见配置用线性插值估计。系统同时得到运行时预测和该资源量下的较优训练配置（PDF 第 3 页）。
3. Task Merger 从 dataset card 中提取任务类别、对象类别等关键词，用语义相似度判断哪些数据集可能安全合并。它不是“能合就全合”：系统枚举候选 merged jobs，把单任务和 merged task 一起放入扩展 MILP，并用 (1 + |merged set|) / 2 对合并任务进度加权，避免一个超长 merged job 拉高平均 JCT（PDF 第 3-4 页，式 5-11）。
4. MILP 为独立作业或 merged job 选择 GPU 数。论文报告 320-job 问题在 1 vCPU 上平均求解 0.005 秒、最大 0.16 秒（PDF 第 2 页）。
5. 当作业完成、需要切换模型参数时，Pipeline Switch 让旧作业的参数 GPU-to-CPU 保存、新作业 CPU-to-GPU 加载，与不同 pipeline stage 上仍在进行的 forward/backward 计算重叠。新作业按反方向从最后一台机器向第一台机器加载，尽量隐藏切换路径（PDF 第 4 页，图 2）。
6. 下一次提交或完成事件重新求解；主模型不依赖频繁抢占，因此调度灵活性主要来自资源分配、合并与切换优化，而不是在途作业的 lease 重排。

吞吐表、MILP 和 Pipeline Switch

1. 固定结构 LUT。 Titan 不试图拟合一个跨模型通用性能公式，而是承认 fine-tuning service 围绕少量 foundation model 反复出现。用 64 GPU 穷举训练配置建表需要 37 小时，但之后每个请求可直接查询（PDF 第 3 页）。这是把离线成本换成在线速度和可预测性。

2. Task Merger。 多个语义相近任务共享同一套模型参数，可以减少重复模型实例和 GPU 消耗。表 2 的例子很直观：两个各 20 分钟的任务，合并后平均 JCT 为 25 分钟，SRTF 顺序执行为 30 分钟；但 5 分钟与 100 分钟任务合并后是 102 分钟，SRTF 平均仅 55 分钟。因此合并必须进入调度优化，而不是作为固定预处理（PDF 第 3 页，表 2）。

3. Pipeline Switch。 ViT-Large/16 的实测切换开销在 8、4、2 GPU 分配下，naive 分别是 46、29、22 秒，pipeline switch 降为 6、5、7 秒（PDF 第 4 页，图 3）。它利用 pipeline 已经存在的 stage 切分来隐藏参数搬运，而不是另造一套 checkpoint 格式。

4. Merge-aware MILP。 同一原始任务不能既独立运行又出现在 merged job 中，不同 merged set 也不能重叠；资源约束同时覆盖两类候选。该模型把“训练系统能否合并”与“此时合并是否有利于 JCT”分开处理。

工作负载、集群与对照

• 生产 FM trace 来自 88 节点、共 704 张 NVIDIA V100 的集群，覆盖 3 个月和 18,471 个作业；论文筛选运行 5 分钟至 10 小时的作业做分析，其中超过 50% 的 FMTrace 作业短于 30 分钟（PDF 第 4-5 页，图 4）。
• 模拟集群是 16 节点、64 GPU，模型只有 ViT-Large/16。合成工作负载含 320 个作业，按 FMTrace 的提交模式在前 8 小时到达；batch size 在 64-512 间按以 sqrt(2) 为底的指数步长 profiling（PDF 第 2、4-5 页）。
• 表 3 的准确结果是：SRTF 平均 JCT 1.68 小时、makespan 33.09 小时；Tiresias 为 1.67/33.09 小时；去掉 task merger 的 Titan 为 1.23/33.11 小时；去掉 pipeline switch 为 1.16/29.01 小时；完整 Titan 为 1.04/29.01 小时（PDF 第 5 页，表 3）。据此论文总结，相比 baseline，平均 JCT 降低 38%，makespan 降低 12%；task merger 与 pipeline switch 分别贡献约 15% 和 10% 的平均 JCT 降幅。
• 相对 workload density 为 0.5、1、1.5、2 时，JCT 显著下降的作业占 18%、19%、20%、19%，显著上升的占 6%、8%、7%、11%；“显著”定义为相对 SRTF 至少变化 10%（PDF 第 5 页，表 4）。

方法贡献

Titan 针对 foundation model 的固定结构、任务适应关系和 pipeline parallelism，分别设计了离线 LUT/plan cache、task merge 和模型切换通道。调度器由此能在计划生成、资源选择与运行时切换中利用 workload structure，而不是沿用通用深度学习作业模型。

合并条件和切换成本

• 这是一篇 7 页的短论文，作者明确称结果为 preliminary。评估只有模拟，没有 Titan 原型；文末把 Kubernetes prototype 和生产部署列为未来工作（PDF 第 5-6 页）。
• 只 profile 和模拟 ViT-Large/16，不能据此断言 LUT、merge 或 pipeline switch 对 NLP 大模型、不同并行框架同样有效。
• Task Merger 有准确率与数据隐私风险。用户可关闭合并，但论文还提出降低此类作业优先级作为激励；这涉及服务策略，不只是技术优化。若合并后达不到目标准确率，方案是再单独训练一段恢复，但没有给恢复成本的实验（PDF 第 4 页）。
• LUT 的“37 小时”是 64 GPU 连续运行 37 小时，即 2,368 GPU-hours 的一次性 profiling 量；模型、输入 shape 或软件栈变化后可能要重建。这里的换算是由论文数字直接计算，不是论文原文指标。
• Pipeline Switch 目前只重叠跨机器参数 load 与 gradient computation；单 GPU 异步切换、数据预处理、参数高效微调、存储成本以及训练/推理混部都被列为未来工作（PDF 第 5 页）。
• MILP 目标是最大化当前单位时间总进度，并不等价于从数学上直接最小化全局平均 JCT；论文靠 task-merge 权重和实验证明其效果。

Lucid 选择了怎样的部署路径

Lucid 是一个 preemption-free 的 learning-augmented scheduler：只读 GPU 硬件指标和历史日志，以保守共置、运行时预测和可解释模型降低 JCT，不要求用户代码、DL framework 或 CUDA 配合。

高收益调度器为何难以接入生产

Lucid 把此前调度研究的落地障碍归为五类：用户代码侵入且易出错、与框架/CUDA 集成维护成本高、自适应 batch size/learning rate 可能损害模型质量、优化器或 RL 在大队列上扩展性差、黑盒决策难以调试。论文举例，Gavel 求解 2,048-job 分配可花数千秒，Metis 只能处理数十个作业；而生产集群可能并发数千作业（PDF 第 2 页）。Lucid 的立场很明确：不再靠更激进的弹性和抢占赢性能，而是利用生产 workload 的低 GPU 利用率、重复提交和大量短调试作业。

Profiler、Binder 与 Orchestrator

Lucid 由三个 scheduling module 和两个 optimizer 组成（PDF 第 4-8 页，图 4）：

1. Non-intrusive Job Profiler 先给作业一个短窗口，只通过 NVIDIA-SMI/DCGM 采 GPU utilization、GPU memory footprint、GPU memory utilization。短调试/失败作业可在此阶段结束；其余作业得到资源特征。Profiler 在空间上优先小 GPU demand、consolidated 放置，在时间上根据预测吞吐动态调 Nprof、Tprof 与 profiling cluster capacity。
2. Packing Analyze Model 用 Decision Tree 把作业分成 Tiny、Medium、Jumbo，对应 Sharing Score 0、1、2。分类依据是资源指标和可选的 mixed-precision 标记，而不是把作业真正共置后再测 slowdown。
3. Affine-jobpair Binder 执行 Indolent Packing。每张 GPU 的 score 总和默认不超过 GSS=2，显存必须安全，只合并 GPU demand 相同的两个作业，资源行为不稳定就驱逐，分布式作业默认不共置。若 Throughput Predict Model 判断集群低负载且不会很快升高，则降为 GSS=1，甚至暂时关闭 sharing，避免无谓 slowdown（PDF 第 6 页，图 5、算法 2）。
4. Workload Estimate Model 用 GA2M 结合用户、作业名、GPU demand、提交时间和 profiler 特征预测时长。Resource Orchestrator 把 预测时长 × GPU demand 当 priority，按升序调度，近似 Shortest-Service-First；有合适 affine pair 时共置，否则 consolidated exclusive placement（PDF 第 6-7 页）。
5. Throughput Predict Model 同样使用可解释 GA2M，以小时、日期、rolling mean/median、历史 soft sum 等特征预测 job 和 GPU request throughput，用于 Binder 模式和 Profiler 容量调整。
6. Update Engine 周期性用新日志更新模型；System Tuner 通过历史 trace simulation 和解释结果调系统参数，并可用 PAV 给特征 shape function 加单调约束（PDF 第 8 页）。

非侵入画像、保守共置和排序

1. 二维 Profiler。 Space-aware 部分先服务小 GPU demand，减少小 profiling cluster 的 HOL blocking；time-aware 部分根据预测负载借还节点、调整 profiling 时间。它不是单纯“为预测采样”，还承担快速返回调试结果和缩小主调度搜索空间的职责。

2. Indolent Packing。 Lucid 宁可漏掉一部分共置机会，也不把明显会互相干扰的作业塞在一起。在论文 workload 组合中，判为可共置的 job pair 有 98.1% 达到 normalized speed 不低于 0.85，同时找到 87.0% 的 packing opportunity（PDF 第 6 页，图 5）。这是一种面向部署风险的保守策略。

3. 可解释的三模型协同。 DT 解释“为什么能共置”，GA2M 解释“为什么预测这段时间会繁忙”以及“哪些特征让该作业被预测为长作业”。模型不是装饰：吞吐预测控制 profiler 与 sharing，时长预测同时影响 Binder 和 Orchestrator，profiled features 又提高历史作业匹配精度。

4. 无抢占的 service-time priority。 duration × GPU count 同时看时间和空间成本，避免一个预计很长且占 GPU 多的作业造成 HOL blocking。新作业没有历史时，按用户历史估计；新用户则用相同 GPU demand 作业的平均时长兜底（PDF 第 6 页）。

Trace、物理集群与模拟

• 实机是 4 台服务器、32 张 RTX 3090，每台双路 Xeon Gold 6326、256 GB RAM、8 GPU；软件为 Ubuntu 20.04、PyTorch 1.10、CUDA 11.3、cuDNN 8。Lucid 实现约 4,700 行 Python，并有 trace simulator（PDF 第 8 页）。
• 三条生产 trace 为：Saturn 2,080 GPU、101,254 jobs、平均 duration 13,006 秒；Venus 1,080 GPU、23,859 jobs、5,419 秒；Philly 864 GPU、12,389 jobs、25,533 秒（PDF 第 8 页，表 2）。
• 物理集群使用 100-job static trace 和 120-job Poisson-arrival continuous trace。Lucid 实机 static makespan 为 8.45 小时，FIFO 为 11.56 小时；continuous 平均 JCT 为 3.64 小时，FIFO 为 8.17 小时，对应约 1.4 倍和 2.3 倍改善。模拟与实机在 makespan、平均 JCT 上误差小于 4.6%（PDF 第 8-9 页，表 3）。
• 大规模模拟中，Lucid 在 Venus/Saturn/Philly 的平均 JCT 分别为 3.58/1.79/6.84 小时，Tiresias 为 4.09/1.89/9.02 小时；平均排队时延分别为 0.25/0.16/0.29 小时，Tiresias 为 0.82/0.28/2.62 小时。三条 trace 上平均排队时延改善为 1.8-9.1 倍（PDF 第 9-10 页，表 4）。
• 相比 Tiresias，GPU utilization 提高 9%-17%，GPU memory usage 提高 7%-24%；P99.9 排队时延改善 1.4-2.1 倍；等待中的不超过 60 秒短作业数减少 4.1-24.8 倍（PDF 第 10 页）。
• 2,048 个待调度作业时，包含模型推理的调度决策仍小于 3 ms；Workload Estimate/Throughput Predict 在半年、10^5-10^7 样本上训练最多约 11 分钟，Packing Analyze Model 少于 1 秒（PDF 第 10 页，图 10）。
• 可解释模型不只是更容易看懂：Venus 上 Throughput Predict 的 MAE 为 4.125，优于 RF 4.607、LightGBM 4.491、XGBoost 5.807、DNN 5.132；Workload Estimate 的 R^2 为 0.413，也高于四个 baseline 的 0.101/0.230/0.332/0.181。Packing Analyze 的 DT accuracy 为 94.1%（PDF 第 11-12 页，表 7）。
• Pollux 对比中，一个 EfficientNet 作业的最佳 validation accuracy 是 Lucid 89.84%、Pollux 87.63%，相差超过 2 个百分点；该实验用于说明自适应训练可能改变模型质量，不应外推为所有 Pollux workload 都固定损失 2%（PDF 第 12 页，图 14）。

方法贡献

Lucid 的创新是系统取舍，而不只是某个排序公式。它证明在 workload 重复、GPU 普遍未充分利用、短作业占比高的生产分布里，非抢占调度可以靠 profiling、历史估时和低干扰共置追回性能，并把决策保持在毫秒级。可解释性还被接入调参、单调约束和更新流程，而非停留在输出 feature importance。

工作负载假设和未覆盖目标

• Lucid 依赖 recurrent workload 和历史日志。新用户、新型模型或分布突变时只能退回粗粒度平均值；Update Engine 能缓解 drift，但不能消除 cold start。
• Profiler 假设初始化和数据搬运不超过 Tprof；超长 cold start 需要 operator 延长配置或用户显式标记。超过 Nprof 的大规模作业只在线采指标，不进入标准 profiling（PDF 第 5 页）。
• 分布式作业默认不 packing，当前只把同构 GPU 当主要资源；异构 GPU、CPU 和网络联合优化留给未来（PDF 第 6、13 页）。
• 系统不支持 fairness 和 SLO guarantee，论文把二者明确列为未来方向（PDF 第 4、13 页）。因此它不能替代 CHRONUS 或 ASTRAEA 的目标，只是在 JCT/利用率目标下更易部署。
• 大规模结果来自 simulator；物理验证只有 32 GPU。虽然论文给出小于 4.6% 的模拟误差，但该 fidelity 是在抽样 workload 和同类硬件上测得。
• “不侵入”换来的代价是不对运行中作业做弹性重配。若 workload 缺少可安全 packing 的余量，或历史时长不可预测，Lucid 的优势会缩小。

1. 共同的起点：DLT 不能照搬通用集群调度

四篇都从 DLT 的特殊结构出发，但选择的可利用属性不同。CHRONUS 利用迭代稳定、可 checkpoint 和 topology sensitivity；ASTRAEA 利用 gang scheduling 下可累计的 GPU-time，并用 lease 克服长期作业不可重排；Titan 利用 foundation model 结构固定、多任务适应性和 pipeline parallelism；Lucid 则利用 GPU underutilization、重复提交和短调试作业占多数。

2. CHRONUS → ASTRAEA：lease 骨架从 SLO 时间表变成公平纠偏器

两篇最直接的技术继承是 lease。CHRONUS 的 lease 是 MILP 的时间离散单位，回答“哪些 SLO 作业应在哪些未来时间片运行”；ASTRAEA 的 lease 是 LTGF 的执行器，回答“现在该把 GPU-time 还给哪个 tenant/job”。前者必须预测剩余运行时间并理解 deadline，后者刻意只看已经发生的分配，因此能容忍取消和失败，但不提供 deadline guarantee。

3. CHRONUS/ASTRAEA → Titan：从通用目标转向 workload-specific opportunity

Titan 没有继续扩展 lease，而是注意到 fine-tuning 作业短、模型固定、切换重。它采用非抢占 MILP，通过 LUT、task merge 和 pipeline switch 获取效率。这是目标和假设的变化：与其把任意 DLT 作业切碎重排，不如利用服务只围绕少量 foundation model 这一规律，把最佳配置和切换路径预先做深。

4. 前三篇 → Lucid：从“还能优化什么”转向“为什么部署不了”

Lucid 的五个 gap 几乎是对研究型调度器常见代价的集中回应。CHRONUS/ASTRAEA 需要 checkpoint 和用户侧配合，Titan 的 task merge 会触及数据与训练语义；这些设计各自有效，却提高集成和维护成本。Lucid 因此主动放弃 fairness、deadline、弹性和激进 packing，把边界收缩到硬件指标、历史日志和保守共置，再用解释性与毫秒级决策增强运维信心。它落在另一处 Pareto 点，目标是降低部署门槛，而不是统一前面四类目标。

5. 演进发生在系统假设上

• CHRONUS：可以 checkpoint，deadline 值得为之预留资源。
• ASTRAEA：可以 checkpoint，长期公平比瞬时平均分配更重要。
• Titan：模型家族固定，数据语义允许部分任务合并。
• Lucid：不能要求用户和框架配合，但有历史 trace 和可读硬件指标。

读论文时应先检查自己的集群符合哪组假设，再看倍数。四篇的实验数字不能直接横比，因为目标、trace 处理、集群规模和 baseline 都不同。

这组 LLM trace 回答什么

这篇论文第一次把“LLM 开发”作为一条由预训练、对齐、评测等阶段组成的生产流水线来刻画，而不是把它简化成长时间占满大量 GPU 的单一训练作业，并据此落地了预训练容错与评测解耦调度两个系统。

两个集群和六个月窗口

数据来自上海人工智能实验室的 Acme 数据中心，观测窗口为 2023 年 3 月至 8 月，共 6 个月。作者选择了专用于 LLM 开发的 Seren 和 Kalos 两个集群：Seren 有 286 个节点、2,288 张 A100-SXM 80GB，Kalos 有 302 个节点、2,416 张同型 GPU，总计 4,704 张 A100；每个节点均有 8 张 GPU 和 128 个 CPU 线程，Kalos 相比 Seren 具有 2TB 主存和 5 条 200Gb/s InfiniBand 链路，其中一条服务存储（PDF 第 3 页，表 1）。

作业日志覆盖 Seren 的 368K 个 CPU 作业和 664K 个 GPU 作业，以及 Kalos 的 42K 个 CPU 作业和 20K 个 GPU 作业，合计约 109 万个作业；表 2 也将 Acme 记为 1.09M jobs。除调度器的提交、启动、结束、状态和资源请求外，作者还采集 Prometheus、DCGM 与 IPMI 监控数据，采样间隔为 15 秒，并保留框架 stdout/stderr 和部分代表性作业的细粒度 profiling 数据（PDF 第 4 页，表 2 与“Trace Source”）。这使论文能够把“申请了多少 GPU”“GPU 是否忙”“为什么失败”三个层次连起来。

需要先划清数据边界：Acme 的这两个集群没有线上 serving 作业；模型主要是 7B 到 123B 以上的 decoder-only Transformer；Seren 使用 Slurm，Kalos 使用 Kubernetes；集群对大规模预训练作业提供配额预留与资源隔离，同时允许 best-effort 作业填充空余资源（PDF 第 3 页）。因此，论文观测到的排队次序并非纯粹由作业固有属性决定，也包含 Acme 当时的资源保留政策。

资源和作业分布

第一，LLM 集群里“短作业很多”与“算力主要被超大作业吃掉”同时成立。 Seren 和 Kalos 的 GPU 作业时长中位数都只有 2 分钟，比 Philly、Helios、PAI 的中位数短 1.7 到 7.2 倍；若比较平均时长，2017 年 Philly 是 2023 年 Acme 的 12.8 倍。作者把原因归于硬件升级、Acme 用户申请更多 GPU、评测等配套短作业很多，以及约 40% 作业失败后很快退出（PDF 第 4 页，图 2(a)）。另一方面，所有集群中请求超过 8 张 GPU 的作业都不足 7%，但 Kalos 中请求至少 256 张 GPU 的大作业占据超过 96% 的 GPU time，单卡作业在两个 Acme 集群中占用不足 2% 的 GPU time（PDF 第 5 页，图 3）。这意味着按作业数看，评测和调试主导队列；按资源量看，预训练主导整个集群。

第二，不同流水线阶段的作业数和资源消耗近乎反转。 在 Kalos，评测作业占 92.9% 的作业数，却只消耗 0.8% GPU time；预训练仅占 3.2% 的作业数，却消耗 94.0% GPU time。Seren 中预训练占 0.9% 作业数和 69.5% GPU time，评测占 64.9% 作业数（PDF 第 5 页，图 4）。评测通常请求少于 4 张 GPU，预训练通常请求超过 100 张 GPU（PDF 第 5 页，图 5）。因此“平均作业”在这里几乎没有代表性，调度器必须知道作业属于哪个开发阶段。

第三，资源预留让小作业反而等得最久。 预训练虽然时长最长，但两个集群中少于 5% 的作业能持续超过一天，频繁故障会把一次逻辑训练拆成多次提交。更反常的是，GPU 需求最小、运行最短的评测作业排队时间最长，因为大部分资源被预留给预训练，评测以低优先级批量提交，只能抢有限的空余资源（PDF 第 6 页，图 6）。所以不能把“卡数越多，排队越久”从旧 DL trace 直接外推到 LLM 集群。

第四，nvidia-smi 式利用率很高，但这不代表每个硬件单元和配套资源都高效。 Seren 和 Kalos 的 GPU utilization 中位数分别为 97% 和 99%，明显高于 Philly 的 48% 与 PAI 的 4%（PDF 第 5 页，图 2(b)）。更细的 DCGM 指标显示，两集群的 SM activity 中位数约 40%，Kalos 中一半 GPU 使用超过 75% 显存，也就是超过 60GB；与此同时，CPU 主存使用率低于 50%，CPU 通常低负载，Seren 的 InfiniBand NIC 超过 60% 时间空闲，活跃时带宽也很少超过峰值的 25%（PDF 第 6 页，图 7）。这组结果既否定了“GPU 忙等于整机资源都忙”，也说明旧式用 GPU sharing 填充算力空洞的方案未必适用于稠密 LLM 预训练。

第五，功耗同样呈现“高负载与空闲并存”。 约 30% GPU 处于空闲状态，但每张仍消耗约 60W；Seren 和 Kalos 分别有 22.1% 和 12.5% 的 GPU 功耗超过 A100 的 400W TDP，少数达到 600W（PDF 第 6 页，图 8(a)）。Seren 的 GPU 服务器平均功耗约为 CPU 服务器的 5 倍，GPU 占 GPU 服务器功耗的 65.7%，CPU 占 11.2%，电源转换损耗占 9.6%（PDF 第 7 页，图 8(b) 与图 9）。附录估算 Seren 在 2023 年 5 月耗电约 673MWh；按 PUE 1.25 和 0.478 tCO2e/MWh 计算，有效排放为 321.7 tCO2e（PDF 第 21 页，附录 A.3）。

第六，评测不是一段连续的 GPU 推理。 用 7B 模型跑 HumanEval 时，在真正 GPU inference 前，模型加载和数据预处理已耗掉总时长的 29.5%；推理结束后的程序正确性测试又让 GPU 空闲 42 秒，占总 GPU time 的 19.0%（PDF 第 8 页，图 13）。也就是说，把评测当作不可拆分的 GPU 作业，会把远端 I/O、tokenization 和 CPU-only metric 都错误地锁在 GPU 配额里。

第七，故障次数不是最重要的指标，故障发生时刻、作业规模和恢复时间才决定损失。 作者分析 Kalos 的 32,500 个任务日志，其中 96.3% 是 inference/evaluation、2.0% 是 pretraining，另分析 Seren 的 675 个预训练任务（PDF 第 8 页）。表 3 显示，NVLink error 有 54 次，但平均涉及 800 张 GPU，并占所列失败 GPU time 的 30.25%；CUDA error 有 21 次，平均涉及 847 张 GPU，占 15.77%；node failure 只有 16 次，却平均涉及 712 张 GPU，占 14.30%。Network error 的平均重启时间为 592.1 分钟，甚至是平均故障前运行时间的 107.74%（PDF 第 9 页，表 3）。反过来，脚本类错误次数很多，却大多在启动初期退出。附录图 17 进一步显示，最终完成的作业只消耗约 20% 到 30% GPU 资源；约 40% 作业失败但只占约 10% 资源；约 7% 被取消的作业反而占 60% 以上资源，因为其中有大量长时间预训练（PDF 第 20 页，图 17）。

从观测到两个工程系统

论文没有训练一个统一的 workload prediction model。方法分成两层：第一层是多源 trace characterization，通过作业元数据、15 秒监控、运行日志和细粒度 profiling 相互验证；第二层是把观测转成两个已经集成到 InternEvo 的系统机制。

预训练容错系统包含 checkpointing、diagnosis、recovery 三部分。异步 checkpoint 先把模型状态写到富余的 host memory，再由独立线程持久化到远端存储，使训练主线程不必等待 TB 级状态写盘。诊断端先让 Log Agent 从数百 MB 的日志中持续生成正则过滤规则，再让 Failure Agent 对压缩日志做规则匹配与向量检索；无法由已有规则诊断时，系统使用 GPT-4 找根因、判断是否可恢复，并把确认后的新规则写回规则库。作者还用 self-consistency 和另一个 LLM 对多次结果投票，降低日志过滤错误（PDF 第 10 至 11 页，图 15）。恢复端会针对故障运行检测。例如 NVLink error 使用两轮 NCCL allgather：先把节点两两分组找出可疑组，再把可疑节点与正常节点重组，以定位并隔离坏节点；loss spike 则回退到更早的健康 checkpoint 并跳过可疑数据批次（PDF 第 11 页）。

评测调度器则把一个看似完整的 evaluation job 拆成可独立调度的阶段。第一步，针对约 60 个数据集并发加载同一模型造成的远端存储争用，trial coordinator 先按节点提交 precursor job，把模型从远端存储搬到节点共享内存，再让各 GPU trial 通过 PCIe 读取本地副本。第二步，GPU 生成结果后立刻释放 GPU，把代码测试等 metric computation 改成 CPU 作业。第三步，利用各数据集历史运行时长较稳定这一先验，对数据集进行合并或拆分，按预计时长排序后 round-robin 分配，并优先启动 CPU metric 较长的 trial，以便与其他 GPU inference 重叠（PDF 第 11 至 12 页，图 16）。

论文报告的数字

在 123B 模型、2,048 张 GPU 的 profiling 中，InternEvo V2 的 hierarchical ZeRO 相比 V1 的 3D parallelism 约加速 16%，并减少空闲区间；同样趋势也出现在 1,024 GPU 的附录实验中（PDF 第 7 页，图 10；PDF 第 20 至 21 页，图 19 与附录 A.4）。这项结果是具体框架配置比较，不应当解释成 hierarchical ZeRO 在所有网络拓扑上固定快 16%。

异步 checkpoint 对 7B 和 123B 模型将 checkpoint 时间及其开销降低 3.6 到 58.7 倍，checkpoint interval 为 30 分钟；但异步测量不包含后台最终持久化到存储的时间。故障诊断系统把人工干预减少约 90%，作者明确承认该数字不是严格评测，因为系统组件仍在持续改进（PDF 第 11 页，“System Performance”）。

评测系统使用一个 7B 模型和 63 个数据集做代表性测试。在单节点条件下，makespan 缩短 1.3 倍；在四节点条件下缩短 1.8 倍（PDF 第 12 页，“System Performance”）。远端加载压力测试还显示，同一节点的单卡 trial 从 1 个增至 8 个时，受 25Gb/s storage NIC 限制，平均加载速度大幅下降；并发扩展到 8 至 256 张 GPU 后，单 trial 加载速度趋于稳定（PDF 第 12 页，图 16）。

数据与系统贡献

论文把 LLM 数据中心的基本调度单位从“训练 job”改写成“开发 pipeline 中的阶段与反馈回路”。预训练、评测、SFT、调试在作业数、卡数、时长、优先级和可拆分性上完全不同；只按 GPU 数或 FIFO 排队无法表达这种结构。作者也没有让 trace study 停在 implication：评测中的 CPU/GPU 阶段分离和预训练中的故障恢复，都是由具体数据直接推导出的系统改造。

第二个实质贡献是把故障代价量化为“GPU 数 × 故障前时间 × 恢复时间”，揭示少量基础设施故障比大量脚本错误更值得系统优先处理。第三个贡献是公开 AcmeTrace、InternEvo 和模型链接（PDF 第 21 页，附录 C），让后续调度研究不必继续只在 2017 年 Philly 一类旧 trace 上拟合。

统计口径和外推限制

第一，trace 只来自一个机构的两个集群，而且资源保留、作业优先级和 InternEvo 使用方式都具有本地政策色彩。评测排队最长是“工作负载属性 + 预训练优先政策”的共同结果，不是任何 LLM 集群的自然定律。第二，数据不含线上 serving，不能用于推断请求到达、TTFT、token latency 或 KV cache 行为；论文的“inference task”大部分实际是离线评测。第三，主体模型是 decoder-only dense Transformer，MoE 只在附录用 Mistral 7B 做了 1,024 GPU 的短 profiling，且单 NIC 网络导致其利用率明显较低；多模态模型、RLHF 和后来的长上下文训练都没有形成同等深度的统计（PDF 第 12 页“Scope Limitations”；PDF 第 21 页，图 22）。

第四，系统实验规模有限。评测调度只报告一个 7B 模型、63 个数据集和一到四个节点；故障诊断减少 90% 人工干预的结果被作者自己标注为非严格评测；异步 checkpoint 的数字排除了后台持久化时间。第五，GPU utilization 的 97%/99% 中位数与 SM activity 的约 40% 中位数定义不同，阅读时不能混为“40% 算力利用率”或“99% 算力利用率”。

这些发现怎样影响调度

这篇论文对通用训练调度器提出了三个修正。其一，Kalos 中大作业消耗超过 96% GPU time，而预训练 GPU 本身又接近满显存、高 nvidia-smi utilization，因此面向小模型的同卡 packing 并不是默认答案。其二，预训练作业规模大、checkpoint 与恢复昂贵，简单依赖频繁 preemption 的 LAS、SRTF 或弹性调度可能得不偿失。其三，评测具有天然的 task decomposition 和 CPU/GPU stage separation，调度器应该操作 trial DAG，而不是把整个 evaluation 当作一块不可分的 GPU 占用。

它与 CSUR 综述形成“证据到设计空间”的对应：Acme 的 GPU sharing 边界对应综述的 training resource-utilization manner；故障与 checkpoint 对应 elastic/preemptive scheduler 的隐藏开销；评测解耦则补足综述对端到端 LLM 开发链路讨论不足的部分。后续调度研究需要联合处理资源预留、故障风险、阶段依赖和反馈时限，继续为 LLM 增加 FIFO 变体并不能回答这些问题。

核对统计时从哪里开始

先读 PDF 第 1 至 4 页，掌握 LLM pipeline、Acme 硬件和 trace 口径；再读第 4 至 9 页的图 2 到表 3，建立作业偏斜、资源利用和故障代价的证据链；随后读第 10 至 12 页的两个系统，检查设计是否真的回应前面的观测；最后只需补读第 20 至 21 页附录 A，重点看最终状态、host memory、碳排放与 MoE 边界。若时间很少，优先读图 4、图 6、图 13、表 3 和第 12 页的评测调度结果。

细粒度监控看到了什么

这篇论文用细粒度监控揭示 R&D 集群最容易被集群级 occupancy 掩盖的问题：GPU 看起来已经分配得很满，但作业内部在空间上只用了一小部分资源，在时间上又存在长时间空闲，因而形成“资源泡沫”。

CloudBrain-I 的采样范围

作者采集了鹏城实验室 CloudBrain-I 的 328 天 trace，表 2 将其概括为 2020 至 2021 年的 10 个月、155K 个 GPU 作业（PDF 第 2 页；PDF 第 4 页，表 2）。集群面向 520 名学生和研究人员，包含 16 个 CPU 节点和 110 个 GPU 节点；论文写作时集群总计约 1,100 张 GPU，而表 2 记为 1,116 张 GPU，差异来自不同统计时点以及部分维护节点。GPU 类型包括 V100-SXM2、V100-SXM3、T4、RTX 2080 和 RTX 2080Ti，最大单作业请求 768 张 GPU（PDF 第 2 至 4 页，表 1 与表 2）。

CloudBrain-I 在 Kubernetes 上运行 OpenI-Octopus，存储使用 Lustre，多卡作业采用 gang scheduling。Prometheus 通过 cAdvisor 与 GPU exporter 记录 CPU、host memory、每张 GPU 的 SM utilization 和 GPU memory，时间间隔为 15 秒，覆盖作业整个生命周期（PDF 第 2 至 3 页，图 1）。和只保留提交、启动、结束时间的 trace 相比，这个数据集的核心价值是能看见“分配量与实际使用量”的差距。

空间泡沫与时间泡沫

作业长尾中混入了人为的 8 小时边界。 CloudBrain-I 作业平均时长为 42,672 秒，中位数为 6,182 秒，明显长于 Philly、Helios 和 PAI；CDF 在 28,800 秒处陡增，因为交互调试作业的最长时限被设为 8 小时（PDF 第 4 页，图 2(a) 与表 2）。因此这里的长作业不全是长训练，一部分是用户保持调试容器不退出。

资源申请很宽，但实际使用显著更低。 作业申请量的第 80 百分位为 8 个 CPU、2 张 GPU 和 128GB host memory；单作业最大值分别达到 3,840 个 CPU、768 张 GPU 和 39,552GB host memory（PDF 第 4 页，图 2(b) 至 2(d)）。约 60% 作业只申请一张 GPU，却只消耗约 20% GPU time，多卡作业仍然主导资源量（PDF 第 4 至 5 页，图 3）。

低利用不是少数异常，而是整体分布。 70.57% 作业的平均 GPU utilization 与平均 GPU memory utilization 都低于 50%；54.57% 作业这两个指标都不超过 20%；50.28% 作业的 GPU 与 CPU 平均利用率都低于 20%（PDF 第 4 至 5 页，图 4）。还有约 5% 作业表现出严重的跨资源错配，即一种资源利用率超过 80%，另一种低于 20%。全体作业的平均 GPU utilization、GPU memory utilization、CPU utilization 与 host memory utilization 分别只有 21.24%、25.75%、18.12% 和 33.08%；作业生命周期内“最大 GPU utilization”和“最大 GPU memory usage”的中位数也只有 0.78 和 2.4GB（PDF 第 5 页，图 5）。后两个数应按论文图中指标原样理解，不宜脱离 exporter 定义推成硬件理论占用率。

可共享空间存在，但不能用静态平均值直接 packing。 11.54% 作业在 120 秒窗口内表现出 CPU 或 GPU utilization 的尖锐波动，超过 75% 的采样区间会冲到 90% 以上（PDF 第 6 页，图 6）。若把“stable phase”定义为持续至少 240 秒且空闲显存至少 2GB，则 87.02% GPU time 落在这种稳定阶段；但 38.05% GPU 作业包含多个 stable phase，20.97% 作业的不同阶段显存需求差超过 1GB，8.99% 超过 8GB（PDF 第 6 页，表 3 与图 7）。所以共享机会很大，但分配必须跟着 phase 变化，否则既浪费显存，也可能在利用率尖峰时产生干扰。

时间上的空闲同样严重。 作者把连续至少 60 秒、GPU utilization 和 GPU memory 都为 0 的区间定义为 idle slot。此口径下，idle slot 与从未使用的已分配 GPU 合计浪费全体作业 15.30% GPU time，其中调试作业浪费自身 GPU time 的 77.72%，非调试作业浪费自身 GPU time 的 12.52%（PDF 第 7 页，表 4）。调试作业内部，41.62% GPU time 属于运行中的 idle slot，36.10% 属于从未使用的已分配 GPU。接近 80% 的调试作业在其约 80% 生命周期里实际不用 GPU，40.41% 调试作业接近或超过 8 小时上限，说明忘记退出也是重要原因（PDF 第 7 页，图 8）。

配置错误可以让整张卡从头到尾没被碰过。 在多 GPU 作业中，24.01% 只使用了部分申请 GPU。即使请求 1 张 GPU，仍有 24,370 个作业完全没有使用该卡，占这一请求规模的 26.20%；请求 2、4、8、16 张 GPU 时，至少浪费一张卡的作业比例分别为 23.82%、15.47%、14.23% 和 17.43%（PDF 第 7 至 8 页，表 5）。这不是调度器可以靠更好的初始 placement 自动消除的问题，还需要运行时异常检测和用户反馈。

阈值算法和资源画像

论文没有提出预测模型，也没有实现一个新调度器。它的方法是先从 trace 中区分“申请/占用”与“真实使用”，再用两个可计算定义刻画空间和时间上的浪费。

空间维度使用 CPU、GPU SM、GPU memory、host memory 的 15 秒时间序列，报告每个作业的平均值、最大值和跨资源关系。为寻找可共享区间，作者定义 stable phase：长度大于阈值 t，且空闲 GPU memory 大于阈值 m，并对 t 为 60、120、240、480、960 秒，m 为 1、2、4、8GB 的组合做敏感性统计（PDF 第 6 页，表 3）。时间维度定义 idle slot：至少连续 60 秒完全没有 GPU compute 和 GPU memory 使用；另行统计“never-used GPU”，即作业整个生命周期都没碰过的已分配卡（PDF 第 7 页，表 4）。

这种方法的好处是定义清晰，任何包含细粒度监控的 R&D 集群都能复算；它的限制也很直接：阈值是人为选择，指标只能看到资源表象，无法从 trace 恢复完整的训练阶段、Python 调试动作或框架内部因果关系。

论文报告的数字

本文的“实验”主要是 trace 阈值分析而非调度器对照实验。最有用的一组数字来自表 3：当 m=2GB 时，满足 stable phase 的 GPU time 随 t 从 60 秒增加到 960 秒，依次为 88.41%、87.91%、87.02%、85.83%、84.45%；当固定 t=240s、把 m 从 1GB 提高到 8GB 时，该比例从 90.86% 降至 69.51%（PDF 第 6 页，表 3）。这说明“有稳定共享空间”的结论并非只在一个极窄阈值上成立，但可共享容量对显存阈值相当敏感。

表 4 的时间浪费分解也应视为核心实验结果：debugging jobs 的 idle-slot 与 never-used 比例合计 77.72%，但由于这类作业总体 GPU time 较少，它们只贡献全体 GPU time 浪费的 3.31%；non-debugging jobs 自身只浪费 12.52%，却贡献全体浪费的 11.99%（PDF 第 7 页，表 4）。因此，只限制调试作业时长能改善用户行为，却不能消除集群中绝大多数绝对浪费。

测量贡献

这项测量纠正了对 cluster-wide GPU occupancy 的常见理解：它 只说明卡被调度器分出去了，不能说明作业有效使用了卡。对 R&D 集群而言，交互调试、配置错误、多阶段执行和新手用户共同造成大量“已占用、低利用”资源，单看 occupancy 会得出虚假的繁荣。

第二个贡献是把 GPU sharing 的论证从“平均利用率低，所以可以共享”推进了一步。论文同时给出尖峰波动与 stable phase，告诉调度器既有共享空间，也有干扰风险；适合落地的是 phase-aware、可撤回、带运行时监控的动态共享。第三个贡献是补上生产集群 trace 的人群盲区：学生、研究人员和共享账号会形成与成熟生产流水线不同的作业行为。

集群人群和硬件带来的限制

这是单机构、单 R&D 集群的观测，用户构成、8 小时调试上限、OpenI-Octopus 提交方式和 GPU 代际都会影响结果。论文从 job name 与 Docker image 推断模型和框架类型，但没有训练代码、iteration progress、I/O 阶段或人工标注，因此对 idle slot 原因只能提出合理解释，不能做严格因果归因（PDF 第 3 页）。

GPU exporter 的 utilization 与 memory 指标也不是 FLOP、Tensor Core occupancy 或有效训练吞吐；平均利用率低不能自动证明两个任意作业可以无干扰共置。stable phase 和 idle slot 的阈值虽做了敏感性表，但仍是离线定义，在线检测延迟和误判代价没有评估。最重要的是，论文没有实现并比较 phase-aware scheduler，因此七条 implication 是有数据支持的设计要求，不是已经验证过的调度收益。

此外，2020 至 2021 年的 V100/T4/RTX 负载不能直接代表 A100/H100 上的大模型训练。NSDI 2024 的 Acme 结果显示，稠密 LLM 作业的显存和表层 GPU utilization 已很高，ICCD 论文中“普遍适合 GPU sharing”的结论必须按 workload class 重新检查。

这些发现怎样改变调度动作

这篇论文直接给调度器提出四类需求：按作业真实使用量而非申请量配资源；识别 debugging job 并使用不同队列或时限；按 stable phase 动态调整 GPU memory allocation；对从未使用的卡做运行时回收和及时告警。它和 Gandiva、AntMan、MIG/MPS 类 GPU sharing 工作关系最紧密，但它同时提醒 sharing scheduler，11.54% 作业有高幅波动，若只按均值 packing 会在尖峰时发生性能干扰。

它也解释了为什么 CSUR 综述把“resource-utilization manner”设为与“scheduling objective”正交的一条分类轴：同样追求低 JCT 或高 fairness，可以用 exclusive allocation、GPU sharing 或 elastic training 达成，而 R&D trace 告诉我们应该何时选择 sharing。与 SC 2021 相比，SC 主要从 scheduler log 推断作业、集群和用户行为，ICCD 加入细粒度 utilization 后，才看见分配后的内部泡沫。

核对分母时从哪里开始

先读 PDF 第 2 至 4 页，明确 R&D 集群、trace 和生产集群的差异；随后集中读第 4 至 8 页的图 4、图 5、表 3、表 4 和表 5，这是论文全部证据；最后回看第 1 至 2 页的动机和第 8 页的七条 implication，判断哪些结论由数据直接支持，哪些仍需要系统实现。时间有限时，可以跳过相关工作，重点精读第 5 至 7 页。

画像和预测怎样接起来

这篇论文既发布了 2020 年 SenseTime Helios 的大规模 DL 作业 trace，也尝试证明历史作业和集群趋势具有足够可预测性，可以用一个插件式框架改善作业排序和节点节能。

Helios 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 衡量，还要看等待伤害是否集中。

QSSF 与 CES

作者设计了一个位于 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 更可靠。

核对基线时从哪里开始

先读 PDF 第 2 至 4 页的 Helios 架构、trace 与 Philly 对比；再读第 4 至 7 页的图 2 到图 9，重点看七条 implication 如何从数据出来；随后精读第 8 至 11 页的算法 1、算法 2、表 3 至表 5；最后一定要读第 12 页的 future work，以免把 simulation 结果误认为生产部署结果。若只关心调度模型，直接读第 8 至 11 页，但应先记住基线是每 VC FIFO 且 SJF/SRTF 使用 oracle runtime。

这篇综述整理什么

这篇综述用“调度目标”和“资源使用方式”两条正交轴整理训练与推理调度器，并把 HPO 与训练/推理混合负载单列出来，提供的是设计空间地图而不是新的调度算法或统一性能排名。

收录范围和时间边界

综述没有采集新的 datacenter trace，也没有统一实验数据集或固定观测窗口。它汇总已有训练、推理、HPO 和 hybrid workload scheduling 文献；稿件记录为 2022 年 5 月 24 日收到、2023 年 2 月 11 日修订、2023 年 12 月 15 日接收，正式发表于 2024 年 1 月（PDF 第 1 页与第 38 页）。引用中包含少量 2024 年工作，因此可以把覆盖边界理解为接收前后的文献快照，而不能理解为完整覆盖 2024 年以后迅速发展的 LLM serving。

论文没有报告系统化检索数据库、检索式、纳入排除流程或 PRISMA 式文献计数。表 1、表 2、表 3 为作者按主题整理的代表性 scheduler 清单，列出年份、目标、方法、异构/弹性能力、代码和物理 testbed 规模。规模被离散为 S (0,30]、M (30,60]、L (60,120]、XL (120,+infinity) 张 GPU，- 表示没有物理集群实验或规模未说清（PDF 第 9、18、27 页，表 1 至表 3 的图例）。

训练和推理的调度分类

综述的“发现”主要是跨论文结构，而不是从同一 trace 计算出的统计分布。作者先提炼六个训练特征：资源异构、placement sensitivity、迭代性、feedback-driven exploration、exclusive allocation 对 GPU sharing、gang scheduling 对 elastic training；再提炼两个推理特征：固定输入下较确定的在线执行，以及 latency/accuracy 的严格要求（PDF 第 4 至 6 页，图 2）。这些特征是后续分类的因果入口。

训练调度按目标分为 efficiency、fairness、deadline guarantee。Efficiency 又含 timing、cost 与 resource efficiency；fairness 区分同构 GPU 和异构资源；deadline 工作则要预测不同 placement 下的 throughput。与目标轴正交，训练还按资源使用方式分为 heterogeneous resources、GPU sharing、elastic training（PDF 第 8 至 18 页，表 1）。这种双轴比按论文逐篇罗列更有用：一个系统可以同时是 fairness scheduler、heterogeneity-aware scheduler 和 elastic scheduler。

推理调度同样分两轴。目标轴包括 accuracy/latency/cost 三者的效率权衡，以及 system throughput；资源轴包括 colocation/resource sharing 和 heterogeneous resources（PDF 第 18 至 25 页，表 2）。作者把 accuracy、latency、cost 称为 trilemma，强调在线服务里 latency 通常优先；提高 throughput 的常用办法是 batching，但它本质上以额外排队延迟换更高 GPU utilization，缓存则以更多存储换更少重复计算（PDF 第 21 至 23 页，Insight 9 与 Insight 10）。

HPO 被单列，是因为一个 HPO job 实际包含大量结构相似的 training trial，scheduler 可以早停差 trial、把资源转给有希望的 trial、融合多个 trial，甚至用小模型转移超参数。Hybrid 类别则讨论端到端训练/推理平台，以及把可预测 batch training 填入在线 inference 的闲时 GPU（PDF 第 26 至 28 页，表 3）。作者最终给出 13 条 Insight，并在结尾把未来问题归为新型 DL workloads、scheduling decision making 和 underlying heterogeneous hardware 三类（PDF 第 28 至 29 页）。

两条 taxonomy 轴

这篇论文的方法是 taxonomy 和 qualitative synthesis，不是预测模型。作者先用 workload characteristics 解释为什么传统 HPC/cloud scheduler 不够，再把 scheduler 放进“目标 × 资源使用方式”的格子，比较其 heuristic、数学优化、profiling/prediction、ML/RL 等决策机制。

训练侧的决策方法包括：LAS/MLFQ 一类启发式优先级；MILP、LP、primal-dual、matching 等数学优化；通过 profiling 或历史 trace 预测 job duration、placement sensitivity 与 interference；用 GBDT、random forest 或 RL 选择 priority、placement 与弹性资源。推理侧则加入 model selection/ensemble、AIMD 或优化式 dynamic batching、result/model caching、few-shot performance model、autoscaling 与干扰感知 colocation。综述没有把它们压成统一公式，因为各论文的输入信息、目标函数、硬件和 SLO 不同。

这也是阅读时应保持的判断：表格中的“支持 heterogeneous/elastic”“有 code”“testbed 为 L/XL”只是功能与证据规模标记，不表示质量评分，更不表示一个 XL 系统一定优于 S 系统。

综述中的证据怎样读

综述没有自己的 scheduler 实验，也没有对被引工作的 JCT、throughput 或 cost 做归一化 meta-analysis。因此不能从表 1 至表 3 读出“哪种方法平均快多少”。它提供的少量数字主要用于说明问题量级和分类口径。

例如，作者引用 AWS 报告称 inference 已占 MLaaS 基础设施成本的 90% 以上；推荐服务常要求低于 100ms，其他推理服务也常见低于 200ms 的 latency 要求（PDF 第 6 页）。这些是背景来源的数字，不是作者在统一 testbed 上复测的结果。论文还指出，针对 HPO 结构进行 GPU sharing 或 trial fusion，相比 workload-agnostic 管理可以带来超过一个数量级的资源与时间节省，但这同样是对已有工作的归纳（PDF 第 28 页，5.3 Discussion）。

综述自己的量化设计主要是物理实验规模分档：S 不超过 30 GPU，M 为 31 至 60，L 为 61 至 120，XL 超过 120（PDF 第 9、18、27 页表格图例）。这个分档很有价值，因为它会提醒读者，大量调度器只在小规模 testbed 或 simulation 上展示结果；但分档太粗，也没有纳入 trace realism、baseline 强度和 production deployment，不能替代逐篇实验审查。

整理贡献

综述先把“目标”与“机制”拆开。很多旧综述按 training/inference 或论文年份排列，容易把目标函数、资源分配和实现技术混在一起；本文明确指出 fairness、JCT、deadline、cost 是目标，GPU sharing、heterogeneous allocation、elasticity 是实现这些目标的资源方式。

第二项贡献是把 training 与 inference 放进同一篇 datacenter survey，同时又不强行统一二者。训练是长时、可 checkpoint、placement-sensitive 的离线作业；推理是短时、请求驱动、受 tail latency SLO 约束的在线服务。两者都能 sharing，但训练担心 convergence、reproducibility 与 preemption overhead，推理担心 interference 导致 SLO violation。

第三项贡献是把 HPO 和 hybrid workload 提到独立位置。它们说明真正的数据中心并非只有“训练队列”和“推理队列”两个孤岛，trial 相似性、在线流量谷值、模型更新和共享中间状态都能创造额外调度空间。这一点也为 Acme 的评测阶段解耦提供了自然延伸。

策展式综述的边界

论文在 PDF 第 8 页主动排除了多类相关工作：单作业训练/推理优化，网络 I/O 与功耗等硬件资源级调度，以 CPU、FPGA、ASIC、PIM 为主的系统，移动端与 edge，特定 RNN/推荐/视频应用，以及 privacy 目标。更关键的是，背景部分明确主要讨论 data-parallel elastic training，把 model parallelism 和 pipeline parallelism 视为 large-model 特例并排除在主体范围外（PDF 第 4 页）。这对 2024 年后的 LLM 训练与 serving 是很大的外推限制。

论文后段虽然补入 Acme、Hydro、Titan、DeltaZip、Punica、S-LoRA、AlpaServe 等 LLM 相关工作，但没有围绕 token-level iteration scheduling、KV cache、prefill/decode disaggregation、expert parallelism、跨机 checkpoint 等形成新的完整 taxonomy。它更适合作为传统 DL datacenter scheduling 到早期 LLM scheduling 的桥梁，而不是当前 LLM serving 的最终综述。

此外，文献选择过程不够系统，表格没有统一复现实验，13 条 Insight 多为作者的定性判断。不同论文中的 JCT、makespan、cost、accuracy 和 utilization 定义并不一致，读者不能横向比较表格后直接选“最好”的 scheduler。对 ML/RL scheduler，论文也明确指出需要更多 benchmark 与集体评测来验证 practicality（PDF 第 18 页，3.3 Discussion）。

怎样用 taxonomy 对照本目录论文

这篇综述就是其余三篇 workload study 通往 scheduler design 的索引。SC 2021 Helios 在综述中同时扮演 trace characterization、ML priority prediction 和 CES 节能的例子；ICCD 2022 CloudBrain-I 为 training GPU sharing 提供低利用与 phase 波动证据；NSDI 2024 Acme 则提醒读者 LLM dense pretraining 的高显存、高表层利用率和昂贵恢复会改变旧 sharing/elasticity 假设（PDF 第 10、11、15 页及参考文献 [65]、[182]、[66]）。

反过来，综述也提供检查 workload paper 的问题清单：论文优化的是 timing、cost、fairness 还是 deadline？它改变的是 placement、sharing、elasticity 还是异构资源分配？预测所需信息从哪里来？preemption、interference、accuracy 与 SLO 的代价是否被计入？用这套框架看前三篇，会发现 Helios 主要优化 timing/cost，CloudBrain-I 主要论证 sharing feasibility，Acme 则把 fault tolerance 与 pipeline-stage scheduling 加进设计空间。

核对综述条目时从哪里开始

先读 PDF 第 2 至 8 页，掌握工作负载特征、调度流程和明确排除范围；然后先看第 9 页表 1，再读第 10 至 18 页训练分类；接着看第 18 页表 2，再读第 19 至 25 页推理分类；最后读第 26 至 29 页的 HPO、hybrid 和 outlook。不要从参考文献顺序通读，也不要试图一次记住所有 scheduler 名字。第一遍只抓“双轴 taxonomy + 13 条 Insight”，第二遍再按自己的目标回到表格找代表系统。