企业生产实践
本章把可靠性工程放回真实企业：四家头部玩家的一手数据对照、上线流程的组织实践、以及可靠性经济学在生产里的最终形态。
8.1 四家头部玩家对照
Meta（Llama 3 + TrainMover + Kokolis）、ByteDance（ByteRobust）、Alibaba（FALCON）、Google（TPUv4 体系）代表了四种互补的生产范式：
| 维度 | Meta | ByteDance | Alibaba | |
|---|---|---|---|---|
| 规模锚点 | 16,384 H100（24K 集群内） | 9,600 GPU 生产作业 | >10,000 GPU 共享集群 | TPUv4 Pod 级 |
| 中断统计 | 466 次/54 天，78% 硬件 | 3 个月 778,135 作业、38,236 显式 + 5,948 隐式失败 | 60% 大作业受 straggler 影响 | ~1% 训练作业受中断影响 |
| 检测时延 | NCCL watchdog 兜底 | GPU 10 s / NIC 30 s / OS 2 s | culprit score 归因打分 | healthd 常驻 + 双 preflight |
| checkpoint | 每 GPU 1MB-4GB 分片，异步 | 每步分层（DRAM+SSD），<0.9% 开销 | — | Orbax/OCDBT 异步 |
| 恢复路径 | 热备 + 沙箱预热 + 两阶段建链（TrainMover） | 热备热更新 46-65 s（快 11.04 倍） | 多级缓解 + 换备 | 双路径：reconfigure / reroute |
| 标杆指标 | 作业级 MTTF 7.9 h（研究集群口径） | 97% ETTR、非生产时间 <50 min | straggler 检测 >99%、缓解 60.1% | 99.98% 可用率 |
| 特色 | 恢复时间线被完整拆解并公开 | 全栈自研（2 万行 Go 控制器） | fail-slow 领域的系统研究 | 可靠性即架构（OCS 拓扑） |
四个范式各补一块拼图：Meta 把恢复经济学量化得最透（TrainMover 的分钟级拆解与美元账），ByteDance 给出了端到端生产系统的完整样本（ByteRobust），Alibaba 把 fail-slow 从"无人理睬"变成一等公民，Google 证明可靠性可以从架构层就买下来（OCS + 双路径，细节见 Google 案例）。
8.2 上线流程：一台节点进入训练池要经历什么
以 ByteRobust 披露的生产流程为骨架，一台新节点（或维修归来的节点）进入训练池的标准路径：
- 上电自检：BMC/带外诊断（电源、风扇、内存 CE/UE、PCIe 链路），失败的直接送修。
- Burn-in 压测：数小时高压负载（计算/显存/网络全矩阵），抓 infant mortality 与间歇性故障。SDC 嫌疑用确定性负载逐位验证——注意 EUD 召回率约 70%，所以关键集群要叠加更长周期的观察。
- 入池观察期：先给低优先级作业跑，画像服务积累带内信号（Xid、ECC、温度曲线、step 稳定性），无异常才转入大训练池。
- 持续体检：运行期巡检线程（秒级）+ 周期性深度自检；劣化信号触发"温柔驱逐"（不interrupt当前 step，等 checkpoint 边界换出）。
- 故障后回收：故障节点自动污点、送修、修复后回到第 2 步——永远不存在"修好了直接回池"的捷径。
与建设期的交互：扩容窗口紧时（xAI 122 天建设 10 万卡、上架 19 天开训），burn-in 与观察期被压缩，早期失效节点更多进入运行期——xAI 案例的建设期时间线与运行期故障率之间的交换关系，是本流程"不可压缩"部分的最好注脚（见 xAI 案例）。
8.3 运行时处置：故障发生后的十分钟
以一次典型 GPU fail-stop 为例的分钟级实录（数字取各家实测）：
| 时刻 | 事件 | 累计 |
|---|---|---|
| T+0 s | GPU 故障，作业 hang | 0 |
| T+10 s | 巡检线程发现 Xid + step 超时上报 | 10 s |
| T+40 s | 控制器完成初判（GPU 类），向调度申请热备 | 40 s |
| T+55 s | 热备唤醒完成热更新，新 rank 加入 | 55 s |
| T+90 s | 增量状态同步完成，回滚到最近 checkpoint（in-memory，分钟级 RPO） | 90 s |
| T+100 s | 通信组 delta 重建 + warmup 完成 | 100 s |
| T+100 s | 训练恢复；故障节点进入回收流程 | — |
对照组是 Llama 3 时代典型路径（NCCL 10 分钟超时 + 全量重启）：30 分钟以上。两端相差约 20 倍——这就是 ByteRobust"平均解决时间最高降 84.5%（CUDA 错误）"的来源。每一次故障处理的结构化记录（各环节耗时 vs 预算）直接决定下一轮优化打哪里。
8.4 经济学：把可靠性换算成钱与卡
可靠性投入的回报可以用三种口径核算（均有一手数字支撑）：
- 损失口径：16K GPU 作业成本约 144 万美元/天（TrainMover），ETTR 0.6 ≈ 每天蒸发 58 万美元；64K/128K 规模吞吐损失 16.47%/31.79%，折合 95 万/363 万美元/天。每 1% ETTR ≈ 每天数万美元——这是可靠性团队的产出定价。
- 投资口径：32K 规模一台热备机的替换能力等效约 2,400 张卡（TrainMover：20 s 替换 vs 4.45 min 冷路径）；ByteDance 热备池 P99 仅 2-4 台换 9,600 卡作业的稳定运行。热备是典型的"百分之几的闲置换百分之十几的 ETTR"。
- 规模口径：没有可靠性工程时，可用率随规模线性塌方（Mini Demo 场景 1：13 万卡 + 5 分钟热备只剩 42.55%）——可靠性投入的边际收益随规模递增，这也是为什么十万卡俱乐部无一不在自研这套系统。
把三种口径放在一起，就是向管理层要预算的标准话术：损失定义价格、热备定义性价比、规模律定义"不投不行"。
8.5 组织实践：可靠性是流程不是英雄
生产数据的另一面是组织设计：
- 自动化优先，人工兜底：Llama 3 的 54 天里人工只介入 3 次；ByteDance 把"人工调整代码/数据"与"平台故障"分开记账（17.3% vs 其余）。值班工程师的职责是处理自动化解决不了的长尾与决策，不是当报警器。
- 预算化管理：ETTR 目标（>95% 起步）、检测/定位/恢复三段时延预算（第 4 章）、checkpoint 开销预算（<2%）写进团队 SLO，按月复盘超支项。
- Blameless 复盘 + 规则回流：每次故障入库（知识库），模式沉淀为检测规则/污点策略/采购反馈。SDC 这类长周期排查（8 小时压测级）必须允许"无结论闭环"——记录嫌疑、隔离节点、持续观察，比强行归因更有价值。
- 故障演练（game day）：随机杀节点/杀交换机/注入慢节点，校验端到端预算是否达标。没有演练的可靠性指标是自我安慰——checkpoint 最常见的死法是"备份存在但恢复不了"。
8.6 与 AI SRE 体系的衔接
训练可靠性平台本质上是 AI SRE 在训练侧的垂直实现：SLO（ETTR/MTTR 预算）、可观测（遥测 + 知识库）、事故响应（决策树）、容量规划（热备池 + 故障率趋势）一一对应。差异在两点：训练侧的"错误预算"花得极快（万卡作业每天数次中断，见 AI SRE 的 SLO 实践），且度量必须区分"平台故障"与"实验操作"（ByteRobust 的 17.3% 教训）。评估可靠性改进是否真实有效时，可以借 Benchmark + Evaluation 的思路：把 ETTR、MTTR、误报率做成可回归的指标，每次平台变更跑对照。
小结
生产实践的共识已经很清晰：检测秒级化、恢复热备化、checkpoint 每步化、经济性账本化、处置流程化。四家头部玩家的数据互相印证了同一条曲线——万卡以下靠工程优化，十万卡必须叠加架构与硬件层的可靠性投资。下一章汇总成可执行的最佳实践清单。