왜 지금 RDMA 얘기가 다시 나올까
AI 클러스터가 수십만 GPU 규모로 커지면서, 네트워크는 더 이상 '주변부'가 아니라 성능의 임계 경로(critical path) 가 됐어요. All-reduce, all-to-all 같은 collective 연산은 수천 개의 가속기를 동기화하는데, 가장 느린 전송 하나가 전체 학습 job의 속도를 결정하죠. 추론에서도 마찬가지예요. 분산된 모델 샤드 간 지연이 곧 사용자 응답 시간이 됩니다.
문제는 기존 RoCEv2 가 "네트워크는 절대 패킷을 잃지 않는다"는 전제 위에 세워져 있다는 점이에요. PFC(Priority Flow Control)로 무손실을 강제하고, 순서 보장을 스위치에 의존하죠. 그런데 GPU가 수십만 개로 늘고 데이터센터가 지역을 넘어가면, 이 전제가 오히려 확장성의 발목을 잡습니다. Multiplane 토폴로지에서 성능을 끌어올리는 패킷 스프레이도 PFC와 상성이 나쁘고요.
Meta가 OCP(Open Compute Project)에 기여한 MetaRoCE 는 이 전제 자체를 뒤집습니다. 핵심 통찰은 한 줄로 요약돼요.
패브릭은 패킷을 보고, NIC는 의도를 본다.
지능을 스위치에 몰아넣는 대신 엔드포인트(NIC)로 옮기자는 겁니다. 이 글에서는 MetaRoCE의 설계 원리와 RoCEv2 대비 실제 측정치, 그리고 국내 인프라 환경에서 이게 어떤 의미인지 짚어볼게요. 근거자료는 Meta Engineering 블로그 원문에서 확인할 수 있습니다.
MetaRoCE 핵심 메커니즘 5가지
1. 네이티브 아웃오브오더 수신 (Native Out-of-Order Delivery)
MetaRoCE는 패킷을 여러 경로에 흩뿌리기 때문에 순서가 뒤바뀌는 게 정상 이에요. 모든 패킷이 자기 목적지 정보를 들고 다니고, 도착하는 즉시 최종 메모리 위치에 바로 씁니다. 재정렬 버퍼가 없으니 head-of-line blocking도 사라지죠.
# 개념 비교
RoCEv2: [P1][P2][P3] → 재정렬 버퍼 → 순서대로 처리 (P2 유실 시 P3 대기)
MetaRoCE: [P1]→mem, [P3]→mem, [P2]→mem (각자 도착 즉시 기록)
2. 네이티브 멀티패싱 (Native Multipathing)
각 커넥션은 여러 개의 퍼스트 클래스 경로 를 갖고, 패킷 단위로 스프레이합니다. 경로마다 별도 UDP 소스 포트를 ECMP 엔트로피로 쓰기 때문에, NIC이 언제든 트래픽을 건강한 경로로 옮길 수 있어요. 경로별로 윈도우와 RTT 추정치를 따로 관리하기 때문에 혼잡과 장애를 구분 할 수 있습니다. 뜨거운 링크 하나가 커넥션 전체를 멈추지 않아요.
3. 손실을 전제로 한 설계 (Loss Tolerance by Design)
PFC도, pause frame도 쓰지 않습니다. 경로마다 자체 순서 번호를 유지하기 때문에, 256비트 SACK 비트벡터의 갭은 재정렬이 아니라 손실의 증거 로 해석돼요. 갭이 발견되는 순간, 그 경로에서 정확히 유실된 패킷만 재전송합니다.
4. 양방향 혼잡 제어 (Congestion Control From Both Sides)
송신자 주도 ECN 기반 AIMD와 수신자 주도 fair-share rate hint 를 결합합니다. 수신자가 매 ACK마다 자신이 이 송신자에게 할당한 인바운드 대역폭 비율을 되돌려주기 때문에, 송신자는 속도를 탐색하지 않고 바로 정답에 접근해요. Incast가 1~2 RTT 안에 해소됩니다.
5. 토폴로지 독립성 (Topology Independence)
MetaRoCE가 패브릭에 요구하는 건 딱 두 가지, ECN 마킹 과 ECMP 입니다. 패킷 트리밍, 인네트워크 텔레메트리, 크레딧 기반 플로우 컨트롤, 스위치 사이드 스프레이는 필요 없어요. Fat-tree, multiplane, deep-buffer, shallow-buffer 어떤 패브릭에서도 동일한 트랜스포트가 돌아갑니다.
6. 스케일에서의 통합 커넥션 (Unified Connections at Scale)
기존 RDMA는 병렬성을 늘리려면 QP를 수십 개씩 열어야 했죠. MetaRoCE는 하나의 커넥션이 위로는 여러 개의 독립적인 순서 스트림 (communicator/collective별), 아래로는 여러 개의 경로 를 하나의 혼잡 제어기 아래에서 관리합니다. 커넥션 상태가 워크로드 병렬성에 따라 무한정 늘지 않아요.
기존 RDMA Verbs API와 소프트웨어 스택은 수정 없이 그대로 동작합니다. Multiplane 지원 같은 확장 기능만 별도 extension API로 붙습니다.
RoCEv2 vs MetaRoCE 한눈에 비교
| 항목 | RoCEv2 | MetaRoCE |
|---|---|---|
| 무손실 전제 | PFC로 무손실 강제 | 손실 허용, PFC 불필요 |
| 순서 처리 | 스위치/재정렬 버퍼 의존 | 아웃오브오더 수신, 재정렬 버퍼 없음 |
| 멀티패싱 | 제한적 (PFC와 상충) | 네이티브, 패킷 단위 스프레이 |
| 혼잡 제어 | 송신자 주도 ECN/AIMD | 송신자 + 수신자 fair-share hint |
| 순서 보장 주체 | 패브릭 | 엔드포인트(NIC) |
| 패브릭 요구사항 | PFC, 순서 보장, 벤더 기능 | ECN + ECMP 만 |
| 1% 손실 시 처리량 | 급격히 저하 | ~86% 유지 |
| 10% 손실 시 | 사실상 붕괴 | 유용한 대역폭 유지 (graceful) |
| QP 확장성 | 노드쌍당 수십 개 필요 | 단일 커넥션에 다중 스트림 |
| 애플리케이션 수정 | - | 불필요 (Verbs API 호환) |
실측 데이터 (AMD Pensando NIC, 64노드 AMD GPU 클러스터)
Meta는 AMD와 협력해 Pensando programmable NIC에 MetaRoCE를 구현하고, RCCL collective로 직접 비교 측정했습니다.
- All-reduce / All-to-all: MetaRoCE가 RoCEv2 대비 일관되게 높은 처리량, 낮은 flow completion time
- 1% 패킷 손실: RoCEv2는 성능이 무너지지만 MetaRoCE는 ~86% 처리량 유지
- 10% 극한 손실: 여전히 유용한 대역폭 제공, 붕괴 대신 우아하게 수렴
- Multiplane 확장성: 4-plane / 8-plane, 최대 4,000 동시 커넥션에서 처리량이 plane 수에 선형 비례
- Plane 장애 시뮬레이션: 애플리케이션 개입이나 운영자 조치 없이 자율 복구
이 기술의 한계와 주의사항
솔직히 말하면, MetaRoCE가 만능은 아닙니다.
- NIC 의존성: 지능이 엔드포인트로 이동했기 때문에, NIC이 똑똑하지 않으면 이득이 없어요. Programmable NIC(예: AMD Pensando)이나 고성능 fixed-function NIC이 전제입니다.
- Scale-across 미완: 데이터센터 내부(scale-out)는 성숙했지만, 수천 km 떨어진 빌딩 간(scale-across)은 아직 연구 단계입니다. 장거리 공유 링크의 공정성 문제가 남아 있어요.
- Storage/KV-cache 대응: 네트워크 속도와 요청 크기가 제각각인 환경에서 수신자 주도 rate hint의 정확도를 유지하는 게 다음 과제입니다.
- 생태계 성숙도: OCP 스펙과 레퍼런스 구현(libsoftmetaroce)이 나왔지만, 실제 상용 스위치/NIC 벤더의 채택 속도는 별개 문제입니다.
다음 단계 학습 방향
- OCP ESUN(Ethernet Scalable Unified Network) 이니셔티브 문서를 먼저 읽어보세요. MetaRoCE가 어디에 얹히는지 그림이 잡힙니다.
- RDMA Verbs API 기본기를 다져두면 MetaRoCE 도입 시 애플리케이션 변경이 없다는 게 얼마나 큰 장점인지 체감됩니다.
- AIMD, ECN, DCQCN 같은 혼잡 제어 기본 개념을 정리해두면 이 글의 4번 항목이 훨씬 잘 들어옵니다.
- 2026년 10월 OCP Global Summit 에서 DPDK 최적화 레퍼런스 구현과 compliance 프레임워크가 공개될 예정이니, 그때 libsoftmetaroce를 직접 돌려보는 걸 추천합니다.
한국 개발 생태계에서의 적용 맥락
국내 대부분의 AI 인프라는 아직 RoCEv2 + PFC 구성 이 표준처럼 굳어져 있어요. 특히 SI/금융권 폐쇄망에서는 스위치 벤더 종속 구성이 많고, PFC 튜닝 노하우가 특정 엔지니어에게 집중돼 있는 경우도 흔합니다. MetaRoCE가 던지는 메시지는 명확해요. "PFC 튜닝으로 무손실을 흉내내는 시대는 저물고 있다."
다만 국내에서 당장 도입을 검토한다면 두 가지를 먼저 확인하세요. 첫째, 보유한 NIC이 programmable 계열인지(또는 벤더가 MetaRoCE 구현 로드맵을 갖고 있는지). 둘째, 기존 RDMA Verbs 기반 학습 프레임워크가 extension API 없이도 정상 동작하는지입니다. 다행히 애플리케이션 레이어 수정은 불필요하다는 게 공식 입장이라, PoC 진입 장벽 자체는 낮습니다.
마무리
MetaRoCE의 진짜 가치는 "더 빠르다"가 아니라 "손실을 전제로 설계해도 더 빠르다" 는 역설에 있어요. 이상적인 조건에서 최고 성능을 뽑는 건 어렵지 않습니다. 어려운 건 조건이 나빠졌을 때 우아하게 버티는 것이고, MetaRoCE는 그 지점을 정면으로 겨냥했어요.
AI 인프라를 다루는 개발자라면, 이 프로토콜이 스펙으로 열린 지금이 학습 곡선을 미리 올려둘 좋은 타이밍입니다.