MetaRoCE와 FPF: GPU 네트워크는 패킷 순서를 어떻게 지킬까

GPU를 더 붙였는데 통신을 기다린다면

분산 학습에서는 GPU들이 각자 계산한 뒤 결과 일부를 주고받는다. 예를 들어 all-reduce는 여러 참여자의 값을 합치는 등의 연산을 하고 그 결과를 참여자들이 공유하는 통신이다. 필요한 데이터가 늦게 오는 구간에서는 계산 자원이 통신을 기다릴 수 있다. 네트워크 설계의 관심이 최고 전송률뿐 아니라 느린 전송이 작업 전체에 미치는 영향으로 옮겨가는 이유다.

Meta는 2026년 10월 26일 OCP Global Summit 네트워크 세션과 발표 자료를 공개했다. 여기에 GPU를 여러 네트워크 plane에 연결하는 Flattened Planar Fabric(FPF)과 RDMA 전송 프로토콜 MetaRoCE가 함께 등장한다. RDMA는 다른 장비의 메모리로 데이터를 옮기는 통신 방식을 뜻하며, 이 글은 그중 신뢰성·경로 선택·순서 규칙에 집중한다. 10월 26일 공식 공개

이 두 이름을 한 제품처럼 읽으면 “8개 경로를 연결하면 순서와 복구도 해결된다”는 오해가 생긴다. FPF는 연결 구조와 제어 방식, MetaRoCE는 그 연결 위에서 데이터를 보내고 완성을 확인하는 규칙이다. 같은 네트워크 설계 논의에 들어가지만, 하나의 이름이 다른 하나의 지원을 보증하지는 않는다.

자료의 날짜도 구분해야 한다. MetaRoCE 최초 설명은 8월 24일, FPF 상세 소개는 10월 12일이다. 10월 26일 자료는 user-space 참조 구현 공개와 DPDK 기반 구현의 향후 공개를 구분한다. 8월 글의 “10월 공개 예정”을 모든 구성요소의 출시 완료로 읽지 않았다. 아래 분석은 10월 29일 확인한 MetaRoCE 명세 1.0, 저장소 커밋 c46fa36을 기준으로 한다. GPU 클러스터·NIC·참조 구현을 직접 실행하거나 성능을 측정하지 않았다. 초기 설명 · 고정한 명세 원문

FPF는 길을 나누고, 전송 계층은 그 길의 상태를 읽는다

10월 12일 설명에서 FPF의 GPU는 각각 독립된 100G 링크 여덟 개로 서로 다른 여덟 스위치에 연결된다. 각 스위치가 속한 네트워크 plane을 통해 트래픽을 분산하며, 기존 3단 Clos에서 2단 Clos로 구조를 줄인다. 패킷 분산은 NIC에서 시작하고, 호스트와 스위치를 함께 포함하는 제어 방식으로 내려간 plane을 피하도록 설계했다. FPF 공식 구조

여기서 plane은 장비 연결의 구분이다. 반면 MetaRoCE의 flow는 한 연결 안에서 패킷 번호, 확인 응답, 전송량, 왕복 시간을 관리하는 논리 단위다. 이 차이는 아래 세 질문으로 정리할 수 있다.

구분	답하는 질문	서로 혼동하면 생기는 오해
네트워크 plane·물리 경로	패킷이 어느 장비와 링크를 지나는가?	여덟 plane이면 모든 작업이 여덟 배 빨라진다고 생각함
MetaRoCE flow	어느 전송 묶음에서 손실·혼잡·응답 지연이 생겼는가?	서로 다른 flow가 항상 서로 다른 물리 경로라고 생각함
메시지 stream인 Tag	어느 작업 흐름의 메시지를 어떤 순서로 완료할 것인가?	한 flow의 순서가 애플리케이션 메시지 순서와 같다고 생각함

명세 7장은 서로 다른 flow가 같은 물리 경로를 공유할 수 있다고 명시한다. 일반적으로 UDP 출발지 포트 같은 값을 바꾸어 ECMP가 경로를 다르게 선택하게 유도하지만, 일대일 대응이 보장되지는 않는다. ECMP는 비용이 같은 여러 경로 중 헤더의 해시 등을 이용해 전달 경로를 고르는 방식이다. 따라서 flow 수를 늘렸다는 설정값만으로 실제 경로가 고르게 쓰인다고 판정할 수 없다. 명세 7장 Multipath and Flow Selection

이 구조에서 얻는 선택 기준은 “어떤 스위치가 더 빠른가”보다 구체적이다. 경로를 얼마나 나눌 수 있는지, 송신 측이 그 경로의 혼잡과 고장을 어떻게 구별하는지를 함께 물어야 한다. 물리 경로가 하나뿐인 구간이 남아 있거나 수신 측이 이미 포화라면 논리 flow 추가만으로 병목이 사라지지 않는다. 이는 구조에서 도출한 분석이며, 특정 FPF 배포에서 관측한 결과는 아니다.

먼저 도착한 패킷과 먼저 완료한 메시지는 다르다

MetaRoCE는 패킷이 순서 없이 도착해도 메시지 안의 위치 정보를 이용해 최종 메모리 위치에 놓을 수 있게 설계됐다. RDMA Write 패킷에는 목적지 주소·길이·접근 키 정보가 더해지고, Send에서는 대응하는 수신 작업이 버퍼를 제공한다. 명세는 큰 NIC 재정렬 버퍼에 모든 데이터를 모아 순서대로 내보내는 방식에 의존하지 않도록 설명한다. 명세 1.3·2·3장

다음은 직접 만든 가상 사례다. 메시지 A를 세 조각 A0·A1·A2로 나누어 보내고, 그 뒤 같은 Tag에 메시지 B를 보낸다. 둘 다 미리 준비된 서로 다른 수신 버퍼로 보내는 Send라고 가정한다. A와 B의 주소는 겹치지 않고, 메시지 전체 수신 전에는 애플리케이션이 그 버퍼를 사용하지 않는다. 시각 숫자는 성능 측정이 아니라 사건 순서를 나타낸다.

사건	수신 메모리 상태	같은 Tag의 ordered 모드에서 가능한 판단
① A2가 먼저 도착	A의 세 번째 위치만 채움	A 완료 아님
② A0가 도착	A의 첫 번째·세 번째 위치가 채워짐	A1이 빠져 있으므로 여전히 미완성
③ B가 전부 도착	B 데이터는 모두 메모리에 있음	A가 미완료이므로 B의 완료 통지를 기다림
④ A1이 도착	A의 모든 위치가 채워짐	A에 이어 B의 완료를 통지할 조건이 충족됨

이 사례의 핵심은 “나중 패킷을 먼저 쓰면 데이터가 뒤섞이지 않나?”라는 질문의 답이다. 도착 순서를 배열의 위치로 쓰지 않는다. 패킷의 메시지·위치 정보를 이용해 제자리에 쓴다. 그렇다고 일부 데이터가 메모리에 보이는 순간 애플리케이션이 완성된 메시지처럼 읽어도 된다는 뜻은 아니다.

공식 소개의 “완료는 순서대로”라는 요약에는 조건을 붙여야 한다. 명세 3.3은 ordered와 unordered 완료 모드를 모두 설명한다. 위 표는 ordered 모드이며, unordered라면 B가 먼저 완료될 수 있다. 다른 Tag의 흐름은 독립적인 순서 공간을 가지므로 한 Tag의 대기 때문에 다른 Tag의 완료까지 같은 순서로 묶을 필요는 없다. 다만 링크와 수신 용량을 공유하므로 성능까지 서로 무관하다는 뜻은 아니다. 명세 3.1·3.3

반례도 중요하다. 서로 겹치는 같은 메모리 주소에 두 Write를 동시에 보내면, “나중에 보낸 값이 최종 값”이라고 기대할 수 없다. 명세 3.2.5는 이런 동시 쓰기와 겹치는 읽기·쓰기의 동작을 정의되지 않은 경우로 다룬다. 필요한 순서를 강제하는 execution fence 등을 사용해야 한다. 네트워크가 패킷 손실을 복구하는 능력은 애플리케이션의 메모리 접근 순서 문제를 대신 해결하지 않는다.

순서가 바뀐 것과 사라진 것을 어떻게 나눌까

서로 다른 길로 보낸 A2가 A1보다 일찍 왔다는 사실만으로 A1이 사라졌다고 단정할 수는 없다. MetaRoCE는 메시지의 위치 번호와 별개로 flow별 패킷 번호(FSN)와 선택 확인 응답(SACK)을 관리한다. SACK은 수신한 위치를 알려 주므로 빠진 패킷만 재전송할 수 있다. 명세는 같은 빈칸을 가리키는 응답이 반복돼도 재전송을 불필요하게 반복하지 않도록 커서를 관리한다. 응답이 오지 않는 경우에는 flow별 재전송 타이머도 사용한다. 명세 2.5·4.5·4.6

고장 난 길로 계속 보내는 문제에는 별도 장치가 있다. 명세 4.8의 타임아웃 후 재전송은 Flow ID와 FSN을 유지하면서 경로 선택에 쓰는 entropy 값을 바꾸는 것을 설명한다. 같은 값으로 먼저 재시도하는 횟수는 설정할 수 있다. 다중 물리 포트를 가진 구현은 후속 타임아웃에 다른 출력 포트를 선택할 수도 있다. 논리적으로 어느 패킷을 복구하는지는 그대로 두고, 물리적으로 지나갈 길을 다시 찾는 구조다.

따라서 “다른 길로 재전송”과 “새 메시지로 다시 실행”은 다르다. 전자는 전송 계층의 패킷 복구이고, 후자는 애플리케이션의 재시도다. 운영 기록에서도 둘을 나누어야 손실이 있어도 작업이 계속된 것인지, 작업 자체를 재시작한 것인지 구분할 수 있다. 모든 경로가 고장 나거나 상대 호스트가 사라진 경우까지 전송 규칙만으로 작업이 계속된다는 보장은 없다.

혼잡 제어 역시 경로 수와 별개다. MetaRoCE는 ECN 혼잡 표시와 손실에 반응해 flow별 전송량을 조절하고, 수신 측이 보내는 목표 전송률도 이용한다. 여러 송신자가 동시에 한 수신자로 몰리는 incast에서는 송신 측 각각의 여유뿐 아니라 수신자가 감당할 합계가 중요하기 때문이다. 명세 1.2부터 1.4·6장

명세의 “PFC가 필수가 아니다”도 같은 맥락이다. PFC는 혼잡한 우선순위 트래픽을 일시 멈춰 손실을 줄이는 링크 제어다. MetaRoCE는 데이터 전송이 PFC에 의존하지 않도록 설계됐지만, 명세에는 확인 응답에 PFC 트래픽 클래스를 활용할 수 있다는 설명이 남아 있다. “PFC를 쓸 수 없다” 또는 “기존 네트워크에서 곧바로 꺼도 된다”는 운영 지시로 바꿀 수 없다.

공개 코드가 바꾸는 것과 아직 확인할 것

공식 저장소에는 프로토콜 명세, verbs provider를 포함한 소프트웨어 전송 구현 libsoftmetaroce, 트래픽 생성기 rdma_gen, Wireshark 분석기가 있다. 고정한 README는 Apache-2.0 라이선스를 명시하고, 빌드 시 기본 컴파일러로 clang이 아닌 gcc를 요구한다. 이 글에서는 설치 명령을 실행하지 않았으므로 이를 검증된 설치 가이드로 제공하지 않는다. 현재 조사 커밋의 README

공개 참조 구현의 가치는 구현자가 같은 전송 의미를 읽고 시험할 기반이 생긴다는 데 있다. 그러나 소프트웨어 구현이 실행된다는 사실과 NIC가 해당 동작을 하드웨어로 처리한다는 사실은 다른 증거다. 참조 구현의 속도를 NIC 성능으로 바꾸거나, 기존 Ethernet 장비라면 변경 없이 전체 경로가 지원된다고 가정해서는 안 된다.

도입 판단은 같은 작업의 완료와 복구로 비교한다

독자가 클러스터 도입·임대 사양을 검토한다면 아래처럼 같은 작업을 기준으로 비교할 질문을 정할 수 있다. 특정 제품의 공식 인증 절차가 아니라 이 글에서 제안하는 평가 틀이다.

실제 판단 상황	확보할 자료	그 자료가 없을 때 남는 한계
GPU 수를 늘리자 학습 스텝이 느려짐	같은 모델·배치·메시지 크기에서 point-to-point와 collective 완료 시간, 계산·통신 겹침	링크 전송률만으로 학습 병목을 특정하기 어려움
여러 flow를 썼지만 일부 링크만 바쁨	flow별 RTT·손실·ECN과 실제 인터페이스별 트래픽	flow 수만으로 물리 경로 분산을 입증할 수 없음
많은 송신자가 한 노드로 몰릴 때 지연	수신 용량, 송신자 수, 수신 측 제어 적용 여부, 완료 시간 분포	평균 대역폭이 높아도 일부 느린 전송을 놓칠 수 있음
격리 시험에서 한 경로를 사용할 수 없음	패킷 재전송·포트 변경·collective 완료·출력 정확성·앱 재시작 여부	재전송 로그만으로 업무 복구를 판정할 수 없음
코드와 NIC 조합을 바꾸려 함	명세·구현 커밋, NIC·펌웨어·드라이버·통신 라이브러리, Tag·완료 모드 지원	저장소 공개만으로 내 실행 조합의 호환성을 확정할 수 없음

장애 조건은 허용된 격리 환경에서만 시험하고, 정상 조건의 비교 기준을 먼저 남기는 편이 좋다. 학습 모델과 통신 라이브러리를 함께 바꾼 결과에서는 네트워크 변경만의 효과를 분리하기 어렵다. 특히 작은 point-to-point 시험이 통과했다는 사실을 큰 collective의 완료 시간과 정확성까지 확인한 것으로 확대하지 않는다.

평가 기록에는 다음 항목을 복사해 둘 수 있다. 빈칸은 미관측 상태로 남기며, 예상 결과를 실측으로 채우지 않는다.

대상 작업 / 모델·배치·메시지 크기 / 참여 노드:
명세·코드 커밋 / NIC·펌웨어·드라이버 / 통신 라이브러리:
물리 plane·경로 / 논리 flow / Tag·완료 모드:
정상 비교 결과 / 계산·통신 중 병목 후보:
격리한 장애 조건 / 재전송·경로 변경 / 앱 재시작 여부:
collective 완료 시간 분포 / 최종 출력 정확성:
남은 미지원 조건 / 채택 기준 / 이전 조합으로 돌아갈 조건:

직접 클러스터를 운영하지 않고 외부 AI API만 사용하는 팀이라면 이 프로토콜을 설치할 일이 당장 생기지는 않는다. 반면 GPU 인프라를 구축하거나 임대하는 팀에는 “총 대역폭” 뒤에 숨은 경로 분산, 수신 병목, 완료 의미와 복구 조건을 따로 확인할 이유가 생긴다. FPF와 MetaRoCE를 함께 읽는 실무 가치는 이 질문들을 사양서와 인수 시험으로 옮길 수 있다는 점이다.

이미 운영 중인 작업과 장비 이상을 연결하려면 NVIDIA Minerva의 토폴로지 관측 분석을, GPU 내부의 계산·메모리 병목부터 구분하려면 HBM과 Roofline 해설을 이어 읽을 수 있다. 위 평가 기록을 다시 쓸 때는 글 위의 저장 기능을, 후속 인프라 분석은 주제 모음과 RSS를 이용할 수 있다.