AI 클라우드 네트워크에는 서로 반대 방향의 요구가 있습니다. 베어메탈 테넌트는 GPU와 RDMA에 직접 접근하는 성능을 원하지만, 운영자는 주소 가상화, 격리와 장비 수명주기를 제어해야 합니다. RNIC마다 DPU를 배치하면 제어 요구를 충족하지만 서버 전력이 늘어납니다. DPU 하나로 모든 트래픽을 보내면 장치 수는 줄지만 고속 데이터 경로가 막힐 수 있습니다. Tencent의 Pegasus는 두 기능을 나눕니다[1].
논문에 나온 서버는 DPU 하나와 RNIC 여덟 개를 사용합니다. DPU는 설정, 모니터링과 가상화를 담당하고 테넌트의 RDMA 패킷은 RNIC으로 직접 이동합니다. 모든 RNIC을 DPU로 교체하는 구성보다 GPU 서버 전력을 10.5% 줄였다고 보고합니다. 2026년 2월 기준으로 Pegasus는 서버 1,000대, GPU 8,000개에서 2년 동안 운영됐습니다[1].
두 단계 플로 테이블로 격리를 유지하는 방식
DPU와 데이터 경로를 분리하면 상태 일관성 문제가 생깁니다. 언더레이와 오버레이 주소 변환을 바꿀 때 두 장치에 같은 상태가 보여야 하며 다른 테넌트의 트래픽이 노출되면 안 됩니다. Pegasus는 DPU와 RNIC에 두 단계 플로 테이블을 두고 트랜잭션 방식으로 갱신합니다. RNIC별 상태 머신은 반복되는 주소 검증과 관리 통신을 줄입니다.
이 제어 구조는 DPU를 패킷 전달 경로에서 뺀 대가입니다. 전력과 직접 RNIC 처리량을 얻는 대신 프로그래밍 가능한 두 장치의 상태를 정확히 맞춰야 합니다. 실제 운영에서는 RNIC 플로 테이블의 해시 충돌로 테넌트 작업이 중단된 사례가 있었습니다. 가상화 장애가 사라진 것이 아니라 다른 경계로 이동한 것입니다.
전송 제어를 RNIC으로 옮긴 변화
Pegasus는 테넌트가 집합 통신 라이브러리를 수정하지 않도록 설계했습니다. 패킷 단위 부하 분산과 크레딧 기반 혼잡 제어는 RNIC에서 실행됩니다. 패킷 분산은 플로 단위 ECMP보다 세밀하게 여러 경로를 쓰며, 크레딧은 버퍼가 넘치기 전에 네트워크로 들어가는 트래픽 양을 제한합니다. 서로 다른 지연 경로로 순서가 바뀐 패킷은 수신 측에서 다시 맞춥니다.
이 구조는 멀티테넌트 환경을 위한 선택입니다. 학습, 추론과 KV 캐시 전송은 서로 다른 패턴을 만들고, 운영자가 제어하지 않는 테넌트 소프트웨어까지 지원해야 합니다. RNIC의 투명한 오프로딩은 이 소프트웨어 경계 아래에서 네트워크가 대응하게 합니다. 반면 특정 RNIC 기능과 펌웨어 정확성에 의존하므로 하드웨어 검증도 패브릭 운영의 일부가 됩니다.
Tencent는 이전 AI 클러스터와 비교해 GPU 32개에서 70B 밀집 모델의 학습 처리량이 7.5%, 7B MoE 모델은 4.8% 높아졌다고 보고합니다. GPU 96개의 LLaMA 7B 학습은 53.2% 개선됐습니다. 서로 다른 ToR 아래 GPU 16개를 사용한 추론에서는 처리량이 3.7% 늘고 평균 요청 완료 시간이 7.2% 줄었습니다[1]. 개선 폭이 크게 다른 이유는 토폴로지와 통신 패턴이 효과를 결정하기 때문입니다.
운영 배치가 입증한 범위
2년과 8,000개 GPU라는 운영 기록은 Pegasus가 시뮬레이터나 소규모 시험 장비에 머물지 않았음을 보여 줍니다. 하루 약 100개의 테넌트 작업을 처리하며, 작업 규모는 GPU 1개부터 2,400개까지라고 논문은 설명합니다. 다양한 워크로드와 운영 버그가 나타날 만큼 크지만 전용 10만 GPU 슈퍼클러스터보다는 작은 범위입니다.
따라서 이번 결과는 DPU 제어와 RNIC 데이터 이동을 분리하면서 테넌트 격리를 유지하고, 테넌트 수정 없이 전송 계층을 개선할 수 있음을 뒷받침합니다. 모든 클라우드가 RNIC 여덟 개당 DPU 하나를 써야 한다는 의미는 아닙니다. 적절한 비율은 포트 속도, 관리 트래픽, 장애 영역과 장치 세대별 기능에 따라 달라집니다.
Pegasus는 DPU를 모든 패킷이 통과하는 장치가 아니라 공유 제어 자원으로 정의합니다. 정책과 수명주기 기능을 모으고 높은 대역폭의 실행은 분산하는 구조입니다. 다만 상태 일관성, 펌웨어와 상태 머신의 동작이 네트워크 신뢰성 문제가 됩니다. 이 논문이 처리량뿐 아니라 운영 장애도 공개했다는 점에서 선택의 대가를 평가할 수 있습니다. AI 클라우드에서 중요한 질문은 DPU 유무가 아니라 어떤 패킷과 어떤 상태가 DPU를 지나야 하는가입니다.
DPU와 RNIC을 분리하면 확장 단위가 달라지는 조건
기존 구성은 DPU 하나와 고속 네트워크 인터페이스 하나를 짝지을 수 있습니다. 이해하기 쉽지만 링크 대역폭을 늘릴 때 워크로드의 필요와 관계없이 제어 코어, 메모리와 보드 전력도 함께 늘어납니다. Pegasus는 가상화와 정책을 DPU에 두고 패킷 전송을 여러 RNIC으로 나눕니다. 하나의 제어 장치가 포트마다 전체 제어면을 복제하지 않고 여러 물리 링크를 베어메탈 테넌트에게 제공할 수 있습니다[1].
분리하면 내부 프로토콜 경계가 생깁니다. DPU는 상태 설치, 수명주기와 격리를 관리하고 RNIC은 선속도로 전달해야 합니다. 패킷마다 DPU의 판단을 받으면 병목 위치만 옮긴 셈입니다. Pegasus는 빠른 전송 경로를 RNIC에 두고 RNIC별 상태 머신으로 제어 통신을 처리합니다. 연결된 NIC 수보다 인터페이스당 제어 메시지와 반응 지연을 비교해야 합니다.
장애 책임도 복잡해집니다. 한 RNIC의 링크가 끊겨도 공유 DPU는 나머지 인터페이스를 계속 서비스해야 합니다. 반대로 DPU 장애는 여러 경로에 동시에 영향을 줄 수 있습니다. 제품에는 독립적인 리셋 범위, 상태 복원과 상태 보고가 필요합니다. 한 부품을 복구하면서 다른 테넌트의 상태를 노출하거나 서버 전체를 재시작해서는 안 됩니다.
두 단계 플로 테이블이 주소 변환과 격리를 담당하는 역할
베어메탈 테넌트는 장치에 직접 접근하고 싶지만 클라우드 운영자는 오버레이 주소, 언더레이 경로와 정책을 유지해야 합니다. Pegasus는 플로 테이블을 DPU와 RNIC으로 나눕니다. DPU는 클라우드 가상화 문맥을 보유하고 RNIC은 고속 전달에 필요한 정보를 적용합니다. RNIC이 전체 클라우드 제어면을 구현하지 않아도 패킷별 판단을 전송 경로 가까이에 둘 수 있습니다.
가장 큰 비용은 상태 일관성입니다. 한쪽 규칙만 활성화되고 다른 쪽이 이전 매핑을 사용하면 안 됩니다. 갱신에는 순서, 버전 또는 단계적 전환이 필요합니다. 종료했다고 판단한 뒤 지연 패킷이 도착할 수 있으므로 삭제도 민감합니다. 2년의 운영 이력은 이 수명주기를 관리할 수 있다는 근거이지만, 공개 요약에는 갱신 지연과 장애 복구 꼬리 시간이 없습니다.
규모는 GPU 수뿐 아니라 활성 플로와 변동률로 측정해야 합니다. 학습은 적은 수의 장기 대용량 플로를 사용할 수 있지만, 추론과 공유 서비스는 연결 수를 늘립니다. 한 트래픽 조합에 맞춘 테이블은 다른 환경에서 넘칠 수 있습니다. DPU와 RNIC별 항목 수, 삽입률, 제거 정책과 테넌트 생성이 몰릴 때의 성능이 필요합니다.
패킷 분산에 필요한 재정렬 조건
패킷 단위 부하 분산은 긴 흐름 하나를 한 경로에 고정하는 방식보다 여러 경로를 고르게 쓸 수 있습니다. 경로의 큐잉과 전파 지연이 다르면 패킷 순서가 바뀝니다. RDMA는 빠진 순번 때문에 뒤의 데이터 처리가 멈출 수 있습니다. 따라서 Pegasus는 경로 분산과 재정렬 지연 최적화를 함께 해결해야 합니다. 링크 사용률만 제시하면 수신 측 비용을 숨기게 됩니다.
경로 집합은 공통 장애와 혼잡 지점을 피해야 합니다. 첫 스위치에서 갈라져도 같은 과다 구독 업링크로 다시 모이면 독립 용량이 아닙니다. RNIC은 유효한 대체 경로를 구분할 토폴로지 또는 성능 피드백이 필요합니다. 하드웨어 지터는 짧은 처리 지연을 지속 혼잡으로 오인하게 만들 수 있으므로 크레딧 제어와 스케줄링이 과도하게 반응하지 않아야 합니다.
크레딧 기반 혼잡 제어는 수신자 또는 네트워크 용량에 맞춰 전송량을 제한합니다. 보수적인 크레딧은 긴 경로에서 대역폭을 남기고, 큰 크레딧은 비행 중 데이터를 늘려 순간 병목의 비용을 키웁니다. 여러 메시지 크기와 거리에서 제어 루프가 안정되어야 합니다. 투명한 전송 오프로딩은 기존 알고리즘을 하드웨어로 옮기는 것보다 넓은 문제입니다.
전력 절감은 서버 전체를 분모로 봐야 할 이유
RNIC마다 완전한 DPU를 두지 않으면 카드 수, 메모리와 제어면 전력을 줄일 수 있습니다. 다만 공유 DPU, 모든 RNIC, 호스트 CPU 작업, PCIe 스위치와 추가 관리 논리를 포함한 서버 전체를 비교해야 합니다. 한 장치에서 작업을 없애고 다른 장치의 사용률을 높였다면 시스템 전력이 줄었다고 바로 말할 수 없습니다.
성능도 같은 분모가 필요합니다. RNIC 하나의 시험은 선속도를 보여도 테넌트가 동시에 바뀌거나 장애를 복구할 때 공유 DPU가 한계가 될 수 있습니다. 모든 RNIC에 부하를 주고 플로를 만들고 지우며 경로 변경을 주입한 뒤 데이터 처리량과 제어면 꼬리 지연을 함께 측정해야 합니다. 격리는 협력적인 균등 작업이 아니라 공격적으로 자원을 쓰는 테넌트 조건에서 확인해야 합니다.
공개된 운영 범위는 GPU 약 8,000개와 2년 이상입니다[1]. 해당 규모에서 장기간 동작했다는 근거는 분명하지만 총 양방향 대역폭, 과다 구독률, 테넌트 수와 전달 비트당 에너지는 공개하지 않았습니다. 다른 클라우드와 직접 순위를 매길 수는 없지만 제어 용량과 링크 용량을 독립적으로 확장해야 한다는 구조적 교훈은 남습니다.
운영 절차도 연구 결과에 포함되는 범위
다중 테넌트 베어메탈은 하이퍼바이저 오버헤드를 줄이는 대신 소프트웨어 개입 지점도 줄입니다. 네트워크 하드웨어는 테넌트가 바꿀 수 있는 호스트 에이전트에 의존하지 않고 주소 변환과 격리를 집행해야 합니다. 관측 체계는 가상 플로, 양쪽 테이블 항목, 선택 경로, 크레딧 상태와 물리 카운터를 하나로 연결해야 합니다.
안전한 업그레이드도 필요합니다. RNIC 전송 펌웨어와 DPU 제어 소프트웨어는 서로 다른 속도로 바뀌므로 전체 장비에 한 번에 적용하지 않고 여러 프로토콜 버전이 공존해야 합니다. 롤백은 전환 중 생성된 흐름까지 호환 상태로 복원해야 합니다. 논문 초록은 데이터 경로를 강조하지만 2년의 운영은 이런 절차가 설계의 일부임을 뜻합니다.
Pegasus는 혼잡 제어 하나보다 클라우드 구조로 읽어야 합니다. 비교적 단순한 RNIC 자원으로 전송 대역폭을 확장하고 무거운 가상화 제어면을 공유한 것이 중심 결정입니다. 패킷 분산과 크레딧은 AI 트래픽에 링크를 활용하게 하고, 상태 머신과 두 단계 플로 테이블은 클라우드 경계를 지킵니다. 운영자가 두 장치를 함께 제어하고 수명주기를 검증할 수 있는 환경에는 적합하지만 독립된 범용 제품 두 개로 도입하기는 더 어렵습니다.
출처와 저작권 안내
이 글은 Tencent 주도의 SIGCOMM 2026 논문과 학회 공식 초록을 바탕으로 Silicon & Systems가 독립적으로 작성한 편집 요약입니다. 아키텍처, 측정값과 운영 한계를 우리 표현으로 다시 설명했으며 원문의 문장, 표, 도판과 구현 그림을 옮기지 않았습니다. 본문 도판은 이 글을 위해 새로 제작했습니다. 논문의 권리는 출판사가 표시한 조건에 따라 저자와 ACM 2026에 귀속됩니다.