{"id":"IL-0586","org":"OpenAI","date":"2026-05-05","docs":["https://www.opencompute.org/documents/ocp-mrc-1-0-pdf"],"title":{"en":"Four NIC-to-T0 links flapped in rapid succession and cut a 50K-GPU pretraining job's throughput about 25% for a minute","ko":"T0 스위치 트랜시버의 링크 네 개가 연달아 플래핑해 50K GPU 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다"},"domain":["ai-infra","networking"],"impact":{"scope":"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","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"With MRC, failures of T0-to-T1 links and T1 switches have almost no effect on training, but NIC-to-T0 links and T0 switches still have a measurable effect and need more care. Most NIC-to-T0 link losses are transient, and a job can often recover to full speed quickly without evicting nodes.","ko":"논문은 NIC 와 T0 사이의 링크를 잃으면 성능이 떨어진다고 했다. 다만 이런 사건은 대부분 잠깐이고, 작업이 노드를 빼지 않고도 금방 원래 속도로 돌아오는 경우가 많다고 했다. NIC 와 T0 사이의 링크와 T0 스위치는 눈에 띄는 영향을 주므로 T1 스위치보다 더 조심해서 다뤄야 한다고 했다. 단일 장애 지점도 남아 있다고 했다. 800 Gb/s NIC 광 모듈을 200 Gb/s 링크 네 개로 나눠 쓰므로 NIC 쪽 트랜시버 자체가 플래핑하면 그 NIC 의 포트를 모두 잃는다. 그러면 QP 가 실패하므로 작업이 이 상황을 견디지 못한다. 논문은 다른 광 설계를 쓰면 이 문제를 아예 피할 수 있을 것이라고 했다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2605.04333","kind":"paper","archived":"https://web.archive.org/web/20261101115009/https://arxiv.org/abs/2605.04333"}],"summary":{"en":"OpenAI and Microsoft run their largest training clusters on a two-tier multi-plane Ethernet network that uses MRC, an RDMA transport that extends the RoCE Reliable Connection protocol and sprays the packets of each queue pair across many paths on all network planes, and static source routing with SRv6 instead of dynamic routing in the switches. Cluster A uses NVIDIA GB200 GPUs with 800 Gbps CX8 NICs, NVIDIA SP4 and Broadcom TH5 switches, and a 4 x 200 Gbps multi-plane topology, so each NIC has four 200 Gb/s ports and MRC spreads each queue pair over all four. When a NIC link drops, the NIC detects it, MRC moves its paths off the failed port, and a port state bitmap in SACK packets tells the remote endpoints to avoid that plane too, which typically takes a few seconds.\n\nDuring a 50K GPU production pretraining job, an optical transceiver on a T0 switch glitched and flapped all four of its links in rapid succession. Three of the four connected nodes were active in the job. Throughput fell by about 25% over the minute of flaps and recovered to full speed immediately afterwards; MRC recovered the lost packets quickly enough that the impact on the job was relatively small; the job did not crash, no queue pair failed and no node had to be removed from the job. The authors state that such transceiver glitches are rarer than single link flaps but happen occasionally, and that losing NIC-to-T0 links affects performance in a way that T0-to-T1 link failures do not.","ko":"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 마다 네 포트 모두에 트래픽을 흩뿌렸다.\n\nOpenAI 의 50K GPU 운영 사전 학습 작업 중에 T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 링크 네 개가 짧은 간격으로 연달아 플래핑했다. 이 링크들은 노드 네 대의 NIC 에 이어져 있었고 세 대가 작업에 들어 있었다. 논문은 NIC 와 T0 사이의 링크가 끊기면 NIC 가 이를 알아채고 MRC 가 끊긴 포트를 피하도록 경로를 다시 정한다고 설명했다. 링크가 끊긴 직후에는 패킷을 많이 잃는다. CX8 의 MRC 구현은 쓰고 있는 많은 QP 의 경로를 다시 정하는 데 시간이 걸려서 그동안 작업 처리량이 잠깐 떨어진다. 상대편 QP 도 SACK 패킷에 담긴 포트 상태 정보를 받아 끊긴 평면을 피한다. 이 과정은 보통 몇 초 걸린다.\n\n동기식 작업이라 가장 느린 노드가 전체 속도를 정했고, 플래핑이 이어진 1분 동안 처리량이 약 25% 줄었다. MRC 가 잃은 패킷을 빠르게 복구했고, 플래핑이 끝나자 처리량은 곧바로 원래대로 돌아왔다. 작업은 죽지 않았고, 실패한 QP 가 없었으며, 영향을 받은 노드를 작업에서 뺄 필요도 없었다. 논문은 이런 트랜시버 오작동이 링크 하나의 플래핑보다 드물지만 가끔 일어난다고 했다."},"trigger":{"en":"An optical transceiver on a T0 switch had a glitch.","ko":"T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 그 트랜시버의 링크 네 개가 짧은 간격으로 연달아 플래핑했다."},"severity":"unknown","symptoms":["link-flapping","throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":"1m"},"date_kind":"published","detection":{"en":"The NICs detected their links going down and the T0 switch recorded the same links as down; the event is shown in the job's throughput and per-node packet loss graphs.","ko":"NIC 와 T0 스위치가 각각 링크가 내려간 것을 기록했고, 두 기록의 시각은 정확히 같지 않았다. 작업 처리량 그래프와 노드별 패킷 손실률 그래프에 이 사건이 나타났다."},"components":["network-link"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"MRC recovered the packets lost during the flaps quickly, so the impact on the job stayed relatively small","ko":"MRC 가 플래핑으로 잃은 패킷을 빠르게 복구해서 작업이 받은 영향은 비교적 작았다."}}],"action_items":[],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"During a 50K GPU production pretraining job at OpenAI on Cluster A, all four links of one optical transceiver on a T0 switch flapped in rapid succession, and the job's throughput dropped by about 25% for the minute of flaps. The four links went to NICs on four different nodes, three of which were running in the job.\n\nThe NICs and the T0 switch recorded the links as down at slightly different times. Packet loss rose on the nodes whose ports flapped and on the nodes that were sending to them at that moment. When a NIC link drops, many packets are lost right after the drop, and in the CX8 implementation of MRC remapping the paths of all the queue pairs in use is not instantaneous, which shows as a dip in job throughput.\n\nBecause the job is synchronous pretraining, the slowest node sets the pace for the whole job, so a few nodes losing links slowed the whole job. Throughput returned to full speed right after the flaps ended. The job did not crash, no queue pair failed and the affected nodes did not have to be removed from the job.","ko":"OpenAI 의 Cluster A 에서 50K GPU 로 돌던 운영 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다. 같은 시각 T0 스위치 한 대의 광 트랜시버에 달린 링크 네 개가 짧은 간격으로 연달아 내려갔다 올라왔다.\n\n링크 네 개는 서로 다른 노드 네 대의 NIC 에 이어져 있었고, 그중 세 대가 그 시각 학습 작업에 들어 있었다. NIC 가 링크가 내려갔다고 본 시각과 스위치가 링크가 내려갔다고 본 시각은 정확히 같지 않았다.\n\n가장 크게 영향을 받은 노드 여덟 대에서 패킷 손실률이 올라갔다. 포트가 플래핑한 노드뿐 아니라 그 시각 그 노드들로 데이터를 보내던 노드에서도 손실이 보였다.\n\n동기식 사전 학습은 가장 느린 노드가 전체 속도를 정하므로, 노드 세 대의 링크 문제가 작업 전체의 처리량을 끌어내렸다. 플래핑이 끝나자 처리량은 곧바로 원래 속도로 돌아왔다. 작업은 죽지 않았고, 실패한 QP 도 없었으며, 영향을 받은 노드를 작업에서 뺄 필요도 없었다."},"updated_at":"2026-11-14T12:34:23.157442Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0586","org_slug":"openai"}