조용한 데이터 손상(silent data corruption, SDC)을 진단하기 어려운 이유는 처음 눈에 띈 오류가 처음 틀린 연산이 아니기 때문입니다. ECC가 보호하지 않는 GPU 로직에서 비트 하나가 바뀌고, 집합 통신이 그 결과를 퍼뜨리며, 여러 층이나 반복 단계 뒤에서 손실이 흔들립니다. 같은 증상이 소프트웨어 경쟁 상태에서도 나올 수 있습니다. 운영자는 서로 다른 세 질문에 답해야 합니다. 실제로 수치 오류가 있었습니까? 어느 장비나 구성 요소가 만들었습니까? 두 실행은 어느 지점에서 처음 달라졌습니까?
ByteDance와 대학 공동 연구진이 OSDI 2026의 같은 세션에 발표한 논문 세 편은 이 질문에 하나씩 대응합니다[1][2][3]. AEGIS는 실행 중인 학습에서 이상을 감지하고 확인합니다. SDCHunter는 사건을 일으킨 작업부하와 입력을 다시 실행해 불량 GPU를 가립니다. OpGuard는 안정적인 연산자 경계에서 실행을 비교하고 처음 비트 단위로 달라진 지점을 찾습니다. 세 시스템은 같은 검출기의 변형이 아니라, 시간 순서가 다른 운영 절차를 구성합니다.
일반 진단 시험이 결함 장비를 놓치는 이유
SDCs in the Wild 연구는 운영 환경 클러스터에서 빼낸 불량 GPU 23장을 분석했습니다[1]. 합성 마이크로벤치마크는 이 장비의 60% 이상을 찾아내지 못했습니다. 처음부터 불량인 장비만 있는 것도 아니었습니다. 사용 기간이 지난 뒤 오류가 생긴 사례가 있고, 특정 데이터 값이나 기능 유닛에서만 실패하는 장비도 많았습니다. 표준 ECC와 열 보호 장치는 모든 로직 경로를 덮지 않으므로 메모리 검사와 일반 스트레스 테스트를 통과한 GPU가 특정 모델 연산에서는 틀린 텐서를 낼 수 있습니다.
SDCHunter는 진단에 사용하는 작업을 바꿉니다. 넓은 범위의 합성 시험 대신, 장애가 발생한 학습 작업부하와 입력을 그대로 재현합니다. 오류를 활성화한 커널 경로, 연산 형태, 데이터 값을 보존하는 방법입니다. ByteDance 배포에서 운영 환경 SDC 40건을 완화했습니다. 일반 시험이 쓸모없다는 주장이 아닙니다. 작업부하 의존적인 장애를 의심할 때 일반 시험의 정상 결과만으로 장비를 다시 투입하면 안 된다는 뜻입니다.
이 방식은 실행 증거를 미리 남겨야 합니다. 원래 실행을 재현하려면 작업 식별자, 입력 또는 재현 가능한 난수 시드(seed), 소프트웨어 버전, 장비 배치가 필요합니다. SDC인지 알기 전부터 학습 플랫폼이 이 정보를 보관해야 합니다.
모든 연산을 두 번 하지 않고 온라인으로 찾는 방식
AEGIS는 첫 질문을 운영 환경 규모에서 다룹니다[2]. cSensor-cVerifier 구조는 비용이 작은 이상 감지와 확정 검증을 분리합니다. 센서는 모든 연산을 복제하지 않으므로 자주 실행할 수 있고, 검증기는 이상 신호가 생겼을 때만 더 많은 연산을 수행합니다. 상시 감지의 오버헤드와 확정 검사의 정확도를 두 단계로 나눈 설계입니다.
배포 범위는 3,500만 GPU 시간입니다. AEGIS는 실제 SDC 사건 18건과 불량 GPU 13장을 찾았고 성능 오버헤드는 0.86%였습니다. 이 수치는 상시 검출이 가능하다는 근거입니다. 그러나 어느 GPU 장비군에도 적용되는 SDC 발생률을 바로 계산할 수는 없습니다. GPU 세대, 작업 구성, 장비군 사용 기간, 사건 정의, 검출 범위가 분모에 함께 있어야 합니다. 하나의 운영 환경을 측정한 결과이지 하드웨어 신뢰성 규격은 아닙니다.
AEGIS와 SDCHunter의 목적은 겹치지만 동작 시점이 다릅니다. 전자는 실행 중인 작업에서 이상 신호를 내고 검증합니다. 후자는 조사할 사건이 생긴 뒤 후보 장비에서 같은 실패를 재현합니다. 온라인 검출기가 결과가 틀렸다고 알려도 어느 GPU를 장비군에서 뺄지는 재현 시험이 결정할 수 있습니다.
나빠진 손실보다 처음 틀린 연산자를 찾는 방식
OpGuard는 소프트웨어와 하드웨어 원인이 섞이는 문제를 다룹니다[3]. 두 실행의 손실이나 기울기 노름을 비교하면 작은 불일치가 퍼질 때까지 집계값에 묻힐 수 있습니다. 모든 명령을 비교하기는 어렵고, 정상적인 비결정성 때문에 단순 비트 비교에는 잡음이 생깁니다. OpGuard는 여러 학습 스택에서 의미가 안정적인 연산자 경계를 찾고 텐서 지문을 남깁니다. 스케줄링 순서가 조금 달라도 대응되는 연산을 맞춥니다.
지문이 계속 같은 가장 긴 앞부분은 정상으로 볼 수 있습니다. 처음 달라지는 경계가 디버깅 기준점이 되고 연산자와 실행 문맥이 함께 제공됩니다. 알려진 비결정성을 통제했으므로 이 지점의 비트 불일치는 훨씬 뒤에서 나타난 손실 변화보다 강한 근거가 됩니다.
ByteDance는 사전학습과 후속학습에 OpGuard를 배포했습니다. 다른 검사에서 놓친 커널 경쟁 상태와 SDC를 포함해 운영 환경 문제 20건 이상을 진단했고, 며칠 걸리던 디버깅 시간을 수분으로 줄였다고 보고합니다. 이 숫자에는 소프트웨어와 하드웨어 문제가 함께 들어 있습니다. AEGIS의 18건, SDCHunter의 40건과 같은 모집단을 본 것이 아니므로 세 값을 더하면 안 됩니다.
하나의 신뢰성 절차와 세 종류의 검증 비용
세 시스템을 합친 구조는 단계별로 다른 검증 비용을 사용합니다. 상시 센서는 매 반복 단계에 넣을 만큼 가벼워야 합니다. 확정 검증은 드물게 실행해도 됩니다. 작업부하 재현은 사건 뒤 격리한 장비에서 수행할 수 있습니다. 정확한 기준점이 필요할 때는 재현한 두 실행의 연산자 경계를 비교합니다. 더 강한 근거일수록 비용을 높이거나 대상을 좁힙니다.
이 절차는 ByteRobust 같은 복구 시스템의 역할도 분명하게 합니다[4]. 빠른 장비 격리와 재시작은 유효 학습 시간을 되찾지만, 실제 결함보다 넓은 범위의 장비를 의도적으로 제외할 수 있습니다. SDC 도구는 정확한 구성 요소를 격리하고 다음 작업을 보호하며 문제 커널을 찾는 느리지만 강한 근거를 제공합니다. 복구와 진단은 서로 다른 시간 단위로 움직이므로 불필요하게 서로를 기다리게 할 필요가 없습니다.
어느 시스템도 발견하지 못한 SDC가 없다고 증명하지는 않습니다. 센서는 선택한 불변 조건만 확인하고, 재현은 같은 원인이 다시 작동해야 하며, 비트 단위 정렬은 실행을 충분히 통제해야 합니다. 여러 장비가 함께 잘못 계산하거나 보관한 증거가 손상되면 진단 절차도 복잡해집니다. 그래도 모든 계산을 항상 검증할 수 없다는 현실에서, 각 단계가 감당할 수 있는 가장 강한 검사를 선택하는 운영 방법을 제시합니다.
검출기 하나로 전체 장비의 신뢰성을 말할 수 없는 이유
세 시스템을 함께 보면 하나의 SDC 검출률이 왜 전체 장비의 신뢰성을 대표하지 못하는지 알 수 있습니다. AEGIS는 실행 중인 학습을 관찰하고, SDCHunter는 의심 장비에서 실제 작업부하를 재현하며, OpGuard는 두 실행을 의미가 안정적인 연산자 경계에서 비교합니다. 사전 확률, 비용, 정답의 정의가 서로 다릅니다. 사건 수를 더하면 같은 장애를 중복 집계할 수 있고, 한 시스템은 사건을 찾고 다른 시스템은 원인을 설명한다는 역할 차이도 사라집니다.
실제 운용 신뢰성 체계에는 근거가 강해지는 상태 전이가 필요합니다. 가벼운 센서가 의심을 만들고, 검증기가 값 손상 가능성을 확인하며, 실제 작업부하 재실행이 특정 GPU에서 문제가 반복되는지를 시험하고, 연산자 비교가 첫 불일치를 찾습니다. 마지막으로 격리와 교체가 진단을 위험 감소로 바꿉니다. 각 전이마다 오탐 비용, 미탐 노출, 걸린 시간을 기록해야 합니다. AEGIS의 0.86% 부하는 첫 단계의 가격이고, 이후에는 재실행 장비, 중복 실행, 격리된 장비, 엔지니어 시간을 별도로 계산해야 합니다.
가장 중요한 운영 자산은 장애를 일으킨 입력 묶음일 수 있습니다. 일반 시험이 불량 GPU의 60% 이상을 놓쳤다는 결과는 스트레스 시험을 통과했다는 이유만으로 장비를 안심하고 되돌릴 수 없음을 뜻합니다. 사건을 드러낸 정확한 작업부하와 입력을 보존하고, 수리 뒤 다시 실행하며, 새 장애가 기존 묶음 밖에서 발생했는지 추적해야 합니다. 드문 값 손상 사례가 시간이 지나면서 장비 인수 시험으로 축적됩니다. 더 근본적인 결론은 정확성도 작업부하 조건에 달려 있다는 점입니다. GPU는 절대적으로 정상이나 불량인 것이 아니라 실제로 실행한 연산자, 데이터 패턴, 수치 경로 안에서 검증된 상태입니다.
3,500만 GPU시간에서 관측한 사건 18건은 정확도를 평가하기 어려울 만큼 드뭅니다. 전체 집계에서는 검출기가 좋아 보여도 피해 범위가 가장 큰 소수 사건을 놓칠 수 있습니다. 따라서 사건 수에는 노출 GPU시간, 영향을 받은 작업 규모, 검출 지연, 격리 전까지 손상된 작업량, 잘못된 값이 체크포인트나 모델 산출물까지 도달했는지를 붙여야 합니다. 오래 발견되지 않은 한 사건의 예상 손실이 빠르게 막은 여러 사건보다 클 수 있습니다.
공통 원인도 고려해야 합니다. 두 실행 비교는 장애와 정상적인 비결정성이 충분히 독립적일 때 강한 판정 기준이 됩니다. 같은 컴파일러 결함, 결정적인 커널 오류, 손상된 입력은 양쪽이 같은 틀린 답에 합의하게 만들 수 있습니다. 비트 단위 정렬은 차이를 찾지만 두 실행이 같은 원인을 공유할 때 절대적인 정답을 증명하지는 않습니다. 일부 검증 경로에는 다양성을 두고, 소프트웨어와 데이터의 출처 이력을 남기며, 전체 장비 변경 뒤 어떤 고비용 검사를 실행할지 정해야 합니다. 세 논문은 ECC가 모든 문제를 알려 주길 기다리는 방식에서 계산을 신뢰할 근거를 직접 관리하는 방식으로 신뢰성 관리를 옮깁니다.
검출 범위는 장애 종류별로 측정해야 할 이유
연산 비트 반전에서 강한 검출기도 메모리, 인터커넥트, 타이밍, 소프트웨어 오류를 놓칠 수 있습니다. 장애 종류와 위치, 활성 조건, 검출 신호, 발견 시간, 오탐률, 복구 가능성을 표로 나눠야 합니다. 매번 나타나는 주입 오류뿐 아니라 특정 온도, 전압, 명령 조합에서 간헐적으로 생기고 여러 연산자를 거친 뒤 드러나는 오류도 시험해야 합니다.
같은 장치와 커널에서 복제한 두 실행은 같은 잘못된 값을 낼 수 있습니다. 가능한 범위에서 장치나 구현을 다르게 하고, 비용 때문에 완전한 다양성을 만들 수 없으면 오프라인 정밀 시험과 장비군 통계로 공통 원인 장애를 보완해야 합니다.
장치를 격리하기 전에 근거를 보존해야 할 이유
빠른 축출은 작업을 보호하지만 초기화 전에 모델, 연산자, 입력 모양, 커널과 컴파일러 버전, 온도, 전력 상태, 오류 계수, 주변 장치 동작을 남겨야 합니다. 그렇지 않으면 일반 진단을 통과한 장치가 같은 활성 조건에서 다시 오류를 낼 수 있습니다.
오류가 모델 상태에 들어간 뒤라면 다른 GPU에서 다시 시작해도 손상이 남습니다. 마지막으로 신뢰한 체크포인트를 찾거나 검증을 붙여 일정 구간을 재실행해야 합니다. 옵티마이저 갱신과 체크포인트 생성에는 일반 순전파보다 강한 검사가 필요할 수 있습니다.
신뢰성 수치에 필요한 오류 예산과 분모
가속기 시간당 검출 사건, 확인한 결함, 정상 장비 오격리, 첫 손상부터 격리까지의 시간, 검출 전에 노출된 작업량을 함께 보고해야 합니다. 중복 실행, 체크섬, 추적, 격리, 재실행 비용도 피한 손상 옆에 적어야 합니다. 오탐이 많으면 안전성은 높아져도 대형 작업을 만들 수 없게 됩니다.
체크포인트 갱신과 평가에는 강한 검사를, 일반 추론에는 샘플링을 적용하고 새 하드웨어·펌웨어·커널에는 관측을 강화할 수 있습니다. 온라인 검출, 장비 격리, 첫 오차 연산 추적은 서로 다른 근거 예산입니다. 셋을 복구 경계와 함께 연결해야 설명되지 않는 품질 저하를 범위가 정해진 신뢰성 사건으로 바꿀 수 있습니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 ByteDance의 OSDI 2026 운영 논문 세 편을 종합해 독자적으로 작성했습니다. 논문의 주장과 결과를 우리 표현으로 다시 썼으며 원문 문장, 표, 도판은 옮기지 않았습니다. 본문의 두 도판은 이 글을 위해 새로 만들었습니다. USENIX 발표 페이지에서 SDCs in the Wild, AEGIS, OpGuard 원문을 볼 수 있습니다. 저작권 (c) 2026 각 논문의 원저자.