规模越大，越会失效的机器

前几章依次讲了如何组装加速器、连接设备、封装芯片，以及为站点供电。进入运行阶段后，问题变了：系统的某些部分失效时，它还能不能继续产出可以验收的工作？只看组件本身的可靠性，回答不了这个问题。训练步骤停滞、张量出错、服务请求超时，以及智能体改错文件，代表的是不同结果，不能混为一谈。

因此，讨论可靠性要先定义一份故障契约，明确工作负载边界、什么事件算故障、观测窗口有多长，以及如何完成恢复验收。对训练来说，目标可能是在不损坏模型状态的前提下持续取得有效进展；对在线服务来说，可能是在时延目标内返回正确结果；对智能体来说，可能是完成一次经过验证的状态变更，而不是给出一条看似合理的最终消息。规模越大，这三件事就越难：组件增多，发生中断的机会也增多；同步范围扩大，一个局部故障会让更多工作停顿；执行轨迹变长，未被发现的错误也有更多时间扩散。规模大到一定程度后，几乎在任何时刻都有某处在出故障。可靠性工程要决定的是，这个局部事件最终会变成进展损失、目标未达标，还是错误结果。此时，运行目标由「预防故障」转向「摊销故障」，把不可避免的中断纳入明确的故障预算。

先统计故障，再预测故障

一套有用的事件分类，应当把原因与症状分开：

• 计划内中断是提前知道的运维、软件、数据或维护事件；
• 停机故障会发出明确信号，并终止进程或集合通信；
• 性能退化故障不会让进程退出，却会减慢甚至停止进展；
• 静默数据损坏不会报错，却会返回错误值；
• 相关故障会同时影响同一故障域，例如主机、机架、交换机、存储服务、供电线路或软件版本。

对每一类故障，都要记录事件数、暴露量、受影响的进程编号、检测延迟、诊断时间、恢复时间、故障波及范围和损失的工作。系统即使很少崩溃，也可能因为很晚才发现卡死而没有多少有效运行时间；系统即使可用性很好，也可能产出错误的检查点。把这些情况压成一个笼统的「故障率」，会同时掩盖两者。

Meta 的 Llama 3 论文提供了一份少见的公开记录。在 405B 模型预训练的 54 天观测期内，训练最多使用 16,384 块 H100 GPU。作者记录了 466 次中断，其中 47 次属于计划内中断，419 次属于意外中断。在意外中断中，58.7% 被归类为 GPU 问题；整次训练的有效训练时间超过 90% (Grattafiori and others 2024)。按算术平均计算，两次意外中断之间约有 3.1 小时。但论文并没有证明每块 GPU 都服从固定的故障规律，也没有说观测期内的每个时刻都恰好使用了 16,384 块设备。

常用的简写是 平均无故障时间（MTBF），也就是平均故障间隔，这里指整项作业两次故障之间的预期时间。对可以维修的设备，「故障间隔」这个说法很合适；对训练作业，更准确的名称往往是「两次导致作业停止的中断之间的平均时间」。采用一个刻意简化的模型，可以写成：

$$\Lambda_{\mathrm{job}} = \sum_{j=1}^{m}\lambda_j, \qquad R_{\mathrm{job}}(t) = e^{-\Lambda_{\mathrm{job}}t}, \qquad M_{\mathrm{job}} = \frac{1}{\Lambda_{\mathrm{job}}}.$$

其中：

• $m$ 是模型中会导致作业停止的故障域数量；
• $j$ 表示其中一个故障域；
• $\lambda_j$ 是该故障域导致作业停止的危险率，单位是每单位时间的事件数；
• $\Lambda_{\mathrm{job}}$ 是导致作业停止的总危险率；
• $\sum$ 表示把各故障域的危险率相加，$e$ 是自然对数的底；
• $t$ 是已经运行的时间；
• $R_{\mathrm{job}}(t)$ 是在 $[0,t]$ 内没有发生模型所描述中断的概率；
• $M_{\mathrm{job}}$ 是模型给出的平均中断间隔。

这个结果假设故障是平稳、相互独立的泊松事件。真实机群会经历磨合期、老化、公共软件故障、共享网络故障、集中维护，以及不同的故障隔离策略，这些因素都会破坏上述假设。把 Llama 的事件率按设备数量成比例放大，只能称为条件性外推：如果所有致停危险率都随设备数线性增长，那么十万块设备下的中断间隔约为 30 分钟。它并非普遍适用的扩展定律，也不是预测。

故障预算把事件换算成有效时间

量出中断之后，多久保存一次检查点就成了一项经济选择。保存得太频繁，写入状态本身会吞掉运行时间；保存得太少，每次中断又会丢掉更多计算。Young 在 1974 年提出了经典的一阶近似，Daly 后来又把它扩展为更完整的重启模型 (Young 1974; Daly 2006)。一份容易检查的一阶损耗预算是：

$$W(\tau) \approx \frac{C}{\tau} + \frac{\tau}{2M} + \frac{D+R}{M}, \qquad E_{\mathrm{approx}} = 1-W(\tau), \qquad \tau^*=\sqrt{2CM}.$$

其中：

• $W(\tau)$ 是损失的挂钟时间占比的近似值；
• $\tau$ 是两个已完成检查点之间的有效计算时间；
• $C$ 是阻塞式检查点的写入成本；
• $M$ 是两次已检测到的致停中断之间的平均时间；
• $D$ 是中断后的检测与诊断时间；
• $R$ 是诊断后的恢复时间；
• $E_{\mathrm{approx}}$ 是剩余有效时间的近似占比；
• $\tau^*$ 是让两个检查点频率相关项最小的 Young 间隔。

$\tau/(2M)$ 这一项假设每次中断平均会损失半个检查点间隔。整个表达式是一种小损耗近似，它还假设中断服从平稳泊松过程、系统使用阻塞式周期检查点，而且恢复期间不会再发生故障。它没有描述异步快照、相关故障、检查点自身失败，或很久以后才被发现的静默损坏。这个模型适合用来暴露假设，不应取代测量；生产系统应在明确的观测窗口内直接测量 ETTR。

from math import sqrt

hours_observed = 54 * 24
unexpected_interruptions = 419
mean_minutes = hours_observed * 60 / unexpected_interruptions

checkpoint_minutes = 1.0
detection_minutes = 1.0
recovery_minutes = 1.0
young_minutes = sqrt(2 * checkpoint_minutes * mean_minutes)
waste = (
    checkpoint_minutes / young_minutes
    + young_minutes / (2 * mean_minutes)
    + (detection_minutes + recovery_minutes) / mean_minutes
)

conditional_100k = mean_minutes * 16_384 / 100_000

print(f"Observed interruption interval: {mean_minutes / 60:.2f} hours")
print(f"Young interval: {young_minutes:.1f} minutes")
print(f"Approximate useful fraction: {1 - waste:.1%}")
print(f"Conditional 100k interval: {conditional_100k:.1f} minutes")

这里把检查点、检测和恢复时间都设为一分钟，仅用于说明；Llama 3 论文并未报告这些数值。这个可运行示例有意把观测输入与假设的运行成本分开。

恢复是一条经过验证的控制闭环

检查点文件只是恢复过程的一部分。完整的运行闭环必须完成检测、隔离、恢复和验证：发现进展已经停止，隔离可信范围内最小的故障域，在确认正常的资源上恢复状态，再验证进展和数值行为都已经恢复。每一次状态转换都要有超时、责任人和验收标准。如果只求快速重启而不隔离，系统可能再次遇到同一个故障；如果重启后不验证，系统可能从已经损坏的状态继续运行。

ByteRobust 是一个有参考价值的生产案例，但不是通用处方。作者报告称，一项在 9,600 块 Hopper GPU 上持续三个月的训练作业，ETTR 最高达到 97%。该系统结合了在线检查、停止时诊断、扩大可疑故障域的隔离范围、热备机器，以及带有组外对等备份的内存检查点。论文还报告，每一步检查点的开销低于 0.9% (Wan and others 2025)。这些数字是该平台上的生产结果。论文展示了恢复机制带来的加速，但不能据此泛化为每次完整重启都只需几秒。

这里的设计原则是分清不同职责。活性信号回答「各进程还在前进吗」；性能信号回答「前进速度符合预期吗」；正确性检查回答「产出的状态可以接受吗」；隔离策略回答「下一次尝试必须排除哪些资源」。控制面需要同时具备这四种能力。

静默损坏需要一条正确性验证路径

静默数据损坏（SDC） 指一种不会触发明确硬件或软件错误，却会给出错误计算结果的故障。它之所以危险，是因为模型状态已经偏离时，常规可用性监控仍可能显示一切正常，整个计算过程也可能不发出警报。讨论这类故障时，必须把发生率与后果分开：研究损坏会呈现什么形态，不能说明它在机群中多久发生一次；研究已经出故障的节点，也不能估算健康节点中的异常占比。

Ma 等人把十五个异常节点与十五个健康节点配对；前一组由生产机群管理系统标记。在确定性执行条件下，他们发现有些案例的权重已经漂移，预训练损失却几乎没有变化；在另一组微调实验中，部分受影响节点出现明显的损失尖峰，其中一次运行的最终准确率为零。该研究使用单节点张量并行，作者也明确说明样本量与规模有限 (Ma et al. 2025)。它展示的是可能造成的后果，而不是任意一次前沿训练遭到损坏的概率。

另一项研究回答的是不同问题。Tung 等人在一种生产级 GPU 架构的双 SM 缩减模型上进行门级固定值故障注入仿真，并运行了 63 个 CUDA 微基准。在这次仿真中，NaN 与无穷值占观测损坏结果的 1.01%，单比特事件占非特殊比特翻转损坏的不到 40% (Tung et al. 2026)。这些数字描述的是特定故障模型下的结果分布，并不是机群中的发生率。它们说明，只监控 NaN 或只注入均匀单比特故障的检测器覆盖率很弱，并不能说明纠错内存没有作用。

一条可操作的正确性验证路径通常分为几层：节点准入时用黄金输出做压力测试；运行时检查数值不变量和进展哨兵；某个进程可疑时进行对比或重放；隔离相关故障域；回滚到首次出现偏差的步骤之前的检查点；最后通过一次干净的重放测试，才允许设备重新服务。覆盖率、开销、检测延迟和误报率都必须测量。「我们会观察损失」并不是覆盖率说明。

局部性决定同步边界

同步会放大故障。在批量同步训练中，一个掉队或失效的参与者，就可能在下一次集合通信处拖住所有进程。具体代价取决于消息大小、集合通信算法、放置方式、拥塞和拓扑，而不只是物理距离。第 62 章 介绍了这些网络域，第 66 章 则说明了它们与并行放置的关系。

NCCLX 给出了一组具体的层级数据。在 Meta 连接超过十万块 GPU 的拓扑中，相对同机架通信，跨机架但位于同一 AI Zone、跨 AI Zone，以及跨数据中心建筑的时延分别约为 7 倍、15 倍和 30 倍 (Si and others 2025)。这些比例是该 RoCE 网络拓扑所特有的，不是自然常数。它们提示我们，应把暴露在关键路径上、对时延敏感的通信放在尽可能小的域内，同时实测更大范围的集合通信能否与其他工作重叠。

放宽全局同步，会同时改变故障域和优化算法。Decoupled DiLoCo 提供了两个不应混在一起的演示。在一项实验中，合成事件序列模拟了 120 万块芯片，并假设每块芯片的中断间隔为一年。八个学习器保留了 88% 的有效吞吐，相比之下，弹性数据并行只有 58%，而两者报告的评估结果接近。另一项实验则用分布在美国不同区域的八个学习器训练一个 120 亿参数模型，报告的步进速度接近同地部署的 DiLoCo (Douillard and others 2026)。前一个结果来自模拟的故障暴露，后一个结果来自地理分散的研究实验。后者证明了该规模下的可行性，但不等同于前沿规模的生产部署。

这也解释了它与 第 68 章 的联系：分散供电可能促使训练跨地域部署，但并不会让异步优化变得没有代价。一套方案还需要在词元数与计算量相同的条件下比较算法质量，提供网络与故障轨迹，说明陈旧更新的处理策略，完成恢复测试，并计入复制模型状态的成本。最终质量不达标，再高的有效吞吐也不能算有效进展。

服务：拆分会增加一次交接

在线服务有不同的事务边界。只有输出通过验收，且时延满足服务目标，一个请求才算成功。两项常见的时延指标是首词元时间（TTFT）和每输出词元时间（TPOT）：前者主要受排队与提示处理影响，后者是生成期间用户感受到的逐词元时延。SLO 有效吞吐是指 TTFT 与 TPOT 都保持在既定阈值内时，系统能够持续处理的请求速率。原始的每秒词元数即使上升，SLO 有效吞吐仍可能下降。

预填充与解码往往具有不同的资源特征，但这种分类取决于工作负载。预填充可以在提示词元之间暴露并行计算，通常能达到较高的算术利用率。自回归解码在批量较小时会反复流式读取权重；如果使用常规注意力且上下文很长，还要读取不断增长的 KV 缓存（key-value cache）。批量大小、提示长度、输出长度、模型架构、精度、并行方式和网络时延，都可能让任一阶段转向另一种瓶颈 (Erdil 2025)。「解码受带宽限制」描述的是一种工作负载，不是恒等式。这种相互作用常被概括为延迟层级和解码带宽限制，但实际部署必须用自己的请求组合测量两者。

DistServe 给出了一种应对方式：把预填充与解码放进不同的 GPU 资源池，分别配置容量，并把池间 KV 缓存传输计入成本。其 OSDI 2024 评估相对所测试的基线，报告了最高 7.4 倍的请求处理量，或最高 12.6 倍更严格的时延目标，但这不是普遍加速比 (Zhong et al. 2024)。Mooncake 为相关设计提供了生产证据。Kimi 的服务平台使用分离的资源池、分布式 KV 缓存和传输引擎；其 FAST 2025 论文使用真实请求轨迹，并报告了横跨数千个节点的部署结果 (Qin et al. 2025)。

拆分也增加了一个故障边界。调度器必须知道，失败的 KV 缓存传输应该重试、重新计算，还是转发到同地副本。它还必须保护解码阶段免受队首阻塞，并在两个资源池中保留重复的模型容量。采用持续批处理或分块预填充的同地部署不需要这次交接，对另一种请求组合可能更合适。选择方案时，需要同时考虑到达轨迹、TTFT 与 TPOT 目标、KV 大小、传输带宽、排队、故障行为和成本。

服务机制与 第 31 章 和 第 32 章 相连。长上下文带来的缓存压力会在 第 35 章 中继续讨论。

智能体也需要事务

一条智能体执行轨迹不是一次模型调用。一个连跑数小时的智能体，会依次提出状态变更、接收工具响应、执行验证，并在必要时重试。所有必要步骤都成功的概率服从概率链式法则：

$$\Pr(S_{1:n}) = \prod_{i=1}^{n} \Pr(S_i \mid S_{1:i-1}).$$

其中：

• $n$ 是既定任务拆分中的必要步骤数；
• $i$ 表示当前步骤；
• $S_i$ 表示步骤 $i$ 满足自身验收条件这一事件；
• $S_{1:i-1}$ 表示步骤 $i$ 之前所有验收事件的历史；
• $S_{1:n}$ 表示从第 1 步到第 $n$ 步全部通过验收这一事件；
• $\Pr$ 表示概率；
• $\prod$ 表示把各步骤的条件概率相乘。

如果每一步相互独立，成功概率都等于 $p$，而且先前的错误无法修正，那么表达式可简化为 $p^n$。这是一个有用的零模型，却不能预测任意智能体的表现。工具故障、自我修正、重试、共享的隐藏状态，以及不断累积错误的上下文，都会让条件概率依赖执行历史。

Sinha 等人在一项受控的多轮任务中隔离了这种执行效应。他们发现，在较早轮次中插入错误会降低后续步骤的准确率，并把这种现象称为自我条件化。在该研究测试的非思考模型中，扩大模型规模并未消除这一效应；测试过的思考模型则没有表现出这一效应 (Sinha et al. 2026)。这个结果是针对一项受控任务的证据，不能证明所有智能体都会按同一速率退化。

另外两项指标回答的是不同问题。METR 的时间跨度，是智能体在某个拟合成功概率下所能完成任务的时长，其中时长指人类专家完成任务所需的时间。它不是模型步骤数，而且取决于基准与运行框架 (METR 2026)。$\tau$-bench 的可靠性指标则询问，同一任务能否在重复试验中持续成功：

$$\operatorname{pass}^{k} = \Pr(Y_1=1,\ldots,Y_k=1).$$

其中：

• $k$ 是同一任务的重复试验次数；
• 试验 $r$ 到达经过验证的目标状态时，$Y_r$ 为 1，否则为 0；
• $r$ 表示某次试验；
• $\operatorname{pass}^{k}$ 是全部 $k$ 次试验都通过的概率 (Yao et al. 2025)。

两者的区别很重要：$p^n$ 是单条轨迹内部的基准，而 $\operatorname{pass}^{k}$ 衡量多条重复轨迹之间的一致性。部署报告应说明任务分布、运行框架与工具版本、重试策略、部分得分规则和置信区间，而不是只给一个通过率。

系统层面的应对方法，是为每个会产生实际后果的动作设置事务边界：先声明前置条件，再执行幂等或可补偿的步骤，对照外部状态检查后置条件，保存紧凑的检查点，最后根据结果继续、重试、回滚或升级给人工处理。这正是 第 41 章 中运行框架和 第 52 章 中评估器的作用，但它们不能把能力不足的模型变成能力足够的模型。第 71 章 追踪模型能力前沿的变化，本章关心的则是：在任意给定模型可以被信任并长时间运行之前，外围系统必须提供什么。

让证据可以重放

可靠性评审应当能从记录中重建，而不是依赖人们对一次事故的记忆。首先固定一套事件分类，并为每个事件附上来源时间戳、软件和固件版本、拓扑、受影响的进程编号，以及故障域分类。还要记录检测时间、隔离时间、恢复时间、检查点年龄、损失的加速器时间、已知情况下首次出现偏差的步骤，以及最终关闭事故所依据的验证结果。

训练报告应分开统计计划内和意外停止、停机故障和性能退化故障的暴露量、检查点开销、ETTR 与数值完整性警报。服务报告应包括请求到达与长度分布、TTFT 和 TPOT 分位数、SLO 未达标次数、重试放大倍数和输出验收率。智能体报告应保留任务版本、完整动作日志、外部状态差异、验证器输出与人工干预。无论哪一层，都应保留重放测试、能覆盖恢复路径的故障注入、验收标准，以及证据失败时的责任人。

这份证据契约可以避免三种常见错误：把一家运营商的事件率外推成硬件定律，把仿真故障模型中的结果当成现场发生率，以及只报告吞吐而不报告正确性或时延。它也让改进可以证伪：新检测器应在既定覆盖率下降低检测延迟；新检查点路径应减少损失的工作；新的服务拆分应提高 SLO 有效吞吐；新的智能体运行框架应提高重复试验中经过验证的任务完成率。

在边界内失效的机器

可靠的机器并不是永不失效的机器。 在继续信任更多状态之前，它必须定义故障、发现故障、限制波及范围、完成恢复，并检查恢复结果。训练可靠性保护的是昂贵的计算进展；服务可靠性保护的是时延与正确性契约；智能体可靠性保护的是它获准改变的现实环境。具体机制不同，运行纪律却一致：在正确的边界上统计，让假设清晰可见，并用证据闭合每一条恢复回路。

本书的基础设施部分到此结束。下一章将从机器本身的极限，转向学习本身的极限。

延伸阅读