一、引言
上一篇文章中介绍了字节的大规模 LLM 训练管理系统 ByteRobust，并借机回顾了笔者之前介绍过的大规模 AI 集群中的常见问题和运维实践。本文进一步分享 Meta 的 FT-HSDP，它与 ByteRobust 有不同的应用场景，主要针对 10 万 GPU 的超大规模场景，与 1 万 GPU 的挑战有所不同。
对应的论文为：[2602.00277] Training LLMs with Fault Tolerant HSDP on 100,000 GPUs [1]
相关工作可以参考笔者之前的文章：
二、摘要
大规模 LLM 训练通常采用同步训练模式，要求所有 GPU 同时处于健康状态。根据作者在 100K GPU 集群的训练经验，同步训练会因为频繁的故障和较长的恢复时间导致训练效率低下。比如 100K GPU 规模，每 18 分钟就会出现一次故障，而恢复时间长达 10 分钟，导致有效训练时间只有 8/18=44% 左右。
为了应对这一挑战，作者提出 FT-HSDP（Fault Tolerant Hybrid-Shared Data Parallelism），该方法以数据并行（DP）副本作为容错单元：当故障发生时，仅将包含故障 GPU 或服务器的单个 DP 副本离线重启，其余副本可持续进行训练。
FT-HSDP 融合了多项关键技术（PS：非数学等价）：
设计了跨 DP 副本的容错 AllReduce（FTAR）梯度交换协议，通过 CPU 驱动动态增减副本的复杂控制逻辑，同时利用 GPU 执行数据传输以获得最优性能。
提出了非阻塞追赶协议，使恢复中的副本能以最小延迟重新加入训练流程。
与 O(100K) GPU 规模的完全同步训练相比，FT-HSDP 能将故障恢复导致的停滞时间从 10 分钟降低到 3 分钟，有效训练时间从 44% 提升到 80%。
三、背景
3.1 硬件稳定性
对于一个 32K GPU 的预训练任务，可以获得 95%-97% 的有效训练时间，平均来说，每天每 1000 台服务器会出现 2.3 次中断。如下图 Table 1 所示为所有的训练中断，其中 78% 是硬件相关的中断：
“Faulty GPU Compute” 原来是占比最高的故障，得益于通过技术手段隔离了大量故障 GPU，该比例大幅下降到只占 7.4%。
“HBM3 Memory” 的问题最多，达到 22.9%。
PCIe Device 的问题也很多，可能也和从 A100 的 PCIe Gen4 升级到 H100 的 PCIe Gen5 后的稳定性下降有关。
3.2 100K GPU 的挑战
如下图 Figure 2 所示（其中 cold-N 表示整个任务终止，warm-N 标准只终止故障有关联的设备），当 GPU 规模从 16K 增加到 98K 时会面临几大挑战：
Allocation：GPU 分配时间超长，warm-N 方案只替换异常相关设备的分配需要 20-40s；而全部重新分配的时间高达 3-5min。
NCCL：NCCL 初始化时间也会随着 GPU 数量的增加大幅提升（字节的 [2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs [2] 也也提到类似问题），16K GPU 的 NCCL 初始化时间 17s 左右，而 98K GPU 的 NCCL 初始化时间高达 200s。
FirstStep：训练的第一个 Step 由于需要进行一些额外的工作，比如初始化 DataLoader，分配内存、JIT 编译等，往往会需要更长的时间，比如正常的 Step 只需要 20s 左右，而这里 FirstStep 高达 2-4min。
Loading：除此之外，还有一些 Checkpoint 加载，健康检查等一系列开销。
3.3 集群 & 网络
超过 100K GPU 的训练集群会分布在多个 DC Building 中，为此，Meta 设计了多 Building 网络架构，将多个相邻的 DC Building 连接到一个统一的 RoCE Fabric（Meta 在 [2510.20171] Collective Communication for 100k+ GPUs [3] 中也介绍过该集群网络架构）。
如下图（a）所示，每一个 Building 里都是 3 层 Clos 架构。
RTSW（Rack Training Switch）连接一个 Rack 内的 GPU；
CTSW（Cluster Training Switch）实现一个 AI Zone 内所有 RTSW 的 Full-mesh 全互联；
ATSW（Aggregator Training Switch）将一个 Building 内的多个 AI Zone 连接起来，跨 AI Zone 的带宽收敛比为 1:2.8。
如下图（b）所示，各个 Building 之间的 ATSW 同样 Full-mesh 全互联，以实现多个 DC Building 的互联，这里跨 DC Building 的带宽收敛比同样是 1:2.8。
相应的通信时延也有较大区别，同一个 Rack 内 GPU 通信时延最低。同一个 AI Zone 不同 Rack、同一个 DC Building 不同 AI Zone、不同 DC Building 的通信时延分别达到其 7x、15x、30x。
Meta 在 [2407.21783] The Llama 3 Herd of Models [4] 中也提到过 LLaMA 3 训练的网络架构。如下图所示，其部分采用 Arista 7800 系列 Switch（PS：参考 Arista 7800R3 Series [5]，有多个版本，分别可以提供 576/432/288/144 个 400 Gbps Port，图中以 288 Port 版本为例）。但是其跨 AI Zone 的收敛比是 1:7，而在新的方案中进一步增加了跨 AI Zone 的带宽，收敛比为 1:2.8。跨 DC Build 也同样保持 1:2.8。
四、相关工作
4.1 Amazon HSDP
HSDP（Hybrid sharded data parallelism - Amazon SageMaker AI [6]） 是对 FSDP 的扩展。简单来说，HSDP 相当于将 FSDP 作为一个 DP 副本，在此基础上进一步扩展 DP 组，当然也会额外引入一些通信操作。具体来说：
FSDP
全集群只有 1 个逻辑副本，模型参数、梯度、优化器状态全部均匀分片到所有 GPU 上。
每张 GPU 只存 model_size / world_size 的状态 → 内存最低。
所有通信（AllGather 参数、ReduceScatter 梯度）都要跨全集群，通信规模随节点数线性增长，容易成为瓶颈。
HSDP
将所有 GPU 分成 R = word_size / K 个独立的分片组，每组包含 K 个 GPU。
每组相当于一个小型的 FSDP：
这个组里有完整的模型副本，模型参数、梯度、优化器状态均匀分布在组内的 K 个 GPU 上。
整个任务有 R 个完整的模型副本。
每个 GPU 的内存占用比 FSDP 更大，大了 R 倍，为 model_size / K。
除了组内的 ReduceScatter 梯度聚合外，还要进行组间（多个副本）的梯度 AllReduce，然后独立进行优化器状态和参数的更新。
4.2 NVIDIA Nonuniform-Tensor-Parallelism
其实 NVIDIA 在 [2504.06095] Nonuniform-Tensor-Parallelism: Mitigating GPU failure impact for Scaled-up LLM Training [7] 中也提出了一种缓解大规模训练中 GPU 故障导致训练效率低下的工作。简单来说，其包含 2 个关键技术：非均匀 TP（Nonuniform-TP，NTP）和具备增强供电与散热能力的机架方案。
非均匀 TP：在标准的 TP 中，Tensor 被均匀的切分到 TP 组中的 GPU 里，相应的存储、计算量一致。当某个 GPU 故障时，将故障 GPU 对应 Tensor 切片以及计算负载均匀切分到 TP 组内健康的 GPU。比如 TP 64，当某个 GPU 故障时，其他 63 个 GPU 重新构成一个 TP 组。
然而，NTP 也会带来额外的挑战：
一方面 DP 组之间的 TP 组大小不同，梯度 AllReduce 会更加复杂，为此，作者也对通信进行了相应的优化，以适配这种场景。
另一方面，由于遭遇 GPU 故障的 DP 副本会以降低后的 TP 维度继续执行，其贡献的吞吐量与剩余正常 GPU 的比例相匹配，相应的 TP 组就会成为 Straggler。
具备增强供电与散热能力的机架方案：为缓解 Straggler 导致的性能下降，作者提出了一种创新的机架电源动态分配方案。该设计允许将故障 GPU 的功率预算重新调配给同机架内正常工作的 GPU，使其在不降低 Local Batch 规模的前提下维持全吞吐量运行。这种机架设计可为剩余工作 GPU 提供最高 TDP 30% 的额外功率，通过提升运行频率实现单 GPU 性能增益。实验表明，该方案无需依赖机架备用 GPU 即可近乎完全消除因 GPU 故障导致的性能损失。
PS：当然，如果是非单一 GPU 的故障，或者 Scale-Up 域较小，此方案也有一定的局限性。
五、FT-HSDP 方案
5.1 概览
FT-HSDP 会创建多个训练副本，每个副本处理不同的数据子集。副本内的每个 GPU 根据其在副本中的位置分配唯一 Rank。在训练完一个 Step 后，不同副本中相同 Rank 的 GPU通过AllReduce 同步梯度。副本内部通信限制在同一 DC Building 内，而梯度交换则跨 DC 进行。
FT-HSDP 的两大容错优势：
单个 GPU 故障只需重建包含该 GPU 的单个副本，恢复规模大幅缩小，恢复时间显著缩短。（PS：副本太多 GPU 内存压力会比较大，副本太少则恢复规模太大，作者实践是 98K GPU 中使用 12 个副本，每个副本 8192 GPU）
故障副本恢复期间，其他健康副本可以继续正常训练（仅整体吞吐量略降），避免整个系统停顿。
整个流程如下图 Figure 4 所示，Rank 0（副本 Leader）：
包含多个 intra-replica 流（Forward/Backward计算与副本内的通信）。
1个 inter-replica 流（执行 FTAR 梯度交换）。
main-tread 执行优化器步骤（OPT）更新模型权重。
FT-HSDP 将 FTAR 与 Backward 计算Overlap，提升训练速度。
Rank 0 额外承担控制逻辑：通过共识服务协调各副本的 Rank 0，确定健康副本；同时查询本副本其他 Rank 是否完成梯度交换，决定是否执行优化器步骤。
5.2 FTAR
跨 DC 梯度交换无法直接使用 NCCL（不支持动态组重建、复杂错误处理、网络感知等）。FT-HSDP 引入自定义 FTAR 协议，满足四大目标：
网络感知架构（跨 DC 带宽受限，需拥塞控制）。
可重建通信组（故障后健康 Rank 可清理旧连接、重建新组）。
易故障管理（区分可恢复/不可恢复错误）。
最小资源争用（与 Backward 计算 Overlap）。
为此，作者设计了 FTAR 协议，如下图 Figure 5 所示，其采用 CPU + GPU 混合设计：
CPU（控制平面）：初始化 RDMA 连接、运行 reconfig 函数决定参与 Rank、处理拥塞控制、错误分类与重试等。
GPU（数据平面）：拷贝数据到 send buffer、通知 CPU、执行 RDMA 发送/接收、reduce 操作等。
除此之外，还对 Ring 算法、Kernel 等进行了优化，这里不再赘述。
5.3 异常后的一致性保障
FT-HSDP 使用了类似两阶段提交（Two-Phase Commit，2PC）的协议来作为更新权重前的屏障，以确保故障后的一致性。具体来说，在执行 Optimizer Step（更新模型权重）之前，副本的 Leader（Rank 0）会向副本内的所有 GPU 确认是否所有的梯度交换都已经完成。
只有当副本内所有 GPU 都回答 “Yes” 时，才会统一执行权重更新。
如果有人回答 “No”，也就是副本中存在故障，Rank 0 就会命令副本内的所有 GPU 重试这一步。此时该异常副本还没有更新模型权重，可以直接重新执行该副本的 Forward、Backward 以及梯度 ReduceScatter（PS：由于梯度聚合是分桶进行，并且与 Backward Overlap，因此部分梯度可能已经释放，因此需要从 Forward 重新开始）。
需要注意的是，由于健康副本会进行权重更新，而异常副本会回退，就导致了不同副本之间 Step 可能存在不一致（比如，副本 1/2 在训练 Step 100，而副本 3 在训练 Step 99），这是 FT-HSDP 允许的，也是能够实现容错的关键。
作者也通过实验证明这种不一致（与同步训练非数学等价）并不会影响模型效果：
5.4 非阻塞追赶协议
发生故障时，可能副本 1 成功完成了梯度交换（2PC 成功，更新了权重进入下一 Step），而副本 2 因为故障导致 2PC 失败（丢弃了梯度，停留在当前 Step）。FT-HSDP 允许这种跨副本的进度差异，Replica 2 随后会通过非阻塞追赶协议（Non-blocking Catch Up）重新与大部队同步。如下图 Figure 6 所示：
每步开始，各副本通过共识服务上报“下一 Step 编号”。
Step 最高的副本（健康）正常训练当前 Step n。
落后副本从健康副本 fetch Step n-1 的 Checkpoint。
FTAR 阶段：健康副本发送真实梯度，落后副本发送零梯度。
FTAR 自动使所有副本状态一致，下一步共同训练 Step n+1。
为了保证 fetch Checkpoint 的时间小于一个 Step 的训练时间，还实现了高效的 Checkpoint Fetching 方案，如下图 Figure 7 所示：
5.5 实现
在实现中也有一些额外的 Tips 需要注意：
不允许跳过数据，也不允许重复训练同一个 Batch，这就需要记录好 DataLoader 的状态，就是一些 index 和偏移值，非常小。当然，如果某个副本频繁故障，可能导致数据的极端不均衡，此时需要进行数据 Batch 的重洗，不过这个概率极低。
副本大小需要权衡，太小无法有效节约资源，太大的话 GPU 显存压力又会很大，为了缓解 GPU 显存压力，增加了优化器状态 offload 到 CPU 内存的机制，拉取 1GB 数据只需要 60ms，几乎不影响训练进度。
恢复后的第一个训练 Step 很慢，为此将很多过程提前，以大幅降低 FirstStep 时间。
真实的 100K GPU 测试成本极高，无法频繁跑。为此，创建了仿真工具，透明替换 GPU 模块为 CPU mock 版本，计算部分直接跳过，通信部分用 CPU 基础通信库替换。可以保障在 100K GPU 之前就完成大规模验证。
六、参考链接
https://arxiv.org/abs/2602.00277
https://arxiv.org/abs/2402.15627
https://arxiv.org/abs/2510.20171
https://arxiv.org/abs/2407.21783
https://www.arista.com/en/products/7800r3-series/specifications
https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-core-features-v2-sharded-data-parallelism.html
https://arxiv.org/abs/2504.06095