사례3건

3건 중 1~3번째

1. IL-0481 RoCEv2 학습 클러스터에서 RNIC 포트가 플랩한 뒤 GID 가 바뀌어 집합 통신이 깨지고 LLM 학습 작업에 크래시가 났다

   Infrawaves2026

   증상

   Infrawaves 가 운영하는 RoCEv2 GPU 학습 클러스터에서 RNIC 포트가 잠깐 내려갔다 다시 올라오는 플랩이 생긴 뒤 집합 통신이 무너지고 LLM 학습 작업에 크래시가 났다. RNIC 는 RDMA 를 지원하는 네트워크 카드다.

   링크 플래핑학습 작업 실패

   촉발

   장애는 RNIC 포트 플랩에서 시작됐다. 운영체제의 기본 네트워크 관리자인 NetworkManager 로 IP 주소를 설정한 서버에서는 포트가 내려간 동안 포트의 IP 주소가 잠깐 사라졌다. 원래 주소가 다시 돌아왔을 때 GID 는 하나 올라가 있었다.

   원인

   소프트웨어 결함

   구성 요소

   NIC·케이블·스위치 포트 링크InfiniBand 패브릭NCCL호스트 라우팅 규칙

   기여 요인

   기본 설정 방치

   조치

   • Infrawaves 는 Ubuntu 에서 RNIC 포트의 IP 주소를 NetworkManager 대신 Networking 서비스로 설정하도록 바꿨다. 그러자 포트가 내려가도 IP 주소가 그대로 남았고 GID 가 바뀌지 않았다.

   교훈

   네트워크 설정은 VCCL 의 신뢰성을 좌우한다. RoCEv2 환경에서는 포트가 내려가도 IP 주소를 유지하는 방법으로 IP 주소를 설정해야 GID 가 바뀌지 않는다. GID 가 올라가는 것을 막는 드라이버 패치는 가상화 네트워크에서 호환성 문제를 일으킬 위험이 있었다. 그래서 Infrawaves 는 가볍고 믿을 만한 대안으로 IP 설정 방법을 바꿨다.

   사례 보기
2. IL-0412 InfiniBand 링크 오류와 링크 flapping 으로 Meta RSC-1 의 bring-up 단계에서 백엔드 패브릭 대역폭이 최대 50~75% 줄었다

   Meta2024

   증상

   RSC-1 의 bring-up 단계에서 InfiniBand 백엔드 패브릭의 대역폭이 최대 50~75% 줄었다. InfiniBand 링크 오류, 줄여서 IB 링크 오류는 RSC-1 과 RSC-2 에서 학습 작업 실패의 큰 원인이기도 했다.

   처리량 저하링크 플래핑학습 작업 실패

   원인

   의존성 장애

   구성 요소

   InfiniBand 패브릭NIC·케이블·스위치 포트 링크

   기여 요인

   –

   감지

   5분마다 도는 노드 헬스 체크가 IB 링크 오류를 잡았다. IB 링크 오류는 높은 심각도 점검이라 걸리면 스케줄러가 바로 노드를 뺐고, 논문은 작업 실패 전후에 감지된 점검 결과로 실패 원인을 정했다.

   조치

   • 클러스터에 Adaptive Routing 을 켜서, 패킷이 혼잡한 곳과 상태가 나쁜 링크를 피하도록 해 성능을 예측할 수 있게 했다.
   • IB 링크 오류를 높은 심각도 헬스 체크에 넣어, 오류가 나면 스케줄러가 노드를 바로 빼고 그 노드에서 돌던 작업을 모두 다시 스케줄하게 했다.

   교훈

   논문은 네트워크가 고장 난 링크를 빼고 그 주변으로 경로를 돌려야 한다고 밝혔다. 이런 복원 장치가 없으면 50% 넘는 대역폭을 잃을 수 있다. 앞으로는 패브릭이 고장을 피해 토폴로지를 다시 구성하는 식으로, 불안정을 없애기보다 덜 드러나게 하는 인프라가 필요하다고 봤다. NCCL timeout 처럼 원인이 여럿일 수 있는 오류는 네트워크 문제로 성급히 판단하기 쉬우니 조심해야 한다.

   사례 보기
3. IL-0418 TPU v4 슈퍼컴퓨터에서 장비, ICI 링크, 광 회로 스위치가 고장 나 학습 작업 약 1% 가 멈추거나 느려졌다

   Google2024

   증상

   TPU v4 슈퍼컴퓨터에서 TPU 장비, 칩 사이를 잇는 ICI 링크, 광 회로 스위치 OCS 가 고장 나면 그 하드웨어를 쓰던 학습 작업이 중단되었다. 장비나 ICI 링크가 고장 난 작업은 남는 정상 큐브로 다시 스케줄되었다. 전체 학습 작업의 약 1% 가 이런 하드웨어 장애를 겪었다.

   학습 작업 실패처리량 저하

   원인

   하드웨어 고장

   구성 요소

   TPUNIC·케이블·스위치 포트 링크

   기여 요인

   –

   감지

   각 TPU 장비의 healthd 데몬이 ICI 링크, PCIe 채널, TPU ASIC 을 실시간으로 감시했다. healthd 는 심각한 증상이 보이면 Borg 에 영향받은 작업을 내보내고 다시 스케줄하라고 알렸다. Pod Manager 는 RPC 로 모든 OCS 의 하드웨어 상태를 주기적으로 조회했다. libtpunet 은 작업 동안 ICI 세션을 지켜보다가 오류, 링크 다운, 드라이버 패닉이 나면 Borg 에 알렸다. 작업마다 시작 전에 작은 표본 워크로드를 돌리는 검사와 물리 계층 지표를 기준값과 비교하는 검사로 이루어진 프리플라이트 검사도 돌렸다.

   조치

   • Borg 는 문제가 생긴 TPU 장비를 쓸 수 없다고 표시하고, 돌던 작업에 알린 뒤 내보냈으며, 문제가 풀릴 때까지 대기 작업이 그 장비에 배치되지 않게 했다.
   • 작업은 알림을 받으면 가능할 때 최신 모델 체크포인트를 썼고, 다시 스케줄된 뒤 최신 체크포인트에서 이어 갔다.
   • 장비와 ICI 장애는 작업이 남는 정상 큐브를 쓰도록 다시 구성해 자동으로 견뎠다.
   • 고장 난 OCS 때문에 차원 순서 라우팅 경로가 끊긴 링크를 지나게 되면, 패킷이 각 차원에서 최대 한 번의 wild hop 을 먼저 한 뒤 차원 순서 라우팅으로 돌아가는 wild-first routing 으로 대체 경로를 만들었다. 경로는 정수 선형 계획법으로 오프라인에서 미리 계산해 두었다.
   • 끊긴 ICI 링크는 드레인해 사용자 애플리케이션이 쓰지 않도록 자동으로 빼고 온라인으로 수리했다. TPU 계산 자원은 그대로 두어, 고장 난 ICI 를 쓰지 않는 작업은 그 장비에 계속 배치되었다.
   • 고장 난 하드웨어는 자동 진단과 필요할 때 기술자의 손을 거쳐 복구했고, 자동 QA 과정을 통과한 뒤에 자원 풀로 돌려보냈다.
   • OCS 장애의 성능 영향을 줄이려고 OCS 부품을 다른 부품보다 먼저 복구했다.
   • 신뢰성을 높이려고 OCS 부품을 전체 플릿에서 계획적으로 업그레이드했다.

   후속 조치

   • 고장이 있을 때 일반 토러스와 트위스티드 토러스 모두에서 부하가 더 고르게 나뉘도록 ICI 스위치에 무작위 라우팅 기능을 넣는다. 특히 가장 가까운 이웃과 통신하는 패턴이 대상이다.
   • 장애가 나면 핫 스탠바이 큐브를 마련하고, 영구 체크포인트를 거치지 않고 가속기 상태를 새 TPU 로 바로 옮긴다. 그러면 작업이 장애에 거의 영향받지 않고 이어진다. 이를 위해 Borg 스케줄러, libtpunet, Pathways ML 런타임을 고친다.

   교훈

   정적으로 연결된 TPU v3 같은 포드에서는 작업에 필요한 연속된 노드가 모두 동시에 정상이어야 해서, 필요한 칩이 1,024개로 늘면 작업 가용성이 급격히 떨어졌다. 큐브 단위로 다시 구성할 수 있게 하자 약 50개 큐브, TPU 3,200개까지 가용성이 약 94% 로 유지되었다. OCS 장애를 견디는 장애 허용 라우팅을 더하자 가용성이 99.98% 가 되었다. 재구성이 없을 때 호스트 1,024대가 필요한 작업이 쓸 만한 가용성을 얻으려면 호스트마다 99.9% 가용성이 필요했지만, OCS 로 재구성하면 99% 로 충분했다. 장애 허용 라우팅의 성능 영향은 all-to-all 위주 작업에서는 작고 all-reduce 위주 작업에서는 더 컸으며, 계산과 통신을 더 잘 겹치면 줄일 수 있다.

   사례 보기

원인별3