Detecting and recovering from silent data corruption on Amazon SageMaker HyperPod

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker HyperPod에서 조용한 데이터 손상(SDC)을 탐지하려면 PyTorch DDP 학습 코드에 비유한 그래디언트 검사, 링 재실행 감사, 가중치 지문 비교를 결합하고, 의심 노드를 격리·검토·교체한 뒤 손상 의심 구간 이전 체크포인트에서 복구해야 한다.

📌 핵심 요약

• SDC는 GPU 같은 하드웨어가 오류 신호 없이 그럴듯한 오답을 반환하는 현상으로, 분산 학습의 모든 복제본에 잘못된 그래디언트와 가중치를 전파할 수 있다. Meta는 최대 16K H100 GPU를 사용한 Llama 3 405B 사전학습의 54일 동안 발생한 예기치 않은 작업 중단 419건 중 6건을 SDC로 분류했으며, 이는 중단되고 원인까지 확인된 사례만 집계한 수치다.
• 비유한 그래디언트 검사는 all-reduce 전후의 NaN·Inf와 오버플로를 탐지한다. 링 재실행 감사는 다른 노드의 마이크로배치를 재계산해 손실의 비트 일치와 결정론적 커널에서의 그래디언트 지문을 비교함으로써, 감사 단계에서 드러나는 유한한 계산 오류를 탐지한다.
• 가중치 지문 비교는 optimizer.step() 이후 매 N단계와 모든 체크포인트 저장 전에 수행하며, 엄격한 과반과 다른 복제본을 찾아 옵티마이저 갱신이나 저장된 가중치의 손상을 탐지한다. 모든 복제본에 동일하게 전파된 계산 오류와 샤딩된 가중치에는 이 비교를 그대로 적용할 수 없다.
• 제안된 구성은 Amazon EKS 기반 SageMaker HyperPod의 최소 3개 GPU 노드, 각 복제본이 자체 옵티마이저 갱신을 수행하는 PyTorch DDP, 특정 단계·순위의 마이크로배치를 재구성할 수 있는 데이터 파이프라인을 요구한다. 검사는 4개 ml.p5.48xlarge 인스턴스의 NVIDIA H100 GPU 32개에서 소프트웨어로 주입한 오류로 시험했고, 각 시험을 3개 인스턴스 구성에서도 반복했다.
• 경보 이후에는 의심 순위를 노드에 연결하고 작업 중단·노드 cordon·GPU 지표 확인을 거쳐, 모호한 경보를 확인하고 검토 후 노드를 교체한다. 정상적인 DCGM 지표나 심층 상태 검사만으로 SDC 가능성을 배제할 수 없으며, 교체 시 로컬 볼륨이 사라지므로 Amazon FSx for Lustre 또는 Amazon S3에 저장한 손상 의심 구간 이전 체크포인트에서 재개해야 한다.

🧩 주요 포인트

1. 오류가 생긴 위치 → all-reduce 이전 계산, 옵티마이저 갱신, 저장된 가중치를 서로 다른 검사로 다뤄야 탐지 공백을 줄일 수 있다.
2. 복제본 간 재현성과 비교 가능성 → 최소 3개 GPU 노드와 마이크로배치 재구성이 오류 위치 판별의 전제이며, 그래디언트 지문 비교에는 결정론적 커널이 필요하다.
3. 학습 코드의 탐지와 HyperPod의 복구 연결 → 하드웨어 지표는 보조 근거로 사용하고, 노드 교체와 손상 의심 구간 이전 체크포인트 복구까지 이어져야 한다.

🧠 상세 정리

1. 오류 신호 없이 학습 전체로 퍼지는 SDC

조용한 데이터 손상(SDC)은 GPU 같은 하드웨어가 틀렸지만 그럴듯한 숫자를 반환하면서도 오류를 보고하지 않는 현상이다. 분산 학습에서는 이 숫자가 그래디언트와 가중치에 섞여 모든 복제본으로 퍼질 수 있고, 손실 값은 몇 시간 동안 정상처럼 보여 예상 밖의 발산이나 모델 성능 저하를 발견했을 때는 이미 연산 자원이 소모된 뒤일 수 있다. 원문은 최대 16K H100 GPU를 사용한 Llama 3 405B 사전학습의 54일 동안 Meta가 예기치 않은 작업 중단 419건 중 6건을 SDC로 분류했다는 사례를 제시한다. 이 수치는 작업을 실제로 중단시켰고 원인이 SDC로 추적된 사례만 포함하므로, 전체 SDC 발생 건수로 해석할 수 없다. SageMaker HyperPod는 오류를 보고하는 노드를 감시하고 교체하는 기능을 이미 제공하지만, 하드웨어가 아무것도 보고하지 않는 SDC를 찾으려면 학습 작업 자체에서 계산 결과를 검사해야 한다.

2. 계산 경로의 결함을 기존 무결성 검사가 놓치는 이유

원문은 SDC의 원인으로 제조사 선별 검사를 통과한 한계 상태의 트랜지스터와 특정 연산 장치의 실리콘 노화를 들며, 특히 모델 학습에서 집중적으로 사용하는 텐서 코어의 곱셈·누산 경로를 지목한다. 이런 회로는 대부분 정상적으로 동작하다가 고온, 전압 강하, 특정 피연산자 패턴 같은 조건에서만 잘못된 결과를 낼 수 있고, 산술 논리 경로에는 메모리와 같은 ECC나 패리티 보호가 없어 오류가 표시되지 않는다. ECC는 메모리 비트 오류를 보호하고 Xid는 GPU가 감지한 결함을 보고하지만, 이들은 오류 신호 없이 수행된 잘못된 산술을 직접 검증하지 않는다. DCGM 심층 상태 검사는 유휴 노드에서 자체 패턴을 실행하므로 실제 학습의 피연산자·열 상태·타이밍이 필요한 결함을 놓칠 수 있다. NVLink·PCIe·EFA 체크섬은 전송된 바이트의 일치를, 체크포인트 체크섬은 저장 왕복의 무결성을 확인할 뿐이므로, 이미 잘못 계산된 값이 일관되게 전달되거나 저장되면 정상으로 통과한다.

3. 탐지에서 노드 교체와 복구까지 이어지는 처리 흐름

제안된 처리 흐름은 탐지, 위치 식별, 확산 억제와 지표 상관 확인, 확인과 복구의 네 단계로 구성된다. 학습 코드의 세 검사가 데이터 병렬 복제본을 비교해 의심 GPU 순위를 지목하면, Amazon EKS 기반 HyperPod에서는 인스턴스 ID가 포함된 Kubernetes 노드 이름을 이용해 해당 순위를 노드와 연결한다. 이후 작업을 중단하고 노드를 cordon 처리한 뒤 HyperPod 관측성 대시보드에서 의심 GPU의 경보 전후 지표를 확인하며, 경보가 모호하면 추가 확인을 거쳐 검토 후 노드를 교체하고 손상 의심 구간 이전 체크포인트에서 재개한다. 원문이 나열한 일곱 계층 중 실제로 조용한 SDC를 탐지하는 것은 학습 코드의 세 검사이며, 위치 식별·DCGM 지표·심층 상태 검사·반복 경보 이력은 위치 파악과 판단을 보조한다. DCGM 지표가 정상이라고 노드를 정상으로 확정할 수 없고, StartClusterHealthCheck의 DCGM L4 진단도 자체 시험 패턴으로 유발되는 결함만 잡으므로 SDC 부재의 증명으로 사용할 수 없다.

4. 적용 전제와 소프트웨어 오류 주입 시험의 범위

이 구성을 적용하려면 Amazon EKS로 오케스트레이션되는 SageMaker HyperPod 클러스터에 최소 3개의 GPU 노드가 필요하다. 링 감사는 비교 결과를 판별할 때 서로 다른 세 노드를 요구하고, 가중치 비교도 서로 다른 복사본 세 개가 있어야 다른 하나를 지목할 수 있다. 학습은 각 복제본이 자체 옵티마이저 갱신을 실행하는 PyTorch DDP여야 하며, 시드 기반 샘플러처럼 특정 단계와 순위의 마이크로배치를 다시 만들 수 있는 데이터 파이프라인이 필요하다. 체크포인트는 Amazon FSx for Lustre나 Amazon S3 같은 공유 저장소에 두어야 하는데, 노드 교체 시 로컬 NVMe를 포함한 루트·보조 볼륨이 사라지기 때문이다. 지표 상관 확인에는 HyperPod 관측성 추가 기능이 필요하고, ECC·NVLink·스로틀링 카운터를 보려면 고급 DCGM 지표를 활성화하며, 운영에는 kubectl 접근과 sagemaker:StartClusterHealthCheck 및 sagemaker:BatchReplaceClusterNodes 권한이 요구된다. 원문은 4개 ml.p5.48xlarge 인스턴스의 H100 GPU 32개에서 소프트웨어로 주입한 오류로 검사를 시험하고, 필요한 최소 구성인 3개 인스턴스에서도 각 시험을 반복했다고 설명한다.

5. DDP의 동기화가 오류 탐지 위치를 결정하는 방식

DDP에서는 각 복제본이 서로 다른 배치 조각으로 학습하므로 로컬 그래디언트는 달라도, all-reduce로 평균을 구한 뒤 동일한 optimizer.step()을 수행하면 가중치는 비트 단위로 일치해야 한다. 원문의 예에서 세 복제본의 시작 가중치가 0.500이고 로컬 그래디언트가 0.20·0.40·0.30이면, 평균 0.30과 학습률 0.1을 적용한 최종 가중치는 모두 0.470이다. 두 번째 복제본이 0.40 대신 4.00을 계산하면 all-reduce가 그 오류를 모두에게 전파하므로, 잘못 갱신된 뒤에도 복제본들의 가중치는 서로 같을 수 있다. 반면 옵티마이저 갱신 중이나 갱신 후 한 복제본의 가중치만 손상되면 복제본 사이의 불일치가 나타난다. 다만 가중치의 NaN·Inf가 다음 all-reduce를 통해 전파되거나 all-reduce 내부의 잘못된 부분합이 모든 복제본에 동일하게 전달되는 경우에는 단순한 일치 비교에 한계가 있다. 따라서 계산 경로의 오류는 잘못된 그래디언트를 버릴 수 있는 옵티마이저 갱신 전에, 갱신이나 저장된 가중치의 오류는 그 이후에 검사해야 한다.

6. 갱신 전 비유한 값 검사와 링 재실행 감사

첫 번째 검사는 all-reduce 전에 로컬 그래디언트의 NaN·Inf를 확인해 순방향 또는 역방향 계산에서 값이 비정상적으로 커진 순위를 지목하고, all-reduce 후에도 축약된 그래디언트를 검사해 갱신을 막는다. 이 검사는 문제가 발생한 단계에서 비유한 값과 오버플로를 포착하지만, 유한하면서 틀린 숫자까지 일반적으로 찾아내는 방법은 아니다. 두 번째인 링 재실행 감사에서는 감사 대상으로 정한 단계에 각 GPU가 다른 노드에 있는 순위의 마이크로배치를 다시 계산하고, 손실을 비트 단위로 비교하며 결정론적 커널에서는 각 파라미터의 그래디언트 지문도 비교한다. 이는 감사 단계에서 손실이나 그래디언트를 바꾸는 유한한 계산 경로 오류를 탐지하기 위한 장치이며, 재계산할 입력을 정확히 복원할 수 있어야 의미 있는 비교가 된다. 두 검사는 모두 optimizer.step() 전에 실행되어 경보 시 해당 단계의 갱신을 중단하고, 그 뒤에 수행하는 가중치 지문 비교는 갱신 이후의 손상과 체크포인트 저장을 다룬다.

7. 로컬 그래디언트 노름의 이상치 탐지가 실패한 근거

원문은 각 순위의 로컬 그래디언트 노름이 해당 단계의 중앙값에서 중앙절대편차(MAD)의 몇 배만큼 떨어졌는지 검사하는 방식을 처음 검토했지만, 정상 변동과 유한한 오류를 구분하지 못했다고 설명한다. 근거로 4개 인스턴스의 H100 GPU 32개에서 9억 5,300만 파라미터 모델을 학습한 무오류 실행 세 번, 총 22,800단계의 모든 순위 노름을 기록했다. 서로 다른 데이터를 처리하는 정상 순위들만으로도 이상치 점수가 첫 800단계에서 224 MAD, 전체 정상 단계에서는 1,240 MAD까지 벌어졌다. 첫 800단계의 최대 점수에 1.5를 곱한 k = 336을 임계값으로 정해도 나머지 22,000개 정상 단계에서 11번의 오경보가 발생했다. 반대로 유한한 오류가 있는 순위의 점수는 활성값 하나를 10,000배로 늘린 경우에도 6.9를 넘지 않았으므로, 이 시험에서는 오경보를 줄이는 임계값이 실제 유한한 오류를 잡지 못했다.

8. 가중치 비교와 지문으로 확인할 수 있는 범위

세 번째 검사는 옵티마이저 갱신 이후 매 N단계와 모든 체크포인트 저장 전에 복제본들의 가중치 지문을 비교하고, 엄격한 과반과 다른 복제본을 찾아 옵티마이저 갱신 또는 저장된 가중치의 손상을 지목한다. 이 검사는 한 복사본의 가중치가 달라지는 경우를 다루므로, 계산 경로에서 발생해 모든 복제본에 동일하게 반영된 오류는 보지 못하며 샤딩된 가중치에도 그대로 적용되지 않는다. 링 감사와 가중치 비교에서 전체 텐서를 GPU 사이에 전송하는 비용을 피하기 위해, 원문은 텐서의 원시 비트 패턴을 일반 합과 위치 가중 합이라는 두 개의 64비트 합으로 축약하는 지문 방식을 사용한다. 제공된 본문은 텐서 원소 한 개 또는 두 개가 바뀌면 이 지문이 달라진다고 설명하지만, 그보다 넓은 오류에 대한 보장이나 추가 구현 내용까지 제시하지는 않는다. 따라서 세 검사는 서로 다른 오류 위치를 보완하는 구성으로 이해해야 하며, 제시된 구현의 범위는 PyTorch DDP이고 텐서·파이프라인·컨텍스트 병렬화에 대한 구체적 방법은 제공된 본문만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 복제본의 가중치가 서로 같다는 사실만으로 계산의 정확성을 보장할 수 없다. all-reduce가 하나의 잘못된 그래디언트를 모든 복제본에 전파하면, 일관성과 손상이 동시에 성립할 수 있다.
• SDC 탐지는 실제 학습 입력을 재현해 계산 결과를 비교하는 문제와 연결된다. 마이크로배치 재구성과 결정론적 커널은 링 감사의 비교 가능성을 뒷받침하는 조건이다.
• 정상적인 하드웨어 지표와 정상적인 손실 추이만으로 SDC를 배제할 수 없다. 학습 코드의 경보를 출발점으로 삼고, 하드웨어 진단은 보조 근거로 해석해야 한다.

✅ 액션 아이템

• PyTorch DDP 학습 단계에 비유한 그래디언트 검사, 링 재실행 감사, 가중치 지문 비교를 갱신 전후의 지정된 순서로 적용.
• 최소 3개 GPU 노드, 마이크로배치 재구성, 결정론적 커널 등 링 재실행 감사와 복제본 비교의 적용 조건 확인.
• SDC 경보 발생 시 작업 중단과 노드 cordon, 검토 후 노드 교체를 수행하고 Amazon FSx for Lustre 또는 Amazon S3의 손상 의심 구간 이전 체크포인트에서 복구.

❓ 열린 질문

• 현재 PyTorch DDP 데이터 파이프라인은 특정 단계와 순위의 마이크로배치를 정확히 재구성할 수 있는가?
• 링 재실행 감사와 매 N단계의 가중치 지문 비교는 각각 어떤 주기로 수행할 것인가?
• Amazon FSx for Lustre 또는 Amazon S3의 체크포인트 중 손상 의심 구간 이전의 복구 지점을 어떻게 판단할 것인가?