Fault tolerance intra-job training
@kpoeppel đang làm issue này rồi.
Từ ngày 7/7/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Fault tolerance intra-job training
During large-scale pretraining on a Slurm cluster, node failures (GPU errors, NVLink/network faults, ECC errors, etc.) are common and grow more frequent with node count and job duration, especially at node counts of 256-1024 which is our target. By default, a single node failure kills the whole job, which then has to requeue and restart from the last checkpoint which costs time. Instead, we want to allocate a small number of spare nodes alongside the training job (e.g. 2 spares). When a node fails, the job swaps in a spare and continues within the same Slurm allocation, avoiding a full requeue and minimizing lost progress. This thus works with a static world size.
Inspiration from Bloom: https://github.com/stas00/ml-engineering/tree/master/training/fault-tolerance#fault-tolerance
Tasks
- Survey existing solutions and assess fit for our stack (Megatron-LM, torchrun elastic launcher, shared sudoless HPC, Slurm). Start with NVIDIA Resiliency Extension (NVRx): https://github.com/NVIDIA/nvidia-resiliency-ext
- Check what Megatron-LM already supports natively (it integrates parts of NVRx / fault tolerance hooks)
- Evaluate torchrun elastic + rendezvous backend (e.g. c10d/etcd) for node replacement
Note any requirements that conflict with a sudoless / shared HPC environment - Design the spare-node mechanism: how spares are allocated in the Slurm job, held idle, and promoted on failure
- Implement the feature in the oellm-autoexp codebase
- Test at small scale and simulate a node failure (e.g. scancel a node, kill a process, or inject a fault) to verify recovery
- Measure recovery cost: wall-clock time to detect + swap + resume, and steps lost per failure
- Document usage (how many spares to request, config flags) for other users of the codebase
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 3
- Fork
- 0
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của OpenEuroLLM/Taskboard
-
[nucleus sparse] Experiment setupCó thể đã có người làm @aaronkl đã nhận 8 ngày trước. Đang mởT4.1 - Optimization HPC T4.2 - model exploration
OpenEuroLLM/Taskboard#439 · 1 reaction · 1 người được giao ·
-
Qwen3.5 35B-A3B hybrid MoE weak and strong scalingCó thể đã có người làm @ibaucells đã nhận 8 ngày trước. Đang mởT4.1 - Optimization HPC
OpenEuroLLM/Taskboard#438 · 2 bình luận · 1 người được giao ·
-
Synthetic Generation for Multilingual Instruction TuningCó thể đã có người làm @abhash-er đã nhận 9 ngày trước. Đang mở4.6 post-training
OpenEuroLLM/Taskboard#437 · 1 người được giao ·
-
Safety and alignment evaluationCó thể đã có người làm @BirgerMoell đã nhận 9 ngày trước. Đang mở4.6 post-training
OpenEuroLLM/Taskboard#436 · 1 người được giao ·
-
Finding optimal dataset mixtures for DPOCó thể đã có người làm @geoalgo đã nhận 9 ngày trước. Đang mở4.6 post-training
OpenEuroLLM/Taskboard#435 · 3 người được giao ·