{"id":"IL-0427","org":"BigScience","date":"2021-08-12","docs":[],"title":{"en":"A GPU with uncorrectable ECC errors crashed tr1-13B training, and Slurm's next job went to the same node and crashed too","ko":"tr1-13B 학습이 고장 난 GPU 가 있는 노드에서 연달아 두 번 죽었다"},"domain":["ai-infra"],"impact":{"scope":"The tr1-13B training run crashed twice in a row on the same faulty node and stopped until the next job landed on other nodes","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Without a way to link an exception to the hostname of the node that raised it, the scheduler can keep placing the training on the faulty node and the training keeps crashing; per-node log files make the faulty node visible so it can be excluded.","ko":"예외가 난 노드의 호스트 이름을 알 수 없으면, 다음 작업이 고장 난 노드에 다시 배정돼 학습이 거듭 죽는다. 호스트 이름을 알면 `sbatch --exclude` 로 그 노드를 뺄 수 있으므로, 예외와 노드를 이어 주는 수단이 꼭 있어야 한다."},"related":[],"sources":[{"url":"https://github.com/bigscience-workshop/bigscience/blob/master/train/tr1-13B-base/chronicles.md","kind":"github","archived":"https://web.archive.org/web/20250925102832/https://github.com/bigscience-workshop/bigscience/blob/master/train/tr1-13B-base/chronicles.md"}],"summary":{"en":"BigScience trained the tr1-13B model with Megatron-DeepSpeed on the JZ cluster, running it as a chain of Slurm jobs in a job array so that each job started as soon as the previous one ended. One job crashed after many hours of training with an uncorrectable ECC error from CUDA. Nobody was around to notice, and the Slurm scheduler started the next job in the array, which was given the same node and crashed immediately during startup with a CUDA out-of-memory error at a torch.distributed barrier.\n\nThe team concluded that one of the GPUs had a hardware fault and contacted the JZ administrators, who confirmed that one of the nodes was faulty. The next training job did not land on that node and training continued. At that point the team had no way to match an exception to the hostname of the node that raised it, so a faulty node could keep being allocated and keep crashing the training. As a workaround the team added %N to the Slurm output file name, which gives every node its own log file and shows which node has the corrupt GPU, so the node can then be left out with sbatch --exclude.","ko":"tr1-13B 학습은 JZ 에서 Slurm job array 로 돌았다. job array 의 작업 하나가 여러 시간 학습한 뒤 iteration 43680 에서 역전파 도중 `cudaErrorECCUncorrectable: uncorrectable ECC error encountered` 로 죽었다.\n\n그때 아무도 지켜보지 않았고, Slurm 스케줄러는 job array 의 다음 학습 작업을 띄웠다. 스케줄러가 같은 노드를 다시 배정해서 이 작업은 2021-08-12 08:19 에 시작하자마자 `torch.distributed.barrier()` 에서 `RuntimeError: CUDA error: out of memory` 로 죽었다.\n\n팀은 GPU 하나에 하드웨어 문제가 있다고 보고 JZ 관리자에게 연락했고, 관리자는 노드 하나가 고장 난 것을 확인했다. 그다음 학습 작업은 그 노드에 배정되지 않아 학습이 이어졌다. 당시에는 예외가 난 노드의 호스트 이름을 알 방법이 없었다. 그래서 팀은 `#SBATCH --output` 에 `%N` 을 넣어 노드마다 로그 파일을 따로 남기기로 했다."},"trigger":{"en":"One GPU on one node of the allocation developed a hardware problem that produced uncorrectable ECC errors.","ko":"학습에 배정된 노드 하나의 GPU 에 하드웨어 문제가 생겨 정정할 수 없는 ECC 오류가 났다."},"severity":"unknown","symptoms":["training-job-failed","gpu-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Nobody was around to notice the first crash, and the Slurm scheduler started the next job in the array on its own, which crashed too.","ko":"첫 충돌 때는 아무도 지켜보지 않았고, 스케줄러가 띄운 다음 작업도 죽은 뒤에야 문제를 알았다. 팀은 두 번의 실패를 보고 GPU 하드웨어 문제를 의심했고, JZ 관리자에게 물어 노드 하나가 고장 난 것을 확인했다."},"components":["gpu-hardware","slurm"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Contacted the JZ administrators, who confirmed one of the nodes was faulty","ko":"JZ 관리자에게 연락해 노드 하나가 고장 난 것을 확인했다."}},{"text":{"en":"Continued training with the next job, which was not placed on the faulty node","ko":"다음 학습 작업이 고장 난 노드에 배정되지 않아 학습이 이어졌다."}}],"action_items":[{"text":{"en":"Add %N to the Slurm output setting (#SBATCH --output=%x-%j-%N.out) so each node writes its own log file and the node with a corrupt GPU can be identified","ko":"`#SBATCH --output=%x-%j-%N.out` 처럼 출력 파일 이름에 `%N` 을 넣어 노드마다 로그 파일을 따로 남기고, 그 로그로 어느 노드의 GPU 가 고장인지 가린다."}},{"text":{"en":"Exclude a node known to be faulty from the allocation with sbatch --exclude","ko":"고장 난 노드의 호스트 이름을 알아내면 `sbatch --exclude=node1,node2,... ` 로 다음 작업에서 그 노드를 뺀다."}}],"contributing":["automation-amplified","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"After many hours of training, one job of the tr1-13B Slurm job array crashed at iteration 43680 of 311541 during the backward pass. The next job in the array started by itself and crashed right away, before training began.\n\nThe first crash ended in \"RuntimeError: transform: failed to synchronize: cudaErrorECCUncorrectable: uncorrectable ECC error encountered\", followed by \"terminate called after throwing an instance of 'c10::Error'\" and \"what():  CUDA error: uncorrectable ECC error encountered\", raised from torch.autograd.backward inside DeepSpeed's pipeline engine.\n\nThe second job, started at 2021-08-12 08:19:28 by the Slurm scheduler, initialized tensor model parallel size 2 and pipeline model parallel size 4, then failed while compiling and loading fused kernels: torch.distributed.barrier() in _compile_dependencies raised \"RuntimeError: CUDA error: out of memory\".\n\nNobody was watching when the first crash happened, and the logs gave no way to tie an exception to the hostname of the node it came from, so the faulty node could not be picked out and excluded.","ko":"tr1-13B 학습이 여러 시간 돌다가 iteration 43680 에서 죽었고, Slurm 이 이어서 띄운 다음 작업도 시작하자마자 죽었다.\n\n첫 충돌은 DeepSpeed 파이프라인 엔진의 `_exec_backward_pass` 에서 역전파를 하던 중에 났다. 로그에는 `RuntimeError: transform: failed to synchronize: cudaErrorECCUncorrectable: uncorrectable ECC error encountered` 가 찍혔고, 이어서 `terminate called after throwing an instance of 'c10::Error'` 와 `what():  CUDA error: uncorrectable ECC error encountered` 가 찍혔다.\n\n두 번째 작업은 2021-08-12 08:19 에 시작해 퓨즈드 커널을 컴파일하고 불러오는 단계의 `torch.distributed.barrier()` 에서 `RuntimeError: CUDA error: out of memory` 로 죽었다.\n\n팀은 두 번 연달아 죽은 것을 보고 GPU 하나에 하드웨어 문제가 있다고 봤다. 하지만 예외를 그 예외가 난 노드의 호스트 이름과 이어 볼 방법이 없어서 로그만으로는 어느 노드가 고장인지 알 수 없었다."},"updated_at":"2026-11-14T12:34:07.731783Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0427","org_slug":"bigscience"}