Mini Demo

本章配套的 Mini Demo 位于 docs/07-ai-sre/training-reliability/mini-demo/，用纯 numpy 实现五个训练可靠性核心量化模型：

可用率 vs 集群规模：MTBF/MTTR 模型，含 Kokolis HPCA'25 与 Llama 3 两组实测校准锚点
checkpoint 间隔优化：Daly 近似 vs 网格精确最优；差量 checkpoint 对比
故障注入 + 弹性恢复：Llama 3 故障分类占比采样；冷重启 vs 热备的 ETTR 对比
straggler 检测与缓解：中位数法慢节点检测；替换后 step 时间恢复
SDC 双跑对比检测：bit flip 注入、分片指纹定位、loss 尖刺守卫

所有模型 CPU 可运行、固定种子、输出确定（与本章所引数字逐字一致）。

目录结构

text

docs/07-ai-sre/training-reliability/mini-demo/
├── README.md
├── pyproject.toml
├── conftest.py
├── training_reliability_mini/
│   ├── __init__.py
│   ├── availability.py   # MTBF/MTTR、可用率、ETTR 简化模型
│   ├── checkpoint.py     # checkpoint 间隔优化（Daly + 网格精确解）
│   ├── recovery.py       # 故障 taxonomy、注入、冷/热恢复时间线
│   ├── straggler.py      # 同步 step=max 语义、中位数法检测、替换缓解
│   ├── sdc.py            # bit flip 注入、双跑对比、分片指纹、尖刺检测
│   └── demo.py           # 五场景一键入口
└── tests/                # 60 个确定性 pytest 测试

运行方式

bash

cd docs/07-ai-sre/training-reliability/mini-demo
pip install -e ".[dev]"
pytest tests/ -v
python -m training_reliability_mini.demo

场景 1：可用率 vs 集群规模

availability.scale_table 用独立故障指数模型（作业 MTBF = 节点 MTBF / N）生成规模-可用率表。实测输出：

text

# 场景 1：可用率 vs 集群规模（MTBF/MTTR 模型）

校准：节点 MTBF = 8089.6 h（Kokolis HPCA'25：1024 卡作业 MTTF 7.9 h 反推）

| 节点数 | 作业 MTBF (h) | 冷修复 MTTR=60min 可用率 | 热备交换 MTTR=5min 可用率 |
|---|---|---|---|
| 128 | 63.200 | 98.44% | 99.87% |
| 1024 | 7.900 | 88.76% | 98.96% |
| 8192 | 0.988 | 49.69% | 92.22% |
| 16384 | 0.494 | 33.05% | 85.56% |
| 32768 | 0.247 | 19.80% | 74.76% |
| 131072 | 0.062 | 5.81% | 42.55% |

Llama 3 口径校准：16,384 卡实测每 2.78 h 一次中断（隐含单节点 MTBF 5.20 年）
1024 卡模型 MTBF = 7.90 h（实测锚点 7.9 h，Kokolis HPCA'25）

读表要点：8,192 卡是冷修复路径的"死亡线"（可用率跌破 50%）；13 万卡即使 5 分钟热备也只有 42.55%——纯运行时手段到顶后，必须回头降故障率（硬件筛选）或改架构（故障域切分），呼应 xAI 案例与 DeepSeek 案例的架构层方案。

场景 2：checkpoint 间隔优化

checkpoint.optimal_interval_grid 对长程效率函数做网格搜索，与 Daly 近似 T* ≈ sqrt(2CM) 互校。实测输出：

text

# 场景 2：checkpoint 间隔优化

参数：step=30s，全量 checkpoint 阻塞 240s，MTBF=7.9 h（1024 卡作业），冷重启 388s（TrainMover 8,192 卡拆解）

- 不 checkpoint：长程效率 27.38%（故障丢失全部进度）
- Daly 近似最优间隔：123 步
- 网格精确最优：123 步，效率 87.45%
- 差量 checkpoint（开销 x0.3）后最优：67 步，效率 92.18%

间隔-效率曲线（节选）：

| 间隔 (步) | 全量效率 | 差量效率 |
|---|---|---|
| 300 | 83.43% | 84.75% |
| 600 | 74.44% | 74.96% |
| 900 | 66.79% | 67.07% |
| 1200 | 60.49% | 60.66% |
| 1500 | 55.24% | 55.36% |
| 1800 | 50.83% | 50.91% |
| 2100 | 47.06% | 47.12% |
| 2400 | 43.81% | 43.85% |
| 2700 | 40.97% | 41.01% |
| 3000 | 38.48% | 38.51% |
| 3300 | 36.28% | 36.30% |
| 3600 | 34.31% | 34.33% |
| 3900 | 32.55% | 32.56% |
| 4200 | 30.95% | 30.97% |
| 4500 | 29.51% | 29.52% |
| 4800 | 28.19% | 28.20% |

三个要点：Daly 与精确解完全吻合（123 步），说明解析公式在工程上可直接使用；阻塞式全量 checkpoint 的最优效率上限只有 87.45%——这就是生产系统必须上异步/分层/差量的原因（ByteRobust 每步 checkpoint 开销 <0.9%）；间隔超过最优点后效率单调劣化（更密的 checkpoint 反而更差）。

场景 3：故障注入 + 弹性恢复

recovery.simulate_run 用固定种子采样一周故障流（占比按 Llama 3 的 58.7% GPU / 8.4% 网络 / 10% 主机 / 14.5% 软件 / 8.4% 其他），按 TrainMover/ByteRobust 的实测时间线分别走冷、热两条恢复路径。实测输出：

text

# 场景 3：故障注入 + 弹性恢复（7 天，1024 卡）

恢复时间线常数：TrainMover 8,192 卡冷重启 6.47 min（停机 0.52 + 重调度 1.50 + ckpt 加载 1.56 + NCCL 1.09 + warmup 1.80）；ByteRobust 热备 hot-update 55 s（实测 46-65 s），检测 GPU 10s / NIC 30s / OS 2s

种子 7 注入故障 20 次，分类分布：{'software': 2, 'other': 2, 'gpu': 13, 'host': 2, 'network': 1}

| 策略 | 丢失工时 (h) | ETTR |
|---|---|---|
| 冷重启（全量 requeue） | 12.204 | 92.74% |
| 热备（warm standby） | 10.724 | 93.62% |

软件/other 类故障热备也救不了（需全量重启），这是热备池要按故障分类配置的原因之一。

20 次故障 ≈ 168 h / 7.9 h 的期望（21.3），模型与锚点自洽；热备把周损失压掉 1.48 小时。注意热备的收益被两个因素限制：软件类故障仍需全量重启、回滚损失与 checkpoint 间隔绑定——这正是第 2 章"三个杠杆要一起拧"的量化注脚。

场景 4：straggler 检测与缓解

straggler 模块实现同步语义的"木桶模型"：step = max(rank 时间）。实测输出：

text

# 场景 4：straggler 检测与缓解（1024 卡，rank 7 慢 20%）

- 同步语义下 step = max(rank 时间)：36.00 s（基准 30 s，拖尾 +20%）
- 中位数法检出慢节点：[7]（precision=1.00, recall=1.00）
- 替换后 step：31.70 s（回到无慢节点基线）

对照（无慢节点，sigma=0.5s 抖动）：
- step = 31.70 s，误报 0 个

替换后 31.70 s 与无慢节点基线 31.70 s 完全对齐（都来自同一批 rank 的抖动上界），说明缓解收益不是"近似恢复"而是精确回到基线。1,024 卡里一个慢 20% 的节点，放任一周的损失 ≈ 1 - 30/36 = 16.7% 的有效算力——比大多数 MFU 优化项目的收益都大，而检测+替换的实现成本极低。

场景 5：SDC 双跑对比检测

sdc 模块模拟硬件 bit flip 与两道防线。实测输出：

text

# 场景 5：SDC 双跑对比检测（1024 rank x 4096 维梯度）

- 注入 bit flip 的 rank：[125, 382, 534, 571, 638, 762, 763, 950]（每 rank 1-8 个 bit）
- 分片指纹定位到 8 个 rank：[125, 382, 534, 571, 638, 762, 763, 950]（精确匹配 = True）
- 双跑逐位对比 8 个样本：检出 8/8
- 干净数据双跑：误报 0
- loss 尖刺检测（5x 滚动中位数）：步 [500] 命中注入点 500；干净曲线误报 0 次

注意：指纹定位是串行逐个对比（n_ranks 次），生产系统会把它摊进通信栈（如 NCCL 内嵌 checksum / 校验和聚合）。

三道结果的边界要读清楚：双跑逐位对比是零漏报但双倍算力；分片指纹是低成本全量巡检但只能发现"副本之间不一致"（单副本运行时发现不了）；loss 尖刺是事后兜底（污染已经发生）。生产部署是三者按成本分层组合（第 5.7 节）。

测试

tests/ 下 6 个文件共 60 个确定性测试，覆盖：MTBF 规模律与两组校准锚点、Daly 与网格最优的一致性、恢复时间线常数（6.47 min 逐段可加）、热备优于冷重启、同步 step=max 语义、慢节点检出与替换、bit flip 注入的确定性与双跑零漏报、尖刺检测对真发散不误报、demo 输出完全确定。

text

60 passed in 0.62s

与真实系统的差异

方面	Mini Demo	真实系统
故障过程	固定种子泊松采样	故障有突发、级联、批次相关性（整机架断电）
恢复时间线	解析常数（TrainMover/ByteRobust 实测值）	NCCL 重建/ckpt 加载依赖实现、拓扑与并发读
checkpoint	单参数阻塞模型	分层 + 异步 + 差量 + 原子提交 + 带宽配额
straggler	单轮中位数法	多轮投票 + 通信栈 culprit 归因（FALCON）
SDC	float64 bit flip	HBM/SRAM/CPU/网络全链路；检测需冗余计算或编码

小结

五个场景覆盖了可靠性工程的五个量化支柱：规模律（场景 1）、checkpoint 权衡（场景 2）、恢复经济学（场景 3）、fail-slow（场景 4）、SDC（场景 5）。每个模型的常数都来自一手实测，可以直接作为生产容量规划的初值。下一章把这些模型放回真实企业的生产实践。

Mini Demo ​

目录结构 ​

运行方式 ​

场景 1：可用率 vs 集群规模 ​

场景 2：checkpoint 间隔优化 ​

场景 3：故障注入 + 弹性恢复 ​

场景 4：straggler 检测与缓解 ​

场景 5：SDC 双跑对比检测 ​

测试 ​

与真实系统的差异 ​

小结 ​

Mini Demo

目录结构

运行方式

场景 1：可用率 vs 集群规模

场景 2：checkpoint 间隔优化

场景 3：故障注入 + 弹性恢复

场景 4：straggler 检测与缓解

场景 5：SDC 双跑对比检测

测试

与真实系统的差异

小结