训练平台选择并行策略时，经常先比较显存是否装得下、单步吞吐和通信带宽，却把故障恢复留到上线后处理。实际上，张量并行把一次算子拆到多个 GPU，流水并行把模型层分成阶段，数据并行复制模型并处理不同样本。三者形成的同步关系不同，一个 GPU、进程、节点或链路故障时，受影响的工作组和恢复状态也不同。放置策略若只追求最短通信距离，可能把同一恢复单元全部集中在一个电力或交换故障域。
张量并行的故障边界最紧密
张量并行组内成员通常频繁参与集合通信，任何一个成员退出都可能使整个组停止。为了性能，成员往往优先放在高带宽节点内互连范围；但当模型必须跨节点扩展时，网络与成员健康就进入每一步关键路径。平台应明确组大小、拓扑约束和替补资源。故障后通常不能只在空闲 GPU 上补一个进程继续，通信器、模型分片和运行状态都可能需要组级重建。
流水并行会把恢复与状态边界拉长
流水阶段之间传递激活与梯度，负载不均会形成气泡。某一阶段故障时，其他阶段即使硬件正常也无法独立完成当前批次。放置时既要考虑相邻阶段的通信，又要防止关键阶段全部依赖同一 ToR、同一机柜电源或同一主机。若不同阶段计算量差异较大，简单按 GPU 数均分可能导致长期等待。恢复方案要知道各阶段模型状态、优化器状态和微批进度如何重新一致。
数据并行更容易扩展但不是完全独立
数据并行副本处理不同数据，却需要同步参数或梯度。一个副本退出是否允许弹性缩容，取决于框架、数据分片、优化算法和通信设置。即使能够重建通信组，批量大小、学习率和数据顺序也可能变化。平台不能把“作业自动重启”当成无损恢复，应验证检查点之后的数据是否重复或跳过、全局步数是否一致，以及新规模下训练语义是否仍被接受。
组合并行要定义最小恢复单元
大模型通常组合多种并行方式。此时调度器需要理解哪些进程构成张量组、哪些属于流水阶段、哪些是数据副本，并把这些关系写入拓扑约束。最小恢复单元可能不是节点，也不是整个作业，而是一个并行组或一个副本集合。没有这张映射，故障时只能全作业重启，浪费大量恢复时间；过度追求局部恢复，又可能留下通信器或优化器不一致。
从 RPO 与 RTO 反推架构
团队应先定义可接受的训练进度损失和恢复时间，再决定检查点频率、保存位置、空闲容量和放置分散度。检查点过于频繁会持续占用存储与网络，过于稀疏则放大节点故障损失。若恢复要求严格，需要验证模型、优化器、随机数、数据加载器和并行元数据能否完整恢复。故障域设计还要覆盖控制平面、存储和网络，不能只给 GPU 节点贴可用区标签。
必须做的演练
- 记录每个 rank 所属的张量组、流水阶段、数据副本、节点、机柜和网络路径。
- 分别终止单进程、单 GPU、单节点和一组网络连接，观察最小实际重启范围。
- 从检查点恢复并核对步数、数据顺序、损失曲线和最终模型状态。
- 在资源不足以原规模重启时，验证缩容是否被框架支持以及训练语义是否改变。
- 统计故障发现、资源重分配、制品读取、通信组重建和重新计算各阶段耗时。
并行策略与故障域没有脱离版本和框架的通用最优解。NCCL 集合通信、通信器和错误处理等基础语义可查阅 NVIDIA NCCL User Guide，上层训练框架的弹性与检查点能力还需分别核对。最终放置规则应同时说明性能意图与恢复意图，不能只保留一张理想拓扑图。
WeChat
Profile