LLM Training | 木叶吟

Helix：用图调度自动化通信-计算重叠

Mon, 18 May 2026 12:00:00 +0800

大模型很少只靠一种干净的并行策略训练或推理。Tensor parallelism 切分矩阵计算，pipeline parallelism 切分模型层，sequence parallelism 把长上下文分散到多张卡上，expert parallelism 则把 token 路由到分布式 expert。真实部署里，这些维度往往会组合在一起。

这种组合很强，但也带来一个熟悉的系统成本：通信空泡。当 AllReduce、AllGather、ReduceScatter 或 All-to-All 落在关键路径上时，GPU 计算单元就在等待。在 dense tensor-parallel block 里，等待可能来自 sharded matrix result；在 long-context sequence-parallel block 里，等待可能来自 sequence chunk 交换；在 MoE layer 里，等待可能来自跨 expert 的 token routing。并行策略不同，但问题形状相同：计算和通信都存在，只是执行图没有暴露出足够多可以安全重叠的机会。

Helix 的核心想法是：communication-computation overlap 应该是一个图调度问题，而不是每遇到一种新并行模式就重新手写一套 kernel trick。Helix 目前是一个从 2026 年初开始的 WIP research project，后续会继续更新。

TL;DR. Helix 把通信-计算重叠变成编译期图调度问题。它不再分别为 tensor、sequence、expert parallelism 手写 overlap，而是在同一张图里暴露 compute、communication、wait 和 dependency，再在 memory budget 约束下调度这张图来减少 bubble。

为什么手写重叠难以扩展

最快的 overlap 技术通常会深入 kernel。它们把一个操作切成小块，提前发起通信，并把足够多的计算融合进去以隐藏通信延迟。对单一模式来说，这种方法可以非常有效。Ring-style attention 可以把 sequence exchange 和本地 attention block 重叠起来；tensor-parallel kernel 可以把 collective 和 partial matrix multiplication 做流水；MoE 系统也可以围绕 token dispatch 调度 expert computation。

问题在于，这类优化往往把模型、collective、tiling shape 和同步协议的假设都写进了实现。一旦模型结构变化，或者部署同时组合 tensor、sequence、expert parallelism，优化就很难复用。更重要的是，局部技巧可能会错过全局机会：某个并行维度产生的通信，本来可以藏到另一个并行维度的计算下面，但 pattern-specific optimizer 未必看得见。

Helix 把优化边界上移到编译后的执行图。torch.compile 捕获 model-parallel program 后，Helix 可以在同一个 intermediate representation 里看到 compute operator、communication operator、wait 和 dependency edge。这个统一图抽象是关键。编译器不再需要为每一种并行策略写单独的 overlap recipe；只要节点在图里可见、依赖关系明确，就可以在同一套正确性规则下调度它们。

关键观察。 重叠机会经常是跨并行维度的：一个并行策略产生的通信，可能可以藏到另一个并行策略的计算下面。Pattern-specific optimizer 容易看漏这种机会，而 graph scheduler 能看到。

调度目标

从高层看，Helix 把 model-parallel program 看成一张有向图。节点是 compute 或 communication operator，边是 precedence constraint：一个 operator 只有在依赖的数据准备好之后才能运行。

优化目标很直接，但有约束：

通过把通信藏到独立计算下面，降低图的 makespan；
保留原始图中的所有数据依赖；
把 peak memory 控制在设备可用预算内。

最后一点很重要。激进 overlap 并不是免费的。如果编译器过早 launch 太多 work，中间 activation 和 communication buffer 的生命周期会变长。一个时间线上看起来更快的 schedule，可能因为 peak memory 膨胀而无法运行。因此 Helix 同时优化时间和内存，并用一个轻量 graph simulator 来指导决策。

系统主要包含三个 compiler pass：tiling、reordering 和 bucketing。

Pass	改变什么	保护什么
Tiling	把粗粒度 operator 切成 tile stream	制造 overlap 机会，同时保持局部依赖
Reordering	围绕 wait 交织不同 tile stream 的 segment	提前通信，同时保留同步语义
Bucketing	把兼容的碎片重新合并	在 memory budget 下拿回 kernel efficiency

Tiling：制造重叠机会

原始执行图通常太粗。一个大的 compute operator 可能必须等待一个大的 communication operator，即使这些工作本来可以拆成小块交错执行。Helix 的第一步是 graph tiling：把 operator 切分成多个 tile stream，同时保留每个 stream 内部的依赖结构。

默认情况下，论文沿 batch dimension 做 tiling，因为它适用范围广，也更容易保证正确性。在某些 correctness 已经明确的图区域里，也可以沿 sequence length 等其他维度切分。

Tiling 有两个收益。第一，它暴露 overlap。一个 tile stream 的通信可以在另一个 tile stream 的计算还在运行时提前发起，从而把一张刚性的图变成几条可以交织调度的小流。第二，它可以降低 activation memory。tile 变小后，同时存活的 input 和 intermediate tensor 也更小，只要生命周期控制得当，peak memory 就会下降。

但 tiling 也有代价。更小的 compute kernel 可能损失效率，尤其是 normalization、softmax 和 pointwise function 这类 memory-bound operator。更小的通信消息也可能降低有效带宽。论文里的 profiling 显示，小 tiling factor 通常是更实际的选择；Helix 默认使用 K = 2，因为它能暴露足够 overlap，同时避免过度碎片化。

Reordering：安全地实现重叠

Tiling 之后，编译器得到多条相对独立的 tile stream。接下来的问题是 launch order。

朴素 schedule 会把这些 stream 逐条执行。这当然正确，但会留下通信空泡。过于激进的 schedule 则会提前 launch 大量 asynchronous operator，虽然可能增加 overlap，却也会让太多 tensor 同时存活，推高 peak memory。

Helix 使用 Segmented Round-Robin Reordering，在两者之间取平衡。关键观察是，显式 wait operator 天然就是 segment boundary。在一条 tile stream 内，Helix 会把连续的 non-blocking compute 和 communication operator 组成一个 segment，直到遇到 wait。之后，它以 round-robin 的方式在多条 stream 之间调度这些 segment。这样，一个 stream 的通信可以被插入另一个 stream 的 compute-heavy 区间，而 wait 仍然保证原始数据依赖不被破坏。

Scheduler 只在 wait 之间积极重排；wait operator 保留了原始依赖契约。

Segment 级粒度很关键。它比逐 operator eager scheduling 更粗，因此不会让大量中间结果同时挂起；segment 在同步边界被 flush 后，其中间 tensor 可以及时释放。它又比完全串行执行更细，因此能把通信提前到原始图中无法利用的位置。

这也是 Helix 泛化性的重要来源。调度器不需要关心某个节点来自 tensor parallelism、sequence parallelism 还是 expert parallelism。只要节点在图中可见，依赖关系是显式的，reordering pass 就可以对它做统一推理。

Bucketing：把 kernel 效率拿回来

Tiling 创造了灵活性，但过度碎片化会伤害硬件效率。Bucketing pass 负责有选择地修复这种损伤。

它的想法是，在确实能提升端到端性能时，把不同 tile stream 中兼容的 operator 重新合并成更大的 bucket。这听起来简单，但里面有 trade-off。Bucketing 可以降低 kernel launch overhead，也可以改善计算或通信效率；但它也可能重新引入同步、减少调度自由度，并因为把某些 work 提前而延长 tensor 生命周期。

Helix 把 bucketing 看成一个 constrained search。对一个 candidate merge，graph simulator 会估计两个量：新的 makespan 和新的 peak memory。只有当节省的时间值得额外内存成本，并且不会破坏 tiling 和 reordering 已经创造出的关键 overlap 时，这个 merge 才有价值。实现上，系统用 dynamic programming 在 candidate bucket 中选择一组最优 merge，使 schedule 在 memory budget 内获得更好性能。

这个 pass 让 Helix 不只是“全部切碎然后祈祷”。它先主动制造 overlap 粒度，再把不该碎着运行的部分融合回来。

Simulator 是控制回路

Graph simulator 很轻量，但很核心。它在编译期运行，用来估计候选 schedule 的 runtime 和 peak memory。对 compute 和 communication cost，它结合图中可见的 operator semantics、tensor shape、analytical modeling 和自动 benchmark。对 memory，它模拟执行顺序，并追踪 tensor 和 communication buffer 的生命周期。

Simulator 估计项	Optimizer 为什么需要
Candidate makespan	判断 schedule 是否真的隐藏了通信
Peak memory	拒绝制造过多长生命周期 tensor 或 buffer 的 schedule
Operator 和 communication cost	在真实执行前比较 tiling、reordering、bucketing 选择

Simulator 不需要完美才有用。它只需要足够准确地给 scheduling choice 排序，让编译器避开明显糟糕的 trade-off。论文报告显示，在 GPT-3、LLaMA3 和 Qwen3-MoE 的配置上，估计结果和真实 trace 比较接近。例如在一个 GPT-3 Curie 配置中，estimated runtime 是 6.80 秒，真实 measured runtime 是 6.41 秒；estimated peak memory 是 65.9 GiB，真实值是 66.0 GiB。

这种 fidelity 很重要，因为 optimizer 必须在真实运行前做决定。没有 simulator，编译器要么需要昂贵的 trial execution，要么只能依赖脆弱的 heuristic。

Helix 带来了什么

在 GPT-3、LLaMA3 和 Qwen3-MoE workload 上，Helix 展现出一致模式：一旦通信被暴露给图调度，bubble 会缩小，有效 GPU work 会增加。端到端训练吞吐在单节点内提升 4% 到 9%；当通信跨节点时，收益扩大到 12% 到 30%。在 layer level，communication bubble 通常减少超过 60%，这直接说明 scheduler 确实在隐藏通信，而不是简单把开销挪到别处。

Helix 换来了什么。

单节点内端到端训练吞吐提升 4% 到 9%。
跨节点通信场景下吞吐提升 12% 到 30%。
许多场景下 layer-level communication bubble 减少超过 60%。
Long-context inference activation memory 最多减少 30%。

内存收益同样重要。在 long-context inference 中，Helix 最多减少 30% activation memory，在 measured trace 中把 peak memory 从 23.5 GiB 降到 21.4 GiB。这和性能收益来自同一个设计原则：graph scheduler 控制 tile 什么时候变成 live、其中间结果什么时候可以释放，而不是让 overlap 意外拉长 memory lifetime。

和手写 tensor-parallel overlap 的对比也很有意思。在大规模 GPT 和 LLaMA 训练中，Helix 相对 baseline 达到 17% 和 16% speedup，而 AsyncTP 在同一对比中是 12% 和 13%。这并不是说 compiler scheduling 会让 specialized kernel 过时；更重要的是，graph-level optimizer 可以在同一个地方同时处理跨维度 overlap、正确性、同步、kernel efficiency 和 memory lifetime。

Helix 的技术核心就是这件事：让通信在图里可见，让依赖关系显式化，然后让编译器去调度那些原本需要为每个 workload 手工重新发现的 overlap。

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 当作启动后固定不变的配置，而是在检测到异常设备后，围绕剩余资源重新组织训练计划。

TL;DR. ResiHP 把 resilience 变成 dynamic parallelism 问题：先把真实 fail-slow 和 sequence-length 噪声区分开，再把 TP、PP、DP 作为一个整体重组，避免一张异常设备决定全局训练速度。

为什么故障检测很难

最直观的信号是 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 本来应该花多少时间。

关键观察。 在 LLM 训练里，时间有噪声，是因为 workload 本身就有噪声。Detector 必须先按 expected FLOPs 和 pipeline schedule 做归一化，再把 slowdown 当作硬件故障信号。

用 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 之间重新分配任务。

Fail-slow GPU 是局部问题，但在 hybrid parallel training 里，它的影响会沿着 TP group、PP stage 和 DP synchronization 扩散。

动态重组 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 来处理。

并行维度	可以如何适配	为什么有用
Tensor parallelism	调整 group size 和 membership	避免慢 rank 或故障 rank 污染整个 TP group
Pipeline parallelism	重新划分各 stage 的 layer	把工作从慢 stage 移走，降低 pipeline bottleneck
Data parallelism	在 replica 之间迁移 workload	当 replica 实际速度分化时重新平衡进度

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。

ResiHP 换来了什么。

把真实 fail-slow signal 和 sequence-length、pipeline schedule 噪声区分开。
将 TP、PP、DP 作为一个连接在一起的 3D layout 适配，而不是孤立调几个 knob。
在评估故障场景中，将训练吞吐提升 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？

TL;DR. 这篇文章主要讲 Bubble Squeezer：Hydro 中把流水线并行训练空泡变成安全临时执行窗口的组件。它的目标不是简单“利用空闲 GPU”，而是判断一个 bubble 是否真的安全，把合适大小的 surrogate trial 放进去，并在主训练任务重新需要 GPU 前及时暂停。

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。

背景组件	它给 Bubble Squeezer 提供什么
Model Shrinker	足够小、可以塞进短暂 bubble 窗口的 surrogate trial
Trial Binder	大小可调的 fused trial bundle，用来适配剩余 memory
`hydro.nn` module	细粒度 pause/resume 的 hook 点

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

大多数 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 来说，这是一个入口。

Bubble Squeezer 的作用。 它看进一个已经分配给 pipeline-parallel 训练任务的 allocation 内部，从中抽取一种新的资源：短暂、重复、stage-local、compute 低但可能仍有 memory 余量的 GPU 时间窗口。

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 期间可用。目标很窄也很明确：在不拖慢主训练任务的前提下运行调优工作。

难点不是找到看起来空闲的时间，而是把这段时间变成可用资源，同时不让 colocation 变成 interference。

控制循环有三项职责：

发现窗口。 Hydro 修改基于 DeepSpeed 的执行路径，报告 pipeline progress 和 resource consumption。这告诉 Bubble Squeezer 某个 worker 什么时候进入 bubble，以及还有多少 memory 可用。
判断窗口是否安全。 Hydro 观察 NCCL kernel 的 CUDA stream 状态，以区分 communication-heavy waiting time 和 compute time。
控制访客任务。 Bubble Squeezer 在 hydro.nn module 上注册 hook，让 HydroTrial 可以在 forward 和 backward pass 内部细粒度 pause/resume。

第二点尤其关键：直接 colocation 会让两个工作负载盲目竞争，论文报告 direct colocation 会给大模型带来约 12% slowdown。

在 bubble 开始时，Hydro resume 一组 fused surrogate trial；在 bubble 结束时，在大模型重新需要 GPU 前把它们 pause。实现上使用 Linux signal 做 pause/resume 控制，调度决策则由 profiled trial footprint 和当前可用 memory 共同决定。

Figure 1. Bubble Squeezer 将 HydroTrial 插入流水线并行训练的空闲区间。

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

Bubble Squeezer 的决策	信号或机制	为什么重要
什么时候可以运行 HydroTrial？	来自主训练任务的 pipeline progress report	Bubble 很短而且 stage-local，时机必须跟随 pipeline schedule
应该运行多少 trial work？	Profiled trial footprint 加当前可用 memory	Fusion count 可以按 bubble 增加、降低或跳过
什么时候必须停？	Fused HydroTrial 中的细粒度 pause/resume hook	访客任务必须在大模型回到 compute 前让出 GPU

理想场景是长时间运行的 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。

Figure 2. 插入 HydroTrial 后，bubble 内 GPU 活动显著增加，同时大模型训练时间线保持稳定。

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

Bubble Squeezer 换来了什么。

Bubble 期间的 SM activity 从约 2% 提升到约 50%。
Fused HydroTrial 在 bubble 内能达到约 15% 的独占吞吐。
它避免了 blind colocation，后者在论文中会给大模型带来约 12% slowdown。
在受限的端到端场景中，它把 HPO 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