进程级别重调度

使用约束

• 进程级重调度支持的版本配套关系如下。
  • PyTorch版本为2.7.1。
  • MindSpeed-LLM版本为2.3.0。
• 当训练任务的annotation中hccl/rankIndex字段为0的Pod发生故障时，不触发Pod级别重调度和进程级别重调度，直接触发Job级别重调度。
• 不能和优雅容错功能同时开启。若同时开启，断点续训将通过Job级别重调度恢复训练。
• MindSpore场景下，为保证本功能的正常使用，请将MindSpore和MindIO安装在同一路径下。
• MindSpore场景下，需要在启动TaskD Manager前设置export TASKD_PROCESS_ENABLE="on"。
• 请勿使用ConfigMap挂载RankTable文件，否则可能会导致任务重调度失败。

• 只支持PyTorch单算子模式、基于Megatron框架的模型以及acjob类型训练任务。

• 只支持单容器迁移，不支持按照亲和性迁移。
• 不支持多模态模型。
• 不支持开启watchdog功能。
• Atlas A3 训练系列产品场景下，若发生NPU掉卡类、OS断连类的故障，可导致进程级别重调度失败。
• 当故障发生在HCCL建链阶段时，会导致进程级别重调度失败。如果除训练初始化的HCCL建链外，还存在其他训练阶段的HCCL建链，可参考配置HCCL主动触发建链章节进行提前建链，防止故障出现在HCCL建链阶段。

支持的产品型号和AI框架

重调度原理

训练过程中如果出现了软硬件故障，将导致训练状态异常。进程级重调度根据配置策略首先销毁故障的训练进程或容器，并通知其他训练容器中的训练进程暂停当前训练任务，然后隔离故障设备，再重新将训练容器调度启动。故障训练容器重新启动后，通知所有容器中的训练进程进行集合通信重建链。建链完成后，将CKPT通过参数面发送给新拉起的训练进程恢复参数，恢复后所有进程重新执行当前step恢复训练。

图1 进程级别重调度原理示意图

在以上原理图中，各个步骤的说明如下。

1. 设备出现硬件故障后，MindCluster在服务器上的检测组件上报故障信息到ClusterD中，软件故障由容器内MindIO Controller感知并上报到ClusterD。
2. ClusterD将故障服务器上的任务容器销毁，重新调度到备用的服务器上。
3. ClusterD通知Master节点上的MindIO Controller进行容错，容错流程包括通知停止训练、通知全局故障、通知恢复策略。
4. MindIO Controller通知每个训练进程中的MindIO Processor，MindIO Processor调用PTA强制停止训练进程。MindIO Processor清理正常节点的资源，销毁通信域，清理后等待新进程加入。
5. 备用服务器上的管理进程拉起训练进程后，创建新的MindIO Processor，MindIO Controller通知每个训练进程中的MindIO Processor恢复训练。
6. 各个进程进行集合通信建链。
7. 正常服务器上的NPU通过参数面将CKPT传递到备用服务器上，完成参数状态恢复后继续训练。

功能适配点

在进程级别重调度中，集群大脑会根据全局故障信息决策恢复策略并将策略下发到MindIO，调度器需要支持故障Pod调度，而非整个任务重调度，支持恢复策略依次回退。在训练容器中，框架首先初始化MindIO服务。启动服务后优化器更新时会上报对应状态到MindIO。随后，创建DP副本组和优化器副本，以保障模型参数的冗余备份。当异常发生时，通过异常捕获装饰器捕获故障模式，当系统恢复时执行算子资源清理，节点重启后触发通信重建。通过参数面在线修复和状态回滚，完成进程级重调度恢复。

对于非MindSpeed-LLM和MindCluster平台用户，需在框架侧完成表2的功能适配。