第 8 课：故障恢复、Checkpoint 间隔与多租户事故设计

本课目标与完成标准

本课产出：计算 Young 近似 checkpoint 间隔，并给出检测、隔离、恢复、复盘的端到端事故方案。

通过要求：唯一代码填空题通过给定检查；Q1～Q3 都给出因果链；能指出一个正确性边界和一个性能/运营取舍；总分至少 8/10。

与既有六条主线的边界

rl/lesson12 和 train/ 提到 checkpoint；本课从平台 MTBF、恢复风暴、租户隔离和运营成本收束全套课程。

前置：Linux/网络基础、runtime 补充线、train 分布式章节。本课只补 AI Infra 缺口，不重复已经完成的 kernel 或并行算法推导。

核心心智模型

1. 它是什么，解决什么问题

在万卡（10,000+ GPUs）乃至更大规模的现代超算基础设施中，“硬件单点故障是系统运行的常态，而非罕见例外”。

这一残酷的工程现实由基础可靠性统计规律所决定：

• 单台 GPU 服务器（包含 8 张加速卡、高频 CPU、海量 DDR5/HBM 内存、NVSwitch 芯片、多张 400Gb RDMA 网卡及高速光模块）的平均无故障时间（MTBF）虽然可以长达数千小时；
• 但在包含数千台物理机的万卡集群中，由于紧耦合分布式训练的可靠性服从独立事件概率串联模型： $$\text{MTBF}_{\text{cluster}} = \frac{\text{MTBF}_{\text{node}}}{N_{\text{nodes}}}$$ 万卡集群约有 1,250 台 8 卡节点，若单节点 MTBF 为 5,000 小时，则 $\text{MTBF}_{\text{cluster}} \approx 5000 / 1250 = 4$ 小时，即集群 MTBF 通常只有数小时。这意味着每隔几个小时，集群中就必然有某张 GPU 发生 Xid 掉盘、ECC 双位错误、或者由于光模块功率衰减导致网络断联。

在全互联集合通信中，任何单卡的物理崩溃都会导致全集群同步屏障锁死。若依赖人工排查故障、重启机器并重新排队提交，昂贵的算力集群将永远处于排障等待中。
本课通过解析经典 Young / Daly 最优检查点保存周期模型（如图 8-1 所示），并设计涵盖“秒级心跳探测 $\rightarrow$ 污染节点自动隔离 $\rightarrow$ 温备节点动态替换 $\rightarrow$ 分布式检查点原子恢复”的无人值守全自动故障自愈流水线（如图 8-2 所示），在理论数学与生产工程两个维度收束整个 AI 基础设施的可靠性设计。

2. 它如何工作

(1) Young / Daly 最优检查点保存周期推导（如图 8-1 所示）

在分布式系统中，决定多久保存一次 Checkpoint 是一个精密的权衡问题： 设单次保存 Checkpoint 的耗时为 $C$（秒），集群平均无故障运行时间为 $M$（MTBF，秒），设定的存盘周期间隔为 $T$（秒）。
在一个运行周期内，系统承受两个维度的算力损耗（如图 8-1 曲线所示）：

1. 正常存盘的时间开销比例：周期间隔越短，存盘越频繁，开销占比越大： $$W_{\text{dump}} = \frac{C}{T}$$

2. 发生故障后丢失的工作量比例：在泊松故障到达分布下，单次故障平均发生在周期的正中间，平均丢失的工作量为半个周期 $\frac{T}{2}$。分摊到整个 MTBF 周期上的浪费比例为： $$W_{\text{lost}} = \frac{T / 2}{M} = \frac{T}{2M}$$

系统的总算力浪费比例为两者之和： $$W(T) = \frac{C}{T} + \frac{T}{2M}$$

为了最小化总浪费比例，对 $T$ 求一阶导数并令其为 0： $$\frac{dW}{dT} = -\frac{C}{T^2} + \frac{1}{2M} = 0 \implies T^2 = 2CM \implies T^* = \sqrt{2 C M}$$

这即为著名的高性能计算 Young 近似公式（Young’s Formula）。在最优周期 $T^*$ 下，正常存盘的开销与故障丢失的工作量恰好完全平衡： $$W(T^*) = \frac{C}{\sqrt{2CM}} + \frac{\sqrt{2CM}}{2M} = \sqrt{\frac{C}{2M}} + \sqrt{\frac{C}{2M}} = \sqrt{\frac{2C}{M}}$$

更精细的 Daly 模型（2006） 在 $C < 2M$ 时给出一阶修正： $$T_{\text{Daly}} \approx \sqrt{2CM}\left[1 + \frac{1}{3}\sqrt{\frac{C}{2M}} + \frac{1}{9}\cdot\frac{C}{2M}\right] - C$$ 从检查点重启恢复的固定开销 $R$ 会增加总浪费（每次故障额外损失 $R$），但不改变最优间隔。当 $C \ll M$ 时 $T_{\text{Daly}} \approx \sqrt{2CM}$，退化为 Young 公式。

(2) 自动化故障自愈五级流水线（如图 8-2 所示）

某计算节点发生 Xid 崩溃或通信断联

控制面探测器毫秒级发现心跳丢失

自动隔离污染坏节点 (Cordon & Taint)

从温备池动态调拨同规格健康节点加入拓扑

从最近持久化 Checkpoint 载入权重并重建 NCCL 通信环

作业恢复正常训练，全过程自动化自愈无需人工干预

图 8-2：万卡分布式集群节点崩溃自动隔离、温备替换与自愈恢复全流程

如图 8-2 所示，生产级平台在物理节点发生故障时执行全自动闭环自愈：

1. 第 1 级：毫秒级多维心跳探测（Fault Detection）：宿主机轻量级健康探测器结合带外 BMC 硬件监控与通信栈心跳，在毫秒级内捕获内核 Xid 硬件异常或网络静默断联；

2. 第 2 级：物理节点即时污染与隔离（Cordon & Taint）：调度控制面自动将故障物理机标记为 Cordon 并打上 NoExecute 污点，终止并清空该节点，防止其再次被调度器选中；

3. 第 3 级：温备节点拓扑对齐替换（Warm Standby Swap）：从集群预留的小比例（如 2%）健康温备节点池中动态挑选一台具有相同物理拓扑规格与 Rail 对齐的健康机器加入作业拓扑；

4. 第 4 级：分布式检查点原子加载（Parallel Restore）：新节点与存活节点通过分布式检查点机制（PyTorch Distributed Checkpoint）直接从中央分布式文件系统或本地 NVMe 异步并发拉取各自的权重切片；

5. 第 5 级：NCCL 通信环重建与断点续训：调用 ncclCommInitRank 重新完成 Rendezvous 握手，恢复数据迭代游标（DataLoader Cursor）与随机数生成器状态（RNG State），从上一个存档点精准恢复无缝续训。

3. 正确性条件与常见误区

• 误区一：磁盘上存在 Checkpoint 目录即代表具备真实恢复能力
  磁盘上存在文件绝不等于能够成功恢复。在工程实践中，由于断电导致的非完整分片、缺少主节点写入的 manifest.json 元数据清单、数据版本与代码不兼容、甚至多卡随机数生成器状态（RNG State）未对齐，都会导致恢复时抛出不可预知的异常。必须确立“无验证不声明”规范，定期在沙箱环境中自动化运行灾难恢复演练（Disaster Recovery Drill）。

• 误区二：大规模宕机后允许所有作业无退避并发自动重启
  当机房经历一次电力闪断或核心交换机抖动后，若成百上千个作业在同一瞬间同时拉起，数万个 Worker 会并发向存储发起海量读取请求，引发严重的惊群风暴（Thundering Herd），冲垮存储网关与镜像仓库，导致全集群在持续的超时报错中反复震荡。系统必须实现指数退避与抖动重试（Exponential Backoff with Jitter），并按作业优先级分批阶梯式恢复。

• 误区三：单租户的故障处理扩散至全集群（Blast Radius Overrun）
  在多租户算力平台中，若未设置严格的网络与权限隔离边界，某租户因算子崩溃频繁向集群 API Server 倾泻错误事件，或者触发了底层的网络 PFC 死锁，会导致其他租户的正常作业被连锁拖死。必须建立机架级网络隔离、Kubelet 速率限制与硬件配额强围栏。

4. 性能与工程取舍

• 存档频度与硬件损耗/训练效率的博弈：
  存档越频繁，故障时丢失的工作量越少，但写入的写放大不仅消耗昂贵的网络与存储带宽，更会急剧加速物理 NVMe SSD 的闪存擦写寿命损耗（TBW 消耗）。因此，基于 Young 近似公式计算的数学最优周期是工程效率与硬件寿命的最佳平衡点。

• 温备节点池（Warm Standby Pool）的比例权衡：
  预留 2% 的温备节点池能够将故障恢复时间从“小时级”压缩至“分钟级”，提升的是有效训练时间占比（goodput / ETTR），MFU（单位时间内的算力利用率）本身不受影响；代价是这 2% 的 GPU 大部分时间不服务主力作业。通常的做法是：在温备节点上运行可随时抢占的离线低优先级作业（如模型评测或数据清洗），实现温备池的双重利用。

具体演示

以一个超大规模训练任务为例：

• 单次全量 Checkpoint 转储时间为 $C = 300\text{ 秒}$（5 分钟）；
• 假设集群平均无故障时间为 $\text{MTBF} = 7\text{ 天} = 7 \times 24 \times 3600 = 604,800\text{ 秒}$（这是偏乐观的设定，对应较小规模或可靠性很高的硬件；万卡规模的情形见下文 3 小时的对比）。

代入 Young 最优周期公式： $$T^* = \sqrt{2 \times 300 \times 604,800} = \sqrt{362,880,000} \approx 19,049.4\text{ 秒 (约 5.29 小时)}$$

代入算力浪费比例公式： $$W(T^*) = \frac{300}{19049.4} + \frac{19049.4}{2 \times 604,800} \approx 0.01575 + 0.01575 = 0.0315 \quad (3.15\%)$$

计算结果表明：在该假设下，每隔约 5.3 小时保存一次检查点最优，存盘与故障重算导致的平均算力损耗约为 3.15%。

对比万卡规模更常见的 $\text{MTBF} = 3\text{ 小时} = 10,800\text{ 秒}$，同样 $C = 300\text{ 秒}$： $$T^* = \sqrt{2 \times 300 \times 10,800} = \sqrt{6,480,000} \approx 2,546\text{ 秒 (约 42 分钟)}$$ $$W(T^*) = \frac{300}{2546} + \frac{2546}{2 \times 10,800} \approx 0.118 + 0.118 = 0.236 \quad (23.6\%)$$

此时 $C/M$ 不再很小，Daly 修正给出 $T_{\text{Daly}} \approx 2,350\text{ 秒}$（约 39 分钟），一阶模型本身的误差也变大。损耗升到约 24%，说明 MTBF 只有数小时时，应优先缩短 $C$（异步 checkpoint、内存快照）并提高 MTBF，而不是只调间隔。

请先独立复述“输入 → 状态变化 → 输出/指标”，再开始填空。

实践任务：唯一代码填空题

补齐 Young 近似 checkpoint 间隔并计算单位时间浪费比例近似。

只能修改 TODO/______ 位置，不得删除断言或放宽通过条件。

import math

def checkpoint_policy(checkpoint_s, mtbf_s):
    if checkpoint_s <= 0 or mtbf_s <= 0:
        raise ValueError("times must be positive")
    interval = math.sqrt(2 * checkpoint_s * mtbf_s)
    # TODO：平均浪费为 checkpoint 开销 C/T + 故障丢失工作 T/(2M)。
    waste_fraction = ______
    return interval, waste_fraction

interval, waste = checkpoint_policy(300, 7*24*3600)
assert 19000 < interval < 19100
assert 0 < waste < 0.1

检查方法

运行本单元格，所有断言必须通过；再补一个边界输入并解释预期。

Q1

为什么 checkpoint 文件存在不等于恢复能力已验证？

你的答案：

Q2

大规模故障后所有作业同时重启会造成什么二次事故？

你的答案：

Q3

多租户平台的最小 blast-radius 控制有哪些？

你的答案：

评分规则

• 代码 4 分：正常输入 2 分、边界输入 1 分、解释 1 分；
• Q1～Q3 各 2 分；
• 一票否决：混淆测量与推测、忽略租户/请求隔离、用平均值掩盖尾延迟、删除失败路径。

Tip💡 点击展开参考答案与详细代码实现

参考答案（仅 answer 分支）

先独立完成。核对后请改变一个规模或故障条件重新推演。

import math

def checkpoint_policy(checkpoint_s, mtbf_s):
    if checkpoint_s <= 0 or mtbf_s <= 0:
        raise ValueError("times must be positive")
    interval = math.sqrt(2 * checkpoint_s * mtbf_s)
    waste_fraction = checkpoint_s / interval + interval / (2 * mtbf_s)
    return interval, waste_fraction

interval, waste = checkpoint_policy(300, 7*24*3600)
assert 19000 < interval < 19100
assert 0 < waste < 0.1

Q1 参考答案

在分布式与大模型系统工程中，物理磁盘上“存在 Checkpoint 目录或文件”绝不等于“具备端到端恢复能力”，二者之间存在巨大的逻辑鸿沟：

1. 物理文件完整性缺失（Truncated / Non-Atomic Writes）：分布式 Checkpoint 通常由数十甚至数百个并行文件切片组成。若在保存的尾声发生节点脱网、内存不足或存储满载，部分分片可能仅写入了部分字节；若缺少主节点原子写入的 manifest.json 元数据清单与全局校验和（Checksum），反序列化解析将直接报错崩溃；

2. 运行时状态机与环境拓扑不一致（State Machine Inconsistency）：一个可恢复的训练状态不仅包含权重张量，还必须包含优化器的一阶/二阶矩、学习率调度器状态、数据加载器的数据游标（DataLoader Cursor）以及全局随机数生成器状态（RNG State）。若恢复时的环境世界大小（World Size）或并行策略发生了改变，未经弹性重切片（Resharding）的权重将直接因张量形状不匹配而无法加载；

3. 真实规模下的不可预测性（Scale Invariance Deficit）：在单卡或小集群上能通过 torch.load 测试，并不意味着在千卡集群上并发加载时 NCCL 集合通信环路能在预设超时内完成重建。必须定期在隔离集群上执行全自动化灾难恢复演练（Restore Drill），验证从拉取数据到完成第 1 个完整训练迭代的确定性闭环。

Q2 参考答案

大规模故障（如电力闪断、骨干网闪断）后所有作业同时重启，会引发惊群（Thundering Herd）二次事故：

1. 存储读过载：大量作业同时读取 TB 级 Checkpoint，MDS 与存储网关被打满，读超时导致作业加载失败并再次重试；
2. 镜像仓库被打满：大量 Pod 同时拉取几十 GB 镜像，出口带宽和磁盘 IO 耗尽，Pod 卡在 ImagePullBackOff；
3. 控制面过载：API Server、etcd 与 Rendezvous 服务（TCPStore 等）同时承受注册与心跳，连接数耗尽。

防护：按优先级分批拉起（Staggered Ramp-up），客户端使用带随机抖动的指数退避（Exponential Backoff with Jitter）。

Q3 参考答案

在企业级多租户算力平台中，为了防止单个租户或任务的异常扩散破坏全集群，必须构筑以下纵深防御的最小爆炸半径（Blast-Radius Control）防护网：

1. 硬件与故障域物理强隔离（Hardware & Failure Domain Partitioning）：
   在集群层面按机架、供电单元或交换机网络划分节点池（Node Pools）。不同敏感度等级的租户调度在相互隔离的物理节点组上，确保单机柜硬件故障或网络断联绝对不会波及其他机柜的租户；

2. 多租户网络与无损网络流控隔离（Network QoS & PFC Isolation）：
   在数据中心交换机与网卡层面，为不同租户分配独立的 VLAN 与以太网优先级流量类别（Traffic Class / DSCP）。严格防范某租户因算子或网络编写不当诱发的巨型 Incast 报文风暴霸占整个机房缓冲区，杜绝跨租户扩散的 PFC 死锁；

3. 节点级资源配额硬围栏（Cgroups & Device Enclosures）：
   通过 Linux Cgroups v2 与 Kubernetes 资源限制，对容器的 Host 内存、CPU 核心数、文件描述符与磁盘 IOPS 施加不可逾越的硬性配额（Limits）。防止单租户的 Host 内存溢出诱发内核 OOM Killer 误杀邻近节点上的其他关键系统守护进程；

4. 控制面速率限制与租户熔断断路器（Rate Limiting & Circuit Breaking）：
   对每个租户向集群 API Server 提交的请求频率设立基于令牌桶的限流器。一旦某租户的自动化训练脚本陷入无限重试并高频狂轰 API Server，控制面断路器立即将该租户的任务提交熔断挂起，坚决捍卫集群全局控制中枢的稳定。

参考资料

• Google SRE Book
• PyTorch Distributed Checkpoint
• Google SRE Workbook: Alerting on SLOs

API 与平台能力会演进；部署前应按目标版本重新核对。

← 上一课
第 7 课：Metrics、Logs、Tra… 下一课 →
第 1 课：MDP、回报与 Bellman …