Model High Availability (HA) Feature Overview
What Is the Model Training HA Feature?
During long-running and large-scale model training, job interruptions are inevitable due to hardware stability issues, network fluctuations, and other factors. If a training job can recover quickly after an interruption, it significantly improves compute device utilization while reducing time costs and compute losses for users.
ModelArts provides a model training high availability (HA) feature. It includes capabilities such as resumable training, fault detection, automatic restart, faulty node isolation, suspension detection, operator re-execution, and failure log analysis. These features enhance the stability of long-running, multi-node multi-PU training jobs for LLMs. In the event of a failure, the system automatically restores the training state and resumes execution, minimizing compute loss.
Model HA primarily addresses the following issues:
- Job failures caused by infrastructure anomalies in nodes, chips, networks, or storage during training.
- Overall task failure triggered by an anomaly in a single node during multi-node multi-PU training.
- Training suspension, where the training process does not exit but makes no meaningful progress for an extended period.
- Distributed training failure caused by sporadic issues in communication links.
- Enabling ModelArts HA configurations improves automatic recovery capabilities, but it cannot replace fault-tolerant code design. You should still thoroughly incorporate fault tolerance into your training scripts.
- For long-running tasks, especially LLM training, it is strongly recommended that you implement checkpoint saving and resumable training from checkpoints.
- If HA is not enabled, ModelArts will not handle exceptions detected during training.
Model Training HA Feature Map
Table 1 lists the HA capabilities supported by ModelArts and their corresponding scenarios. Select the features that best match your requirements.
| HA Capability | Key Function | Code Modification Required | Recommended Scenario |
|---|---|---|---|
| Resumable training | Resumes training progress from a saved checkpoint after job interruption. | Yes | All long-running training tasks. |
| Auto restart | Automatically resubmits the training job after a failure. | Recommended with checkpoint | Hardware failures, environment anomalies, abnormal process exits. |
| Unconditional auto restart | Triggers job-level rescheduling after an abnormal exit of user processes. | Recommended with checkpoint | Sporadic software errors, process exits. |
| Job suspension detection | Detects when a training process makes no meaningful progress for a long time. | No | Multi-node multi-PU training, long-term stability training. |
| Restart upon suspension | Restarts user training processes after detecting a suspension. | Recommended with checkpoint | Training process remains running but makes no progress. |
| Fault recovery | Executes in-place recovery, job rescheduling, or pod rescheduling based on fault types. | Yes (scripts should be re-entrant) | Distributed training, NPU/GPU multi-node training. |
| Operator re-execution | Retries failed communication operators to prevent overall job failure. | No or minor adaptation required | Ascend supernode communication failure scenarios. |
| Training log failure analysis | Assists in troubleshooting and pinpointing root causes after training failures. | No | Job failure troubleshooting. |
What is your overall rating for this page?
Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot