GPU 클러스터 네트워크의 모든 것

AI 데이터센터에서 GPU 성능을 제대로 쓰려면 이제 단순히 “좋은 GPU를 많이 사는 것”만으로는 부족하다.수백 개, 수천 개 GPU가 동시에 학습에 참여하는 순간 병목은 GPU 연산이 아니라 네트워크에서 터진다. 특히 대규모 학습에서는 GPU들이 서로 계속 데이터를 주고받는다. 대표적으로 NCCL의 All-Reduce 같은 collective communication이 반복되는데, 여기서 한 GPU라도 늦어지면 전체 학습 스텝이 지연된다. 그래서 AI 클러스터 네트워크의 핵심은 평균 대역폭보다 지연시간, tail latency, 무손실 전송, 경로 균등성에 있다.

1. 왜 AI 클러스터에는 특별한 네트워크가 필요한가?

전통적인 데이터센터 네트워크는 웹, DB, 스토리지, VM 트래픽처럼 다양한 north-south/east-west 트래픽을 처리하는 데 초점이 있었다. 반면 AI 학습 클러스터는 성격이 다르다. GPU 학습에서는 수많은 GPU가 짧은 시간 안에 서로 동기화해야 한다. 패킷 손실이나 혼잡이 생기면 GPU는 연산을 멈추고 기다린다. 결국 비싼 GPU가 놀게 된다. 그래서 AI 클러스터 네트워크는 다음 조건을 요구한다.

2. InfiniBand와 RoCEv2의 차이

위의 맥락에서 등장하는 대표 기술이 InfiniBand와 RoCEv2다. nfiniBand는 HPC와 AI 학습 클러스터에서 오래 쓰인 고성능 네트워크다. RDMA를 기본적으로 지원하고 낮은 지연시간과 안정적인 무손실 특성이 강점이다. 특히 NVIDIA GPU 클러스터와 함께 많이 사용된다. 장점은 성능과 예측 가능성이다. 단점은 전용 생태계 성격이 강하고, 비용과 운영 인력 측면에서 진입장벽이 있다.

반면에 RoCEv2는 RDMA over Converged Ethernet v2의 약자다. 쉽게 말하면 RDMA의 장점을 표준 Ethernet/IP 네트워크 위에서 구현하려는 방식이다. RoCEv2는 InfiniBand transport 개념을 UDP/IP 패킷 안에 실어 IP 네트워크에서 라우팅 가능하게 만든다.

장점은 이더넷(Ethernet) 기반이라 기존 네트워크 장비·운영 경험을 활용하기 좋다는 점이다. 하이퍼스케일러(hyperscaler)들이 RoCEv2를 적극적으로 쓰는 이유도 비용과 운영 유연성 때문이다. 메타 회사는 RoCE 기반 클러스터를 수천 GPU 규모로 확장해 여러 AI 학습 워크로드에 사용해 왔다고 공개한 바 있다.

다만 RoCEv2는 Ethernet 위에서 무손실에 가깝게 동작해야 하므로 PFC, ECN, DCQCN 같은 혼잡 제어 설정이 매우 중요하다. 설정이 어긋나면 성능 편차가 커지고, GPU 유틸리제이션(utilization)이 급락할 수 있다.

3. ROD: Rail-Optimized Design

ROD는 각 GPU 또는 각 NIC 경로를 서로 다른 leaf switch, 즉 서로 다른 “rail”에 분산해 연결하는 구조다.

쉽게 말하면, GPU 1은 Leaf 1, GPU 2는 Leaf 2, GPU 3은 Leaf 3…처럼 서버 안의 여러 GPU가 각각 별도 네트워크 rail을 타도록 설계하는 방식이다.

이 구조의 장점은 명확하다. 첫째, GPU 간 통신 경로가 더 균등해진다. 둘째, 특정 리프 스위치(leaf switch)에 트래픽이 몰릴 가능성이 줄어든다. 셋째, 스위치 장애가 발생해도 전체 서버가 한 번에 고립될 가능성이 낮다. 넷째, 대규모 클러스터로 확장할 때 성능 예측이 더 쉽다.

ROD는 각 GPU가 별도 리프 스위치(leaf switch)에 연결되어 레일(rail)을 형성하며, 지연시간을 줄이고 대역폭을 극대화하며 장애를 rail 단위로 격리하는 설계로 설명된다.즉, ROD는 성능, 확장성, 장애 격리를 우선하는 대규모 AI 학습 클러스터에 적합하다.

4. RUD: Rail-Unified Design

RUD는 여러 GPU 또는 여러 NIC가 동일한 leaf switch에 묶여 연결되는 방식이다. 쉽게 말하면, 한 서버 안의 여러 GPU가 같은 leaf switch로 올라가는 구조이다. 이 방식은 케이블링과 설계가 단순해진다. 스위치 수나 배선 복잡도도 줄일 수 있다. 따라서 초기 구축 비용이나 운영 단순성을 중시하는 환경에서는 매력적이다.

하지만 단점도 있다. 하나의 leaf switch에 장애가 생기면 해당 서버의 여러 GPU가 동시에 영향을 받을 수 있다. 또한 특정 leaf에 트래픽이 몰리면 ROD보다 병목이 생기기 쉽다. 공개 자료에서도 RUD는 비용과 케이블링 측면에서는 유리하지만, 성능과 장애 격리 면에서는 ROD보다 불리할 수 있다고 설명된다. 따라서 RUD는 상대적으로 작은 클러스터, 비용 민감한 환경, 또는 서버 내부 NVSwitch 성능을 적극 활용하는 구조에서 고려할 수 있다.

5. ROD vs RUD 비교

6. RoCEv2 환경에서는 혼잡 제어가 더 중요

InfiniBand는 무손실 네트워크 특성이 비교적 기본적으로 잘 갖춰져 있다. 반면 RoCEv2는 Ethernet 기반이기 때문에 lossless fabric을 만들기 위해 세밀한 설정이 필요하다.

RoCEv2는 잘 튜닝하면 Ethernet의 비용·운영 장점을 활용하면서도 AI 학습에 필요한 성능을 낼 수 있다. 하지만 반대로 PFC, ECN, DCQCN 설정이 어긋나면 병목, pause storm, head-of-line blocking 같은 문제가 생길 수 있다. 그래서 RoCEv2는 “싸고 쉬운 InfiniBand 대체재”라기보다 정교한 운영 역량이 필요한 Ethernet AI fabric에 가깝다.

7. AI 클러스터 네트워크 설계의 실제 판단 기준

GPU 클러스터 네트워크를 설계할 때는 단순히 “InfiniBand냐 RoCE냐”만 보면 안 된다. 다음 질문으로 검증해서 판단 해봐야 한다.

• 클러스터 규모가 몇 GPU인가?
• 주 워크로드가 사전 훈련(pre-training)인가, 미세 조정(fine-tuning)인가, 추론(inference)인가?
• All-Reduce 비중이 얼마나 높은가?
• GPU 간 통신이 학습 시간에서 차지하는 비율은 어느 정도인가?
• 운영팀이 RoCEv2 lossless fabric을 튜닝하고 장애 분석할 역량이 있는가?
• 케이블링, leaf/spine 포트 수, 전력, 냉각까지 감당 가능한가?
• 장애 시 전체 job completion time에 미치는 비용은 얼마인가?

대규모 pre-training 클러스터라면 ROD + InfiniBand 또는 잘 설계된 RoCEv2 fabric이 필요하다. 반면 소규모 fine-tuning이나 inference 중심이면 RUD나 단순화된 Ethernet 구조도 충분할 수 있다.

8. 결론: GPU 클러스터의 진짜 병목은 네트워크 설계다

AI 인프라에서 GPU는 가장 눈에 띄는 부품이다. 하지만 실제 학습 성능을 좌우하는 것은 GPU만이 아니다. GPU들이 얼마나 빠르고 균등하게 서로 통신하느냐가 전체 클러스터 효율성(cluster efficiency)를 결정한다. ROD와 RUD는 단순한 케이블 연결 방식이 아니다. 이 둘은 성능, 장애 격리, 비용, 운영 복잡도를 어떻게 트레이드 오프할 것인가에 대한 아키텍처 선택에 달려 있다.

대규모 AI 학습 클러스터에서는 ROD가 성능과 확장성 측면에서 유리하다. RUD는 비용과 단순성 면에서 장점이 있지만, 병목과 장애 영향 범위를 더 신중히 봐야 한다. RoCEv2는 Ethernet 기반의 강력한 선택지지만, lossless fabric과 혼잡 제어 운영 역량이 성패를 가른다.