{"id":"IL-0416","org":"ByteDance","date":"2026-07-13","docs":[],"title":{"en":"Defective GPUs silently corrupted ByteDance's LLM training, showing as loss spikes, NaN and misleading code errors","ko":"LLM 학습에서 SDC 결함이 있는 GPU 가 ECC 오류나 온도 경보 없이 계산을 조용히 망가뜨려 손실이 치솟거나 작업이 멈췄다"},"domain":["ai-infra"],"impact":{"scope":"LLM training jobs crashed or produced corrupted checkpoints and had to be restored from a valid checkpoint; engineers spent days or weeks debugging software before the GPU was found","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"SDC diagnosis has to be part of the training control plane rather than a separate hardware test: the most useful step during an incident is to take suspicious machines out of the training path quickly and leave device-level confirmation to offline analysis. Replaying the exact workload works better than synthetic stress tests, because many defective GPUs fail only on the kernels, data ranges and communication schedules that triggered the original anomaly, and because occurrence rates vary so widely a fixed-duration stress test is not a reliable acceptance check; production systems should keep the alert-triggering trace. Deterministic training turns ambiguous symptoms such as loss spikes into reproducible comparisons, and SDCs appear throughout the hardware lifecycle, so GPUs need continuous monitoring rather than checks only when new.","ko":"ByteDance 는 세 가지를 배웠다고 정리했다. 첫째, SDC 진단은 따로 도는 하드웨어 테스트가 아니라 학습 컨트롤 플레인과 묶어야 한다. 사고 중에는 의심 장비를 학습 경로에서 빨리 빼고 장치 수준 확인은 오프라인으로 미루는 것이 가장 쓸모 있었다. 둘째, 결함 GPU 는 원래 이상을 낸 모델 커널, 데이터 범위, 통신 순서에서만 실패하는 경우가 많아 합성 스트레스 테스트보다 실제 워크로드 재실행이 효과적이었다. 셋째, 결정적 학습은 손실 급등 같은 모호한 증상을 재현 가능한 비교로 바꿔 데이터 문제, 모델 문제, 인프라 문제, 연산자 버그, 하드웨어 손상을 가려 준다. 결함 GPU 마다 SDC 발생률이 크게 달라서 정해진 시간 동안 돌리는 스트레스 테스트는 인수 기준이 되지 못한다. 경보를 낸 실행 기록은 보관했다가 드문 결함을 확인할 때 재실행해야 한다. SDC 는 하드웨어 수명 내내 나타나므로 장비를 계속 지켜봐야 한다."},"related":[],"sources":[{"url":"https://www.usenix.org/conference/osdi26/presentation/zheng","kind":"paper","archived":null}],"summary":{"en":"The paper is written by ByteDance Seed and Shanghai Jiao Tong University engineers and characterises 23 GPUs with confirmed silent data corruption (SDC), errors that change data without any signal, collected from a large production LLM training cluster, by replaying the same workloads and kernels on the defective GPUs and measuring error rates. CPU and GPU memory are protected by ECC and were not the source. Only 25% of the corruptions were found during pre-deployment burn-in; 25% appeared within the first two months, 10% within six months and 40% around one year after deployment, and once a GPU started to corrupt data its error rate usually rose over time. Vendor analysis points to resistance drift in computational circuits caused by electrical stress from repeated intensive computation. The first corrupted kernel was GEMM in 17.3% of cases, InplaceMoE in 17.3%, FlashAttention in 13.0% and RMSNorm, InplaceLinear, Scatter, FusedKernel, Mean and internally implemented kernels in 8.69% each, and FP64 and FP32 CUDA cores were more prone to errors than Tensor Cores. The errors depended on data type and input value: two GPUs gave wrong FP32 GEMM results across all input ranges while another failed only in specific value bands, and one GPU gave 100% wrong FP64 results with 50 times the normal latency.\n\nHow often a defective GPU produced a wrong tensor when its alert-triggering workload was replayed ranged from 100% down to 10^-6 %, which is why generic stress tests missed so many; at a rate of 0.01%, diagnosing one GPU with the usual software replay would cost about as much compute as training three full LLM models (about 290%). Fail-stop errors left the allocated GPUs idle until the job was restored from a valid checkpoint and the defective hardware was isolated, while loss spikes could keep producing invalid checkpoints. ByteDance built SDCHunter, which runs production training deterministically (less than 0.01% step-time difference), splits the cluster along the data-parallel dimension into two replicas fed the same batch and compares hashes of the tensors at pipeline-parallel boundaries to find the divergent stage, then replays the iteration on that group and a healthy reference group to find the first divergent tensor and kernel and the GPU that produced it. SDCHunter is now the first hardware check when loss spikes or unexplained fail-stop errors occur; it has found 40 SDC-defective GPUs in production, the training job resumes within an hour after the suspicious group is isolated, and the defective GPU is confirmed offline in under an hour, where offline debugging used to take several days.","ko":"ByteDance Seed 와 상하이교통대 연구진은 ByteDance 의 운영 클러스터에서 회수한 SDC 결함 GPU 23개를 분석했다. SDC 는 오류 신호 없이 데이터가 바뀌는 현상이다. 이 GPU 들은 계산을 간헐적으로 망가뜨리는 미세한 하드웨어 결함을 안고 있었고, 같은 장치가 학습 작업을 거듭 망가뜨릴 수 있었다. CPU 와 GPU 메모리는 ECC 로 보호되어 SDC 의 원인이 아니었다. 작업이 예외로 멈추면 유효한 체크포인트에서 학습 상태를 되살리고 결함 하드웨어를 격리할 때까지 할당된 GPU 가 놀았다. SDC 가 손실 급등으로 나타나면 학습은 계속 돌면서 쓸 수 없는 체크포인트를 만들었다.\n\nSDC 는 새 장비에서만 나지 않았다. 배포 전 번인 테스트에서 찾은 것은 25% 뿐이었다. 25% 는 배포 뒤 두 달 안에, 10% 는 여섯 달 안에, 40% 는 배포 뒤 1년 무렵에 나타났다. GPU 가 SDC 를 내기 시작하면 오류율은 대개 시간이 갈수록 올라갔다. 공급사 분석은 반복된 고강도 계산의 전기적 스트레스가 연산 회로의 저항 값을 서서히 바꿔 산술 오류를 낸다고 봤다. SDC 는 특정 커널과 데이터 유형과 입력 값에서만 났다. 처음 SDC 가 감지된 커널은 GEMM 과 InplaceMoE 가 각각 17.3%, FlashAttention 이 13.0% 였고, GEMM 에서는 FP64 와 FP32 CUDA 코어가 더 자주 틀렸다. 한 GPU 는 FP64 에서 결과가 100% 틀리고 계산 지연이 평소의 50배였고, 다른 GPU 는 특정 값 범위에서만 틀렸다. 결함 GPU 마다 같은 워크로드를 결정적으로 재실행했을 때 틀린 텐서가 나오는 비율은 100% 에서 0.000001% 까지 달랐다.\n\n합성 벤치마크는 결함을 일으키는 데이터 패턴과 명령 순서를 갖추지 못해 결함을 놓쳤다. ByteDance 는 장애를 낸 학습 워크로드와 입력 데이터를 그대로 재실행해 결함 GPU 를 찾는 SDCHunter 를 만들었다. SDCHunter 는 난수 시드를 고정하고 결정적 GPU 커널을 강제하며 통신 순서를 고정해, 정상 하드웨어라면 비트 단위로 같은 결과가 나오게 한다. 먼저 데이터 병렬 차원을 따라 클러스터를 두 복제본으로 나누고, 파이프라인 경계에서 텐서 해시를 비교해 문제 있는 묶음을 몇 시간 안에 좁힌다. 그 묶음을 빼고 학습을 다시 시작한다. 그다음 오프라인에서 의심 묶음과 정상 기준 묶음으로 문제가 난 이터레이션을 재실행해 처음 어긋나는 텐서와 커널을 찾고 결함 GPU 를 가린다. 결정적 학습을 켜도 스텝 시간은 0.01% 안에서만 달라졌고, 정규화한 디버깅 시간은 70% 줄었다. SDCHunter 는 운영에서 SDC 사고 40건을 처리했고, 결함 GPU 40개를 찾았으며, 오프라인 진단 시간을 며칠에서 1시간 안으로 줄였다."},"trigger":null,"severity":"unknown","symptoms":["training-divergence","training-job-failed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Corruptions surfaced as crashes, NaN or loss spikes in training jobs, or as failed numerical validation in offline stress tests that used online workloads; ECC, thermal and other hardware signals did not show them.","ko":"운영 학습에서 드러난 13개는 두 가지 경로로 드러났다. shape mismatch, out-of-bound access 같은 예외로 작업이 바로 멈췄거나, 학습 중 손실이 치솟아 엔지니어가 학습을 손으로 멈추며 알아챘다. 나머지 10개는 운영 워크로드로 돌린 오프라인 스트레스 테스트의 수치 검증에서 걸렸다. 하드웨어 진단 도구와 ECC, 온도 센서는 SDC 를 잡지 못했다."},"components":["gpu-hardware"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Halted the training and took the affected nodes offline to confirm the defective GPU","ko":"손실이 치솟은 사례에서는 학습을 멈추고 영향받은 노드를 오프라인으로 빼서 결함 GPU 가 있는지 확인했다."}},{"text":{"en":"Isolated the suspicious data-parallel group and resumed the training job from a checkpoint on healthy machines","ko":"SDCHunter 로 의심스러운 데이터 병렬 묶음을 먼저 떼어 내, 운영 학습 작업이 영향받은 장비를 벗어나 체크포인트에서 다시 시작하게 했다. 학습은 묶음을 뗀 뒤 1시간 안에 다시 돌았다."}},{"text":{"en":"Confirmed the defective GPU offline by replaying the alert-triggering trace and checking it with hardware tools","ko":"학습이 정상 장비에서 다시 돈 뒤, 경보를 낸 실행 기록을 오프라인에서 거듭 재실행하고 하드웨어 도구로 결과를 확인해 결함 장치를 확정했다."}},{"text":{"en":"Sent the confirmed defective GPUs to hardware repair","ko":"결함 GPU 는 1시간 안에 확정해 하드웨어 수리로 넘겼다."}},{"text":{"en":"Enabled every deterministic setting in production training, including torch.use_deterministic_algorithms, so anomalies could be replayed bit for bit","ko":"재현 가능한 학습을 위해 소프트웨어 스택의 결정성 설정을 모두 켰다. torch.backends.cudnn.benchmark 를 끄고, torch.backends.cudnn.deterministic 과 torch.use_deterministic_algorithms 를 켰다."}}],"action_items":[],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"In ByteDance's production LLM training cluster, GPUs with hardware defects silently corrupted computation without any error signal. Training jobs either crashed with errors that looked like software bugs, such as a shape mismatch or an out-of-bound access, or kept running with sudden loss spikes until engineers stopped them by hand. Of the 23 SDC-defective GPUs the paper characterises, 13 surfaced this way during active LLM training and 10 were found in offline stress tests that used online workloads and failed numerical validation checks.\n\nThe first errors engineers saw were \"Workload Test Error\", \"Suboptimal Convergence\", \"Unexpected CUDA Error\", \"Shape Error\", \"Value Error\", \"Program Crash\" and \"NaN in loss or output\". In one Megatron MoE training job, a corruption during the token count aggregation silently changed the computed buffer size; the corrupted scatter operation then raised a shape mismatch, and in another case a corrupted modulo operation led to a segmentation fault on an out-of-bound access. The code at the crash site was correct, because the corruption had happened in an earlier kernel, so the error message pointed developers at the wrong place.\n\nNothing in the hardware monitoring showed the fault. Machine check exceptions, performance counters and device status registers on the defective GPUs looked the same as on healthy ones, the ECC error count had no correlation with the corruptions, and clock frequencies and thermal limits showed no anomaly. Some defects produced large deviations, while others were sparse bit flips; one GPU produced value biases smaller than 10^-3 that later operations could absorb.\n\nEngineers first suspected the training software or numerical instability and could spend days or weeks isolating pipeline components; the hardware fault was usually found only after every software explanation had been ruled out. In one case, 10 training runs were started on the same cluster from the identical checkpoint: Runs 1 and 2 showed a sharp loss spike, Runs 3 and 4 trained normally, which made engineers suspect silent data corruption. Runs 5 and 6, and later Runs 8 and 9, spiked again at completely different steps, which pointed to a hardware fault in the floating-point units, so engineers halted the training and took the nodes offline. Synthetic stress tests and diagnostic tools such as intensive GEMM loops missed more than 60% of the defective GPUs.","ko":"운영 중인 LLM 학습 작업이 shape mismatch 나 out-of-bound access 같은 예외로 갑자기 멈추거나, 학습은 계속되는데 손실이 크게 치솟았다. 하드웨어 쪽에서는 ECC 오류도 온도 경보도 없어서, 엔지니어 눈에는 소프트웨어 버그나 수치 불안정과 똑같아 보였다.\n\nSDC 는 오류 신호 없이 데이터가 바뀌는 현상이다. ByteDance 가 SDC 를 확인한 GPU 23개 가운데 10개는 실제 워크로드로 돌린 오프라인 스트레스 테스트에서 수치 검증에 실패해 드러났고, 13개는 운영 중인 LLM 학습을 중단시키며 드러났다. 처음 감지된 오류는 Workload Test Error, Suboptimal Convergence, Unexpected CUDA Error, Shape Error, Value Error, Program Crash, 손실이나 출력의 NaN 이었다.\n\nMoE 학습의 한 사례에서는 Megatron 이 토큰 수를 모아 버퍼 크기를 정하는 단계에서 SDC 가 계산을 바꿨고, 뒤이은 scatter 연산이 잘못되어 torch.split 에서 shape mismatch 오류가 났다. 다른 사례에서는 잘못 계산된 나머지 연산이 out-of-bound 접근을 만들어 임베딩 조회에서 segmentation fault 가 났다. 오류가 난 줄의 코드는 맞았고, SDC 는 이미 앞선 커널에서 프로그램 상태를 바꿔 놓은 뒤였다.\n\n같은 클러스터에서 같은 체크포인트로 시작한 학습 10번 가운데 Run 1 과 Run 2 에서 손실이 크게 치솟았고, Run 3 과 Run 4 는 아무 문제 없이 돌았다. Run 5 와 Run 6, 그 뒤 Run 8 과 Run 9 에서 다시 손실이 치솟았는데, 앞선 실패와 전혀 다른 스텝에서였다. 코드 오류라면 대개 같은 지점에서 실패한다. 엔지니어는 무작위로 나타나는 큰 기울기 값을 보고 부동소수점 장치의 하드웨어 결함을 의심했다.\n\n엔지니어는 하드웨어 결함이 드물다고 보고 학습 프레임워크의 논리 버그나 모델 구조의 수치 불안정부터 의심했다. 파이프라인 구성 요소를 하나씩 떼어 보고 오류를 재현하는 데 며칠에서 몇 주를 썼지만 헛수고인 경우가 많았다. 하드웨어 결함은 소프트웨어 쪽 가설을 모두 배제한 뒤에야 남은 답으로 떠올랐다. 업계에서 흔히 쓰는 하드웨어 진단 도구와 GEMM 반복 같은 합성 스트레스 테스트는 결함 GPU 의 60% 이상을 놓쳤다.\n\n결함 GPU 의 실행 기록을 정상 장비와 비교해도 machine check exception, 성능 카운터, 장치 상태 레지스터에는 차이가 없었다. ECC 오류 수는 SDC 와 상관이 없었고, 클럭 주파수와 온도 한계에도 이상이 보이지 않았다."},"updated_at":"2026-11-14T12:34:06.693704Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0416","org_slug":"bytedance"}