操作系统课程文献阅读记录----Just-In-Time Checkpointing： Low Cost Error Recovery from Deep Learning Training Failures

说实话，如果直接看这个和目前方向不相关的论文，感觉真的很糖，也很抽象。这里感谢某篇博客对我的启发与帮助，链接如下：https://profetia.github.io/u/posts/papers/2024-08-27-reading-notes-just-in-time/

大佬分析得肯定是比我看到的要更加细致与全面的。

摘要

在大型深度学习任务中，往往会使用到多个GPU进行数据集的处理。训练过程中的错误，会导致任务的重新启动，并丢失训练至今的内存状态。而常规的检查点机制通过定期保存训练状态，可以帮助错误的恢复，但会导致显著的稳态开销，同时，大量GPU需要重新执行上一个检查点以来的训练任务。为解决这一问题，提出了一种及时检查点的机制，仅在故障发生时，基于数据并行性的特点，使得所有的GPU仅仅只需重新执行单个小批次的迭代操作即可恢复。在此机制的基础上，作者提供了用户级和透明级两种实施方式。

背景与动机

在大型深度学习任务中，往往利用了大量的GPU进行训练。而在训练的过程中，错误的数量是巨大的。每当错误发生时，所有的GPU将停止工作并丢失当前的训练状态。为解决这种情况，当前，使用最多的是定期检查点。通过定期保存GPU的状态，当错误发生时，则将故障GPU状态重置为最近检查点的状态。但这种方式因为要定期保存GPU状态，所以会造成显著的稳态开销，同时，当故障GPU恢复后，所有的GPT都得重写只需自最近检查点所有工作，会造成大量GPU的浪费。
作者观察到下述三点现象：
（1）训练过程中的故障主要是由于单个GPU或者网络设备的故障引起的，而主机/CPU和同时发生的多节点故障及其罕见。
（2）大部分的深度学习任务采用的是数据并行，所有的GPU所使用的是相同的参数副本。当一个GPU发生错误时，其他GPU上存在可用的模型参数和优化器状态。
（3）由模型参数和优化器状态组成的关键 GPU 状态仅在反向传播结束时的优化器步骤中的一个小间隔内更新。

因此，作者提出了一种及时检查点机制，仅在错误发生后，进行检查点的保存。

方法设计

关键机制

（1）领域感知设备API拦截
当任务发生错误时，常常会将当前作业挂起，或者直接崩溃。但是，同时作业启动器会直接终止所有任务。但这个对于深度学习任务而言，其实是灾难性的，一旦任务直接被中止，那么将从头开始所有的训练。因此，作业提供了一个库，可以对于CUDA和NCCL API的调用进行领域感知的透明拦截。

在用户级中，拦截使我们能够检测错误，并在用户脚本中小心地执行一个对 CPU 和 GPU 状态进行检查点操作的函数。此外，同时，还能够检查挂起情况，异步地将GPU情况复制到CPU。
在透明级方案的情况下，作者创建的库可以在稳定状态下记录所有 GPU 设备 API，在不将错误暴露给应用程序代码的情况下检测错误，然后对 GPU 和 CPU 状态进行检查点操作和恢复，重放 GPU API。这里，作者利用了一个独立的设备代理服务器，代理服务器执行所有设备和网络操作，并避免在应用程序的工作进程中持有任何 GPU 或网络驱动程序状态。这样只需重新启动设备代理服务器的相关进程即可清楚错误的状态，并不会影响到应用进程的执行。