silent data corruption(SDC)이 어려운 이유는 처음 눈에 띈 오류가 처음 틀린 연산이 아니기 때문이다. ECC가 보호하지 않는 GPU logic에서 bit 하나가 바뀌고, collective communication이 그 결과를 퍼뜨리며, 여러 층이나 iteration 뒤에서 loss가 흔들린다. 같은 증상이 software race에서도 나올 수 있다. 운영자는 서로 다른 세 질문에 답해야 한다. 실제로 수치 오류가 있었는가, 어느 장비나 구성 요소가 만들었는가, 두 실행은 어느 지점에서 처음 달라졌는가.

ByteDance와 대학 공동 연구진이 OSDI 2026의 같은 session에 낸 논문 세 편은 이 질문에 하나씩 대응한다[1][2][3]. AEGIS는 실행 중인 학습에서 이상을 감지하고 확인한다. SDCHunter는 사건을 일으킨 workload와 입력을 다시 실행해 불량 GPU를 가린다. OpGuard는 안정적인 operator 경계에서 실행을 비교하고 처음 bit 단위로 달라진 지점을 찾는다. 세 시스템은 같은 검출기의 변형이 아니라, 시간 순서가 다른 운영 chain을 이룬다.

일반 진단 시험이 범인을 놓치는 이유

SDCs in the Wild 연구는 production cluster에서 빼낸 불량 GPU 23장을 분석했다[1]. synthetic microbenchmark는 이 장비의 60% 이상을 찾아내지 못했다. 처음부터 불량인 장비만 있는 것도 아니었다. 사용 기간이 지난 뒤 오류가 생긴 사례가 있고, 특정 데이터 값이나 functional unit에서만 실패하는 장비도 많았다. 표준 ECC와 열 보호 장치는 모든 logic 경로를 덮지 않으므로 memory 검사와 일반 stress test를 통과한 GPU가 특정 모델 연산에서는 틀린 tensor를 낼 수 있다.

SDCHunter는 진단에 넣는 작업을 바꾼다. 넓은 범위의 합성 시험 대신, 장애가 발생한 학습 workload와 입력을 그대로 재현한다. 오류를 활성화한 kernel 경로, 연산 shape, 데이터 값을 보존하는 방법이다. ByteDance deployment에서 production SDC 40건을 완화했다. 일반 시험이 쓸모없다는 주장이 아니다. workload 의존적인 장애를 의심할 때 일반 시험의 정상 결과만으로 장비를 다시 투입하면 안 된다는 뜻이다.

이 방식은 실행 증거를 미리 남겨야 한다. 원래 실행을 재현하려면 작업 식별자, 입력이나 재현 가능한 seed, software version, 장비 배치가 필요하다. SDC인지 알기 전부터 training platform이 이 정보를 보관해야 한다.

SDC 운영에서 서로 다른 세 질문. a, 잘못된 연산은 collective를 통해 퍼진 뒤 loss divergence로 늦게 나타난다. b, AEGIS는 실행 중 오류가 있었는지, SDCHunter는 어느 GPU가 문제를 재현하는지, OpGuard는 두 실행이 어느 operator에서 처음 달라지는지 묻는다. c, 가벼운 감지에서 표적 재현과 operator 문맥으로 근거가 강해진다. 이 글을 위해 새로 만든 도판.

모든 연산을 두 번 하지 않고 온라인으로 찾는다

AEGIS는 첫 질문을 production 규모에서 다룬다[2]. cSensor-cVerifier 구조는 비용이 작은 이상 신호와 확정 검증을 분리한다. sensor는 모든 연산을 복제하지 않으므로 자주 실행할 수 있고, verifier는 근거가 생겼을 때만 더 많은 일을 한다. overhead를 낮추면 신호가 약해지고, 확실히 검사하면 비용이 커지는 기존 선택을 두 단계 예산으로 풀려는 설계다.

deployment 범위는 3,500만 GPU-hour다. AEGIS는 실제 SDC 사건 18건과 불량 GPU 13장을 찾았고 성능 overhead는 0.86%였다. 이 수치는 상시 검출이 가능하다는 근거다. 그러나 어느 GPU fleet에도 적용되는 SDC 발생률을 바로 계산할 수는 없다. GPU 세대, 작업 구성, fleet 사용 기간, 사건 정의, 검출 범위가 분모에 함께 있어야 한다. 하나의 production 환경을 측정한 결과이지 hardware 신뢰성 규격은 아니다.

AEGIS와 SDCHunter의 목적은 겹치지만 동작 시점이 다르다. 전자는 실행 중인 작업에서 이상 신호를 내고 검증한다. 후자는 조사할 사건이 생긴 뒤 후보 장비에서 같은 실패를 재현한다. 온라인 검출기가 결과가 틀렸다고 알려도 어느 GPU를 fleet에서 뺄지는 재현 시험이 결정할 수 있다.

나빠진 loss보다 처음 틀린 operator를 찾는다

OpGuard는 software와 hardware 원인이 섞이는 문제를 다룬다[3]. 두 실행의 loss나 gradient norm을 비교하면 작은 불일치가 퍼질 때까지 집계값에 묻힐 수 있다. 모든 instruction을 비교하기는 어렵고, 정상적인 비결정성 때문에 단순 bit 비교에는 잡음이 생긴다. OpGuard는 여러 training stack에서 의미가 안정적인 operator 경계를 찾고 tensor fingerprint를 남긴다. scheduling 순서가 조금 달라도 대응되는 연산을 맞춘다.

fingerprint가 계속 같은 가장 긴 앞부분은 정상으로 볼 수 있다. 처음 다른 경계가 debugging 기준점이 되고 operator와 실행 문맥이 함께 제공된다. 알려진 비결정성을 통제했으므로 이 지점의 bit 불일치는 훨씬 뒤에서 나타난 loss 변화보다 강한 근거가 된다.

ByteDance는 사전학습과 후속학습에 OpGuard를 배포했다. 다른 검사에서 놓친 kernel race와 SDC를 포함해 production 문제 20건 이상을 진단했고, 며칠 걸리던 debugging 시간을 수분으로 줄였다고 보고한다. 이 숫자에는 software와 hardware 문제가 함께 들어 있다. AEGIS의 18건, SDCHunter의 40건과 같은 모집단을 본 것이 아니므로 세 값을 더하면 안 된다.

세 평가가 입증하는 범위. a, AEGIS는 3,500만 GPU-hour에서 18건의 사건과 불량 GPU 13장을 0.86% overhead로 찾았다. b, 불량 장비 23장 분석에서는 일반 microbenchmark가 60% 이상을 놓쳤고 SDCHunter는 실제 작업 재현으로 production 사건 40건을 완화했다. c, OpGuard는 hardware와 software 문제 20건 이상을 진단해 며칠 걸리던 작업을 수분으로 줄였다. 사건 수의 범위와 분모는 서로 다르다. 이 글을 위해 새로 만든 도판.

하나의 신뢰성 chain, 세 종류의 근거 비용

세 시스템을 합친 구조는 비용을 단계별로 쓴다. 상시 sensor는 매 iteration에 넣을 만큼 가벼워야 한다. 확정 검증은 드물게 실행해도 된다. workload 재현은 사건 뒤 격리한 장비에서 수행할 수 있다. 정확한 기준점이 필요할 때는 재현한 두 실행의 operator 경계를 비교한다. 더 강한 근거일수록 비용을 높이거나 대상을 좁힌다.

이 chain은 ByteRobust 같은 복구 시스템의 역할도 분명하게 한다[4]. 빠른 장비 격리와 재시작은 유효 학습 시간을 되찾지만, 실제 범인보다 많은 장비를 의도적으로 뺄 수 있다. SDC 도구는 정확한 구성 요소를 격리하고 다음 작업을 보호하며 문제 kernel을 찾는 느리지만 강한 근거를 제공한다. 복구와 진단은 서로 다른 시계로 움직이고, 불필요하게 서로를 기다리게 할 필요가 없다.

어느 시스템도 발견하지 못한 SDC가 없다고 증명하지는 않는다. sensor는 선택한 invariant만 보고, 재현은 같은 trigger가 다시 발생해야 하며, bitwise alignment는 실행을 충분히 통제해야 한다. 여러 장비가 함께 틀리거나 보관한 증거가 손상되면 chain도 복잡해진다. 그래도 모든 계산을 항상 증명하라는 불가능한 요구 대신, 각 단계에서 감당할 수 있는 가장 강한 질문을 고르는 운영 방법을 제시한다.

검출기 하나로 전체 장비의 신뢰성을 말할 수 없다

세 시스템을 함께 보면 하나의 SDC 검출률이 왜 전체 장비의 신뢰성을 대표하지 못하는지 알 수 있다. AEGIS는 실행 중인 학습을 관찰하고, SDCHunter는 의심 장비에서 실제 워크로드를 재현하며, OpGuard는 두 실행을 의미가 안정적인 연산자 경계에서 비교한다. 사전 확률, 비용, 정답의 정의가 서로 다르다. 사건 수를 더하면 같은 장애를 중복 집계할 수 있고, 한 시스템은 사건을 찾고 다른 시스템은 원인을 설명한다는 역할 차이도 사라진다.

실제 운용 신뢰성 체계에는 근거가 강해지는 상태 전이가 필요하다. 가벼운 센서가 의심을 만들고, 검증기가 값 손상 가능성을 확인하며, 실제 워크로드 재실행이 특정 GPU에서 문제가 반복되는지를 시험하고, 연산자 비교가 첫 불일치를 찾는다. 마지막으로 격리와 교체가 진단을 위험 감소로 바꾼다. 각 전이마다 오탐 비용, 미탐 노출, 걸린 시간을 기록해야 한다. AEGIS의 0.86% 부하는 첫 단계의 가격이고, 이후에는 재실행 장비, 중복 실행, 격리된 장비, 엔지니어 시간을 별도로 계산해야 한다.

가장 중요한 운영 자산은 장애를 일으킨 입력 묶음일 수 있다. 일반 시험이 불량 GPU의 60% 이상을 놓쳤다는 결과는 스트레스 시험을 통과했다는 이유만으로 장비를 안심하고 되돌릴 수 없음을 뜻한다. 사건을 드러낸 정확한 워크로드와 입력을 보존하고, 수리 뒤 다시 실행하며, 새 장애가 기존 묶음 밖에서 발생했는지 추적해야 한다. 드문 값 손상 사례가 시간이 지나면서 장비 인수 시험으로 축적된다. 더 근본적인 결론은 정확성도 워크로드 조건에 달려 있다는 점이다. GPU는 절대적으로 정상이나 불량인 것이 아니라 실제로 실행한 연산자, 데이터 패턴, 수치 경로 안에서 검증된 상태다.

3,500만 GPU시간에서 관측한 사건 18건은 정확도를 평가하기 어려울 만큼 드물다. 전체 집계에서는 검출기가 좋아 보여도 피해 범위가 가장 큰 소수 사건을 놓칠 수 있다. 따라서 사건 수에는 노출 GPU시간, 영향을 받은 작업 규모, 검출 지연, 격리 전까지 손상된 작업량, 잘못된 값이 체크포인트나 모델 산출물까지 도달했는지를 붙여야 한다. 오래 발견되지 않은 한 사건의 예상 손실이 빠르게 막은 여러 사건보다 클 수 있다.

공통 원인도 고려해야 한다. 두 실행 비교는 장애와 정상적인 비결정성이 충분히 독립적일 때 강한 판정 기준이 된다. 같은 컴파일러 결함, 결정적인 커널 오류, 손상된 입력은 양쪽이 같은 틀린 답에 합의하게 만들 수 있다. 비트 단위 정렬은 차이를 찾지만 두 실행이 같은 원인을 공유할 때 절대적인 정답을 증명하지는 않는다. 일부 검증 경로에는 다양성을 두고, 소프트웨어와 데이터의 출처 이력을 남기며, 전체 장비 변경 뒤 어떤 고비용 검사를 실행할지 정해야 한다. 세 논문은 ECC가 모든 문제를 알려 주길 기다리는 방식에서 계산을 신뢰할 근거를 직접 관리하는 방식으로 신뢰성 관리를 옮긴다.

출처와 저작권 안내

이 글은 Silicon & Systems가 ByteDance의 OSDI 2026 운영 논문 세 편을 종합해 독자적으로 작성했다. 논문의 주장과 결과를 우리 표현으로 다시 썼으며 원문 문장, 표, 도판은 옮기지 않았다. 본문의 두 도판은 이 글을 위해 새로 만들었다. USENIX 발표 페이지에서 SDCs in the Wild, AEGIS, OpGuard 원문을 볼 수 있다. 저작권 (c) 2026 각 논문의 원저자.