완전히 고장 난 GPU는 찾기 쉽습니다. 프로세스가 끝나고 오류가 남으므로 복구를 시작할 수 있습니다. Fail-slow 장치는 결과를 계속 내기 때문에 더 어렵습니다. 가속기 하나, CPU 경로 하나, 공유 네트워크 링크 하나가 느려지면 동기화 지점에서 다른 순위가 기다립니다. 대규모 학습 작업은 멈추지 않은 채 비효율적으로 보입니다.
GREYHOUND는 이 중간 상태를 운영 대상에 넣습니다[1]. HKUST와 Alibaba Group 연구진은 노드 4,000대 이상, 이기종 GPU 1만 장 이상의 운영 환경을 분석했습니다. 여기에는 H800 약 1,800장과 A100 약 2,600장이 포함됩니다. 연산과 통신의 속도 저하를 나누고, 규모에 따라 관측 집단이 어떻게 바뀌는지 측정한 뒤, 진단과 단계별 완화 체계를 만들었습니다.
가장 중요한 결과는 99.8%의 진단 정확도 하나가 아닙니다. 규모에 따라 달라지는 발생 양상입니다. 완료한 단일 노드 시험 392개 중 6개에서 연산 fail-slow가 나왔습니다. 완료한 4노드 시험 107개 중 42개에서는 네트워크 혼잡이 생겼습니다. 별도의 2024년 7월 기록에서는 GPU 512~1,024장을 쓴 작업 27개 중 16개가 fail-slow를 겪었고 완료 시간이 평균 34.59% 늘었습니다. 세 집단의 분모가 다르므로 하나의 보편적인 발생률로 합쳐서는 안 됩니다.
장치가 살아 있어도 전체 순위의 속도를 정할 수 있는 조건
혼합 병렬 학습은 텐서, 파이프라인, 데이터 병렬화를 함께 사용합니다. 각 차원에는 순위가 데이터를 주고받거나 다음 단계를 기다리는 지점이 있습니다. 반복은 가장 느린 의존 경로의 속도로 진행됩니다. 순위 하나가 20% 느려지면 정상 순위까지 대기하므로 전체 처리량 손실은 그 장치가 차지하는 비중보다 커질 수 있습니다.
통신 fail-slow는 더 불규칙할 수 있습니다. 혼잡한 RoCE 링크가 몇 분 동안 집단 통신을 늦추고 회복한 뒤 다시 느려질 수 있습니다. GPU 1,024장 규모에서는 여러 경로의 저하가 온도나 연산 문제와 겹칠 수 있습니다. 작업이 계속 실행되고 체크포인트도 만들면 이진 건강 검사는 장애를 찾지 못하지만, 구매한 GPU 시간에서 끝낸 작업은 크게 줄어듭니다.
이 차이는 용량 계산을 바꿉니다. Fail-slow가 발생해도 설치, 전원, 할당 GPU 수는 그대로입니다. 시간당 유효 반복 수가 줄고 전체 장치 묶음을 더 오래 점유합니다. 손실 용량은 독립적으로 진행할 수 없는 정상 장치에도 퍼집니다. 처리량이 낮아진 시간을 빼고 하드웨어 가용성만 보고하면 고객이 실제 사용할 수 있는 용량을 과대평가합니다.
서로 다른 질문에 답하는 세 평가 집단
단일 노드 연구는 시험 400개를 시작해 392개를 완료했습니다. 각 시험은 H800 네 장으로 110억 매개변수 GPT-2 구성을 1만 번 반복했으며 보통 70~90분 걸렸습니다. 전체 H800 약 1,800장 중 약 500장을 포함했습니다. 연산 fail-slow 작업은 6개였습니다. 네 개는 CPU 경합, 두 개는 GPU 성능 저하로 분류했습니다. 평균 지속 시간은 10분, 평균 작업 완료 시간 증가는 11.79%였습니다.
GPU 성능 저하 사례 하나는 약 20% 느리게 실행됐습니다. 저자들은 이런 GPU 저하를 관측 집단의 약 0.5%로 추정합니다. 온도 상승과 속도 저하가 동시에 보인다는 사실만으로 원인을 확정하지 말라고도 지적합니다. 온도는 대기 증가나 다른 시스템 조건의 결과일 수 있으므로 열 측정값만 보고 GPU 불량을 판정해서는 안 됩니다.
4노드 연구는 시험 120개를 시작해 107개를 완료했습니다. 노드마다 A100 여덟 장을 사용해 70억 매개변수 GPT-2 구성을 1만 번 반복했습니다. 400Gb/s RoCE 패브릭에서 보통 약 5시간 실행했고, A100 약 2,600장 중 690장을 포함했습니다. 네트워크 혼잡 fail-slow는 42개였고, 추가로 작업 하나에서 CPU 경합이 발생했습니다. 네트워크 사건은 평균 24분 지속됐고 완료 시간은 평균 15.45% 늘었습니다.
42/107은 약 39.3%지만 이를 장비 전체의 연간 네트워크 장애 확률이라고 부를 수는 없습니다. 공유 멀티테넌트 네트워크에 장시간 노출된 시험 작업의 결과입니다. 분모는 링크, 노드, 고객, 달력 시간이 아니라 완료한 시험 작업입니다. 비교 의미는 분명합니다. 이 환경의 표본에서는 통신 저하가 연산 저하보다 자주 나타났고 더 오래 지속됐습니다.
세 번째 집단은 한 달 동안 GPU 512~1,024장을 각각 사용한 운영 작업 27개입니다. 그중 16개가 fail-slow를 겪었습니다. 13개는 네트워크 혼잡, 세 개는 네트워크와 GPU 저하가 함께 나타났습니다. 사건의 평균 지속 시간은 72분이었고 작업 완료 시간은 평균 34.59% 늘었습니다. 작업의 20% 이상은 50% 넘게 늦어졌습니다. GPU 1,024장 사례 하나는 혼잡과 열 스로틀링이 겹쳐 처리량이 정상의 10%까지 떨어졌습니다.
규모가 커지면 장애 기회만 늘어나는 것이 아닙니다. 더 많은 공유 링크를 지나고 더 많은 전역 동기화 지점에서 기다리며 여러 저하가 겹칠 수 있습니다. 단일 노드의 1.5% 관측값을 GPU 1,024장 작업에 그대로 곱하는 모델은 상관된 네트워크 조건과 동기화 증폭을 놓칩니다.
텔레메트리는 증상을 보여도 원인을 검증하지 못하는 이유
운영 모니터링에는 GPU 이용률, 온도, CPU 부하, 네트워크 카운터, 반복 처리량이 이미 있습니다. 어려운 부분은 원인을 정하는 일입니다. 낮은 GPU 이용률은 네트워크 대기, 입력 부족, 파이프라인 빈 구간, 원래 연산이 적은 단계, 장치 저하에서 모두 나타날 수 있습니다. 바쁜 링크도 집단 통신 중에는 정상일 수 있습니다. 시각이 일치하는 두 신호만으로 인과관계를 증명할 수는 없습니다.
GREYHOUND는 학습의 의존 관계에 더 가까운 지점에서 시작합니다. LD_PRELOAD 계층이 통신 라이브러리를 바꾸지 않고 NCCL 호출을 관찰합니다. 자기상관으로 반복 주기를 추정하고, 베이지안 온라인 변화점 탐지로 성능 변화를 찾습니다. 10%를 넘는 변화가 이어지는지 확인한 뒤 상세 진단으로 들어갑니다. 논문의 환경에서는 두세 번의 반복, 5초 이내에 이 단계가 반응했습니다.
프로파일러는 통신량이 같은 그룹을 비교합니다. 같은 양을 처리해야 하는데 더 늦는 그룹이 의심 대상입니다. 능동 검증 전에 순위와 링크 범위를 좁힙니다. 연산은 FP8, FP16, FP32 GEMM으로 확인하고, 통신은 전체 패브릭을 훑지 않고 링이나 트리가 실제 사용하는 링크를 시험합니다. 논문은 검증에 필요한 순회 수가 상수이며 약 5초가 걸린다고 보고합니다.
순서가 중요합니다. 수천 순위에서 능동 벤치마크를 계속 돌리면 학습과 경쟁하며 자체 혼잡을 만들 수 있습니다. 텔레메트리만 보면 싸지만 모호합니다. GREYHOUND는 응용 단계의 시간과 그룹 비교가 작은 의심 집합을 만든 뒤에만 검증 비용을 냅니다. 넓은 증상을 운영자가 조치할 수 있는 근거로 바꾸는 구조입니다.
보고 정확도의 두 평가 계층
시험 작업 499개 가운데 498개를 올바르게 진단해 99.8% 정확도를 보고했습니다. 연산 탐지는 완료한 단일 노드 작업 392개를 모두 맞췄고 거짓 양성과 거짓 음성이 없었습니다. 통신 탐지는 4노드 작업 107개 중 106개를 맞춰 정확도 99.1%, 거짓 양성 0, 관련 양성 사례 기준 거짓 음성 2.3%였습니다.
이 값을 모든 규모에서 99.8%라고 합쳐서는 안 됩니다. GPU 512~1,024장 운영 기록은 영향 분석에 사용했으며 완전한 정답표를 가진 정확도 집단이 아닙니다. 종단 간 256-H800 시험은 fail-slow 사건 12개를 주입하고 반응과 완화를 측정합니다. 주입 시험은 정확한 발생 시각을 알 수 있지만 멀티테넌트 환경의 모든 자연 발생 연산, 통신, 펌웨어, 온도, CPU 복합 양상을 포함하지는 못합니다.
상시 추적의 평균 부담은 0.39%, 최대 1.1%입니다. 변화 탐지는 보통 5초 이내이고 프로파일링과 검증에 약 5초가 더 필요합니다. 256-GPU 시험의 평균 총 반응 시간은 10.56초입니다. 반복 길이, 검증 코드, 10% 확인 기준에 묶인 시스템 값이므로 다른 학습 환경의 고정 시간으로 사용해서는 안 됩니다.
그래도 정확도와 낮은 추적 부담, 조치할 수 있는 의심 경로를 함께 제시한 점은 운영상 의미가 있습니다. 느린 반복을 모두 맞혀도 진단에 몇 분이 걸리거나 대상 그룹을 찾지 못하면 학습 작업을 거의 회수하지 못합니다. GREYHOUND는 대응을 선택할 수 있는 진단까지 걸리는 시간을 평가합니다.
누적 손실이 커질 때만 대응 비용을 높여야 할 이유
짧은 저하마다 재시작할 필요는 없습니다. GREYHOUND는 네 대응을 둡니다. S1은 배치를 바꾸지 않고 관찰합니다. S2는 데이터 병렬 마이크로배치를 조정해 느린 워커의 일을 줄입니다. S3는 토폴로지를 바꾸고 느린 워커를 모아 혼합 병렬 구조에서 영향을 격리합니다. S4는 체크포인트 뒤 작업을 다시 시작합니다.
시스템은 누적 처리량 손실과 다음 조치의 예상 비용을 비교합니다. 짧은 사건은 이동 비용을 회수하기 전에 끝날 수 있습니다. 계속되면 재조정, 토폴로지 변경, 재시작을 차례로 정당화할 만큼 손실이 커집니다. 이 정책은 비싼 대응을 반복하지 않으면서 지속되는 저하를 무기한 허용하지 않습니다.
논문 실험에서 데이터 병렬 재조정은 저하 기준선보다 최대 1.59배 높은 처리량을 냈고, 토폴로지 조정은 최대 1.23배였습니다. 256-H800 시험은 400억 매개변수 GPT-2 구성에 텐서 병렬 8, 데이터 병렬 16, 파이프라인 단계 2를 사용합니다. 사건 12개를 주입하면 완화하지 않은 처리량은 분당 37.4회에서 18.9회로 낮아졌습니다. GREYHOUND는 분당 29.8회까지 회복해 저하 기준선보다 1.58배 높였습니다.
분당 37.4회까지 완전히 돌아오지 않았다는 점도 중요합니다. 완화는 느린 장치를 수리하거나 공유 혼잡을 없애지 않습니다. 느린 경로가 동기화된 작업 전체를 지배하는 정도를 줄입니다. 결과는 해결된 하드웨어 사건이 아니라 회복한 처리량과 남은 손실로 보고해야 합니다.
GPU 용량 계약에 필요한 성능 저하 상태
클라우드와 네오클라우드의 용량 계약은 건강 검사를 통과하면 장치를 가용으로 세기 쉽습니다. 대규모 학습에는 정상과 장애 두 상태만으로 부족합니다. GPU가 기본 진단을 통과하면서 같은 그룹보다 느릴 수 있고, 네트워크가 패킷을 전달하면서 집단 통신 완료 시간을 늘릴 수 있습니다. 고객은 전체 장치 묶음 비용을 계속 냅니다.
SLO에 처리량 저하 시간을 추가해야 합니다. 작업마다 예상 반복 또는 토큰 처리량, 관측 P50과 P5, 기준선의 일정 비율 아래에 머문 시간, 영향받은 순위, 원인 신뢰도, 적용한 완화를 기록합니다. 장비 보고에는 할당한 가속기 시간, 허용 처리량 안에 있었던 가속기 시간, 느린 동기화 의존성 때문에 기다린 정상 장치 시간을 나눠야 합니다.
토폴로지도 사건 기록에 들어가야 합니다. 데이터 병렬 그룹의 느린 GPU와 여러 파이프라인 단계가 공유한 혼잡 링크는 복구 방법이 다릅니다. 스케줄러는 텐서, 파이프라인, 데이터 병렬 매핑을 물리 노드와 네트워크 경로에 연결해야 합니다. 이 정보가 없으면 공유 패브릭이 원인인데 GPU를 교체하거나 같은 혼잡 영역으로 다시 시작할 수 있습니다.
재무 분모는 완료한 학습 작업입니다. GPU 1,024장 작업이 34.59% 길어지면 정상 장치까지 더 오래 묶이고 후속 실험이 늦으며 예약 구간을 놓칠 수 있습니다. 손실은 느린 구성 요소의 전력보다 큽니다. 공급자는 약속한 처리량보다 낮았던 전체 장치 묶음 시간의 가격이나 보상을 정해야 하고, 구매자는 일정과 체크포인트 계획에 fail-slow 여유분을 포함해야 합니다.
구현과 근거의 적용 범위
GREYHOUND의 통신 추적은 라이브러리 주입 방식이지만 완화는 Megatron-LM 플러그인으로 통합했습니다. 프레임워크와 무관한 제어 계층은 아닙니다. 다른 런타임에서 같은 효과를 얻으려면 병렬 매핑, 마이크로배치 정책, 토폴로지 변경에 접근할 수 있어야 합니다.
종단 간 완화 평가는 장애를 주입합니다. 정확한 발생 시각은 얻지만 운영에서 생기는 혼잡, 펌웨어, 온도, CPU, 복합 양상을 모두 재현하지 못합니다. 논문은 연산과 통신이 동시에 실행되어 예상 시간 신호를 감추는 특수 사례를 탐지가 다루지 못한다고도 밝힙니다.
상대 비교에는 정상 기준이 필요합니다. 통신량이 같은 모든 그룹이나 후보 링크가 함께 느려지면 정상 상대가 없어 원인을 격리하기 어렵습니다. 전체 전력 제한, 동시 스토리지 정지, 패브릭 전체 혼잡에는 독립적인 기준선이 필요합니다. 저자들은 익명화한 기록을 공개할 계획이라고 썼지만 논문 출판 시점에는 데이터셋을 제공하지 않았습니다.
이 한계를 반영해도 운영 판단은 남습니다. Fail-slow는 작은 하드웨어 건강 항목이 아닙니다. 동기화 AI 학습에서 정상 GPU 수천 장의 시간을 함께 소비하는 용량 상태입니다. 응용의 반복 시간에서 시작해 의심 토폴로지를 좁히고 검증한 뒤 조치해야 합니다. 대응은 누적 손실이 정당화하는 범위까지만 작업을 흔들어야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 독립적으로 작성한 편집 요약입니다. 원 논문의 주장과 결과를 우리 표현으로 다시 썼으며, 문장·표·도판을 옮기지 않았습니다. 물성 하드웨어 바탕은 이 글을 위해 생성하고 코드로 설명 요소를 올렸으며, 수치 도판 두 개는 보고된 값으로 다시 그렸습니다. 원문은 USENIX ATC 2025 회의록에 공개돼 있습니다. 저작권 (c) 2025 원저자. Alibaba Group은 저자 소속을 표시한 것이며 해당 기업의 보증을 뜻하지 않습니다. 전체 논문은 USENIX 논문 페이지에서 확인할 수 있습니다.