LLM Training | 木叶吟

GPU 集群调度：深度学习任务该如何排队、放置与共享

Sun, 17 May 2026 14:30:00 +0800

GPU 集群调度很容易被低估。乍看起来，它像一个熟悉的资源分配问题：任务到达，GPU 有空闲也有忙碌，调度器决定谁先运行。

深度学习打破了这种简单性。

训练任务可能运行好几天，需要成组 GPU，并且对 placement topology 非常敏感。推理服务是在线服务，对 latency 敏感，如果不做 batching 或 colocation，往往又难以充分利用 GPU。超参数搜索会启动大量相似 trial，其中大多数注定会被丢弃。LLM workload 还会带来 model parallelism、巨大的 memory footprint、long context，以及开发过程中的 bursty pattern。

我们的 survey，Deep Learning Workload Scheduling in GPU Datacenters，试图整理这个复杂的设计空间。理解这个领域最有用的方式，不是把调度器列成清单，而是看它们面对的一组张力：速度与成本、利用率与隔离、公平性与效率、在线 latency 与集群整体吞吐。

为什么深度学习调度不一样

传统 HPC 和大数据调度器提供了有用起点，但深度学习任务有自己的物理规律。

训练任务往往需要 gang scheduling。一个分布式任务必须同时拿到所有请求的 GPU，因此 GPU 不像 CPU slot 那样容易切分。Placement 很重要，因为通信密集型任务如果被放在同一节点内或通过 NVLink 连接，可能比散落在弱链路上快得多。抢占很昂贵，因为模型和优化器状态都很大。同时，训练又具有迭代性，所以少量 profiled iteration 往往能暴露 throughput、memory behavior 和 placement sensitivity。

推理的压力几乎相反。每个请求相比训练任务很小，但服务有 latency SLO。Batching 可以提高 GPU utilization，但等待组 batch 会增加用户可见 latency。Colocation 可以提升 throughput，但 interference 可能打破 tail latency。调度器必须在平均效率和最坏情况下的用户体验之间做取舍。

这就是为什么 GPU 集群调度不是一个单一问题。它是一组相关问题，正确答案取决于工作负载。

训练：效率、公平性、Deadline

对于训练任务，survey 把调度目标分成三大类。

第一类是效率。有些调度器通过 priority rule 降低任务完成时间，比如 least attained service 或 progress-aware variant。另一些调度器使用 profiling 或 learning-based method 预测任务时长、速度、placement sensitivity 或未来资源需求。Placement 是效率的核心部分：一个调度器可能在总量上有足够 GPU，却因为集群碎片化而无法满足 locality，导致性能很差。

第二类是公平性。公平性很微妙，因为在常见 gang-scheduling 场景中 GPU 不可分割，而异构 GPU 对不同任务的价值也不一样。Finish-time fairness、long-term GPU-time fairness 和 heterogeneity-aware fairness 都在回答同一个问题的不同版本：这个任务或租户应得多少 service，实际又获得了多少？

第三类是 deadline guarantee。Deadline-aware training 研究相对少，但对生产流程很重要。Best-effort 任务可以容忍等待；SLO 任务不行。这类系统需要预测某个任务在不同 placement 和 resource allocation 下能否按 deadline 完成，再决定如何混合 deadline 任务和普通任务。

训练：GPU 如何被使用

目标只是 taxonomy 的一半，另一半是调度器如何使用资源。

Heterogeneous resource scheduling 认识到“一张 GPU”并不是一个统一单位。不同 model architecture 对新一代 GPU、CPU allocation、memory、network bandwidth 和 storage 的收益不同。一个 cost-effective 调度器应该把任务放到和其 bottleneck 匹配的硬件上，而不是盲目把所有任务都送到最新设备。

GPU sharing 试图解决 underutilization 问题。许多训练任务无法吃满现代 GPU。通过 MPS、MIG、virtualization、time sharing 或 framework-level co-execution，把多个任务打包到同一设备上可以提高利用率。风险是 interference：调度器必须知道什么时候 sharing 有收益，什么时候它只是悄悄拖慢所有任务。

Elastic training 会随时间改变分配给任务的 GPU 数量。在需求波动时，它可以减少排队并提升利用率。但 elasticity 不是免费的。资源变化可能需要 checkpoint、reinitialization 或 batch-size adaptation。如果 batch size 的变化影响 convergence，调度器可能提升了系统 throughput，却悄悄改变了模型行为。

一个大趋势是，训练调度器越来越需要和训练框架协同设计。调度器想要细粒度控制，但框架才知道一个任务是否能安全 pause、resize、share 或改变 batch size。

推理：Latency、成本、Throughput

推理调度由另一组三角关系塑造：latency、cost 和 accuracy。

Latency 通常是一等约束。Model serving system 可以通过 batching 提升 throughput，但请求在队列里等待本身就是用户可见 latency。实际调度器往往使用 dynamic batching：服务健康时增大 batch size；latency 接近 SLO 时缩小 batch。

Cost 来自 cloud instance selection、autoscaling 和 heterogeneous hardware。有些工作负载在 CPU 上更便宜，有些需要 GPU，还有些只有在 batch 足够大时才划算。调度器不仅要决定模型放在哪里，还要决定需要多少 replica、哪些 instance type 值得付费。

Accuracy 又引入了一个维度。有些系统会在 model variant、ensemble 或 modality 之间选择。小模型便宜快速但准确率较低；大模型更慢但效果更好。这让推理调度变成 policy problem：在给定 latency 或 cost budget 下，可以接受多大 accuracy loss？

Throughput 技术包括 batching、caching、model residency 和 colocation。但推理 colocation 比训练 colocation 更危险，因为 SLO violation 是即时可见的。调度器需要 interference model、isolation mechanism 或 hardware partitioning，才能让 sharing 安全。

训练和推理之外

有些工作负载值得单独分类。

Hyperparameter optimization 技术上属于训练，但在操作上很不一样。它会启动许多相似 trial，提前剪枝较弱的 trial，并把资源转向更有前途的 configuration。这种结构带来了 early stopping、elastic trial allocation、trial packing、model fusion 和 surrogate-based tuning 的机会。我们的 Hydro 工作就是一个例子：它用 model scaling、trial fusion 和 cluster-level interleaving 让 HPO 少一点 brute force。

混合训练和推理工作负载是另一个前沿。推理集群往往为了应对 burst 而过度配置，在低流量期间留下 idle GPU。如果系统能在推理需求回来时快速 preempt 或 resize 训练任务，训练就可以借用这部分容量。挑战是，在回收空闲资源的同时仍然尊重在线 SLO。

这些例子指向一个更大的趋势：未来调度器会越来越 workload-aware。面对深度学习开发的多样性，一个泛泛的 GPU queue 已经太粗糙。

这个领域正在走向哪里

Survey 最后总结了三个至今仍然重要的研究方向。

第一，emerging workload 会继续改变调度器设计。LLM pretraining、fine-tuning、serving、agentic inference 和 HPO 都暴露出不同瓶颈。调度器需要理解的不只是 GPU 数量，还包括 memory pressure、communication structure、context length、trial similarity 和 elasticity。

第二，调度决策需要更好的智能。Heuristic 鲁棒且容易部署，mathematical optimization 更有原则但可能很慢，ML/RL-based scheduler 能捕捉复杂 pattern 但难以信任和 benchmark。实际调度器可能会结合三者：fast path 用 heuristic，profiling 用于校准，复杂决策再交给 optimization 或 learning。

第三，hardware heterogeneity 已经不可避免。生产集群可能包含多代 GPU、专用 interconnect、CPU、storage tier 和 accelerator。异构性带来更好的 cost-performance 机会，但也让公平性更复杂。给一个任务分配老 GPU 和新 GPU，即使用时相同，也很少代表相同服务。

最简单的总结是：GPU 调度已经不再只是填满空 slot。它是在用户可见目标之下，把工作负载结构匹配到硬件结构。

这也是这个方向有意思的地方。最好的调度器不只是队列最短的那个，而是理解眼前的深度学习任务是什么、真正需要什么资源，以及集群愿意做出什么 trade-off 的那个。

Paper: Deep Learning Workload Scheduling in GPU Datacenters: A Survey
Project: Awesome DL Scheduling Papers

ResiHP：大模型训练故障下的动态混合并行

Sun, 17 May 2026 14:00:00 +0800

Reference reading: 大模型训练遇到 GPU 故障怎么办？我们的做法是动态调整 3D 并行.

大规模 LLM 训练不是一个单独的分布式系统问题，而是好几个问题叠在一起。

当训练规模达到数百甚至数千张 GPU 时，故障不再是罕见事件。有些设备会直接消失；另一些设备还活着，但变慢了。后者尤其麻烦：fail-slow GPU 不会让训练任务崩溃，却会拖慢整个同步训练迭代。在 hybrid parallel training 中，这个延迟会沿着 tensor parallelism、pipeline parallelism 和 data parallelism 传播，最后让一张变慢的设备悄悄决定整个任务的速度。

ResiHP 就是为这个场景设计的。它的核心思想是让 hybrid parallelism 变成动态结构。ResiHP 不把 3D parallel layout 当作启动后固定不变的配置，而是在检测到异常设备后，围绕剩余资源重新组织训练计划。

为什么故障检测很难

最直观的信号是 iteration time。如果某一次 iteration 变慢了，也许就有设备故障。

这个逻辑对 LLM 训练来说太脆弱。

现代 LLM workload 经常使用 variable-length sequences。即使用 sequence packing 控制 token budget，真实 attention cost 仍然取决于每个 micro-batch 内部的 sequence length。一个包含许多长序列的 packed batch，自然会比短序列更多的 packed batch 更慢。Pipeline scheduling 又增加了一层噪声：观测到的 iteration time 不只是某个 micro-batch cost，而是多个 pipeline stage 上 forward、backward 和 weight-update chunk 共同形成的 critical path。

这也是知乎文章强调的点：detector 不能盯着 raw iteration time，把每个 spike 都判成故障。它首先要估计，如果所有设备都健康，这个 iteration 本来应该花多少时间。

用 FLOPs 归一化检测信号

ResiHP 的 Detector 会用期望计算量对 iteration time 做归一化。

在 micro-batch 层面，它根据 packed sequence structure 估计工作量。Attention cost 并不是 sequence length 的线性函数，所以模型不仅数 token，还会考虑 quadratic attention cost。在 pipeline 层面，ResiHP 模拟 forward、backward 和 weight-update chunk 的 schedule，预测健康 iteration 的 critical path。

只有在完成这种归一化之后，ResiHP 才比较 observed time 和 expected time。如果二者之间的 gap 仍然异常，系统才把它当作 fail-slow signal，而不是普通的 sequence-length variation。Fail-stop 则通过 missing heartbeat 另行处理。

这个区分很重要，因为 false positive 代价很高。如果一个 resilient training system 经常把正常工作负载偏斜误判成硬件故障，它就会毫无必要地反复重组训练任务。ResiHP 试图让检测足够轻量，能够在线使用；同时也足够准确，让 adaptation 只在真正出问题时发生。

为什么混合并行让恢复更棘手

一旦某个设备被识别为不健康，最简单的反应是把它移除。

但这通常不够。

在纯 data parallelism 中，少一个 worker 主要意味着 replica 数量下降。在 hybrid parallelism 中，一个设备参与的是结构。它可能同时是 tensor-parallel group 里的一个 rank、pipeline 的一个 stage，以及 data-parallel replica 的成员。如果一个 tensor-parallel rank 故障，整个 TP group 都受影响。如果一个 pipeline stage 变慢，上游和下游 stage 都会等待。如果一个 data-parallel replica 落后，同步也会被拖慢。

故障是局部的，但性能损伤是全局的。

因此 ResiHP 不采用单一 workaround，而是在多个层面适配。它会改变 parallelism group size，重新划分 pipeline stage 上的 model layer，调整工作调度，并在 replica 之间重新分配任务。

动态重组 3D 并行

ResiHP 的 Scheduler 负责把检测结果转化为新的训练计划。

对于 tensor parallelism，ResiHP 可以围绕健康设备收缩或重组 TP group。目标不是简单丢弃受影响 group 里的所有设备，因为那可能浪费太多健康 GPU。调度器会搜索更合适的 group size 和 membership，在避开慢 rank 或故障 rank 的同时保留尽可能多的有效计算。

对于 pipeline parallelism，ResiHP 可以重新平衡 model partitioning。慢 stage 不应该继续承担和健康 stage 一样多的 layer。如果某个 stage 变慢，调度器可以给它分配更少 layer，并把工作转移给更健康的 stage，从而降低 pipeline bottleneck。

对于 data parallelism，ResiHP 使用 workload migration。如果某个 replica 落后，而另一个 replica 还有余量，调度器可以迁移一部分工作，让整体进度更平衡。这一点尤其有用，因为 data-parallel replica 在逻辑上对称，但在设备故障或性能退化之后，实际速度可能分化。

关键工程点在于，这些 adaptation 是协调发生的。只调 TP 可能制造 pipeline imbalance；只调 PP 可能让健康 GPU 利用不足；只调 DP 可能没有消除原始瓶颈。ResiHP 把 layout 当作一个相互连接的 3D object 来处理。

Executor 如何兜住重配置

新的 plan 只有在 runtime 能执行时才有意义，而且 recovery 本身不能变成第二次故障。

ResiHP 的 Executor 负责动态重配置的具体机制。它在新的 parallel layout 下重建 model 和 optimizer state，更新通信策略，并支持针对新 group 的高效 data movement。也正是在这里，系统从调度策略进入真正的 fault-tolerant training。

Executor 对 fail-stop recovery 也很重要。如果 GPU 消失了，系统必须在重新分布受影响 model shard 和工作负载的同时保持训练连续性。如果 GPU 只是变慢了，系统又必须避免过度反应，同时降低它对全局 critical path 的影响。

ResiHP 带来了什么

ResiHP 在 256-GPU 集群上、多个故障场景中进行了评估。论文报告称，它达到接近最优的故障检测准确率，并相比已有 resilient training system 将训练吞吐提升 1.13x 到 2.22x。

更大的经验是：LLM 训练的 resilience 不能只是一个 checkpoint-and-restart loop。Hybrid parallelism 本来就是大规模训练能够成立的结构，因此 resilience 也必须理解这个结构。ResiHP 把问题拆成三个层次：

这次 slowdown 是真实故障，还是 sequence-length variation？
3D parallel layout 中真正受损的是哪一部分？
TP、PP 和 DP 应该如何一起改变，才能让训练任务持续前进？

我喜欢 ResiHP 的地方就在这里：它把故障处理看成一个 dynamic parallelism 问题，而不只是 device replacement 问题。

Paper: ResiHP: Taming LLM Training Failures with Dynamic Hybrid Parallelism
Preprint: arXiv:2605.06374

Hydro：把超参数搜索放进流水线空泡

Sun, 17 May 2026 12:00:00 +0800

超参数搜索曾经像是一种可以接受的成本。训练很多个模型，扫几组 learning rate 和 batch size，然后留下最好的那个。它很贵，但仍然属于正常工程节奏的一部分。

后来模型大到一定程度，这个心智模型悄悄失效了。

如果训练一个模型本身就已经占用 GPU 集群的大块资源，那么传统 hyperparameter sweep 几乎显得荒唐：系统要求我们训练很多个高度相似的模型，而其中大多数只是为了被丢弃。更糟的是，已有 tuning framework 通常只看自己被分配到的资源。它们并不知道周围的集群里可能存在空闲 GPU 碎片、异构加速器，或者带有周期性空泡的长时间 pipeline-parallel 训练任务。

Hydro 从一个简单问题出发：能不能让 hyperparameter tuning 少一点 brute force，多一点 systems thinking？

Hydro 有两面。在任务层面，它通过调优更小的 surrogate model 让每个 trial 变便宜。在集群层面，它问了一个更有意思的问题：数据中心能不能用当前被浪费的 GPU 时间来运行这些便宜 trial？

先让 Trial 变小

Hydro 的第一步，是尽可能避免直接调优 target model。它缩小模型，调优小模型，再把找到的 hyperparameter 转移回原模型。风险在于，朴素缩小会改变训练动态。一个适合窄模型的 learning rate，可能在更宽的模型上完全失效，因此 cheap search 可能给出误导性答案。

Hydro 通过 parametrization 让这个想法变得可行，具体来说，是对 maximal update parametrization 的系统化适配。它不只是改变 layer width，还会逐层调整 initialization 和 optimizer behavior，让不同宽度模型在训练中保持可比较的 update scale。更工程化地说，Hydro 希望 surrogate 和 target model 对“哪些 hyperparameter configuration 更好”这件事有一致判断。

实现上，Hydro 采用服务化设计。Model Shrinker 用 torch.fx trace PyTorch model，缩放符合条件的 layer，应用 parametrization rules，并在调优任务继续之前做轻量 correctness check。Trial Binder 则通过 grouped hydro.nn module，把许多小 surrogate trial 融合成一个批量执行单元。这很重要，因为单个 surrogate trial 可能太小，无法喂饱一张 A100；fusion 把很多 tiny trial 变成了形状更适合 GPU 的工作负载。

这些组件都重要，但这篇文章想重点看最有 datacenter 味道的部分：Bubble Squeezer。

集群也是调优系统的一部分

大多数 tuning framework 把集群调度器当作资源售货机。Hydro 则把集群本身纳入优化空间。

Hydro Coordinator 加入了这种集群视角。它最有辨识度的组件是 Bubble Squeezer，目标是长时间运行的 pipeline-parallel 训练任务。Pipeline parallelism 常用于大模型，因为模型会被切成多个 stage，放到多张 GPU 或多个节点上。在常见的 1F1B schedule 中，每个 worker 交替执行 forward 和 backward microbatch，但 schedule 并不是完全致密的。某个 stage 可能完成了一个 microbatch 的 forward pass，然后等待另一个 stage 产生对应的 backward work。这个等待区间就是 pipeline bubble，也就是这里说的流水线空泡。

对大型训练任务来说，bubble 很尴尬。它们很短，反复出现，并且和通信交织在一起。在 bubble 期间，唯一活跃的 kernel 可能只是 NCCL communication，所以即使 GPU 名义上已经分配给训练任务，SM activity 也可能非常低。对普通训练任务来说，这点空间不足以安全运行新任务；但对 Hydro 来说，这是一个入口。

HydroTrial 特别适合放进 bubble 里运行，原因有三点。第一，它们对吞吐波动不敏感：某个 candidate trial 慢一点没关系，只要整个调优任务在前进。第二，它们经过 profiling：Hydro 在把 trial 放到大模型旁边之前，已经知道每个 fused trial 的 memory 和 compute footprint。第三，它们是 elastic 的：fusion count 可以调整，让 trial bundle 适配某个 bubble 剩余的 memory 和 time budget。

Bubble Squeezer 如何挤出空泡

Bubble Squeezer 把 pipeline bubble 变成短暂可用的资源。当一个 pipeline-parallel 大模型训练任务正在运行时，Hydro 会和数据中心调度器协调，获取这些临时机会，并把相应 GPU 标记为只有在 bubble 期间可用。目标很窄也很明确：在不拖慢主训练任务的前提下运行调优工作。

控制循环分成两边。

在大模型侧，Hydro 修改了基于 DeepSpeed 的执行路径，用来报告 pipeline progress 和 resource consumption。这告诉 Hydro 某个 worker 什么时候进入 bubble，以及还有多少 memory 可用。Hydro 还会观察 NCCL kernel 的 CUDA stream 状态，以区分 communication-heavy waiting time 和 compute time。这个区分非常关键：直接 colocation 会让两个工作负载盲目竞争，论文报告 direct colocation 会给大模型带来约 12% slowdown。

在 tuning 侧，Hydro 已经把 surrogate model 规范化成 hydro.nn module。Bubble Squeezer 在这些 module 上注册 hook，让 HydroTrial 可以以细粒度 pause 和 resume，包括 forward 和 backward pass 内部。在 bubble 开始时，Hydro resume 一组 fused surrogate trial；在 bubble 结束时，在大模型重新需要 GPU 前把它们 pause。实现上使用 Linux signal 做 pause/resume 控制，调度决策则由 profiled trial footprint 和当前可用 memory 共同决定。

Fusion count 不是固定的。如果某个 pipeline stage 有更多 spare memory，Hydro 可以运行更大的 fused HydroTrial；如果某个 stage 更紧张，就降低 fusion count 或跳过这个 bubble。这正是 Hydro 任务层和集群层两部分之间的小而关键的连接：surrogate scaling 让每个 trial 变小，trial fusion 塑造工作负载，Bubble Squeezer 决定这种工作负载能在某个具体 bubble 里放进去多少。

理想场景是长时间运行的 pipeline-parallel foundation-model 训练任务，它跨多个 stage 和多台服务器。Stage 越多，通常意味着 bubble 越多，也意味着临时执行机会越多。Multi-fidelity tuning 也很适合这种模式，因为许多不 promising 的 trial 可以用 bubble resource 先推进或淘汰，最强的 trial 再获得 exclusive resource。

空泡能换来什么

评估给出了一个很直观的尺度。Hydro 将 ResNet-18 HydroTrial 插入到一个运行在 32 张 A100、4 个 pipeline stage 上的大型 GPT 训练任务中。在原始 GPT training trace 里，bubble 内 SM activity 大约只有 2%。使用 Bubble Squeezer 后，Hydro 把 bubble 期间的 SM utilization 提升到约 50%，同时没有观察到对 GPT 任务的明显 slowdown。

这些调优工作不会像独占 GPU 时那样快，这是预期内的。在实验中，一个 fusion count 为 16 的 HydroTrial 在 bubble 中获得了大约 15% 的 exclusive throughput。但这部分资源基本来自原本闲置的时间片。在一个端到端模拟场景中，当调优任务只有 1 张独占 GPU、而大模型占据大部分集群时，Bubble Squeezer 将 tuning makespan 降低了 2.7x。

这是 Hydro 最有意思的地方。调度器通常会把已经分配给大训练任务的 GPU 看作不可用。Bubble Squeezer 则往这个 allocation 内部看，找到可重复、边界清晰、低干扰的窗口，让小型、已 profile、可 pause 的工作向前推进。

完整 Hydro 系统仍然很重要：surrogate scaling 让 trial 变便宜，fusion 把 trial 组合成高效 bundle，Bubble Squeezer 再把这些 bundle 放进 pipeline bubble。它们合起来，把 HPO 从 brute-force outer loop 变成了 datacenter-aware service。

当然也有限制。Parametrization 最适合控制 initialization 和 training dynamics 的 hyperparameter，比如 learning rate、batch size、learning-rate scheduler 和 momentum。Dropout、weight decay 这类 regularization 相关选择更难，因为它们更直接依赖模型和数据规模。一些 architecture 也可能需要定制分析。Hydro 并不声称所有 hyperparameter 都可以在所有模型之间转移。

但核心经验是持久的：一旦模型训练进入数据中心规模，超参数搜索就必须同时理解模型、运行时和集群。Hydro 是让这整个 stack 可见的一次尝试。

Paper: Hydro: Surrogate-Based Hyperparameter Tuning Service in Datacenters
Code: S-Lab-System-Group/Hydro