RoCEv2란? AI 데이터센터 Ethernet이 GPU 통신에 쓰이는 방법

Ethernet은 원래 AI를 위해 만들어진 Network가 아닙니다.

기업의 Server, Storage, Web Traffic처럼 수많은 서로 다른 Flow를 안정적으로 전달하기 위해 발전해온 범용 Network입니다. 그런데 지금은 NVIDIA GPU와 AMD Accelerator 수천 개, 많게는 수십만 개를 연결하는 AI Cluster의 핵심 Network 후보가 됐습니다.

Ethernet 자체가 갑자기 GPU 전용 Network로 바뀐 것은 아닙니다.

중요한 변화는 Ethernet 위에서 RDMA(Remote Direct Memory Access)를 사용할 수 있게 됐다는 것입니다.

34번에서 살펴본 것처럼 RDMA는 CPU가 Network Packet 하나하나를 처리하고 Memory를 반복적으로 복사하는 과정을 줄이고, NIC가 Memory 사이의 Data Movement를 직접 처리하도록 합니다.

그렇다면 이런 RDMA를 Ethernet에서 사용하려면 어떻게 해야 할까요?

바로 RoCE가 필요합니다.

RoCE: RDMA over Converged Ethernet의 약자로, 기존 Ethernet Infrastructure 위에서 RDMA의 낮은 CPU Overhead와 Direct Memory Access를 사용할 수 있도록 만든 기술입니다.

그리고 현재 AI Data Center에서 주로 이야기하는 것은 RoCEv2입니다.

RoCEv2: RDMA Packet을 UDP/IP 위에 Encapsulation해 Layer 3 Ethernet Network에서도 Routing할 수 있도록 만든 RoCE의 두 번째 세대입니다.

쉽게 말하면 RoCEv2는 “Ethernet을 그대로 사용하면서 InfiniBand처럼 빠른 RDMA 통신을 하고 싶다”는 요구에서 만들어진 기술이라고 이해하면 됩니다.

RoCE Initiative를 운영하는 InfiniBand Trade Association(IBTA)은 RoCE가 Ethernet Infrastructure를 그대로 활용하면서 RDMA를 통해 CPU의 Data Movement 부담을 줄이고, 낮은 Latency와 높은 Server Efficiency를 제공하도록 설계됐다고 설명합니다.

AI Infrastructure에서 RoCEv2가 중요한 이유도 여기에 있습니다.

GPU를 더 많이 연결하는 것만으로 AI Cluster가 빨라지는 것이 아니라, GPU 사이에 데이터를 얼마나 빠르고 예측 가능하게 전달할 수 있느냐가 전체 System Performance를 결정하기 때문입니다.

RoCEv2를 먼저 한눈에 보면

구분	일반 Ethernet + TCP/IP	RoCEv2
Data Movement	CPU·OS 개입이 상대적으로 큼	RDMA Hardware Offload
Network	Ethernet	Ethernet
Routing	Layer 3 가능	Layer 3 가능
Transport 기반	TCP 등	UDP/IP + RDMA
Memory Copy	상대적으로 많을 수 있음	최소화 가능
Latency	일반적인 Network 수준	낮게 설계 가능
CPU Overhead	상대적으로 큼	낮음
주요 용도	일반 Server Traffic	AI, HPC, Storage
핵심 문제	일반 Network Congestion	Loss·Congestion·Tail Latency

RoCEv2의 가장 큰 의미는 새로운 Cable이나 새로운 Switch Connector가 아닙니다.

우리가 이미 알고 있는 Ethernet을 RDMA Fabric으로 바꾼다는 것입니다.

RoCE와 RoCEv2는 무엇이 다를까요?

RoCE에는 크게 두 세대가 있습니다.

RoCE v1: Ethernet Layer 2 Frame 위에서 RDMA를 전달하며 같은 Layer 2 Network Domain 중심으로 사용됩니다.

RoCEv2: RDMA Traffic을 UDP/IP Packet으로 Encapsulation해 Layer 3 IP Routing이 가능한 Network로 확장합니다.

이 차이는 Data Center 규모가 커질수록 중요합니다.

GPU 몇 대를 같은 Rack이나 작은 Layer 2 Network에서 연결한다면 Routing이 크게 중요하지 않을 수 있습니다. 하지만 GPU가 수천 개, 수만 개로 늘어나면 여러 Switch와 Subnet을 연결해야 합니다.

이때 Layer 3 Routing이 가능한 RoCEv2가 훨씬 유연합니다.

그래서 오늘날 AI Data Center에서 단순히 “RoCE”라고 이야기할 때 실제로는 RoCEv2를 의미하는 경우가 많습니다.

RoCEv2는 Ethernet을 버리지 않는다는 것이 가장 큰 장점입니다

InfiniBand를 사용하려면 InfiniBand NIC와 Switch, Management Environment가 필요합니다.

반면 RoCEv2는 Ethernet을 사용합니다.

Data Center Operator 입장에서는 익숙한 IP Routing, Ethernet Switching, Optical Transceiver, Cable, Network Management Ecosystem을 활용하면서 RDMA를 도입할 수 있습니다.

RoCE Initiative는 RoCE의 중요한 장점으로 기존 Ethernet Data Center Infrastructure를 그대로 활용할 수 있다는 점을 강조합니다.

이것은 기술적인 장점인 동시에 경제적인 장점입니다.

AI Network가 성장할수록 고객은 특정 Vendor의 전용 Network에 완전히 종속되는 방법과, 여러 Switch·NIC·Optics 업체가 참여할 수 있는 Ethernet 방식 사이에서 선택하게 됩니다.

RoCEv2는 바로 후자의 핵심 기술입니다.

그런데 Ethernet은 원래 Packet Loss가 가능한 Network입니다

여기서 문제가 시작됩니다.

Ethernet은 기본적으로 Packet이 손실될 수 있다는 것을 전제로 만들어졌습니다.

Switch Buffer가 가득 차면 Packet을 Drop할 수 있고, TCP가 이를 발견해 다시 전송합니다.

Web Service라면 이런 방식이 잘 작동합니다.

하지만 GPU 수천 개가 동시에 AllReduce를 수행하는 AI Training에서는 이야기가 달라집니다.

GPU들은 서로 계산결과를 교환해야 다음 계산단계로 넘어갈 수 있습니다. Network Packet이 손실돼 Retransmission이 발생하면 특정 GPU가 늦어지고, 결국 다른 GPU들도 기다려야 할 수 있습니다.

즉 AI Network에서는 Packet 하나의 Delay가 GPU 전체의 Idle Time으로 확대될 수 있습니다.

이 때문에 RoCE Network에서는 전통적인 Ethernet보다 Packet Loss와 Congestion을 훨씬 민감하게 관리해야 합니다.

왜 AI Traffic은 일반 Ethernet Traffic보다 까다로울까요?

일반 Data Center에서는 수많은 작은 Flow가 서로 다른 방향으로 움직이는 경우가 많습니다.

AI Training Traffic은 다릅니다.

AllReduce, AllGather, All-to-All 같은 Collective Communication이 반복되면서 비교적 적은 수의 매우 큰 Flow가 동시에 움직입니다.

NVIDIA는 이를 일반 Data Center의 High-entropy Traffic과 AI Training의 Low-entropy Traffic 차이로 설명합니다. AI Traffic에서는 여러 대형 Flow가 같은 Link에 충돌할 가능성이 높고, 한 Flow가 늦어지면 Collective 전체가 기다리는 Straggler 문제가 발생할 수 있습니다.

즉 Ethernet을 AI Network로 사용하는 데 가장 어려운 것은 단순 Bandwidth가 아닙니다.

혼잡이 발생했을 때 Network가 얼마나 빠르고 정확하게 대응하느냐입니다.

Incast가 RoCE에서 특히 위험합니다

Incast: 여러 Sender가 거의 동시에 하나의 Receiver로 대량 Data를 보내면서 특정 Switch Port나 Receiver Link에 Traffic이 순간적으로 몰리는 현상입니다.

예를 들어 GPU 64개가 동시에 하나의 GPU 또는 하나의 Node에 데이터를 전송한다고 생각해보겠습니다.

각 Link는 충분히 빠를 수 있습니다.

하지만 마지막 Receiver Port는 하나입니다.

여러 Sender의 Traffic이 한꺼번에 몰리면 Switch Buffer가 빠르게 차고 Packet Loss가 발생할 수 있습니다.

AI Training의 Collective Communication에서는 이런 Traffic Pattern이 반복적으로 나타날 수 있습니다.

따라서 RoCEv2에서는 Congestion을 발생한 뒤 복구하는 것보다 미리 감지하고 Sender의 속도를 조절하는 것이 중요합니다.

PFC는 RoCE에서 왜 등장했을까요?

PFC: Priority Flow Control의 약자로, 특정 Ethernet Traffic Class의 Buffer가 가득 차기 전에 상대쪽 Device에 Pause Frame을 보내 잠시 전송을 멈추게 하는 기술입니다.

RoCE에서는 Packet Loss를 최대한 줄이기 위해 오랫동안 PFC가 활용돼왔습니다.

RoCE Initiative 역시 PFC를 RoCE에서 Deterministic Performance를 지원하는 대표적인 Data Center Bridging 기능으로 설명하고 있습니다.

쉽게 비유하면 좁은 도로 앞에 차가 너무 많이 몰렸을 때 사고가 난 뒤 처리하는 대신, 뒤쪽 신호등에서 잠시 차량을 세우는 것입니다.

Packet Drop은 줄일 수 있습니다.

하지만 PFC에도 문제가 있습니다.

PFC가 모든 것을 해결하지 못하는 이유

Pause Frame을 받은 Link는 전송을 멈춥니다.

문제는 한 곳에서 시작한 Pause가 Network 다른 부분으로 퍼질 수 있다는 것입니다.

이런 상황에서는 Head-of-line Blocking이 발생하거나, 특정 Congestion이 다른 Traffic까지 막을 수 있습니다.

NVIDIA는 기존 RoCEv2 Deployment에서 PFC가 Packet Loss를 줄이는 데 사용되지만 Pause Frame이 Congestion을 확산시키고 Fabric을 Stall시킬 가능성이 있다고 지적합니다.

즉 PFC는

Packet을 버리지 않는 것

에는 도움을 주지만,

Network를 항상 효율적으로 사용하는 것

까지 자동으로 해결하는 기술은 아닙니다.

그래서 RoCEv2에는 또 다른 Mechanism이 필요합니다.

ECN은 Network가 보내는 혼잡 경고입니다

ECN: Explicit Congestion Notification의 약자로, Switch가 Queue Congestion을 감지했을 때 Packet을 Drop하는 대신 Packet Header에 Congestion Mark를 표시해 Endpoint에 알려주는 기술입니다.

자동차로 비유하면 도로가 완전히 막힌 뒤 차량을 버리는 것이 아니라, 앞쪽 도로가 막히기 시작했다는 정보를 운전자에게 미리 보내는 것과 비슷합니다.

RoCEv2 Sender는 이 신호를 이용해 전송속도를 줄일 수 있습니다.

이 방식의 장점은 Packet이 실제로 Drop되기 전에 Congestion에 대응할 수 있다는 것입니다.

하지만 ECN Mark만 있다고 문제가 해결되는 것은 아닙니다.

그 정보를 받은 Sender가 얼마나 빨리, 얼마나 많이 속도를 줄여야 할지 판단해야 합니다.

여기서 Congestion Control Algorithm이 등장합니다.

DCQCN이란 무엇일까요?

DCQCN: Data Center Quantized Congestion Notification의 약자로, RoCEv2 Network에서 ECN Feedback을 바탕으로 Sender의 전송률을 조정하는 대표적인 Congestion Control 방식입니다.

Switch가 Congestion을 감지해 ECN Mark를 남기면 Receiver와 Sender가 Feedback을 주고받으며 Sender가 Rate를 낮춥니다. Network가 안정되면 다시 조금씩 속도를 높입니다.

즉 PFC가 Link를 잠시 멈춰 Packet Loss를 막는 안전장치라면, DCQCN은 Sender가 애초에 너무 많은 Traffic을 보내지 않도록 속도를 조절하는 방식에 가깝습니다.

전통적인 RoCE Data Center에서는 PFC, ECN, DCQCN 계열의 Congestion Control을 함께 사용하는 구성이 널리 알려져 있습니다.

하지만 AI Cluster가 더 커지면서 이 방식에도 한계가 나타나기 시작했습니다.

AI Traffic에서는 Congestion Control이 훨씬 빨라야 합니다

대규모 AI Training에서는 GPU들이 매우 빠르게 대량 Data를 주고받습니다.

Traffic이 갑자기 몰리는 Microburst도 많습니다.

Congestion Control이 너무 늦게 반응하면 Switch Buffer가 이미 가득 찬 뒤입니다.

반대로 너무 민감하게 반응하면 잠깐 발생한 Congestion에도 Sender들이 전부 속도를 줄여 Network Utilization이 떨어집니다.

NVIDIA는 기존 DCQCN 계열 방식이 동기화된 AI Burst Traffic에서는 조정이 어렵고, 반응이 늦거나 과도할 경우 Buffer Buildup, Underutilization, Latency Spike가 발생할 수 있다고 설명합니다.

그래서 최신 AI Ethernet에서는 단순히 ECN을 사용하는 것을 넘어 Switch와 NIC가 함께 Network 상태를 실시간으로 판단하는 방식으로 발전하고 있습니다.

Spectrum-X가 일반 RoCE와 다른 이유

NVIDIA의 Spectrum-X는 Ethernet 위에서 RoCE를 사용하는 AI Networking Platform입니다.

하지만 단순히 기존 Ethernet Switch와 ConnectX NIC를 조합한 것과는 다릅니다.

NVIDIA는 Spectrum-X에서 Switch와 SuperNIC을 함께 설계해 Adaptive Routing, Targeted Congestion Control, Telemetry와 Load Balancing을 결합합니다. NVIDIA는 이 Platform을 수십만 GPU 규모의 AI Fabric까지 확장하는 방향으로 발전시키고 있습니다.

즉 RoCE의 성능을 높이는 방법이

“Switch를 하나 더 빠르게 만들자”

가 아니라

“Switch가 Network 내부 상태를 보고, NIC가 그 정보에 맞춰 Data를 보내게 만들자”

로 바뀌는 것입니다.

Adaptive Routing은 무엇을 해결할까요?

기존 Ethernet에서는 ECMP(Equal-Cost Multi-Path)를 많이 사용합니다.

ECMP: Source와 Destination 사이에 여러 동일비용 Path가 있을 때 Flow Hash를 이용해 특정 Flow를 하나의 Path에 배정하는 Load Balancing 방식입니다.

일반 Traffic에서는 잘 작동합니다.

AI에서는 큰 Flow 몇 개가 우연히 같은 Path에 배정될 수 있습니다.

그러면 다른 Path는 비어 있는데 특정 Link만 막히는 상황이 발생합니다.

Adaptive Routing: Switch가 각 Path의 실제 Congestion 상태를 확인하고 Packet을 현재 덜 혼잡한 Path로 동적으로 보내는 기술입니다.

NVIDIA Spectrum-X에서는 Switch가 Egress Queue 상태를 매우 빠른 시간단위로 확인하고 덜 혼잡한 Port로 Traffic을 전달합니다.

즉 AI Network가 정해진 길만 따라가는 Network에서 실시간 교통상황을 보고 길을 바꾸는 Network로 발전하는 것입니다.

그런데 Packet을 다른 길로 보내면 순서가 바뀌지 않을까요?

맞습니다.

Packet A는 짧은 Path를 지나고 Packet B는 조금 더 긴 Path를 지나면 B보다 A가 먼저 도착할 수 있습니다.

전통적인 RoCEv2는 Packet Ordering에 민감합니다.

AMD는 기존 RoCEv2 RDMA Write의 경우 Destination GPU Memory Address와 R_Key 정보가 첫 Packet의 RETH에만 들어 있기 때문에 뒤쪽 Packet이 순서와 다르게 도착하면 처리하기 어렵다는 문제를 설명합니다.

이것이 기존 RoCE에서 자유로운 Packet Spraying이 어려웠던 이유 중 하나입니다.

AI Network가 커지면서 이 제한을 해결하려는 움직임이 본격화되고 있습니다.

AMD Pollara는 Packet 순서 문제를 어떻게 해결할까요?

AMD의 Pensando Pollara 400 AI NIC는 400Gbps Ethernet Adapter로 RoCEv2와 UEC-ready RDMA를 함께 지원합니다.

Pollara의 UEC-ready RDMA에서는 각 Packet에 필요한 Address 정보를 포함시켜 Packet이 서로 다른 Path를 지나 순서가 바뀌어 도착해도 적절한 GPU Memory 위치에 Data를 배치할 수 있도록 설계합니다.

AMD는 Pollara 400의 주요 AI Networking 기능으로 Intelligent Packet Spray, Path-aware Congestion Avoidance, Out-of-order Packet Handling, In-order Message Delivery, Loss Retransmission과 Programmable Congestion Control을 제시합니다.

여기서 중요한 것은 단순히 AMD NIC가 하나 더 나온 것이 아닙니다.

RoCEv2에서 드러난 Scale 문제를 NIC Hardware가 해결하기 시작했다는 것입니다.

RoCEv2에서 UET로 가는 흐름도 같은 문제에서 시작합니다

Ultra Ethernet Consortium이 UET(Ultra Ethernet Transport)를 만든 이유도 기존 Ethernet이 느려서가 아닙니다.

기존 RDMA Transport가 수십만 Accelerator 규모의 AI Network에 맞춰 설계되지 않았기 때문입니다.

UET: Ultra Ethernet Consortium이 AI와 HPC용 Ethernet에서 RDMA를 더 확장성 있게 제공하기 위해 정의한 차세대 Transport입니다.

UEC는 UET의 핵심 목표를 RDMA를 현대화하고 Network Utilization을 높이면서 Tail Latency를 낮추는 것이라고 설명합니다.

즉 UET는 RoCE의 존재를 부정하는 것이 아닙니다.

오히려 RoCE 시대에 확인된 Packet Ordering, Multipathing, Congestion Control, Retransmission 문제를 AI Scale에 맞게 다시 설계하는 것입니다.

RoCEv2와 UET는 어떻게 다를까요?

구분	RoCEv2	UET
기본 Network	Ethernet	Ethernet
핵심 목적	Ethernet에서 RDMA 제공	AI/HPC에 최적화된 차세대 RDMA
Routing	Layer 3 지원	Layer 3 Scale-out 지향
Multipathing	기본 구조에 제약	강화
Out-of-order	상대적으로 제한적	적극 지원
Retransmission	기존 RDMA 방식	Selective 방식 강화
Congestion Control	PFC, ECN, DCQCN 등	확장성 높은 새로운 CC
주요 시장	Cloud, Storage, AI	대형 AI/HPC Cluster

2026년 현재 중요한 점은 RoCEv2에서 UET로 단번에 시장이 교체되는 것이 아니라는 것입니다.

실제 AI NIC는 둘을 함께 지원하는 방향으로 나오고 있습니다.

AMD Pollara 400은 RoCEv2와 UEC-ready RDMA를 모두 지원하며, AMD의 2026년 Operations Guide에는 기존 RoCEv2와 UEC-ready RDMA Configuration이 별도로 제공됩니다.

즉 고객이 기존 RoCE Infrastructure를 유지하면서 점진적으로 차세대 Transport 기능을 사용할 수 있도록 하는 것입니다.

Broadcom Thor Ultra도 같은 방향입니다

Broadcom의 Thor Ultra는 800G AI Ethernet NIC입니다.

2025년 공개됐으며 PCIe Gen6 x16 Host Interface, 800Gbps Ethernet, Packet-level Multipathing, Out-of-order Data Placement, Selective Retransmission, Programmable Congestion Control을 지원합니다. Broadcom은 Thor Ultra를 UEC Feature-compliant AI NIC로 설계했으며 Advanced RoCE 기능도 함께 제공합니다. 2025년 발표 당시 제품은 Sampling 단계였습니다.

즉 AI NIC 경쟁이 단순히

400G NIC와 800G NIC의 속도경쟁

으로 끝나지 않습니다.

더 중요한 것은 800G Traffic을 얼마나 안정적으로 GPU Memory에 전달할 수 있는가입니다.

800G가 되면 RoCE Transport 문제가 더 커집니다

Network Bandwidth가 두 배로 증가하면 좋은 것처럼 보입니다.

하지만 Congestion이 발생했을 때 Buffer가 차는 속도 역시 훨씬 빨라집니다.

400Gbps Link보다 800Gbps Link에서는 같은 Buffer Capacity가 훨씬 짧은 시간에 소진될 수 있습니다.

따라서 Bandwidth가 높아질수록 Congestion Control이 반응해야 하는 시간도 짧아집니다.

이것이 AI NIC 안에 Programmable Congestion Control Engine과 Telemetry Hardware가 들어가는 이유입니다.

NIC가 단순히 “800G Packet을 보낼 수 있는가”가 아니라 Network 상황에 맞춰 얼마나 정교하게 800G Traffic을 제어할 수 있는가가 중요해지는 것입니다.

MRC는 RoCEv2 자체를 확장하려는 또 다른 방식입니다

2026년에는 MRC(Multipath Reliable Connection)라는 새로운 기술도 주목받기 시작했습니다.

MRC: 하나의 RDMA Connection을 여러 Network Path에 분산해 Throughput, Load Balancing, Availability를 높이는 RoCEv2 확장 Transport입니다.

Broadcom에 따르면 MRC는 AMD, Broadcom, Intel, Microsoft, NVIDIA, OpenAI 등이 공동 개발했으며 기존 RoCEv2가 가진 Single-path와 Retransmission 문제를 개선하는 것이 목적입니다.

NVIDIA 역시 2026년 5월 MRC를 Spectrum-X에 적용하면서 하나의 RDMA Connection이 여러 Network Path를 동시에 사용할 수 있도록 한다고 발표했습니다.

이것은 꽤 중요한 변화입니다.

왜냐하면 AI Ethernet의 진화가 반드시

RoCEv2 폐기 후 UET 전환

이라는 한 방향으로만 진행되는 것이 아니기 때문입니다.

기존 RoCEv2 자체도 계속 진화하고 있습니다.

MRC와 UET를 같은 기술로 보면 안 됩니다

둘 모두 Multipathing과 AI Scale을 해결하려 하기 때문에 비슷해 보입니다.

하지만 접근방식은 다릅니다.

MRC: 기존 RoCEv2 Ecosystem을 유지하면서 Multipath와 Reliability 기능을 확장하는 방식입니다.

UET: Ultra Ethernet Consortium이 AI와 HPC를 위해 RDMA Transport 자체를 보다 광범위하게 현대화하는 Architecture입니다.

따라서 향후 AI Ethernet에서는 기존 RoCEv2, Advanced RoCE, MRC, UET 같은 기술이 일정 기간 함께 존재할 가능성이 높습니다.

결국 Hyperscaler가 중요하게 볼 것은 기술 이름 자체보다 GPU Job Completion Time과 전체 Network Utilization을 얼마나 개선하는가입니다.

Microsoft와 OpenAI가 MRC를 사용하는 이유도 Scale 때문입니다

Broadcom은 2026년 MRC 발표에서 이 기술이 Microsoft와 OpenAI의 여러 Data Center에 이미 Deployment됐다고 밝혔습니다. Thor Ultra는 최대 2·4·8 Plane Network를 지원하며 하나의 Connection을 최대 128개 Path에 Load Balance할 수 있도록 설계됐습니다.

이 사례가 보여주는 것은 명확합니다.

AI Cluster가 충분히 커지면 하나의 Flow를 하나의 Path에 묶어두는 Architecture 자체가 비효율적이 될 수 있다는 것입니다.

AI Ethernet이 Multi-plane, Multipath Architecture로 발전하는 이유입니다.

Multi-plane Network란 무엇일까요?

Multi-plane Network: 하나의 AI Cluster를 여러 개의 독립적이거나 병렬적인 Network Plane으로 구성해 Bandwidth와 Fault Tolerance를 높이는 Architecture입니다.

예를 들어 GPU Server가 Network Plane A, B, C, D에 동시에 연결될 수 있습니다.

하나의 Plane에 문제가 생기더라도 다른 Plane을 사용할 수 있고, 정상상태에서는 여러 Plane의 Bandwidth를 동시에 활용할 수 있습니다.

문제는 Traffic을 어떻게 여러 Plane에 균형 있게 분산시키느냐입니다.

단순히 Hash로 나누면 특정 Plane이 혼잡하거나 장애가 발생해도 Traffic이 계속 보내질 수 있습니다.

그래서 NIC가 각 Plane의 상태까지 이해하는 방향으로 발전합니다.

NVIDIA Spectrum-X Multiplane도 NIC Intelligence를 강화합니다

NVIDIA는 2026년 Spectrum-X Multiplane Architecture에서 SuperNIC 안에 Plane Load Balancer를 넣었습니다.

NIC가 각 Network Plane의 Queue와 End-to-end Congestion Telemetry를 바탕으로 Traffic을 동적으로 분산시키는 방식입니다.

NVIDIA는 이를 이용해 Application과 Operating System은 하나의 RoCE Device만 보고, 실제 Traffic Distribution과 Failover는 Hardware가 처리하도록 설계합니다.

즉 RoCEv2가 발전하면서 NIC는 점점 더 단순 Network Adapter가 아니라 Traffic Decision Processor가 되고 있습니다.

왜 RoCE에서는 Switch와 NIC를 같이 봐야 할까요?

RoCE Congestion은 Network 안쪽 Switch에서 발생합니다.

하지만 Traffic을 실제로 줄일 수 있는 것은 Sender NIC입니다.

Switch만 똑똑하고 NIC가 Network 상태를 모르면 Congestion 해결에 한계가 있습니다.

반대로 NIC만 똑똑해도 Switch 내부 Queue 상태를 정확하게 알 수 없다면 최적의 Path를 선택하기 어렵습니다.

그래서 최신 AI Ethernet에서는 Switch Telemetry와 NIC Congestion Control을 함께 설계합니다.

NVIDIA Spectrum-X가 Switch와 SuperNIC을 하나의 Platform으로 판매하는 이유도 여기에 있습니다.

이것은 NVIDIA의 중요한 경쟁우위입니다

NVIDIA는 GPU만 가지고 있는 회사가 아닙니다.

AI Ethernet에서는 Spectrum-X Switch, ConnectX SuperNIC, BlueField DPU, GPUDirect RDMA, NCCL Communication Software까지 하나의 Stack으로 제공합니다.

GPU에서 발생하는 Collective Communication Pattern을 알고, NIC가 어떻게 데이터를 보내는지 알고, Switch 내부 Congestion까지 동시에 제어할 수 있습니다.

즉 NVIDIA의 장점은 개별 Component Benchmark보다

GPU에서 Network Fabric까지 하나의 System으로 최적화할 수 있다는 것

입니다.

NVIDIA는 Spectrum-X가 Off-the-shelf Ethernet 대비 AI Networking Performance를 최대 1.6배 높일 수 있다고 제시하고 있습니다. 다만 이는 NVIDIA의 Platform 비교 및 특정 조건에 따른 수치이므로 모든 Network 환경에서 동일한 성능차이가 발생한다고 해석해서는 안 됩니다.

Broadcom의 전략은 NVIDIA와 조금 다릅니다

Broadcom은 GPU와 Network 전체를 하나의 Proprietary Stack으로 판매하기보다 Open Ethernet Silicon Ecosystem에서 강합니다.

Switch 쪽에는 Tomahawk 6, Jericho 4 등이 있고, Host 쪽에는 Thor Ultra 800G NIC가 있습니다.

Broadcom은 2026년 5월 기준 Tomahawk 6 102.4Tbps Switch가 Production Volume으로 출하 중이라고 밝혔고, Thor Ultra를 UEC 기반 800G AI NIC로 확대하고 있습니다.

즉 Broadcom의 기회는 특정 GPU Vendor가 아니라 NVIDIA GPU, AMD GPU, Custom XPU 등 다양한 Accelerator가 Open Ethernet을 선택할수록 커질 수 있는 구조입니다.

RoCE가 Broadcom에 중요한 이유는 Switch만 팔리는 것이 아니기 때문입니다

GPU Cluster가 Ethernet으로 커지면 NIC가 필요합니다.

NIC Traffic을 전달할 Switch ASIC이 필요합니다.

Switch와 Server 사이에는 800G·1.6T Optical Link도 필요합니다.

결국 AI Ethernet Cluster가 커질수록 Broadcom이 노릴 수 있는 영역은 Switch ASIC 하나가 아닙니다.

Switch Silicon, NIC Silicon, SerDes, Optical DSP와 Custom AI Infrastructure가 하나의 Value Chain으로 연결됩니다.

그래서 RoCEv2나 UET의 성공은 단순 Network Protocol 변화가 아니라 Server당 Networking Semiconductor Content가 얼마나 증가하는가와 연결해서 볼 필요가 있습니다.

AMD는 왜 Pensando가 중요할까요?

AMD 역시 Instinct GPU만 판매해서는 Rack-scale AI System 전체를 통제하기 어렵습니다.

그래서 Pensando Networking Technology가 중요합니다.

Pollara 400은 RoCEv2와 UEC-ready RDMA를 모두 지원하고 Programmable Congestion Control, Intelligent Packet Spray, GPUDirect 계열 GPU Direct Connectivity 기능을 제공합니다.

AMD의 장기적인 방향은 EPYC CPU, Instinct GPU, Pensando NIC를 하나의 AI Platform으로 결합하는 것입니다.

즉 GPU 업체의 경쟁도 점점

GPU 성능

이 아니라

GPU + NIC + Switch + Software + Rack Architecture

경쟁으로 확대되고 있습니다.

RoCEv2와 InfiniBand 중 무엇이 더 좋을까요?

이 질문에는 단순한 답이 없습니다.

InfiniBand는 AI와 HPC에서 오랫동안 검증된 낮은 Latency와 RDMA Fabric을 제공합니다.

RoCEv2는 Ethernet Ecosystem을 활용할 수 있고 여러 Switch·NIC Vendor와 기존 IP Network 운영환경을 활용하기 쉽다는 장점이 있습니다.

구분	InfiniBand	RoCEv2 Ethernet
Fabric	전용 InfiniBand	Ethernet
RDMA	Native	Ethernet 위에서 제공
Routing	InfiniBand Architecture	IP/Ethernet 활용
강점	검증된 AI/HPC Performance	Open Ethernet Ecosystem
운영환경	전용성이 상대적으로 높음	기존 Ethernet 경험 활용
주요 Challenge	Vendor·Fabric 선택	Congestion·Loss 관리
발전방향	NVIDIA Quantum 등	Spectrum-X, Advanced RoCE, MRC, UET

결국 AI Data Center가 어떤 Network를 선택하느냐는 Performance뿐 아니라 Cost, Vendor Choice, 기존 Network Team의 경험, Scale, Software와 운영방식까지 함께 결정합니다.

Ethernet이 InfiniBand를 따라잡았다고 단순하게 보면 안 됩니다

최근 AI Ethernet이 크게 발전한 것은 사실입니다.

하지만 이것을

“Ethernet이 이제 InfiniBand와 완전히 똑같다.”

라고 이해하면 지나치게 단순합니다.

RoCEv2는 Ethernet의 범용성과 RDMA의 효율성을 결합한 기술이지만, 안정적인 대형 AI Fabric을 만들려면 Congestion Control, Adaptive Routing, PFC·ECN Configuration, Telemetry, NIC·Switch Integration 같은 추가적인 Engineering이 필요합니다.

즉 일반 Enterprise Ethernet Switch를 가져와 RoCEv2만 켠다고 곧바로 최고성능 AI Network가 되는 것은 아닙니다.

AI Ethernet은 Ethernet이라는 표준 위에 상당히 복잡한 Hardware와 Software 최적화를 추가한 Network입니다.

Lossless Ethernet이라는 표현도 조심해서 봐야 합니다

RoCE를 설명할 때 흔히 Lossless Ethernet이라는 표현을 사용합니다.

하지만 실제 Ethernet에서 Packet Loss가 물리적으로 절대 발생하지 않는다는 뜻은 아닙니다.

정확한 의미는 PFC, Buffer Management, ECN, Congestion Control 등을 이용해 RoCE Traffic에서 Packet Loss가 발생할 가능성을 극도로 줄이는 Network를 구성한다는 것에 가깝습니다.

최근에는 오히려 완벽한 Lossless Fabric에만 의존하지 않고, Packet Loss가 발생하더라도 Selective Retransmission과 Advanced Transport로 빠르게 복구하는 방향도 강해지고 있습니다.

AMD는 Pollara 400의 UEC-ready RDMA가 엄격한 Lossless Network Requirement를 완화하는 방향을 강조하고 있고, Broadcom Thor Ultra 역시 Selective Retransmission과 Advanced Congestion Signaling을 지원합니다.

즉 AI Ethernet은

절대로 Packet을 잃지 않는 Network

에서

Packet Loss와 Congestion을 똑똑하게 관리하고 빠르게 복구하는 Network

로 발전하고 있습니다.

Tail Latency가 중요한 이유도 다시 등장합니다

AI Network에서 Average Latency만 보면 문제가 잘 보이지 않을 수 있습니다.

GPU 10,000개 중 9,999개가 Data를 빨리 받아도 한 GPU가 늦으면 Collective Operation 전체가 그 GPU를 기다릴 수 있습니다.

Tail Latency: 전체 Packet이나 Transaction 중 가장 느린 일부가 경험하는 지연시간으로 P99, P99.9 같은 값으로 표현합니다.

AI Network에서는 평균적인 Packet Latency보다 가장 느린 Flow가 얼마나 느린지가 Job Completion Time에 더 큰 영향을 줄 수 있습니다.

UEC가 UET의 중요한 목표로 높은 Network Utilization과 낮은 Tail Latency를 함께 강조하는 이유도 이것입니다.

RoCEv2는 AI Storage에서도 중요합니다

RoCEv2는 GPU끼리 통신하는 데만 사용되지 않습니다.

AI Training에서는 엄청난 양의 Dataset을 Storage에서 읽어야 하고, Model Checkpoint를 다시 Storage에 저장해야 합니다.

GPU Cluster가 커질수록 Storage Traffic도 급격히 증가합니다.

NVMe over Fabrics, Distributed Storage, GPUDirect Storage 같은 Architecture에서 RDMA Ethernet을 활용하면 CPU Overhead를 줄이고 Storage와 Compute 사이의 Data Movement를 더 효율적으로 만들 수 있습니다.

NVIDIA 역시 Spectrum-X Ethernet을 AI Compute Fabric뿐 아니라 AI Storage Fabric으로 확대하고 있으며 Adaptive Routing과 Congestion Control을 Storage Traffic에도 적용하고 있습니다.

즉 RoCE가 성장하면 Networking Silicon 수요가 Training Network 한 곳에서 끝나는 것이 아닙니다.

Compute Fabric과 Storage Fabric 양쪽으로 확대될 가능성이 있습니다.

RoCEv2와 GPUDirect RDMA는 어떻게 연결될까요?

34번에서 GPUDirect RDMA를 살펴봤습니다.

RoCEv2 Network에서도 GPUDirect RDMA를 사용할 수 있습니다.

GPU Memory의 Data를 Host DRAM에 복사한 뒤 NIC로 보내는 대신, NIC가 GPU Memory에 직접 접근하고 Ethernet RoCE Network를 통해 다른 GPU Server로 전달하는 방식입니다.

즉 Data Path의 핵심은 GPU Memory, NIC, RoCEv2 Ethernet, 상대편 NIC, 상대편 GPU Memory입니다.

CPU와 Host Memory의 Bounce Buffer를 줄이면 GPU 사이 Data Exchange가 더 효율적으로 이루어질 수 있습니다.

이것이 AI Ethernet에서 NIC가 단순 CPU Peripheral이 아니라 GPU Data Path의 일부가 되는 이유입니다.

Network Bandwidth per GPU가 중요한 이유

AI Network 시장을 볼 때 “GPU 출하량”만 보면 부족합니다.

같은 GPU 10,000개라도 GPU당 Scale-out Bandwidth가 200Gbps인지, 400Gbps인지, 800Gbps인지에 따라 필요한 Networking Infrastructure가 크게 달라집니다.

GPU당 Network Bandwidth가 증가하면 NIC Bandwidth, Switch Port 수, Switch ASIC Capacity, Optical Transceiver Speed가 함께 증가해야 합니다.

NVIDIA는 최신 Spectrum-X Architecture를 Rubin 기반 AI Factory까지 확대하면서 GPU당 최대 1.6Tb/s Scale-out Bandwidth를 제시하고 있습니다. 이는 NVIDIA의 특정 차세대 Platform Architecture 기준입니다.

즉 미래 AI Networking 시장에서 중요한 지표는

GPU 개수

뿐 아니라

GPU당 Network Bandwidth

입니다.

RoCE가 성장하면 Optics도 같이 움직입니다

Ethernet Switch와 NIC 사이를 Copper로 연결할 수 있는 거리는 제한적입니다.

400G, 800G 그리고 1.6T로 올라갈수록 Optical Connectivity 비중이 커집니다.

RoCE Network라고 해서 Optical Layer가 특별히 다른 것은 아닙니다.

하지만 AI Scale-out Network의 Port 수와 Bandwidth가 증가하면 800G·1.6T Optical Transceiver, Silicon Photonics, CPO 같은 기술수요가 함께 증가할 수 있습니다.

즉 RoCEv2의 성장경로를 산업적으로 보면 AI GPU에서 NIC, Switch ASIC, SerDes, Optical Module까지 이어지는 하나의 Network Value Chain입니다.

NVIDIA가 Spectrum-X에 Silicon Photonics까지 넣는 이유

NVIDIA는 현재 Spectrum-X에 Silicon Photonics 기반 Switch System까지 추가하고 있습니다.

회사는 Optics를 Switch ASIC Package 가까이에 배치해 Network Power Consumption과 Reliability를 개선하는 방향을 추진하고 있습니다.

이것은 RoCE Transport와 직접 동일한 기술은 아닙니다.

하지만 AI Ethernet이 수십만 GPU 규모로 커질수록 Transport Software만 잘 만들어서는 충분하지 않다는 것을 보여줍니다.

RDMA Traffic을 실제로 전달하기 위해 Switch, NIC, Optics, Cable까지 모두 함께 Scale해야 합니다.

AI Ethernet에서 누가 돈을 벌 수 있을까요?

RoCEv2를 하나의 “관련주”로 묶는 것보다는 Value Chain을 나누는 편이 훨씬 정확합니다.

Layer	역할	기업 사례
GPU / XPU	AI Compute	NVIDIA, AMD 등
AI NIC / SuperNIC	RoCE·RDMA Endpoint	NVIDIA, AMD, Broadcom
Switch ASIC	Ethernet Fabric	NVIDIA, Broadcom 등
Congestion / Network Software	Traffic Control	NIC·Switch Platform 업체
Optical Connectivity	400G·800G·1.6T Link	다양한 Optical 업체
SerDes / DSP	고속 Signal Processing	Broadcom, Marvell, Credo 등
Server / System	실제 AI Rack 구축	OEM·ODM 업체

RoCEv2 자체는 무료 Protocol입니다.

돈은 그 Protocol을 수십만 GPU 규모에서 실제로 빠르고 안정적으로 움직이게 만드는 Hardware와 Software에서 발생합니다.

NVIDIA의 투자포인트는 Vertical Integration입니다

NVIDIA는 GPU, SuperNIC, Ethernet Switch, InfiniBand, Optics, Communication Software를 모두 보유합니다.

RoCE가 Ethernet AI Fabric의 중요한 Transport가 될수록 NVIDIA는 GPU만 판매하는 것이 아니라 GPU가 사용하는 Network Infrastructure까지 Content를 확대할 수 있습니다.

특히 Spectrum-X의 핵심은 범용 Ethernet을 그대로 판매하는 것이 아니라 NVIDIA GPU Workload에 맞춰 Switch와 SuperNIC을 Co-design한다는 것입니다.

따라서 NVIDIA의 Networking 사업을 볼 때 단순 NIC 출하량보다 GPU System당 Networking Content가 얼마나 증가하는가가 중요합니다.

Broadcom의 투자포인트는 Open Ethernet입니다

Broadcom은 NVIDIA와 반대 방향에서 강점을 갖습니다.

특정 GPU Architecture에 종속되기보다 여러 XPU, Switch Vendor, Optics Vendor와 연결되는 Ethernet Silicon을 공급할 수 있습니다.

Thor Ultra 800G NIC는 Advanced RoCE와 UEC 기능을 지원하고, Tomahawk 6는 102.4Tbps Switching Capacity를 제공합니다. Broadcom은 2026년 Tomahawk 6가 Production Volume으로 출하되고 있다고 밝혔습니다.

Hyperscaler가 Open Ethernet과 Multi-vendor AI Infrastructure를 확대한다면 Broadcom의 NIC와 Switch Silicon 모두 기회가 생길 수 있습니다.

AMD의 투자포인트는 Full Rack Platform으로의 확장입니다

AMD 역시 Instinct GPU만으로 NVIDIA와 경쟁하는 것이 아니라 EPYC CPU와 Pensando Networking을 결합하려 하고 있습니다.

Pollara 400은 400G RoCEv2와 UEC-ready RDMA를 지원하고, 향후 더 높은 Bandwidth의 NIC Portfolio로 확대되고 있습니다.

AMD가 GPU와 NIC를 함께 최적화할 수 있다면 Networking이 Instinct Platform의 경쟁력을 높이는 요소가 될 수 있습니다.

다만 현재 AMD Data Center 매출 대부분을 Pensando NIC가 만든다고 해석해서는 안 됩니다.

Networking은 아직 AMD 전체 Data Center 사업에서 향후 Platform Content를 확대할 수 있는 Layer로 보는 편이 적절합니다.

RoCEv2 시장에서 가장 먼저 확인해야 할 것은 800G NIC입니다

400G AI NIC는 이미 시장에 들어왔습니다.

다음 전환은 800G AI NIC입니다.

Broadcom Thor Ultra는 800G와 PCIe Gen6 x16을 결합합니다. Network가 800G인데 Host Interface가 충분히 빠르지 않으면 NIC가 받은 Data를 GPU나 Host로 전달하는 부분에서 병목이 발생하기 때문입니다.

즉 800G NIC 전환은 단순 Ethernet Port Upgrade가 아니라 PCIe 6, 200G SerDes, Optical 800G, Switch 51.2T·102.4T 세대가 함께 움직이는 System Upgrade입니다.

두 번째는 PFC 의존도가 줄어드는지 봐야 합니다

기존 RoCE Network는 PFC 기반 Lossless Fabric에 크게 의존했습니다.

하지만 AI Cluster 규모가 커질수록 Pause Storm과 Head-of-line Blocking 같은 문제가 커질 수 있습니다.

그래서 UET, Advanced RoCE, MRC 같은 차세대 Transport는 더 좋은 Congestion Control과 Selective Retransmission을 이용해 완벽한 Lossless Network에 대한 의존도를 줄이는 방향으로 발전하고 있습니다.

이 변화는 중요합니다.

RoCE Network를 구축하는 데 필요한 Operational Complexity가 낮아진다면 Ethernet을 AI Fabric으로 채택하려는 고객이 더 늘어날 수 있기 때문입니다.

세 번째는 MRC가 얼마나 확대되는지 봐야 합니다

MRC는 2026년 상당히 흥미로운 변화입니다.

기존 RoCEv2 Ecosystem을 유지하면서 Single-path Connection의 한계를 줄일 수 있기 때문입니다.

Broadcom은 MRC가 Microsoft와 OpenAI의 여러 Data Center에 이미 배치돼 있다고 밝혔고 NVIDIA도 Spectrum-X에서 MRC를 지원합니다.

따라서 MRC가 특정 Hyperscaler Architecture를 넘어 더 넓게 채택되는지가 중요한 관찰포인트입니다.

네 번째는 UET와 RoCE가 실제로 어떻게 공존하는지입니다

UEC Specification이 공개됐다고 RoCEv2가 바로 사라지는 것은 아닙니다.

이미 설치된 RoCE Infrastructure가 매우 많고, Application과 Driver Ecosystem도 성숙했습니다.

그래서 최신 NIC는 기존 RoCEv2와 UET 계열 기능을 함께 지원하는 방향으로 발전하고 있습니다.

AMD Pollara 400이 대표적입니다.

장기적으로 고객이 어떤 Workload에서 RoCE를 유지하고 어떤 Cluster에서 UET를 선택하는지 확인해야 합니다.

다섯 번째는 Switch와 NIC의 Co-design입니다

일반 Ethernet 시장에서는 Switch와 NIC를 서로 다른 Vendor에서 사도 큰 문제가 없는 경우가 많습니다.

AI Network에서는 Congestion Control과 Adaptive Routing 때문에 둘 사이의 Coordination이 중요해지고 있습니다.

NVIDIA는 Spectrum-X를 통해 가장 강력한 Vertical Integration 전략을 사용합니다.

반면 Broadcom과 UEC Ecosystem은 Open Standard를 통해 Multi-vendor 환경에서도 비슷한 기능을 구현하려고 합니다.

즉 AI Ethernet 경쟁의 중요한 축은 통합된 Proprietary Optimization과 Open Multi-vendor Ecosystem 중 어느 방식이 더 높은 성능과 경제성을 만드는가입니다.

여섯 번째는 Network Telemetry입니다

AI Cluster가 수천 대 규모가 되면 문제가 발생했을 때 어느 Link가 원인인지 찾는 것 자체가 어렵습니다.

Packet Retransmission이 늘었는지, 특정 Switch Queue가 막혔는지, Optical Link에서 BER가 증가했는지 확인해야 합니다.

Telemetry: Network Device가 Queue Depth, Congestion, Packet Loss, Retransmission, Link Error 같은 상태정보를 실시간으로 수집하고 외부 Management System에 제공하는 기능입니다.

NVIDIA는 Spectrum-X에서 Switch와 SuperNIC Telemetry를 이용해 RoCE Retransmission 증가와 특정 Port의 Symbol Error를 추적하는 사례를 공개하고 있습니다.

AI Network가 커질수록 Telemetry는 부가기능이 아니라 GPU Utilization을 유지하기 위한 운영기술이 됩니다.

일곱 번째는 RoCE가 Scale-out을 넘어 어디까지 확대되는지입니다

현재 RoCE의 대표적인 AI 역할은 GPU Server 사이의 Scale-out Network입니다.

하지만 Ethernet은 Scale-up 영역까지 들어오려 하고 있습니다.

Broadcom은 Tomahawk Ultra와 Scale-Up Ethernet을 통해 Rack 내부 Accelerator Fabric까지 Ethernet을 확대하고 있고, UEC 역시 현재 Backend Scale-out을 우선하면서 장기적으로 다른 Network 영역을 검토하고 있습니다.

만약 Ethernet이 Scale-out뿐 아니라 Scale-up 일부까지 차지한다면 Ethernet Switch와 NIC Silicon의 시장범위는 더 넓어질 수 있습니다.

결국 RoCEv2가 해결하려는 문제는 ‘Ethernet이 느리다’가 아닙니다

Ethernet 자체의 Link Speed는 이미 충분히 빠릅니다.

400G, 800G 그리고 1.6T가 등장하고 있습니다.

문제는 그 Bandwidth를 AI Application이 실제로 얼마나 사용할 수 있는가입니다.

Packet Loss 때문에 Retransmission이 반복되거나, 특정 Path에 Traffic이 몰리거나, PFC가 Network를 멈추거나, Tail Latency 때문에 GPU가 기다린다면 800G라는 숫자는 의미가 줄어듭니다.

그래서 AI Ethernet의 진짜 성능은

Peak Bandwidth가 아니라 Effective Bandwidth

로 봐야 합니다.

GPU가 실제 Training과 Inference에서 얼마나 안정적으로 Network Bandwidth를 활용하는지가 중요합니다.

핵심 정리

질문	답
RoCEv2란?	Ethernet과 IP Network 위에서 RDMA를 사용할 수 있도록 만든 Transport
RoCE v1과 차이는?	RoCEv2는 UDP/IP를 이용해 Layer 3 Routing이 가능합니다
왜 AI에서 중요한가?	GPU 사이 Data Movement의 CPU Overhead와 Latency를 낮출 수 있기 때문입니다
가장 큰 문제는?	Congestion, Packet Loss, Tail Latency입니다
PFC란?	Traffic Class를 일시 정지시켜 Packet Loss를 줄이는 Flow Control입니다
ECN이란?	Packet을 버리기 전 Congestion을 Endpoint에 알려주는 표시입니다
DCQCN이란?	ECN Feedback으로 RoCE Sender의 전송률을 조절하는 Congestion Control입니다
UET가 나오면 RoCE는 끝나나?	아닙니다. RoCE도 MRC·Advanced RoCE로 계속 진화하고 있습니다
누가 돈을 버나?	AI NIC, Ethernet Switch ASIC, Optics, SerDes와 Network Software 업체가 연결됩니다

RoCEv2가 중요한 이유는 Ethernet을 완전히 새로운 Network로 바꾸지 않고도 AI GPU가 원하는 RDMA Data Path를 제공할 수 있기 때문입니다.

하지만 RoCEv2를 단순히 “Ethernet에서 RDMA를 사용할 수 있게 해주는 Protocol” 정도로 이해하면 현재 AI Networking의 변화를 절반밖에 보지 못합니다.

초기의 RoCE는 CPU Overhead와 Memory Copy를 줄이는 것이 중요했습니다.

AI Cluster가 커진 지금은 문제가 달라졌습니다.

GPU 수천 개가 동시에 Traffic을 발생시키기 때문에 어느 Path로 Packet을 보낼지, Congestion을 얼마나 빨리 발견할지, Sender의 속도를 어떻게 조절할지, Packet이 순서와 다르게 도착해도 처리할 수 있는지, 손실된 Packet만 선택적으로 다시 보낼 수 있는지가 더 중요해지고 있습니다.

그래서 AI NIC도 변하고 있습니다.

단순 Ethernet Adapter에서 RDMA Engine, Multipathing, Congestion Control, Telemetry, GPU Direct Memory Access를 처리하는 AI Transport Processor로 발전하고 있습니다.

Switch 역시 단순 Packet Forwarding Chip에서 실시간 Queue 상태를 보고 Path를 결정하는 AI Fabric Processor에 가까워지고 있습니다.

이 변화가 NVIDIA Spectrum-X, Broadcom Thor Ultra와 Tomahawk, AMD Pensando Pollara 같은 실제 제품에서 나타나고 있습니다.

결국 RoCEv2를 이해할 때 가장 중요한 질문은

“Ethernet이 InfiniBand보다 빠른가?”

가 아닙니다.

더 중요한 질문은

“수십만 개의 GPU가 동시에 통신할 때 Ethernet이 얼마나 안정적으로 RDMA Bandwidth를 GPU에게 제공할 수 있는가?”

입니다.

그 질문을 해결하기 위해 RoCEv2에서 Advanced RoCE와 MRC가 등장하고, 동시에 Ultra Ethernet의 UET가 만들어지고 있습니다.

즉 RoCEv2는 완성된 기술이라기보다 AI 시대에 맞춰 Ethernet 자체를 고성능 Computing Fabric으로 바꾸고 있는 출발점에 가깝습니다.

그리고 바로 이 변화 때문에 Ethernet NIC, Switch ASIC, SerDes, Optical Networking은 GPU 못지않게 중요한 AI Infrastructure의 Networking Layer로 올라오고 있습니다.