soobook
NETWORK

Ethernet vs RoCE vs InfiniBand

GPU 클러스터의 노드 간 fabric 선택 기준 — 셋의 차이는 속도가 아니라 패킷 손실을 다루는 방식이다

2026.07.04 16 min read

멀티노드 학습의 노드 간 fabric 후보는 Ethernet(TCP), RoCE, InfiniBand 셋이다. 셋을 가르는 것은 최고 대역폭이 아니라, 패킷 손실을 다루는 방식이다.

Intro

NVLink와 NVSwitch는 한 서버 안의 GPU 통신을 해결한다. 서버 밖으로 나가면 NIC과 RDMA가 그 역할을 이어받는다.

그런데 RDMA까지 이해하고 나면 실제 클러스터를 설계할 때 바로 다음 질문에 부딪힌다. 노드 사이를 잇는 NIC과 스위치로 무엇을 살 것인가.

후보는 셋이다. 평범한 Ethernet 위의 TCP/IP, Ethernet 위에서 RDMA를 돌리는 RoCE, 그리고 처음부터 RDMA를 위해 설계된 InfiniBand.

스펙표만 보면 셋 다 400 Gb/s를 넘는 제품이 있으니 대역폭으로는 갈리지 않는다. 갈리는 지점은 다른 곳에 있다. 패킷이 스위치에서 버려질 수 있는가, 버려지면 무슨 일이 벌어지는가.

Why Loss Matters

비교에 들어가기 전에, 왜 하필 “손실”이 기준인지부터 짚어야 한다.

TCP는 손실을 전제로 설계됐다. 패킷이 버려지면 재전송하고, 손실 자체를 혼잡 신호로 읽어 전송 속도를 조절한다. 인터넷처럼 통제할 수 없는 네트워크에서는 이 전략이 옳다.

RDMA는 반대다. RDMA의 기본 전송 모드인 RC(Reliable Connection)는 하드웨어가 순서 보장과 재전송을 처리하는데, 이 재전송이 go-back-N 방식이다. 패킷 하나가 유실되면 그 지점 이후 전송분을 통째로 다시 보낸다.

수십 GB/s로 흐르는 링크에서 go-back-N 재전송이 일어나면 유효 대역폭이 급락한다. 그래서 RDMA fabric의 암묵적 전제는 “패킷은 유실되지 않는다”이다.

 

TCP는 손실을 복구하고, RDMA는 배제한다\textbf{\text{TCP는 손실을 복구하고, RDMA는 배제한다}}

 

이 전제를 어떻게 충족하느냐가 세 기술의 정체성이다. TCP Ethernet은 충족하지 않고(손실 허용), RoCE는 Ethernet을 튜닝해서 충족하고, InfiniBand는 하드웨어 설계로 충족한다.

그리고 이 차이가 학습 성능에 직결된다. 분산 학습에서는 매 step마다 gradient all-reduce가 돈다. all-reduce는 참여한 GPU 전체가 통신을 마쳐야 다음 단계로 넘어가는 collective 연산이라, 노드 간 통신이 늦어진 만큼 GPU는 논다.

Ethernet with TCP/IP

가장 익숙한 조합부터 보자. Ethernet 위에서 TCP/IP를 쓰는 일반 네트워크다.

이 경로에서 데이터는 application buffer에서 kernel buffer로 복사되고, kernel의 TCP/IP stack이 패킷마다 헤더를 붙이고 ACK을 관리한다. CPU가 모든 패킷 처리에 개입하고, 레이턴시는 수십 μs에서 밀리초 단위까지 늘어난다.

학습 클러스터의 backend로 이 조합이 탈락하는 이유는 명확하다.

  • CPU 병목: 400 Gb/s급 트래픽의 패킷 처리를 CPU가 감당해야 한다. gradient를 주고받는 동안 CPU가 포화되고, GPU는 통신 완료를 기다린다.
  • 레이턴시: all-reduce는 step마다 반복되는 동기화 지점이라 레이턴시가 곧 GPU 유휴 시간이 된다.
  • GPUDirect RDMA 불가: GPU memory에서 NIC로 가는 직접 경로가 없어, 데이터가 host memory를 경유한다.

그렇다고 Ethernet(TCP)이 클러스터에서 사라지는 것은 아니다. 관리 트래픽, 스토리지, 인터넷으로 나가는 frontend 통신은 여전히 이 경로를 쓴다. 탈락하는 것은 GPU 간 gradient가 흐르는 backend fabric 자리다.

RoCE

RoCE(RDMA over Converged Ethernet)는 Ethernet 인프라 위에서 RDMA를 구현한다. application은 InfiniBand와 같은 RDMA Verbs API를 쓰고, NIC 하드웨어가 패킷 처리를 전담하며, 패킷은 Ethernet frame에 실려 나간다.

현재 표준은 RoCE v2다. v1은 IB 패킷을 Ethernet frame(L2)에 직접 실어 같은 L2 도메인 안에서만 통신할 수 있었다. v2는 UDP/IP(목적지 포트 4791)로 감싸 L3 라우팅이 가능하다. 지금 RoCE라고 하면 사실상 v2를 가리킨다.

TCP는 App에서 kernel TCP/IP stack을 거쳐 NIC으로 내려가지만, RoCE와 InfiniBand는 RDMA Verbs로 kernel을 우회해 각각 RoCE NIC과 HCA로 내려간다

RoCE와 InfiniBand는 application이 보는 API가 같다. NCCL도 두 fabric을 같은 IB Verbs 경로로 다룬다. 다른 것은 그 아래, 패킷이 실려 가는 네트워크다.

The Lossless Problem

여기서 RoCE의 근본 딜레마가 나온다. RDMA는 무손실을 전제하는데, Ethernet은 손실을 허용하는 네트워크다.

Ethernet 스위치는 버퍼가 차면 패킷을 버린다. 그것이 Ethernet의 정상 동작이다. 그 위에 RDMA를 올리려면 “패킷을 버리지 않는 Ethernet”, 즉 lossless Ethernet을 만들어야 한다. 이를 위한 장치가 PFC와 ECN이다.

PFC

PFC(Priority Flow Control, IEEE 802.1Qbb)는 링크 단위의 브레이크다. 수신 측 버퍼가 임계치를 넘으면 송신 측에 PAUSE frame을 보내 해당 priority class의 전송을 일시 중지시킨다.

버퍼가 넘치기 전에 멈추니 드롭은 막을 수 있다. 문제는 이 브레이크가 사후 대응이라는 점이다. 버퍼가 이미 찬 뒤에 멈추라는 신호가 나가고, 그 여파가 연쇄된다.

  • HoL blocking: PAUSE는 priority class 단위라, 혼잡을 일으킨 flow만이 아니라 같은 class의 무고한 flow까지 함께 멈춘다.
  • PAUSE 전파: 멈춘 스위치의 버퍼가 차면 그 상류로 PAUSE가 번진다. 혼잡 지점 하나가 fabric 전체의 정지로 확대될 수 있다.
  • PFC deadlock: PAUSE 의존 관계가 순환을 이루면 아무도 전송을 재개하지 못하는 교착이 온다.

ECN and DCQCN

PFC만으로는 위험하니, 그 전에 작동하는 완충 장치를 둔다. ECN(Explicit Congestion Notification)은 스위치가 혼잡 조짐이 보이는 패킷에 CE 표시를 남기는 기능이고, DCQCN은 이 표시를 이용하는 RoCE용 혼잡 제어 알고리즘이다.

동작은 이렇다. 스위치가 패킷에 CE를 마킹하면, 수신 NIC이 송신 NIC에게 CNP(Congestion Notification Packet)를 보내고, 송신 NIC이 하드웨어에서 전송률을 낮춘다. 혼잡이 풀리면 서서히 회복한다.

의도된 설계는 “DCQCN이 평소의 혼잡을 다스리고, PFC는 최후의 안전장치로만 발동”이다. 그런데 이 균형이 저절로 잡히지 않는다. ECN 마킹 임계치, PFC 발동 임계치, CNP 주기, 회복 속도 같은 파라미터를 스위치와 NIC 양쪽에서 맞춰야 하고, 트래픽 패턴이 바뀌면 다시 틀어진다.

튜닝이 어긋난 lossless Ethernet은 종종 그냥 TCP보다 느리다. RoCE의 비용은 장비가 아니라 이 운영 난이도에 있다.

이것이 이론상의 걱정이 아니라는 건, 대규모로 RoCE를 굴려본 사업자들이 실제로 겪은 일이다. Microsoft는 자사 데이터센터의 RoCE 운영 경험을 담은 논문에서 PFC로 인한 deadlock이 실제로 발생했다고 보고했다(“yes, it happened!”). Meta는 수천 GPU 규모의 RoCE 학습 클러스터 운영기에서, 400G 세대에 와서는 DCQCN 튜닝이 득보다 실이 많아 아예 꺼버리고, 혼잡 관리를 collective library의 수신자 주도 흐름 제어로 옮겼다고 밝혔다.

이 난이도가 감당 불가능하다는 뜻은 아니다. Meta가 보여주듯 대규모 RoCE 학습 클러스터는 현실이고 잘 돌아간다. 다만 그 전제는 학습 전용 backend 네트워크를 따로 두고, 스위치 버퍼부터 collective library까지 스택 전체를 함께 설계할 수 있는 조직 역량이다.

InfiniBand

InfiniBand는 접근이 정반대다. Ethernet을 고쳐 쓰는 대신, RDMA를 위한 네트워크를 처음부터 새로 설계했다. 링크 계층부터 transport까지 Ethernet과 호환되지 않는 독자 스택이고, NIC 대신 HCA(Host Channel Adapter), Ethernet 스위치 대신 IB 스위치를 쓴다.

Credit-Based Flow Control

InfiniBand가 무손실을 만드는 방식은 PFC 같은 사후 브레이크가 아니라 사전 허가다.

수신 측은 자기 버퍼의 빈 공간만큼을 credit으로 송신 측에 알려준다. 송신 측은 credit이 있을 때만 패킷을 보낸다. credit이 떨어지면 보낼 수 없고, 수신 버퍼가 비워지면 credit이 다시 채워진다.

PFC는 수신 버퍼가 찬 뒤 PAUSE로 송신을 멈추게 하고, credit은 수신이 빈 자리만큼 credit을 미리 발급해 그만큼만 송신하므로 드롭이 생기지 않는다

같은 무손실이라도 성격이 다르다. PFC는 버퍼가 찬 뒤에 “멈춰”라고 외치는 방식이라 그 신호가 fabric을 타고 번지는 부작용이 따라오지만, credit은 애초에 빈 자리가 확인된 패킷만 링크에 올라간다. 드롭을 억제하는 게 아니라 드롭이 발생할 조건 자체가 없다. 관리자가 튜닝할 파라미터도 없다. 레이턴시도 이 설계 위에서 나온다. IBTA가 공식적으로 내세우는 수치는 end-to-end 600ns다.

공정하게 말하면 InfiniBand의 무손실에도 고유한 리스크가 하나 있다. credit을 기다리는 의존 관계가 fabric 안에서 순환을 이루면 credit loop deadlock이 생길 수 있다. 다만 이는 토폴로지와 라우팅 알고리즘 설계로 예방하는 문제라, 운영 중 상시 튜닝이 필요한 PFC/ECN과는 부담의 성격이 다르다.

Subnet Manager

InfiniBand fabric에는 SM(Subnet Manager)이라는 중앙 관리자가 있다. SM은 fabric의 모든 노드와 스위치를 발견해 각 port에 LID(Local Identifier) 주소를 할당하고, 스위치의 forwarding table을 프로그래밍하고, 경로를 계산한다.

Ethernet 스위치가 MAC learning으로 각자 알아서 경로를 배우는 것과 대조적이다. IB 스위치는 스스로 아무것도 배우지 않고, SM이 내려준 테이블대로만 전달한다. 그래서 SM이 없으면 IB fabric은 아예 동작하지 않는다.

중앙 집중 관리는 단점이자 장점이다. 관리 대상이 하나 늘어난 대신, fabric 전체의 토폴로지를 아는 주체가 있어 경로 최적화와 QoS를 일관되게 걸 수 있다. 테넌트 격리도 SM의 몫인데, PKey(Partition Key)라는 VLAN 유사 파티션이 그 수단이다. 모든 IB 패킷은 16-bit PKey를 담고 다니며, 수신 측 HCA나 스위치의 PKey 테이블과 맞지 않으면 하드웨어가 폐기한다. 이 테이블을 채우는 주체가 SM이라, 노드는 자기가 어느 파티션에 속하는지 스스로 정할 수 없다.

SM이 fabric을 발견하고 세우는 과정, LID와 forwarding table, PKey partition의 동작은 InfiniBand Fabric과 Subnet Manager에서 따로 다뤘다.

클라우드에서 IB 클러스터를 임대해 쓰는 입장이라면 이 구조를 뒤집어 읽어야 한다. SM은 provider가 쥐고 있고 사용자에게 설정 권한을 열어주지 않는 경우가 많다. PKey 파티션 같은 fabric 수준 격리를 직접 구성할 수 없다면, 그 위에서 무엇으로 격리를 보강할지가 사용자의 숙제가 된다.

Bandwidth Generations

InfiniBand는 세대 이름으로 속도를 부른다. 링크는 보통 lane 4개를 묶은 4x 구성으로 쓴다.

세대4x 링크 대역폭
EDR100 Gb/s
HDR200 Gb/s
NDR400 Gb/s
XDR800 Gb/s

설치 기반의 주력은 NDR 400 Gb/s이고, XDR 800 Gb/s 세대 스위치와 어댑터가 출하되기 시작했다. IBTA 로드맵은 그 다음으로 1.6 Tb/s 세대를 예고하고 있다.

속도 경쟁만이 아니라 fabric 안에서 연산을 대신해주는 기능도 있다. SHARP(Scalable Hierarchical Aggregation and Reduction Protocol)는 all-reduce 같은 collective 연산의 집계를 IB 스위치가 수행해, 같은 데이터가 endpoint 사이를 여러 번 오가는 것을 없앤다. 아직 Ethernet 진영에 표준화된 등가물이 배치되지 않은, InfiniBand 고유의 무기다.

Comparison

Ethernet (TCP)RoCE v2InfiniBand
RDMA없음있음있음
레이턴시수십 μs 이상수 μs1 μs 미만
data path의 CPU개입우회우회
무손실아니오 (재전송으로 복구)PFC + ECN 튜닝으로 달성credit 기반, 설계상 보장
혼잡 제어TCP (소프트웨어)DCQCN (튜닝 필요)하드웨어 + SM
인프라기존 EthernetEthernet 재활용 가능전용 HCA와 스위치
관리익숙함Ethernet + RDMA 운영 역량SM 중심, 별도 생태계
GPUDirect RDMA불가가능가능

TCP Ethernet은 범용이지만 학습 backend로는 CPU와 레이턴시가 발목을 잡는다. RoCE는 Ethernet 생태계 위에서 RDMA 성능을 내지만 무손실을 운영으로 만들어내야 한다. InfiniBand는 무손실과 저레이턴시를 하드웨어로 보장하는 대신 전용 인프라와 SM 생태계를 통째로 들여야 한다.

When to Use

무엇을 고를지는 조직이 처한 조건에서 갈린다.

InfiniBand를 고르는 경우: 학습 성능과 안정성이 최우선이고, 전용 fabric 비용을 감당할 수 있으며, 네트워크 팀이 RoCE 튜닝을 상시 운영할 여력이 없을 때. 특히 NVIDIA GPU 중심 클러스터에서 검증된 reference 구성을 따라가려면 IB가 마찰이 가장 적다.

RoCE를 고르는 경우: Ethernet 장비 생태계와 조달 유연성이 중요하고, lossless 네트워크를 설계하고 운영할 네트워크 역량이 조직에 있을 때. hyperscaler들이 이 길을 택하는 이유는 규모가 커질수록 이점이 커지기 때문이다. 같은 세대 기준으로 Ethernet 스위치가 포트 밀도에서 앞서는 데다, transceiver와 케이블을 여러 벤더에서 조달할 수 있어 클러스터가 클수록 비용 격차가 벌어진다.

**Ethernet(TCP)**은 backend fabric 후보가 아니라 나머지 전부의 기본값이다. 관리, 스토리지, frontend 트래픽은 TCP Ethernet으로 충분하고, 실제 클러스터는 예외 없이 backend fabric과 frontend Ethernet의 이중 네트워크로 구성된다.

Summary

세 기술의 차이는 대역폭 숫자가 아니라 손실을 다루는 철학에 있다.

TCP Ethernet은 손실을 전제로 두고, 버려진 패킷을 소프트웨어가 되돌린다. 범용 네트워크로는 완성형이지만, CPU 개입과 레이턴시가 GPU 학습 backend 자리에서는 발목을 잡는다.

RoCE는 Ethernet 위에 RDMA를 얹고, 무손실을 PFC와 DCQCN 튜닝으로 빚어낸다. 장비값은 Ethernet 재활용으로 아끼지만, 그 무손실을 유지하는 운영 부담은 조직 몫으로 남는다.

InfiniBand는 credit 기반 흐름 제어로 손실 자체가 생길 수 없게 설계됐고, SM이 fabric 전체를 중앙에서 관리한다. 성능과 안정성의 기본값이지만, 그 대가로 전용 인프라와 생태계 종속을 함께 들여야 한다.

그리고 이 구도 자체가 움직이고 있다. Ultra Ethernet과 Spectrum-X가 보여주듯, 다음 세대 AI fabric의 싸움은 “Ethernet이 InfiniBand의 장점을 얼마나 흡수하느냐”를 축으로 돌고 있다.

References