프런티어 모델의 사전학습은 수만 장의 GPU가 몇 달 동안 대체로 멈추지 않을 것이라는 데 거는 내기인데, 하드웨어는 몇 시간마다 반대표를 던진다. 메타의 Llama 3 학습에서는 H100 16,000장에서 평균 2.78시간에 한 번꼴로 하드웨어 장애가 났고[3], 표준 대응(중단, 로그 분석, 스트레스 테스트, 재스케줄링, 원격 스토리지에서 수 테라바이트 체크포인트 재적재)은 사건당 몇 시간씩을 태운다. ByteDance Seed와 홍콩대의 SOSP 2025 논문은 바이트댄스의 프로덕션 LLM 학습을 1년 넘게 떠받쳐 온 관리 계층 ByteRobust를 공개하고[1], 결과를 이 분야의 화폐 단위로 제시한다. 유효 학습 시간 비율(ETTR), 즉 벽시계 시간 중 실제로 학습이 전진한 비율이다. Hopper GPU 9,600장에서 석 달을 돈 사전학습 작업에서 ByteRobust는 누적 ETTR을 97%로 유지했고, 한 번의 비생산 구간이 50분을 넘긴 적이 없다.
아래는 논문의 논지를 우리 표현으로 재구성한 것이다. 이 논문의 흥미는 개별 메커니즘보다 직관의 반전에 있다. 이 규모에서는 정확히 무엇이 고장 났는지 알아내는 일 자체가 사치이고, 시스템은 그것을 몰라도 되도록 설계되어 있다.
장부: 실제로 무엇이 고장 나는가
논문은 대부분의 운영자가 감춰 두는 통계 조사로 시작한다. 프로덕션 플랫폼의 석 달, 778,135개 학습 작업에서 ByteRobust는 명시적 장애 38,236건과 암묵적 장애 5,948건을 분류했다. 전자는 읽을 수 있는 에러 메시지나 종료 코드가 남는 사건이고, 후자는 작업이 전진을 멈추거나 손실 곡선이 이상해지는 것으로만 자신을 드러내는 사건이다. 명시적 장애에서는 CUDA 에러가 36.1%로 압도적이고 CPU 과부하 11.0%, 호스트 메모리 고갈 10.1%가 뒤를 잇는다. 암묵적 장애에서는 작업 멈춤(hang)이 전체 사건의 9.9%로 선두다. 세 번째 범주가 이 워크로드의 정체를 드러낸다. 전체 사건의 17.3%는 의도적 재시작, 즉 엔지니어가 데이터 배합을 바꾸거나 융합 커널을 넣거나 병렬화 구성을 조정하려고 돌아가는 작업을 일부러 세운 것이다. LLM 사전학습은 실험 장치를 비행 중에 뜯어고치는 과학 실험처럼 굴러가고, 워크로드를 고정된 코드로 가정하는 신뢰성 설계는 시작하기도 전에 중단의 6분의 1을 놓치고 들어간다.
이 조사는 사건 발생 시점의 근본 원인 분석이 왜 함정인지도 보여 준다. 같은 증상이 서로 무관한 원인들로 갈라진다. 한 달치 대형 작업 사건 중 불법 메모리 접근은 사용자 코드에서 41번, 인프라에서 21번 나왔으니, 코드 롤백도 장비 교체도 안전한 반사 행동이 못 된다. 암묵적 장애는 더 나쁘다. 멈춘 집합 통신은 NCCL 타임아웃이 울리는 30~60분 뒤까지 아무 로그도 남기지 않고[2], MFU 하락은 장비별 지표 전부를 나란히 끌어내리며, 조용한 데이터 손상(SDC)[7]은 집합 통신을 타고 번져서 GPU 한 장이 계산한 틀린 숫자가 전역 그래디언트를 오염시키고 눈에 보이는 NaN은 발원지에서 멀리 떨어진 곳에 나타난다. 구체적으로 저자들은 나중에 확정한 SDC 장비들에 대해 NVIDIA의 현장 진단 도구가 재현율 70%에 그쳤다고 보고한다. 가장 좋은 도구조차 범인의 3분의 1 가까이를 놓친다는 뜻이다.
축출을 선호하는 격상 사다리
ByteRobust가 내세우는 철학은 정밀한 위치 특정보다 빠른 격리다. 희소 자원은 GPU 시간이므로, 증거를 기다리며 클러스터를 놀리느니 의심만으로 장비를 쫓아내는 쪽을 택한다. 아키텍처는 제어 평면(탐지와 복구를 지휘하는 컨트롤러, 런타임 증거를 다루는 분석기)과 파드마다 상주하는 데이터 평면(감시·진단·트레이스 수집·체크포인트 에이전트)으로 나뉘고, 사건은 격상 사다리를 오르는데 값싼 아래 칸들이 거의 전부를 처리한다.
맨 아래 칸은 실시간 점검이다. 가벼운 검사 스레드가 GPU에 아무 부하도 주지 않으면서 네트워크, GPU, 호스트 상태를 초 단위 간격으로 살피는데, 숫자가 이 배관 공사를 정당화한다. 로그를 지켜보는 시스템이라면 약 10분짜리 분산 타임아웃을 기다려야 할 NIC 고장을 30초에, GPU 드라이버 멈춤을 10초에 잡고, OS 커널 오류는 2초 만에 드러난다. 확신도가 높은 신호(사라진 GPU, 죽은 디스크)는 추가 진단 없이 즉시 축출로 이어진다. 뚜렷한 범인 없이 학습이 멈추면 둘째 칸이 정지 시점 진단을 돌린다. GPU 자체 검사, 장비 내 all-to-all, 장비 간 all-gather로 이어지는 고정 절차가 장비 하나를 지목하거나 하드웨어의 혐의를 벗긴다. 전부 통과하면 셋째 칸은 그냥 제자리에서 재시작한다. 일시적 링크 펄럭임에는 수사가 아니라 어깨 한 번 으쓱하는 게 맞다는 논리다. 넷째 칸이 이 논문의 독특한 대목이다. ByteRobust는 엔지니어들의 개발 속도 자체를 장애 원인으로 취급해서, 재시작이 또 실패하면 사용자 코드를 마지막 안정 버전으로 되돌리고 다시 시도한다. “새 커널 탓인가 나쁜 장비 탓인가”라는 디버깅 세션이 자동화된 실험으로 바뀌는 것이다. 9,600장 이상 GPU를 쓴 프로덕션 작업 19개에서 이 네 칸이 각각 장애의 32.52%(축출), 22.70%(재시도), 9.20%(롤백)를 해결했고, 꼭대기 칸에는 1.23%만 남았다.
꼭대기 칸은 모든 검사를 무력화하는 경우, 즉 어떤 진단으로도 재현되지 않는 SDC 의심 사례를 맡는다. ByteRobust는 그룹 검사(group testing)로 후퇴한다. 축소판 작업을 두 번 재연하는데, 한 번은 장비를 연속 구간으로, 한 번은 일정 간격을 띄운 방식으로 묶는다. 텐서·파이프라인 병렬 크기는 고정해 통신 패턴의 재현성을 지키고 데이터 병렬 폭만 줄인다. 각 단계에서 결함을 재현한 그룹이 좌표 하나씩을 내놓고, 두 좌표의 교차점이 고장 장비를 찍는다. 장비 24대가 이진 탐색이라면 다섯 번 걸릴 것을 재연 두 번으로 끝낸다. 이렇게 할 수 있는 이유는 이 함대의 SDC 사건이 거의 항상 정확히 한 대의 장비에서 나오기 때문이다.
로그 대신 스택 트레이스를 읽는다
멈춤과 감속에 대해 ByteRobust의 분석기는 로그를 아예 건너뛰고, 모든 학습 프로세스의 파이썬·네이티브 스택 트레이스를 그 자리에서 걷어 온다. 근본 원인이 자주 숨는 데이터 로더와 체크포인트 하위 프로세스까지 포함해서다. 집계는 세 단계다. 각 파드의 프로세스 트리를 해석하고, 수집한 스택을 문자열 일치로 묶고, 다수파 묶음을 건강하다고 선언한다. 남는 것이 이상치이고, 시스템은 이상치 전부를 덮는 가장 작은 병렬 그룹(대개 파이프라인 그룹 하나)을 축출한다. 이것이 의도된 과잉 축출(over-eviction)이라는 데 유의해야 한다. 9,600장 GPU 작업에서 PP 그룹 하나는 장비 8대에 걸치는데 실제 결함은 한두 대뿐이니, 사건마다 멀쩡한 장비 6~7대를 함께 내보내는 셈이고, 저자들은 그것을 몇 분 안의 재시작을 위한 값으로 받아들인다. 감속(fail-slow) 사례에서는 집계를 10초마다 반복해 다섯 라운드 동안 가장 자주 지목된 병렬 그룹을 성능 저하범으로 확정한다. 사례 연구가 이 방식의 효용과 정직함을 같이 보여 준다. 평가 단계의 멈춤 하나가 장비 6대짜리 파이프라인으로 자동 격리되어 즉시 축출되었고, 진짜 원인(CUDA 코어가 결함인 장비 2대)은 어느 작업도 기다릴 필요가 없는 백그라운드 스트레스 테스트 며칠 뒤에야 밝혀졌다.
복구도 일급 메커니즘이다
수리할 때마다 전체 재스케줄링을 치러야 한다면 탐지는 무의미하므로, 복구 쪽도 같은 수준의 공학을 받는다. 제자리 핫 업데이트는 파드를 허물지 않고 코드 변경을 적용하는데, 게으르게 한다. 급한 수정은 즉시 학습을 세우지만, 일상적 업그레이드는 기다렸다가 다음 장애로 인한 재시작에 편승한다. 어차피 몇 시간마다 중단이 온다는 냉정한 산수를 역이용하는 것이고, 24시간의 마감이 안전판으로 붙는다. 웜 스탠바이 장비는 미리 준비해 자체 점검을 마치고 저전력 대기 상태로 세워 두며, 동시 장애를 이항분포로 모형화해 99분위 수량만큼 확보한다(장비 1,024대 작업에 예비 4대면 충분하다). 체크포인트는 인메모리로, 매 스텝마다 찍는다. 샤드를 전용 CUDA 스트림에서 이중 버퍼로 호스트에 복사하고, 백업 상대는 자기 텐서·파이프라인·데이터 병렬 그룹 바깥의 장비로 고른다. 병렬 그룹 하나를 통째로 과잉 축출해도 체크포인트가 주인과 함께 사라지는 일이 없도록 하기 위해서다. 최대 16,384 GPU 작업에서 재본 결과, 핫 업데이트는 전체 재큐잉보다 11.04× 빨리 학습을 재개하고(최대 규모에서 65초 대 768초), 웜 스탠바이는 평균 재스케줄링 시간을 10.87× 줄이며 예비가 무한하다고 가정한 오라클과의 격차가 5.19%에 불과하다. 매 반복 체크포인트는 스텝당 0.01~0.04초만 학습을 세워, 체크포인트 없는 학습 대비 MFU의 99% 이상을 지킨다. Megatron-LM 기본 방식이 지키는 것은 40% 남짓이다.
배치가 보여 준 것
대표 배치 사례는 Hopper GPU 9,600장 클러스터의 프로덕션 사전학습 두 건이다. 70B급 밀집 모델을 석 달, 200B급 전문가 혼합(MoE) 모델을 한 달 학습했다. 두 작업 모두 누적 ETTR을 97% 고원에 붙들어 두었고, 1시간 슬라이딩 윈도로 보면 결이 드러난다. ETTR 하락은 각 작업의 후반부에 몰리는데, 처음 배치된 장문맥 기능이 코드 장애를 일으키고 노후해진 클러스터의 성능 저하가 잦아진 시기다. 그래도 복구가 충분히 빨라 누적 곡선은 거의 흔들리지 않았다. 종전 표준 관행인 선별적 스트레스 테스트[4][6]와의 해결 시간 비교에서는 CUDA 에러 평균 시간이 84.50% 줄었고(93초 대 518초), 사람의 코드 변경이 일으킨 장애처럼 스트레스 테스트로는 아예 위치를 짚을 수 없는 범주는 롤백 메커니즘이 1분 안팎에 처리한다. 그 사이 두 작업의 MFU는 학습 기간에 걸쳐 1.25×와 1.58× 올랐는데, 곡선의 계단 하나하나가 ETTR을 거의 잃지 않고 핫 업데이트로 배치된 최적화다. 논문의 솔직함은 자기 도구에까지 미친다. MFU 저하 사건 하나는 결국 진단 도구 자신이 원인으로 밝혀졌다. 앞선 점검 도중 GPU 주파수 잠금을 슬그머니 풀어 버린 것이다.
우리가 읽어낸 것
이 시리즈의 다른 시스템들과 나란히 읽으면 ByteRobust는 바이트댄스 학습 스택의 그림을 완성한다. HybridFlow[8]가 GPU들이 무엇을 계산할지를 조직한다면(그 논문의 제1저자가 이 논문에도 이름을 올렸다), ByteRobust는 그 GPU들이 계속 계산할 수 있는지를 결정한다. 같은 SOSP 세션에 실린 Aegaeon과의 철학적 친족 관계도 눈에 띈다. 두 논문 모두 누구나 당연시하던 단위 하나를 버려서 이득을 본다. 저쪽은 요청을, 이쪽은 근본 원인을 버렸다. 우리는 신뢰성을 처리량 문제로 다시 정의한 것이 오래 남을 기여라고 본다. 논문의 모든 메커니즘(과잉 축출, 게으른 업데이트, 그룹 경계를 넘는 백업, 그룹 검사 재연)은 값싼 자원인 예비 장비와 중복 상태를 써서 비싼 자원인 클러스터 시간을 아끼고, 진짜 진단은 아무 비용도 들지 않는 백그라운드로 밀어낸다. 97%라는 숫자는 맥락과 함께 읽어야 한다. 상비 엔지니어 부대가 뒤를 받치는 성숙한 시스템이, 스탠바이 풀의 크기를 정하는 모형에 바로 그 함대의 장애 통계를 먹여 가며 낸 성적이다. 일반화되는 것은 논문이 실전에 옮긴 회계 항등식이다. GPU 1만 장 규모에서 ETTR은 장애 빈도, 탐지 지연, 복구 비용 세 항의 곱으로 정해지고, 그중 소프트웨어의 손이 닿지 않는 것은 첫째 항뿐이다.
출처와 저작권 안내
이 글은 Silicon and Systems가 작성한 편집 요약으로, 아래에 인용한 논문의 논지를 우리 표현으로 재서술한 것이다. 원문의 문장, 도판, 표는 이 글에 재사용하지 않았으며, 이 페이지의 도판은 모두 이 요약을 위해 새로 제작했다. 논문은 SOSP 2025에서 발표되었고 Creative Commons Attribution 4.0 International 라이선스로 배포된다. 확정본은 Proceedings of the 31st ACM Symposium on Operating Systems Principles에 실려 있다. (c) 2025 the authors.