# 7.7 检查点管理与容错

大规模训练任务往往持续数周甚至数月，硬件故障几乎不可避免。稳健的检查点管理和容错机制是确保训练能够成功完成的工程基石。

## 7.7.1 检查点的内容与策略

一个完整的训练检查点应保存所有恢复训练所需的状态：模型参数、优化器状态（一阶/二阶矩）、学习率调度器状态、当前步数、随机数生成器状态，以及数据加载器的位置（确保断点续训时不重复使用已见数据）。

检查点保存频率是一个权衡：**太频繁**会导致大量 I/O 开销（保存一个 70B 模型的完整检查点涉及数百 GB 的写入），**太稀少**则意味着故障后损失更多的训练进度。常见做法是每 500\~2000 步保存一次。

现代大规模训练中常用的优化策略包括：

* **分片检查点**（Sharded Checkpoints）：在分布式训练中，不是让某个 GPU 保存整个模型，而是让每张 GPU 保存自己负责的参数切片，大幅减少单 GPU 的 I/O 负载。恢复时各 GPU 并行读取自己的分片，加速重启。
* **异步保存**（Asynchronous Checkpointing）：检查点写入由后台线程或另一个进程完成，不阻塞训练循环。这允许 GPU 在 I/O 进行时继续计算，显著降低检查点保存的性能开销。

## 7.7.2 检查点平均

**检查点平均**（Checkpoint Averaging）是一种有时能提升最终模型性能的技巧。在训练后期，取若干相邻检查点的参数权重求平均，可能获得比任何单个检查点更平滑的解；但收益强依赖任务、指标、训练阶段和检查点间距，不能把某个 benchmark 上的数值直接外推为通用 LLM 收益。

其原理与模型集成类似：不同检查点对应损失曲面上略有不同的位置，取平均后的模型更接近损失盆地的中心，泛化性能更好。

## 7.7.3 容错机制

大规模集群上的故障类型包括 GPU 硬件错误、网络中断、节点宕机等。常见的容错策略包括：

* **自动重启**：检测到节点失败后自动从最近的检查点恢复训练
* **弹性重启**：支持节点失败或成员变化时由调度器重启 worker，并从最近检查点恢复
* **拓扑可迁移检查点**：当 GPU 数量、ZeRO/FSDP 分片或 TP/PP/DP 拓扑变化时，需要能重分片模型、优化器、随机数和数据加载器状态；这比普通弹性重启更复杂
* **冗余存储**：检查点保存到分布式文件系统或对象存储，避免单点故障

框架如 DeepSpeed、Megatron-LM 和 Ray Train 都提供了不同程度的容错支持。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/llm_internals/di-er-bu-fen-xun-lian-pian/07_distributed_training/7.7_checkpoint.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.