OpenAI, Microsoft 그리고 동료들이 더 나은, 더 확장 가능한 Ethernet을 구축하다

때때로 특정 시스템 아키텍처 (system architecture) 문제를 해결하기 위해서는 새로운 기술을 발명해야 할 때가 있습니다. 그리고 때로는, 문제를 조금 다르게 바라보고 이미 가지고 있는 것을 살펴본 뒤 그 부품들을 다른 방식으로 사용하기만 하면 될 때도 있습니다.

후자의 접근 방식은 OpenAI, Microsoft, Broadcom, AMD, 그리고 Nvidia의 연구원들이 네트워크 포트의 끊임없이 커지는 대역폭 (bandwidth)이, 더 높은 차수 (radix) 스위치—즉, 장치 간에 훨씬 더 많은 네트워크 링크를 갖는 것—를 가진 확장형 네트워크 (scale out networks) 및 더 적은 스위치를 가진 더 평탄한 네트워크 (flatter networks)를 갖는 것에 비해 반드시 가치 있는 것은 아니라는 점을 면밀히 검토하면서 발생한 일입니다. 스위치 수를 줄이는 것은 AI 시스템 노드들을 하나로 묶는 확장형 네트워크의 지연 시간 (latency)을 낮추고 (임의의 두 엔드포인트 사이의 네트워크 홉 (hop) 수 감소), 비용을 낮추며 (총 획득 비용 감소), 전력 소비를 낮춥니다 (총 소유 비용 (TCO)을 더욱 낮춤).

대부분의 위대한 공학적 아이디어와 마찬가지로, 일단 살펴보면 새로운 접근 방식은 직관적으로 명백하며 왜 항상 그런 방식으로 이루어지지 않았는지 의구심이 들 정도입니다. Ultra Ethernet Consortium이 2023년 7월에 Ethernet을 100만 개 이상의 엔드포인트로 확장하고 AI 클러스터를 위한 InfiniBand 저지연 네트워크만큼 좋게 만드는 것을 명시적인 목적으로 설립하여 제시한 Ultra Ethernet 사양 (specification)의 많은 아이디어를 차용한, Ethernet 스위치 ASIC 위에 구축되는 새로운 네트워크 프로토콜인 다중 경로 신뢰 연결 (Multipath Reliable Connection)이 바로 그러한 경우입니다.

MRC 노력은 2년 전에 시작되었습니다. 지난주 새로운 MRC 프로토콜이 공개되었을 때 OpenAI가 많은 부분을 설명했지만, 우리는 Microsoft가 RoCE Ethernet 및 InfiniBand 네트워크 모두에 대한 광범위한 경험을 바탕으로 많은 작업을 수행했을 것이라고 강력하게 추측합니다. 여기에서 MRC에 관한 OpenAI 블로그를 읽을 수 있고, 다섯 기업이 발표한 논문을 다운로드할 수 있으며, 이 링크에서 해당 노력에 대한 Open Compute Project 사양을 확인할 수 있습니다.

본질적으로 MRC가 하는 일은 점점 더 높은 대역폭을 가진 포트(port)를 쫓는 것을 멈추고, 주어진 스위치 ASIC의 동일한 총 대역폭(aggregate bandwidth)을 사용하여 장치 간의 링크(link) 수를 늘리는 것입니다. 여러분이 무슨 생각을 하는지 알고 있습니다. 포트 수와 링크 수를 늘리는 것이 해당 링크들의 잠재적 장애(failure) 수를 늘려, 결과적으로 AI 학습 실행과 같이 절대적으로 동기화된 작업이 더 자주 중단되게 만들지 않겠느냐는 것이죠? 엔드포인트(endpoint) 간의 링크 수를 근본적으로 늘린다면 그렇지 않습니다. 결과적으로 충분한 링크와 적절한 프로토콜이 있다면, 링크 장애가 발생하더라도 이를 우회하여 복구(heal)할 수 있습니다. AI 학습 작업이 느려지기는 하겠지만, 트래픽을 재라우팅(reroute)할 수 있는 충분한 방법이 있어 네트워크가 링크 장애를 우회하여 복구될 수 있습니다. 그리고 AI 학습 작업을 중단할 필요 없이, 여러분이 편한 시간에 링크를 수리할 수 있습니다.

엔드포인트 장애(Endpoint failures) — 즉 GPU 및 XPU — 는 물론 여전히 학습 실행을 중단시킬 것입니다. 이에 대해 우리는 다음과 같이 제안합니다: 각 서버 노드에 로컬 스냅샷 체크포인트(checkpoint)를 생성하여 네트워크 스토리지나 공유 메모리 어플라이언스(shared memory appliance)로 스트리밍하고, 네트워크에 몇 개의 예비 GPU 또는 XPU를 유지한 상태에서, 실패한 연산 엔진(compute engine)을 복구한 뒤 계산을 재개하면 어떨까요? 아마 이것은 들리는 것보다 더 어려울 수도 있습니다. . . . 연산 엔진의 장애를 예측하여, 엔진이 충돌하기 전에 학습 실행을 일시 중지하고, 장애가 발생한 연산 엔진을 오프라인으로 전환하며, 예비 연산 엔진에 데이터를 로드한 뒤 처리를 재개하는 대역 외(out of band) 연산 엔진 모니터(compute engine monitor)를 갖추는 것이 더 나을 수도 있습니다. 왜 굳이 충돌하게 내버려 두겠습니까?

어쨌든, 다시 MRC로 돌아가 보겠습니다. Ultra Ethernet 프로토콜이 저지연(low latency), 트래픽 셰이핑(traffic shaping), 적응형 부하 분산(adaptive load balancing) 측면에서 Ethernet을 InfiniBand와 더 유사하게 만들기 위해 백지 상태에서 시작한 완전히 새로운 프로토콜인 반면, MRC 프로토콜은 훨씬 덜 급진적인 변화이며, 사실 하이퍼스케일러(hyperscalers), 클라우드 구축업체, 슈퍼컴퓨팅 센터들이 10년 넘게 불만을 제기해 온 현재의 RDMA over Converged Ethernet (RoCE) 프로토콜의 상위 집합 확장(superset extension)입니다.

적응형 부하 분산(adaptive load balancing)은 명시적 혼잡 알림(Explicit Congestion Notification, ECN)을 기반으로 하며, Ultra Ethernet과 마찬가지로 MRC는 혼잡 문제를 해결하기 위해 패킷의 순서 변경 전달(out of order delivery), 여러 링크에 걸친 패킷 스프레이잉(packet spraying), 선택적 재전송(selective retransmission), 그리고 패킷 트리밍(packet trimming)을 지원합니다.

패킷 트리밍 (packet trimming)은 스위치 ASIC 버퍼 오버플로 (buffer overflows)로 인해 드롭된 패킷만을 재전송하며, 전역 ECN (ECN) 메커니즘을 호출하지 않고 이를 수행한다는 점에서 깔끔합니다. (Nvidia는 Mellanox를 인수한 직후 획득한 Cumulus Linux 네트워크 운영 체제에 구현되었던 패킷 트리밍에 대해 [여기서] 잘 설명하고 있습니다.) ECN이 패킷 송신자에게 스위치나 엔드포인트 (endpoint)에 과부하를 줄 때 속도를 줄이라고 지시하는 반면, 패킷 트리밍은 헤더 (headers)를 추적하고 패킷 페이로드 (payload)를 드롭하며, 혼잡으로 인해 패킷이 드롭되었을 때 네트워크에 누락된 데이터만 재전송하도록 요청합니다. 패킷 트리밍은 스위치 ASIC 또는 네트워크 인터페이스 카드 (NIC) 내부에서의 가속 및 처리를 필요로 합니다.

새로운 MRC 프로토콜은 IPv6 세그먼트 라우팅 (segment routing)과 결합되어 사용되는데, 이는 네트워크 주변으로 패킷을 정적 (static) 방식으로 라우팅하는 데 사용되며, 아이러니하게도 프로토콜 스택 내의 동적 라우팅 (dynamic routing) 메커니즘은 꺼져 있었습니다. 엔드포인트당 8개의 링크에 걸친 적응형 부하 분산 (adaptive load balancing)과 정적 라우팅의 조합은 비교적 구현하기 쉬우며, 링크와 포트가 그렇게 부족하지 않고 어떤 엔드포인트로든 도달할 수 있는 8가지의 서로 다른 방법이 있기 때문에 적응형 라우팅 (adaptive routing)이 필요하지 않음을 의미합니다.

이는 데이터 플레인 (data plane)을 병렬화함으로써 달성되며, 이것이 MRC를 정말 강력하게 만드는 토폴로지 (topology)의 마법입니다. 이는 두 장의 사진이 말 그대로 천 마디 말의 가치가 있는 경우 중 하나이므로, 현재 51.2 Tb/sec 스위치를 사용하여 AI 클러스터를 구축하는 방식과 MRC를 사용하여 구축하는 방식을 비교하고 대조해 보겠습니다.

지난 10년 정도 동안, AI 클러스터를 구축하려면 3계층 (three-tier) 네트워크를 사용해야 했습니다. 즉, 랙 (rack) 내의 리프 스위치 (leaf switches), 이들을 연결하여 포드 (pods)를 만드는 스파인 스위치 (spine switches), 그리고 포드들을 서로 연결하는 슈퍼스파인 스위치 (superspine switches)를 사용하는 방식입니다. 이것이 각각 64개의 포트를 가진 51.2 Tb/sec 스위치의 800 Gb/sec 포트를 사용하여 전통적인 RoCE Ethernet으로 AI 슈퍼컴퓨터를 결합하는 방법입니다:

각 포드 (pod)는 64개의 GPU 또는 XPU를 보유하며, 각각 800 Gb/sec 네트워크 인터페이스를 갖추고 있습니다. 이 64개의 컴퓨팅 엔진은 32개의 Tier 0 Top of Rack (ToR) 리프 스위치 (leaf switches)로 연결되며, 이들은 다시 32개의 Tier 1 스파인 스위치 (spine switches)와 교차 결합 (cross-coupled)됩니다. 각 Tier 1 스파인 스위치는 Tier 2 슈퍼스파인 스위치 (superspine switches)로 향하는 32개의 포트와 Tier 0 리프 스위치로 향하는 32개의 포트를 가집니다. 64개의 포드를 서로 연결하는 1,024개의 Tier 2 슈퍼스파인이 존재하며, 이를 통해 총 65,536개의 GPU 또는 XPU에 대한 연결성을 제공합니다. 이 3계층 (three-tier) 네트워크에는 총 5,120개의 64포트 51.2 Tb/sec 스위치가 있으며, 이들은 단일 클로스 토폴로지 (Clos topology) 데이터 평면 (data plane)을 형성합니다.

이보다 더 많은 GPU를 사용하려면 102.4 Tb/sec 스위치를 기다리거나 네트워크에 4계층을 추가해야 합니다. 이는 비용뿐만 아니라 지연 시간 (latency)을 증가시킬 것입니다. 3계층 네트워크에서는 어떤 GPU나 XPU라도 최대 5~7번의 스위치 홉 (switch hops)만큼 떨어져 있을 수 있습니다.

이제 더 높은 레이딕스 (radix) 관점으로 전환해 보겠습니다. 800 Gb/sec 포트를 갈망하는 대신, 51.2 Tb/sec 스위치 ASIC을 분할하여 100 Gb/sec로 동작하는 512개의 포트를 지원하도록 만듭니다. 그리고 하나의 클로스 데이터 평면을 갖는 대신, 8개의 고유한 클로스 데이터 평면 (네트워크 내 임의의 두 장치 사이의 8개의 고유한 경로)을 갖습니다. 2계층 네트워크에서는 얼마나 많은 장치를 연결할 수 있을까요? 이것을 보십시오:

각 GPU 또는 XPU로 들어가는 대역폭을 동일하게 유지하면서 (하나의 평면 대신 8개의 평면에 분산), 2계층 네트워크에서 131,072개의 컴퓨팅 엔진을 하나로 묶을 수 있습니다. 놀랍지 않습니까? Ethernet MRC 클러스터의 각 포드에는 256개의 XPU가 있으며, 이들은 평면당 512개의 스위치로 구성된 Tier 0 리프 복합체 (leaf complex)로 연결되어 총 4,096개의 스위치를 형성합니다. Tier 1 스파인 계층은 평면당 256개의 스위치로 구성되어 총 2,048개의 스위치를 가집니다. 이를 모두 더하면 MRC 네트워크를 구축하는 데 6,144개의 스위치가 필요합니다. 그리고 어떤 GPU나 XPU도 다른 장치로부터 3홉 이상 떨어져 있지 않습니다.

이는 컴퓨팅 엔진당 동일한 대역폭을 유지하면서 컴퓨팅 엔진 용량을 두 배로 늘리기 위해 스위치를 20% 더 사용하는 것입니다. 이는 공정한 거래 (fair trade)로 보입니다.

MRC 논문에는 "전체 이분할 대역폭 (full-bisection bandwidth)을 위해서는 3계층 네트워크와 비교했을 때 광학 부품 (optics)은 2/3, 스위치 수는 3/5가 필요하다"라는 내용이 있습니다. 이는 위에서 언급한, 3계층 네트워크의 65,536개 컴퓨팅 엔진과 2계층 네트워크의 131,072개 컴퓨팅 엔진을 비교한 사례에 대한 것이 아닙니다. 해당 비율은 각 클러스터의 컴퓨팅 엔진 수가 동일할 때만 성립합니다.

참고로, 65,536개의 엔드포인트 (endpoint)를 가진 3계층 RoCE Ethernet 네트워크는 모든 스위치와 컴퓨팅 엔진 사이에 총 196,608개의 링크 (link)를 가지며, 2계층 설계는 무려 1,179,648개의 링크를 가집니다. 하지만 컴퓨팅 엔진이 65,536개뿐인 2계층 네트워크라면 1,048,576개의 링크를 갖게 됩니다. 랙 (rack) 내부에는 구리 DAC 케이블을 사용하고, 스파인 (spine) 및 슈퍼스파인 (superspine, 필요한 경우 해당 계층 포함)에는 광학 링크 (optical links)를 사용합니다. DAC와 광학 링크가 공짜가 아니라는 점을 고려하면, MRC 네트워크를 통해 스위치 예산을 절약하거나 스위치 예산을 20%만 더 쓰고도 규모를 두 배로 늘릴 수 있다고 하더라도, 링크 예산 (link budget)에서 큰 손실을 볼 수도 있습니다.

하지만 역설적으로, 그것은 중요하지 않을 수도 있으며 그 이유는 다음과 같습니다. 세상 그 무엇도 링크 장애로 인해 작업을 수행하지 못하는 GPU 또는 XPU 컴퓨팅 엔진보다 비싸지는 않습니다. 만약 "일반적인" Clos 스위치 아키텍처에서 링크 하나가 실패하면, 전체 AI 슈퍼컴퓨터가 멈추고 체크포인트 (checkpoint)로 돌아가 처음부터 다시 시작해야 합니다. 따라서 수만 개에서 십만 개 이상의 컴퓨팅 엔진이 그냥 가만히 앉아 있게 됩니다.

반면 MRC를 사용하면, GPU 또는 XPU로 들어가는 8개의 링크 중 하나를 잃더라도 800 Gb/sec 대역폭의 12%만을 잃게 되며, AI 학습 작업은 계속 실행됩니다. 또한 고장 난 링크를 교체하면 다시 온라인 상태가 될 수 있습니다. 스위치가 해당 링크를 활성화하여 특정 엔드포인트에 대역폭을 다시 제공하기 시작할 것입니다.

MRC 네트워크에서는 Tier 1 스위치를 재부팅하더라도 시스템이 다음과 같이 그 주변을 스스로 복구(heal)할 수 있습니다:

OpenAI는 블로그 게시물을 통해 AI 클러스터의 규모가 커진 것 외에도, “MRC의 적응형 패킷 스프레이잉 (adaptive packet spraying)은 부하 분산 (load-balancing)을 충분히 잘 수행하여 네트워크 코어에서 정체 (congestion) 현상을 거의 볼 수 없습니다. 이는 성능의 핵심인 이상치 (outliers) 제거가 중요한 동기식 학습 (synchronous training) 과정에서 흐름 (flows) 간의 처리량 (throughput) 변동을 크게 줄여줍니다. 또한 여러 작업 (jobs)이 클러스터를 공유할 때 서로의 성능에 영향을 미치지 않음을 의미합니다.”라고 밝혔습니다.

OpenAI는 텍사스주 애빌린(Abilene)에 위치한 Oracle Stargate 데이터 센터와 위스콘신주 페어워터(Fairwater)에 위치한 Microsoft Azure AI 데이터 센터의 클러스터에서 MRC를 실행했습니다. MRC 프로토콜은 Nvidia ConnectX-8 SmartNIC, AMD “Pollara” 및 “Vulcano” DPU, 그리고 Broadcom Thor Ultra SmartNIC에 구현되었습니다. SRv6 정적 라우팅 (static routing)은 Cumulus Linux와 SONiC 네트워크 운영 체제 (network operating systems)를 모두 실행하는 Nvidia Spectrum 4 및 Spectrum 5 스위치와, Broadcom Tomahawk 5 ASIC 위에서 실행되는 Linux의 EOS 변형을 기반으로 하는 Arista Networks 스위치에 구현되었습니다.