FastCheck：大规模DNN训练中应对严重故障的高效检查点恢复框架

1. 项目概述：当万亿参数模型训练遇上“致命”故障

如果你参与过大规模深度学习模型的训练，尤其是在动辄使用成千上万张GPU卡的超算集群上，那么对“训练中断”这个词一定深恶痛绝。这不仅仅是程序崩溃那么简单，背后往往是硬件故障、网络分区、甚至是操作系统内核崩溃导致的整台服务器“宕机”。这种需要重启整个物理节点的故障，在论文里被精准地称为“严重故障”。虽然它们发生的频率可能只占总故障的11%，但造成的恢复时间开销却超过82%。想象一下，一个万亿参数的模型，单次检查点文件就高达12TB，当严重故障发生时，你需要从远程的慢速存储（比如网络文件系统）重新加载这12TB的数据到GPU内存，这期间所有的计算卡都在空转。一次这样的中断，可能就浪费掉数万甚至数十万的GPU小时，成本和时间的损失是惊人的。

传统的检查点方案，无论是简单粗暴地存到本地硬盘，还是像Gemini那样存到另一个节点的内存里，在面对严重故障和超大模型时都显得力不从心。前者受限于磁盘I/O的龟速，后者则受限于单节点网络带宽的瓶颈。FastCheck这个框架，正是为了解决这个痛点而生。它的核心思路非常清晰：用并行化对抗带宽瓶颈，用定制化压缩对抗数据体积。它不是一项孤立的技术，而是对现有训练容错体系的一次系统性优化，目标直指大规模DNN训练中最昂贵的那部分时间浪费——由严重故障引发的漫长恢复。

简单来说，FastCheck想回答的问题是：在必须将检查点持久化到能扛过整机重启的可靠存储这个大前提下，如何把保存和加载这个“必要之恶”的开销降到最低？它的答案是，构建一个分层的、智能的存储体系。本地内存作为第一级缓存提供最快访问；多个对等节点的内存作为第二级分布式缓存，通过并行读写提供高带宽和容错；最终的远程持久化存储作为兜底的第三级。同时，针对检查点数据的独特性质进行“瘦身”，让每一级之间流动的数据量尽可能小。下面，我们就来拆解这个框架是如何一步步实现其目标的。

1.1 核心需求与挑战解析

要理解FastCheck的设计，首先要明白大规模DNN训练中检查点所面临的几个核心矛盾。

第一，可靠性要求与性能需求的矛盾。检查点的根本目的是容错，因此其存储介质必须能在节点完全失效后依然可访问。这天然排除了单纯依赖本地CPU内存的方案（因为节点重启后内存数据丢失）。而高可靠的持久化存储，如网络附加存储，其带宽往往远低于节点间的内存网络（如InfiniBand或高速以太网）带宽，成为性能瓶颈。

第二，数据体积巨大与恢复时间紧迫的矛盾。模型参数规模的增长速度远超存储和网络带宽的提升速度。一个千亿参数模型（FP32）的检查点约400GB，万亿参数模型则达到12TB。以10 GB/s的网络存储带宽读取12TB数据需要1200秒，即20分钟。这期间，价值数百万美元的GPU集群处于闲置状态。

第三，数据特性与通用压缩算法失效的矛盾。检查点数据（主要是模型权重和优化器动量）是二进制浮点数。研究发现，这些浮点数的尾数低位比特具有高度随机性，导致GZIP等通用压缩算法对其压缩率极低，几乎无法减少数据体积。必须设计针对检查点数据内在规律的专用压缩方法。

第四，集群资源动态性与方案普适性的矛盾。训练集群中，节点的网络带宽并非独占，可能同时承载推理服务等流量，导致入向和出向带宽不对称、节点负载不均。一个优秀的检查点方案必须能适应这种动态环境，智能选择传输目标和时机，避免对训练任务造成干扰。

FastCheck正是围绕解决这四个矛盾展开的。它不满足于“能用”，而是追求在复杂、动态的真实生产环境中，依然能保持“高效”和“稳定”。

2. FastCheck 核心架构与设计哲学

FastCheck的整体架构是一个典型的分层、分布式系统设计，其核心思想是将原本集中、串行的检查点操作，转变为分散、并行的流水线作业。下图勾勒了其核心组件与数据流：

[训练节点] --生成检查点--> [本地内存] --分区/压缩--> [并行传输] --> [多个存储节点内存] | | | | [健康状态维护] <-------------- [KV存储] <-----------------------------| | | v v [远程持久化存储] <----------- (异步持久化) <---------------- [存储节点内存]

整个系统由三类角色构成：训练节点、存储节点和协调者。训练节点负责执行模型的前向和反向传播，定期触发检查点保存。存储节点是集群中其他可供利用的服务器，提供其空闲的CPU内存作为“临时缓存池”。协调功能则由一个轻量级的键值存储（如Memcached）和一个主节点来承担，负责维护全局的节点健康状态。

2.1 分层存储策略：本地、对等与远程

FastCheck采用三级存储策略来平衡性能与可靠性：

1. 本地内存缓存：检查点生成后，首先写入训练节点自身的CPU内存。这一步速度极快，旨在应对最常见的“普通故障”（如单个GPU错误、进程崩溃），此时可以直接从本地内存快速恢复，延迟最低。
2. 对等节点内存存储：这是FastCheck应对严重故障的核心。检查点被分片后，并行传输到多个（例如3-4个）其他存储节点的内存中。这样，即使训练节点整机宕机，检查点数据仍然分布在集群中其他健康节点的内存里，可以从这些节点并行读取恢复。这利用了节点间高速网络的带宽，远快于从远程存储读取。
3. 远程持久化存储：作为最终的安全网，完整的检查点会异步地写入共享的持久化存储（如NFS、Ceph对象存储）。只有当所有内存副本都丢失时（概率极低），才会从这里恢复。由于是异步操作，它不会阻塞训练的主流程。

这个策略的精妙之处在于，它用概率换性能。严重故障本身是低概率事件，多个存储节点同时发生严重故障的概率则更低。通过将数据分散在多个节点的内存中，FastCheck在绝大多数故障场景下都能从高速内存中恢复，仅在极小概率的灾难性场景下才退回到慢速存储，从而在统计意义上大幅降低了平均恢复时间。

2.2 并行传输与分片机制

并行化是突破单点带宽瓶颈的关键。FastCheck将每个完整的检查点（包含权重和动量两个字典）均匀地分割成N个数据分片。这里的关键是“均匀”，以确保每个分片传输时间相近，避免木桶效应。

分片数量的选择并非越多越好。它受到两个因素制约：一是发送方（训练节点）的出向带宽，二是接收方（存储节点）的入向带宽。假设训练节点出向带宽为B_out，单个存储节点入向带宽为B_in。当N * B_in > B_out时，瓶颈在于训练节点的出向带宽，此时增加N无法提升总吞吐。因此，最优的N值应使得N * B_in略大于或等于B_out。在实践中，论文通过实验发现，在它们的测试环境中，N=3时达到最优，N=4则因出向带宽饱和而收益甚微。

节点选择策略同样重要。FastCheck采用了一个兼顾延迟和负载的智能选择算法：

• 延迟探测：每秒向集群所有节点发送探测包，测量网络往返延迟。优先选择延迟最低的N个节点，以减少传输的端到端延迟。
• 负载均衡：当多个节点延迟相近时，选择内存负载最轻的节点。因为检查点占用的是内存资源，过高的内存使用率可能引发交换，反而降低性能。

通过这种动态选择，FastCheck能够适应网络拥塞和节点负载波动，确保传输过程的高效和稳定。

2.3 定制化压缩：针对权重与动量的“瘦身术”

通用压缩在检查点数据上折戟沉沙，迫使FastCheck转向针对性的压缩算法。它敏锐地抓住了权重和动量这两类数据的本质差异。

对于模型权重，其特点是连续变化小。在训练过程中，权重通过梯度进行微调，相邻两个检查点（可能间隔数百或数千个训练步）之间的权重值变化非常细微。FastCheck采用了增量压缩。具体来说，它保存第一个检查点的完整权重作为“基准备份”。对于后续的第t个检查点，不再保存完整的权重张量W_t，而是保存它与前一个检查点权重的差值（Delta）Δ_t = W_t XOR W_{t-1}。由于变化小，Δ_t中绝大部分位都是0，使用游程编码等简单方法就能获得极高的压缩比。论文中在VGG模型上实现了最高77.4%的压缩率。

实操心得：增量计算的实现细节这里的XOR（异或）操作是在二进制位层面上进行的，它能精准地捕捉每一位的变化。在实现时，需要确保两个张量在内存中对齐。直接对两个torch.Tensor进行XOR操作可能会触发自动类型转换或设备间数据传输。一个高效的实现是：先将张量转换为numpy.ndarray并展平为一维字节数组(tensor.numpy().tobytes())，然后使用numpy.frombuffer结合numpy.bitwise_xor对字节数组进行操作，最后再处理压缩。这避免了在Python循环中进行逐元素操作，性能更高。

对于优化器动量，其特点是数值范围小，前缀重复度高。动量（如Adam优化器中的一阶矩和二阶矩估计）是梯度的移动平均，其绝对值通常远小于权重。在IEEE 754浮点数表示中，数值越小，其指数部分（exponent）和前几位有效数字（significand）相同的可能性就越高。FastCheck采用了索引压缩。它扫描动量张量中所有浮点数的前P位（例如前12位），构建一个“前缀-索引”映射表。然后将每个浮点数原本的前P位替换成一个短得多的索引号。由于前缀种类有限，这个索引号可能只需要3-4个比特，从而为每个浮点数节省了8-9个比特的存储空间。对于动量的压缩率虽不及权重，但因其本身数据量小于权重，整体贡献依然可观。

并行字节流填充是压缩过程中的一个性能优化点。经过上述压缩，每个浮点数变成了变长比特串。将这些变长数据打包成标准的字节流（8比特为单元）如果串行进行，会成为瓶颈。FastCheck的解决方案是：将待压缩的数据分成P组，每组独立计算压缩后的总比特长度，预分配字节缓冲区，然后并行地进行比特填充操作。虽然这可能造成每个组尾部不到一个字节的浪费（填充0），但相对于整体性能提升，这点存储开销（论文指出<0.01%）是完全可以接受的。

3. 关键技术实现与优化细节

3.1 增量合并：化解恢复时的“读放大”难题

增量压缩在保存时效果显著，但在恢复时却可能带来一个新问题：读放大。假设我们已经保存了基准备份W_0和100个增量Δ_1到Δ_100。当需要恢复第100个检查点时，朴素的做法需要先读取W_0，然后顺序读取并应用100个增量，这相当于读取了101倍于单个检查点的数据量，恢复时间会随着检查点数量线性增长，完全抵消了压缩带来的传输收益。

FastCheck引入了一个巧妙的后台增量合并机制来解决这个问题。存储节点在后台异步地执行合并操作。当它接收到Δ_1后，可以立即计算W_1 = W_0 XOR Δ_1，并将W_1保存在内存中，同时丢弃Δ_1。随后，当Δ_2到达，它计算W_2 = W_1 XOR Δ_2，以此类推。这样，存储节点上始终保存着最新一个完整检查点的权重，以及一个合并中的增量基准备份。

当发生故障需要恢复时，训练节点只需向存储节点请求最新的完整权重W_t即可，无需关心历史增量。这彻底消除了读放大，使得恢复时的数据读取量恒等于一个检查点的大小。这个设计体现了系统思维，将计算开销从关键路径（恢复过程）转移到了非关键路径（存储节点的后台任务）。

3.2 轻量级一致性的健康状态维护

在并行传输中，必须确保不会将检查点分片发送给已经故障的节点，否则会导致数据丢失和恢复失败。因此，集群需要维护一个全局一致的节点健康状态视图。FastCheck设计了一个轻量级且保证一致性的协议。

它使用一个独立的KV存储（如Memcached）来记录每个节点的状态（可用/不可用）。但直接频繁读写KV存储可能成为瓶颈。为此，FastCheck引入了一个主节点和位图机制。

1. 主节点与位图：集群中选举一个节点作为主节点，它维护一个位图，每一位对应一个训练节点，表示该节点“是否正在更新其状态”。
2. 状态更新流程：当一个节点要更新自己的状态时（例如心跳上报），它： a. 向主节点发送请求，主节点将该节点对应的位图位置为1（表示更新中）。 b. 该节点去更新KV存储中的自身状态。 c. 更新成功后，再次通知主节点，主节点将位图对应位置为0（表示更新完成）。
3. 状态读取流程：当训练节点需要查询某个存储节点的状态以决定是否向其发送数据时，它： a. 先查询主节点的位图，如果目标节点位为1，则等待片刻（因为它的状态可能正在变更中）。 b. 如果位为0，则直接去KV存储中读取该节点的最新状态。

这个协议保证了在状态更新期间，任何查询者都不会读到中间状态或过期状态，实现了强一致性。同时，由于位图操作非常轻量，且大部分状态查询只需访问主节点（位图）而无需访问KV存储，大大降低了协调开销。

3.3 容错与数据重建：引入奇偶校验分片

仅将数据分片存储在多个节点，如果某个存储节点恰好也发生故障，就会导致一个分片丢失。为此，FastCheck借鉴了纠删码的思想，引入了奇偶校验分片。

在将检查点分成N个数据分片D1, D2, ..., DN后，FastCheck会计算一个奇偶校验分片P = D1 XOR D2 XOR ... XOR DN，并将这个P分片存储到第N+1个节点上。这样，在N+1个节点的组内，可以容忍任意一个节点的故障。

• 如果故障的是某个数据分片节点，可以通过剩余N-1个数据分片和奇偶校验分片P进行XOR运算来重建丢失的数据：Dx = P XOR D1 XOR ... XOR D_{x-1} XOR D_{x+1} XOR ... XOR DN。
• 如果故障的是存储校验分片P的节点，则不影响数据恢复，因为所有数据分片都完好。

这种N+1的冗余策略，在只增加一个节点存储开销（存储校验分片）的情况下，将容错能力从0提升到了1。对于现实中占主导地位的单节点故障，这提供了足够的保护。对于更罕见的多节点同时故障，系统则降级到从远程持久化存储中读取丢失的分片。

4. 系统集成与PyTorch实现剖析

将FastCheck集成到现有的训练框架（如PyTorch）中，需要以非侵入式的方式挂钩检查点的保存和加载流程。以下是基于论文描述和工程实践的核心实现思路。

4.1 挂钩检查点回调

PyTorch训练通常使用torch.save和torch.load进行模型状态的保存和加载。FastCheck需要封装这两个操作。

import torch import torch.distributed as dist from fastcheck.core import FastCheckManager class FastCheckWrapper: def __init__(self, model, optimizer, checkpoint_dir, num_shards=3): self.model = model self.optimizer = optimizer self.manager = FastCheckManager(checkpoint_dir, num_shards) # 注册到PyTorch的钩子或自定义训练循环中 def save_checkpoint(self, epoch, step): # 1. 构建标准检查点字典 checkpoint = { 'epoch': epoch, 'step': step, 'model_state_dict': self.model.state_dict(), 'optimizer_state_dict': self.optimizer.state_dict(), # ... 其他状态 } # 2. 调用FastCheck的异步保存接口 # 该接口内部会执行：分区 -> 压缩 -> 并行传输 -> 异步持久化 future = self.manager.save_async(checkpoint, tag=f"epoch{epoch}_step{step}") # 3. 返回future，训练循环可以继续，无需等待持久化完成 return future def load_checkpoint(self, resume_path=None): # 如果指定路径，则从远程存储加载 # 否则，尝试从内存副本恢复（由manager自动选择最快源） checkpoint = self.manager.load(resume_path) if checkpoint: self.model.load_state_dict(checkpoint['model_state_dict']) self.optimizer.load_state_dict(checkpoint['optimizer_state_dict']) return checkpoint['epoch'], checkpoint['step'] return 0, 0 # 从头开始

关键点在于save_async是异步的。它立即将检查点写入本地内存，然后启动后台线程进行分片、压缩和并行传输到其他节点，最后再异步写入远程存储。训练进程在写入本地内存后就可以继续，极大减少了检查点对训练流程的阻塞。

4.2 压缩算法的具体实现

权重增量压缩的实现：

import numpy as np import zlib # 用于对XOR后的字节流进行压缩 class DeltaCompressor: def __init__(self): self.prev_weights_bytes = None # 上一个检查点权重的字节流 def compress_weights(self, state_dict): # 将state_dict中的所有权重张量拼接并转换为字节流 current_bytes = self._state_dict_to_bytes(state_dict) if self.prev_weights_bytes is None: # 第一个检查点，保存完整数据 compressed = zlib.compress(current_bytes) self.prev_weights_bytes = current_bytes return compressed, is_delta=False else: # 计算增量 # 注意：需要确保两个字节数组长度一致 delta_bytes = bytes(a ^ b for a, b in zip(current_bytes, self.prev_weights_bytes)) compressed_delta = zlib.compress(delta_bytes) self.prev_weights_bytes = current_bytes return compressed_delta, is_delta=True def _state_dict_to_bytes(self, state_dict): # 将所有张量转换为numpy，拼接，再转为bytes # 需要保证每次的顺序一致，用于正确的XOR计算 buffer = bytearray() for key in sorted(state_dict.keys()): # 按key排序保证顺序 param = state_dict[key].cpu().numpy() buffer.extend(param.tobytes()) return bytes(buffer)

动量索引压缩的实现：

class IndexCompressor: def __init__(self, prefix_bits=12): self.prefix_bits = prefix_bits self.prefix_to_index = {} # 前缀 -> 短索引 self.index_to_prefix = [] # 短索引 -> 前缀 self.index_bit_len = 0 # 索引所需的比特长度 def compress_momentum(self, momentum_tensor): # momentum_tensor 是一个大的浮点型张量 flattened = momentum_tensor.cpu().numpy().view(np.uint32) # 以32位整型看待浮点数 compressed_chunks = [] index_table = {} # 第一步：扫描并构建前缀表 for value in flattened: prefix = value >> (32 - self.prefix_bits) # 提取高prefix_bits位 if prefix not in self.prefix_to_index: idx = len(self.index_to_prefix) self.prefix_to_index[prefix] = idx self.index_to_prefix.append(prefix) if idx.bit_length() > self.index_bit_len: self.index_bit_len = idx.bit_length() # 动态确定索引位长 # 第二步：编码 # 将每个浮点数编码为：索引（index_bit_len位） + 剩余低位（32-prefix_bits位） for value in flattened: prefix = value >> (32 - self.prefix_bits) idx = self.prefix_to_index[prefix] lower_bits = value & ((1 << (32 - self.prefix_bits)) - 1) # 将 idx 和 lower_bits 打包成比特流（此处简化，实际需用位操作打包） encoded = self._pack_bits(idx, lower_bits) compressed_chunks.append(encoded) # 返回压缩后的比特流和前缀映射表 return b''.join(compressed_chunks), self.index_to_prefix

4.3 并行传输与网络通信

并行传输的核心是使用非阻塞I/O和线程池，同时向多个存储节点发送数据分片。

import concurrent.futures import socket class ParallelTransmitter: def __init__(self, storage_nodes, port): self.nodes = storage_nodes # 存储节点地址列表 self.port = port self.executor = concurrent.futures.ThreadPoolExecutor(max_workers=len(storage_nodes)) def send_shards(self, shard_list): """并发发送所有分片。shard_list长度应与storage_nodes长度一致。""" futures = {} for node, shard in zip(self.nodes, shard_list): future = self.executor.submit(self._send_to_node, node, shard) futures[future] = node # 等待所有传输完成，或处理失败 done, not_done = concurrent.futures.wait(futures.keys(), return_when=concurrent.futures.ALL_COMPLETED) for future in done: if future.exception(): node = futures[future] print(f"Failed to send shard to {node}: {future.exception()}") # 触发重试或故障转移逻辑

网络通信应使用高效的序列化协议（如Protocol Buffers、FlatBuffers）和可能的数据流压缩，以进一步减少传输量。

5. 性能评估与实战调优指南

论文中的实验数据已经充分证明了FastCheck的优越性：在多个模型上，检查点时间相比基线方法最高减少78.42%，恢复时间最高减少77.41%。但在实际部署中，如何根据自身集群情况调优以达到最佳效果，才是工程师最关心的问题。

5.1 关键参数调优实践

1. 分片数量N：这是最重要的参数。你需要测量集群中节点间的有效带宽，而非理论峰值。

   • 测试方法：使用iperf3或nc工具，在训练节点和潜在存储节点之间进行TCP流测试，记录稳定的吞吐量。注意区分单向（出向/入向）带宽。
   • 计算公式：N ≈ 训练节点出向总带宽 / 单个存储节点平均入向带宽。向上取整，但不宜超过4或5，因为管理开销和故障概率会随之增加。
   • 动态调整：可以实现一个简单的反馈机制，如果连续几次检查点传输都因某个节点慢而拖后腿，则在下一轮选择时将其暂时排除。

2. 增量压缩的间隔：论文测试了间隔T=1到5。结论是T=1（即每次都和上一个检查点做差分）压缩率最高。在实践中应始终坚持T=1。因为后台合并机制已经解决了读放大问题，无需为了恢复性能而牺牲压缩率。保持高压缩率以减少传输数据量是首要目标。

3. 索引压缩的前缀位数P：论文测试了7到14位。这是一个数据依赖的参数。

   • 调优方法：在训练初期，保存几个检查点的动量数据，编写一个脚本离线测试不同P值下的压缩率。选择压缩率开始趋于稳定的那个P值。通常，对于FP32的动量，12位是一个不错的起点。
   • 注意：P值越大，前缀种类可能越多，索引表越大，但每个浮点数节省的位数也越多（因为替换的部分更长）。需要在索引表开销和压缩率之间取得平衡。

4. 并行填充的线程数：论文显示8线程和16线程效果接近。这取决于你CPU的物理核心数。建议设置为CPU物理核心数 - 1，留一个核心给系统和其他任务。过度超线程可能因资源竞争反而导致性能下降。

5.2 常见问题与故障排查

问题1：恢复时，从存储节点读取的数据分片无法合并成完整检查点。

• 可能原因1：分片大小不一致。确保分区算法在发送端和接收端是完全确定性的。在序列化分片数据时，应该在头部加入分片索引、总片数、校验和等信息。
• 可能原因2：存储节点内存数据被覆盖或丢失。检查存储节点的内存管理策略。FastCheck需要确保为检查点数据预留固定的内存区域，并实现简单的LRU淘汰机制，避免被其他进程占用。同时，需要实现“租约”机制，定期续租，超时未续租的数据可被清理。
• 排查步骤：
  1. 在恢复时，记录每个分片的MD5哈希值。
  2. 与发送时记录的哈希值对比，定位损坏的分片。
  3. 从奇偶校验分片或其他数据分片尝试重建该损坏分片。
  4. 如果重建失败，则从远程持久化存储拉取该分片。

问题2：检查点保存过程中，训练速度明显变慢。

• 可能原因1：压缩过程占用大量CPU。增量压缩和索引压缩，尤其是XOR和前缀扫描，是CPU密集型操作。如果使用Python原生循环实现，会成为瓶颈。
• 解决方案：
  • 使用向量化操作：尽可能使用numpy或torch的批量位运算，避免Python层循环。
  • 使用C++扩展：将核心的压缩/解压算法用C++实现，并通过PyBind11为Python提供接口。这是生产环境推荐的方案。
  • 限制CPU使用：为压缩线程设置CPU亲和性，避免与训练线程争抢关键核心。
• 可能原因2：网络传输占满带宽，影响了梯度同步。在数据并行训练中，梯度同步也需要占用网络带宽。
• 解决方案：
  • 设置流量控制：为检查点传输流量设置较低的TCP拥塞窗口或使用 QoS 策略，给梯度同步流量预留带宽。
  • 错峰传输：如果训练是迭代式的，可以在梯度同步完成后的计算阶段进行检查点传输，此时网络相对空闲。

问题3：主节点故障导致健康状态服务中断。

• 解决方案：实现主节点选举。可以使用基于Raft的轻量级库（如pyraft）或者利用分布式锁服务（如ZooKeeper、etcd）。当检测到主节点失联时，剩余节点迅速选举出新主节点，并从KV存储中恢复位图状态。论文中提到使用了类似Raft的算法，这是保证服务高可用的标准做法。

5.3 与现有训练框架的融合建议

• PyTorch：如前面代码所示，最佳方式是创建一个FastCheckCallback，集成到torch.nn.Module或训练循环中。可以利用torch.distributed的通信原语来协调集群内的操作。
• TensorFlow：可以自定义一个tf.train.CheckpointManager的子类，重写save和restore方法，接入FastCheck的后端。
• DeepSpeed / Megatron-LM：这些大规模训练框架本身有复杂的状态分区（模型并行、流水线并行）。FastCheck需要与之深度集成。建议的路径是：钩住框架内部的save_checkpoint和load_checkpoint钩子。在保存前，先调用框架的接口获取全局的、聚合后的优化器状态和模型状态字典，然后再交给FastCheck处理。这需要仔细阅读框架源码，找到合适的中断点。

最后一点个人体会：FastCheck这类系统的价值，在模型规模较小或者故障不频繁的集群中可能不那么明显。但是，当你管理的集群规模达到上百台服务器，训练一个模型需要数周甚至数月时，每一次非计划的中断都是真金白银的损失。此时，投资于这样一套高效的检查点恢复系统，其回报率会非常高。它不仅仅是节省时间，更是提升了整个集群的可预测性和资源利用率，让昂贵的算力资源更多地用于创造价值的计算，而非等待I/O。在AI基础设施领域，这种对“魔鬼细节”的优化，往往是决定大规模训练成败的关键。