Incident Library

IL-0586 OpenAI · 2026-05-05 (게시일)ai-infranetworking

T0 스위치 트랜시버의 링크 네 개가 연달아 플래핑해 50K GPU 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다

OpenAI 와 Microsoft 는 가장 큰 학습 클러스터의 백엔드 네트워크에서 MRC 와 정적 SRv6 소스 라우팅을 쓴다. MRC 는 RoCE 의 Reliable Connection 을 확장한 RDMA 전송 프로토콜이다. MRC 는 RoCE 의 Queue Pair 인 QP 하나의 패킷을 모든 네트워크 평면의 많은 경로에 흩뿌려 보낸다. 패킷을 잃은 경로는 곧바로 쓰지 않고, 잃은 패킷만 골라 다시 보낸다. Cluster A 는 NVIDIA GB200 과 800 Gbps CX8 NIC 를 쓰고 2단 다중 평면 네트워크로 이어진 클러스터였다. NIC 하나는 200Gb/s 포트 네 개로 나뉘었고, MRC 는 QP 마다 네 포트 모두에 트래픽을 흩뿌렸다.

OpenAI 의 50K GPU 운영 사전 학습 작업 중에 T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 링크 네 개가 짧은 간격으로 연달아 플래핑했다. 이 링크들은 노드 네 대의 NIC 에 이어져 있었고 세 대가 작업에 들어 있었다. 논문은 NIC 와 T0 사이의 링크가 끊기면 NIC 가 이를 알아채고 MRC 가 끊긴 포트를 피하도록 경로를 다시 정한다고 설명했다. 링크가 끊긴 직후에는 패킷을 많이 잃는다. CX8 의 MRC 구현은 쓰고 있는 많은 QP 의 경로를 다시 정하는 데 시간이 걸려서 그동안 작업 처리량이 잠깐 떨어진다. 상대편 QP 도 SACK 패킷에 담긴 포트 상태 정보를 받아 끊긴 평면을 피한다. 이 과정은 보통 몇 초 걸린다.

동기식 작업이라 가장 느린 노드가 전체 속도를 정했고, 플래핑이 이어진 1분 동안 처리량이 약 25% 줄었다. MRC 가 잃은 패킷을 빠르게 복구했고, 플래핑이 끝나자 처리량은 곧바로 원래대로 돌아왔다. 작업은 죽지 않았고, 실패한 QP 가 없었으며, 영향을 받은 노드를 작업에서 뺄 필요도 없었다. 논문은 이런 트랜시버 오작동이 링크 하나의 플래핑보다 드물지만 가끔 일어난다고 했다.

심각도
–
영향 범위
A 50K GPU production pretraining job on Cluster A ran at about 25% lower throughput for about a minute; three nodes in the job lost links
영향 사용자
–
지역
–
감지까지
–
복구까지
1m

증상

OpenAI 의 Cluster A 에서 50K GPU 로 돌던 운영 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다. 같은 시각 T0 스위치 한 대의 광 트랜시버에 달린 링크 네 개가 짧은 간격으로 연달아 내려갔다 올라왔다.

링크 네 개는 서로 다른 노드 네 대의 NIC 에 이어져 있었고, 그중 세 대가 그 시각 학습 작업에 들어 있었다. NIC 가 링크가 내려갔다고 본 시각과 스위치가 링크가 내려갔다고 본 시각은 정확히 같지 않았다.

가장 크게 영향을 받은 노드 여덟 대에서 패킷 손실률이 올라갔다. 포트가 플래핑한 노드뿐 아니라 그 시각 그 노드들로 데이터를 보내던 노드에서도 손실이 보였다.

동기식 사전 학습은 가장 느린 노드가 전체 속도를 정하므로, 노드 세 대의 링크 문제가 작업 전체의 처리량을 끌어내렸다. 플래핑이 끝나자 처리량은 곧바로 원래 속도로 돌아왔다. 작업은 죽지 않았고, 실패한 QP 도 없었으며, 영향을 받은 노드를 작업에서 뺄 필요도 없었다.

증상 링크 플래핑처리량 저하

원인

원인 하드웨어 고장

구성 요소 NIC·케이블·스위치 포트 링크
기여 요인 –
촉발
T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 그 트랜시버의 링크 네 개가 짧은 간격으로 연달아 플래핑했다.

감지

NIC 와 T0 스위치가 각각 링크가 내려간 것을 기록했고, 두 기록의 시각은 정확히 같지 않았다. 작업 처리량 그래프와 노드별 패킷 손실률 그래프에 이 사건이 나타났다.

조치

후속 조치

–

교훈

논문은 NIC 와 T0 사이의 링크를 잃으면 성능이 떨어진다고 했다. 다만 이런 사건은 대부분 잠깐이고, 작업이 노드를 빼지 않고도 금방 원래 속도로 돌아오는 경우가 많다고 했다. NIC 와 T0 사이의 링크와 T0 스위치는 눈에 띄는 영향을 주므로 T1 스위치보다 더 조심해서 다뤄야 한다고 했다. 단일 장애 지점도 남아 있다고 했다. 800 Gb/s NIC 광 모듈을 200 Gb/s 링크 네 개로 나눠 쓰므로 NIC 쪽 트랜시버 자체가 플래핑하면 그 NIC 의 포트를 모두 잃는다. 그러면 QP 가 실패하므로 작업이 이 상황을 견디지 못한다. 논문은 다른 광 설계를 쓰면 이 문제를 아예 피할 수 있을 것이라고 했다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: NIC·케이블·스위치 포트 링크. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.