原文：https://dev.to/shrsv/the-straggler-problem-why-one-slow-gpu-can-stall-an-llm-training-run-1cio（作者 @shrsv）
想象一下，你正在 4,096 块 GPU 上训练一个 LLM。
一个训练步（training step）结束时，4,095 块 GPU 已经跑完。
还有一块 GPU 仍在工作。
接下来会发生什么？
什么都不会发生。
其余 4,095 块 GPU 在等它。
这就是同步分布式训练中的掉队者问题（straggler problem）：整个作业的吞吐量往往不是由平均水平的那批 worker 决定，而是由每个同步点上最慢的那个 worker 决定。
这听起来只是个不起眼的系统小麻烦。但在 LLM 的规模下，它会变成一个经济问题。
一个动用数千块 GPU 的训练任务，可能把相当大一部分实际运行时间（wall-clock time）花在等待上，而集群里有些工作其实早就做完了。罪魁祸首往往也不是快坏的 GPU 或断掉的网络链路。最近对一个真实 LLM 训练集群的测量发现：负载不均衡、序列长度不均衡、垃圾回收暂停，都可能制造掉队者。
核心思想很简单：
在同步并行中，波动会被同步成倍放大。
本文将从这个直觉出发，一路深入到具体机制、数学、经济学层面，以及工程师究竟能做些什么。
1. 先忘掉 LLM：餐厅问题
假设 8 位厨师并行准备 8 道菜。
7 位 10 分钟做完。
1 位用了 14 分钟。
如果所有菜必须同时装盘上桌，餐厅就得干等 4 分钟。
平均烹饪时间是：
(10 + 10 + 10 + 10 + 10 + 10 + 10 + 14) / 8 = 10.5 minutes
但这批菜的总耗时是：
max(10, 10, 10, 10, 10, 10, 10, 14) = 14 minutes
这个区别就是问题的全部。
对相互独立的工作而言，重要的是 worker 的平均速度。
对同步的批次来说，重要的是最慢 worker 的耗时。
LLM 的数据并行训练正是这种结构。
一个简化后的训练步大致如下：
GPU 0: forward -> backward -> \ GPU 1: forward -> backward -> \ GPU 2: forward -> backward -> --> all-reduce --> next step GPU 3: forward -> backward -> / ... GPU N: forward -> backward -> /
all-reduce 是一个同步屏障（synchronization barrier）。从概念上讲，必须等所有必需的参与者都到达同步点，下一次迭代才能继续。
所以每一步的耗时大致是：
T_step ~= max(T_0, T_1, ..., T_N) + T_sync
而不是：
average(T_0, T_1, ..., T_N) + T_sync
这就是为什么单个 worker 上 5% 的减速，对系统利用率造成的影响会远超 5%。
这一现象比现代 LLM 早出现了十多年。2010 年代初，包括 Jeff Dean 在内的 Google 工程师就研究过用数千台机器做大规模神经网络训练。他们的 DistBelief 系统既探索了异步训练，也探索了应对 worker 进度不均的机制。几年后，Jianmin Chen、Xinghao Pan、Rajat Monga、Samy Bengio 和 Rafal Jozefowicz 明确重新审视了同步 SGD，并证明可以在保留同步优化的同时，降低最慢 worker 带来的影响。
硬件变快并没有让这个问题消失。情况恰恰相反：作业规模大得多之后，同步反而变得更重要。
2. 为什么 LLM 训练会让问题更糟
关键的扩展方程简单得让人不好意思。
假设每个 worker 的耗时为：
T_i = 100 ms + noise_i
8 个 worker 时，最慢的那个偶尔也就跑到 110 ms。
而 4,096 个 worker 时，你就有 4,096 次"某个人变慢"的机会。
你不需要每个 worker 都变得不可靠，只需要一大组随机变量的最大值向上漂移就够了。
这正是让尾延迟成为分布式系统顽固难题的同一种统计现象。
纯粹当作一个玩具模型：假设每个 worker 在某一步有 1% 的概率耗时超过 120 ms。
100 个 worker 时：
P(at least one slow worker) = 1 - 0.99^100 ~= 63.4%
4,096 个 worker 时：
1 - 0.99^4096 ~= ~100%
所以在大规模下，问题不再是：
"单块 GPU 会不会偶尔出现慢步骤？"
答案是：会。
真正的问题是：
"有多少慢步骤行为会进入整个作业的关键路径？"
这就是为什么普通的分位数思维可能有误导性。
假设某个 worker 的步耗时分布为：
p50 = 100 ms p95 = 105 ms p99 = 110 ms
这些数字看起来非常出色。
但如果每个同步步骤都有数千个 worker 参与，作业就会反复采样到分布的极端尾部。
实际起决定作用的量更接近：
E[max(T_1, T_2, ..., T_N)]
随着 N 增大，期望最大值通常也会随之增大——哪怕每个 worker 自身的分布纹丝不动。
这就带来一个糟糕的扩展特性：
加更多 worker 能提升算力，同时也增大了对尾部事件的暴露。
这也是为什么"GPU 数翻倍，训练就该快一倍"这种想法，最终会被证明是对系统行为的糟糕建模。
3. 算力浪费的数学账
下面这个粗略的估算，能让问题变得具体可感。
假设：
N = 4096 GPUs normal step time = 100 ms straggler step time = 120 ms
在出现掉队者（straggler）的那一步里，快的 GPU 在 100 ms 就完成了计算，却要一直等到 120 ms。
每块快 GPU 的等待时间是：
20 ms
对全部 4,095 块快 GPU 来说：
4095 * 20 ms = 81.9 GPU-seconds
这就是单个 step 上被白白浪费掉的 GPU 时间总量。
任务实际只推进了 20 ms，集群却烧掉了将近 82 GPU 秒的等待。
换个角度看利用率。
忽略通信开销，快 GPU 进行有效计算的时间占比为：
100 / 120 = 83.3%
也就是说，大约有：
16.7%
的时间处于空闲。
现在再想象这种事经常发生。
如果一个任务在 4,096 块 GPU 上运行 10 天，总分配的 GPU 时间是：
4096 * 10 * 24 = 983,040 GPU-hours
如果掉队现象导致有效算力实际减少 10%：
~98,304 GPU-hours
就相当于凭空损失掉了。
按每 GPU 小时仅 2 美元的示意性基础设施成本计算：
98,304 * $2 = $196,608
按每 GPU 小时 5 美元计算：
= $491,520
这些并不是什么罕见的故障场景，只是大规模加速器空闲时间所对应的经济账。
此外还有二阶成本。
如果一次 10 天的训练拖成了 11 天，多出来的这一天可能会推迟：
evaluation checkpointing fine-tuning research iteration deployment the next experiment
对研究团队来说，这种机会成本可能比 GPU 账单本身更重要。
这也正是为什么掉队者问题有一部分属于运维和经济学的范畴，而不仅仅是分布式系统的问题。
4. 在真实的 LLM 系统里，“慢 GPU”往往不是 GPU 本身
这是近期一系列实测中最有价值的教训之一。
一个常见的心智模型是：
straggler = broken GPU
但它往往是错的。
2025 年，来自纽约大学（NYU）、字节跳动和浙江大学的研究人员在 OSDI 上发表了一项研究，分析了字节跳动某个集群五个月的生产环境 LLM 训练 trace 数据。他们检查了 3,079 个至少使用 128 块 GPU 的任务，其中包括动辄使用数千块 GPU 的任务。
他们的核心结论相当刺眼：
42.5% of jobs were at least 10% slower because of stragglers.
在最差的一端，有些任务浪费掉了高达 45% 的已分配资源。
更有意思的是他们排查根因时的发现。
单台服务器的硬件或软件故障并不是主要原因。
相反，几个看起来平平无奇的来源才是关键：
流水线不均衡
假设一条流水线有四个阶段：
stage 0: 8.0 ms stage 1: 8.1 ms stage 2: 11.0 ms stage 3: 8.0 ms
阶段 2 最慢。
其他阶段不可能永远按自己的理想速率跑下去，最终都得停下来等阶段 2。
因此，单个阶段 3 毫秒的不均衡，就可能传导并放大到一个大得多的系统里。
这一点对流水线并行（pipeline parallelism）尤其相关，因为在这种并行方式下，模型本身就是被切分到多块 GPU 上的。
序列长度不均衡
Transformer 的计算量高度依赖序列长度。
想象这样一组微批次（microbatch）：
worker A: 2,000 tokens worker B: 2,000 tokens worker C: 2,000 tokens worker D: 7,000 tokens
worker D 并不是“坏了”。
它只是拿到的工作更多而已。
但同步训练并不关心一个 worker 为什么慢——大家照样都得等。
这是一条重要的系统设计原则：
同步并行会把负载不均衡转化为全局空闲时间。
垃圾回收
在 LLM 的规模下，这一条听起来几乎有些荒谬。
成千上万块 GPU 摆在那里，每一块都在烧真金白银。
而 CPU 一侧的垃圾回收器只要把某个进程暂停得足够久，这个进程就会成为同步环节里最慢的那一个。
字节跳动的这项研究确实在观测到的掉队原因中，发现了由 GC 引起的停顿。
这很好地提醒了我们：加速器的性能并不完全由加速器本身决定。
关键路径可能穿过以下任何环节：
GPU kernels CPU runtime memory management network collectives scheduler behavior data loading pipeline scheduling
其中任何一环都可能成为掉队者。
5. 现代 LLM 训练的拓扑结构让延迟传播变得复杂
LLM 的训练很少"只用数据并行"。
现代大模型任务通常会组合多种并行方式：
data parallelism pipeline parallelism tensor parallelism possibly context / expert parallelism
这就构成了一个层级化的同步依赖结构。
一个有用的简化图景是：
DATA PARALLEL
+---------+---------+
| |
pipeline pipeline
group A group B
| | | | | |
TP TP TP TP TP TP
现在设想某个张量并行的 worker 变慢了。
它可能拖慢一个流水线阶段。
被拖慢的流水线阶段又会拖慢它所在的数据并行副本。
进而拖慢梯度同步。
于是一个局部 10 毫秒的延迟，就可能沿着执行图的多层结构一路传播。
Deepak Narayanan、Mohammad Shoeybi 及其同事在 2021 年的 Megatron-LM 工作中恰好描述了这个底层挑战：大模型训练需要组合张量并行、流水线并行和数据并行，同时尽量减少通信与同步引入的等待。
在这个规模上，同步并不只是一道 barrier。
而是一张由多道 barrier 组成的网络。
这个区别在调试时至关重要。
如果 trace 只是简单地告诉你：
step 18392 = slow
这远远不够。
你想知道的是：
which worker? which collective? which parallelism group? which microbatch? which pipeline stage? compute or communication? persistent or transient?
能否回答这些问题，正是“修复根因”与“重启任务了事”之间的区别。
6. 工程师实际如何对付掉队节点（straggler）
没有万能方案，因为每一种缓解手段都要拿别的东西来换。
A. 让负载更均衡
第一种解决方案也是最乏味的那种：
一开始就别制造不均衡的工作负载。
这意味着要把下面这些事情做得更好：
pipeline partitioning sequence-length bucketing microbatch construction GPU placement load balancing
例如，如果某个流水线阶段包含的层明显更“贵”（计算开销更大），在阶段之间挪动一些层，就能减少掉队现象中确定性的成分。
这往往好过专门发明一套复杂的运行时变通方案。
B. 使用备用 worker
有个经典思路说起来很简单。
假设系统中有：
N = 100 workers
但系统不必等满 100 个，而是在收到最快那批 worker 的足够结果后就继续推进。
例如：
wait for 94 ignore the six slowest
这 6 个被跳过的 worker 实际上就成了备用 worker。
吸引力显而易见：
synchronous semantics + less waiting for the slowest workers
代价也同样显而易见。
你现在要为那些结果可能根本用不上的 worker 付费。
而对现代 LLM 训练来说，这个取舍尤其难受：同步发生得很频繁，GPU 又极其昂贵。
Chen 等人在分布式同步 SGD 中研究过这个思路，并证明备用 worker 能够在保留基本同步优化行为的同时，显著降低掉队节点造成的损害。
C. 丢弃或延迟部分工作
更激进的方案是干脆不等慢的 worker。
这能提升系统吞吐量，但会改变优化算法。
你实际上等于在说：
the global model update does not need every worker's contribution
这会让训练走向异步或部分异步。
工程上的好处是机器更忙了。
算法上的坏处是，你的梯度更新不再和完全同步的 SGD 一致。
对某些负载来说，这笔交易划算。
对另一些负载，可复现性、收敛行为、优化器动态或模型质量会让它失去吸引力。
D. 把掉队节点检测当作一等运维信号
最糟糕的系统是这样的：运维人员看到的只有
GPU utilization: 68%
却完全不知道为什么。
一套有用的监控系统给出的信息应该更接近这样：
job utilization: 68% dominant cause: synchronization waiting largest straggler: global rank 1842 scope: TP group 12 PP stage 7 DP replica 31 excess step time: +17.4 ms persistence: 82% of recent steps probable cause: sequence-length imbalance
这样的信息在运维上可操作得多。
字节跳动的这项研究之所以值得关注，正是因为这一点：作者将 trace 分析工具内置到一个名为 SMon 的监控系统中，并把其中一部分部署到了训练集群的 on-call 值班流程里。
这条经验的意义不止于 LLM：
分布式系统需要在同步依赖层面具备可观测性，而不只是停留在单机层面。
7. 更深层的启示：同步式的大规模改变了“快”的含义
工程师在思考性能时往往是局部的：
GPU A is 10% faster. network B has 20% more bandwidth. kernel C is 5% faster.
但同步式分布式训练是一个全局系统。
真正相关的性能量不是：
average worker throughput
而更接近于：
throughput ~ 1 / E[max(worker_time)]
并且通信和调度的影响会叠加在其上。
这带来一个让人不太舒服的推论。
在小规模下，优化往往意味着让平均情况更快。
在超大规模下，优化越来越意味着控制尾部。
这正是大型分布式服务领域曾经历过的同一种观念转变：一旦一个请求扇出到足够多的机器上，罕见的一次慢事件在系统层面就不再罕见。
LLM 训练本质上是在数值计算上重演同样的事情。
由此可以得出一条实用的设计准则：
当一项计算需要反复同步成千上万个 worker 时，方差就成了一种必须靠工程手段消除的性能要素。
并不是因为方差在道理上有多坏，而是因为同步屏障会把它直接转化为加速器的空转时间。
对 LLM 基础设施工程师来说，这提示了一个实用的优先级顺序：
1. Balance the work. 2. Identify where synchronization is actually waiting. 3. Separate compute stragglers from communication stragglers. 4. Determine whether the cause is persistent or transient. 5. Only then choose between rebalancing, backup workers, scheduling changes, or relaxing synchronization.
而最重要的经济学教训也许是这样的：
当关键路径由一小部分 worker 决定时，一个 4096 卡的 GPU 集群并不能真正给你“4096 张 GPU 的算力”。
你是按整个集群付的钱。
你的吞吐量却由尾部决定。
这就是 straggler（掉队者）问题。
你在分布式系统里遇到过的最离奇的 straggler 是什么，一台状态不佳的机器、网络问题、数据倾斜、垃圾回收，还是某个平凡得多的原因？
原文：https://dev.to/shrsv/the-straggler-problem-why-one-slow-gpu-can-stall-an-llm-training-run-1cio（作者 @shrsv）
