데이터센터에 빠른 네트워크를 설치해도 모든 서버의 NIC가 동시에 바뀌지는 않습니다. 오래된 스토리지 서버, 새로 투입한 추론 서버와 자체 개발 장비가 서로 다른 전송 기능을 가진 채 통신할 수 있습니다. 한쪽에서 보낸 패킷을 상대의 RDMA 하드웨어가 처리하지 못하면 링크 대역폭이 충분해도 기존에 의도한 통신 경로를 사용할 수 없습니다.
ByteDance와 후난대가 NSDI 2026에서 발표한 BURST는 일반 이더넷 NIC와 상용 RDMA NIC가 만나는 경우를 대상으로 합니다[1]. 양쪽 애플리케이션을 모두 다른 통신 인터페이스로 바꾸는 대신, 부족한 RDMA 전송 기능을 사용자 공간의 프로세스에서 구현합니다. 신구 장비가 섞인 상태에서도 RDMA를 사용하는 소프트웨어를 유지하려는 접근입니다.
결과를 읽을 때는 소프트웨어가 모든 NIC의 차이를 없앴다고 생각해서는 안 됩니다. CPU 처리량과 메모리 매핑, DMA 지원, 큐 병렬성에 따라 회복할 수 있는 성능이 달라집니다. 특히 KV 캐시 전송이 약 4배 개선된 결과와 추론의 첫 토큰 응답이 개선된 결과는 같은 수치가 아닙니다.
이더넷 연결과 RDMA 기능의 차이
이더넷으로 연결됐다는 사실만으로 RoCE 전송이 가능한 것은 아닙니다. RDMA NIC(RNIC)는 정해진 패킷 형식뿐 아니라 순서 번호, 메모리 접근 권한과 완료 처리도 기대합니다. 같은 케이블을 통해 패킷이 오갈 수 있어도 상대 메모리에 접근하는 유효한 연산이 되는 것은 아닙니다.
논문은 RDMA 기능이 없는 NIC와 RNIC 사이의 경로를 NR2R이라고 부릅니다. 양쪽 모두 RNIC인 환경에서 전송 정책을 바꾸는 연구와는 출발점이 다릅니다. 양쪽 모두 일반 NIC인 환경에 독자적인 소프트웨어 프로토콜을 설치하는 것과도 다릅니다. 상대 상용 RNIC가 그대로 남으므로 소프트웨어 쪽이 그 장비의 동작과 호환돼야 합니다.
프리필과 디코드를 분리한 추론이나 점진적으로 교체 중인 스토리지 클러스터에서 이런 구성이 나타날 수 있습니다. 두 작업을 다른 장비 풀에 배치했는데 네트워크 기능도 다르면 상태를 넘기는 경로가 제약을 받습니다. 호환 계층이 충분한 성능을 제공한다면 전체 장비를 한 번에 교체하지 않고도 기존 자원을 활용할 수 있습니다.
다만 TCP 경로가 이미 요구 지연과 CPU 예산을 만족한다면 새로운 전송 계층을 운영하는 비용까지 비교해야 합니다. 반대로 호환성 때문에 선택한 경로가 많은 CPU를 쓰거나 상태 전송을 늦춘다면 개선 여지가 큽니다. BURST의 의미는 이런 환경에서 선택 가능한 구현과 시험 결과를 제시했다는 데 있습니다.
표준 인터페이스 뒤에서 동작하는 별도 프로세스
애플리케이션은 기존 RDMA 라이브러리 인터페이스를 사용하지만, 실제 호출을 BURST 프로세스로 연결하는 제공자와 드라이버가 필요합니다. 큐 쌍(QP), 완료 큐(CQ), 등록 메모리 영역(MR)을 공유하거나 매핑해 서비스가 작업을 처리하도록 합니다. 애플리케이션 API의 호환성은 설치와 설정이 전혀 필요 없다는 뜻이 아닙니다.
권한이 필요한 자원 등록과 메모리 매핑에는 커널이 남습니다. 준비된 자원을 이용하는 빈번한 데이터 처리는 DPDK 기반 사용자 공간 경로로 수행합니다. 커널 우회라는 설명을 메모리 보호와 장치 준비까지 모두 커널 없이 처리한다는 의미로 확대해서는 안 됩니다.
독립 프로세스는 여러 애플리케이션의 큐를 받아 작업 스레드에 배정할 수 있습니다. 각 애플리케이션 안에 전송 스택을 별도로 넣는 대신 호스트의 공유 서비스로 관리하는 구조입니다. 이에 따라 스레드 배정, 자원 제한과 서비스 장애의 영향 범위도 운영자가 관리해야 하는 대상이 됩니다.
연결 상태를 호스트 메모리에 두면 NIC 내부의 제한된 저장 공간에만 의존하지 않을 수 있습니다. 그러나 호스트 메모리도 접근 비용과 캐시 제약이 있습니다. NUMA 배치가 맞지 않거나 여러 스레드가 같은 정보를 갱신하면 병목이 생길 수 있으므로, 상태를 밖으로 옮겼다는 사실만으로 확장 문제가 사라지지는 않습니다.
작업 알림 큐에서의 동시성과 장애 복구
애플리케이션이 새 작업을 넣었다는 사실을 서비스에 알려야 합니다. 하드웨어 RDMA의 도어벨은 장치가 감지하는 이벤트지만, 별도 소프트웨어 프로세스는 이를 프로세스 간 통신으로 구현해야 합니다. 큐마다 개별 알림을 계속 확인하면 연결 수가 늘수록 비용이 커지고, 매번 커널 알림을 쓰면 우회하려던 비용이 다시 들어옵니다.
BURST는 작업 스레드별 공유 도어벨 큐에 여러 생산자가 알림을 넣도록 합니다. 하나의 작업 스레드가 여러 QP를 담당하고, 여러 스레드가 병렬로 처리합니다. 모든 연결을 하나의 잠금이나 순회 작업에 묶지 않으면서 알림을 모아 처리하는 방식입니다.
논문에는 처리량 시험만으로 놓치기 쉬운 장애 사례가 나옵니다. 생산자가 큐의 자리를 예약한 뒤 내용을 확정하기 전에 종료하면 소비자는 그 자리가 준비되기를 계속 기다릴 수 있습니다. 실패한 애플리케이션 하나 때문에 같은 작업 스레드를 공유하는 다른 전송도 멈추는 것입니다.
BURST는 일정 시간 이상 확정되지 않은 예약을 무효화하고 회수하는 방식으로 진행을 복구합니다. 실제 도입에서는 강제 종료, 느린 생산자, 오래된 메모리 매핑과 서비스 재시작을 함께 시험해야 합니다. 잠금 없는 큐라는 성능상의 설명만으로 여러 애플리케이션을 안전하게 수용한다고 판단할 수는 없습니다.
송신 복사 제거와 수신 복사 오프로딩
송신에서는 등록된 애플리케이션 메모리를 NIC가 직접 읽을 수 있도록 주소를 연결합니다. 패킷 헤더와 페이로드를 합친 새 버퍼를 만들기 위해 데이터를 먼저 복사하지 않고, 각각의 위치를 전송 경로에 제공합니다. 이때도 프로토콜 처리와 완료 추적은 남으므로 페이로드 복사가 없다는 것과 CPU 작업이 없다는 것은 다릅니다.
수신에서는 NIC가 받은 패킷 버퍼의 데이터를 애플리케이션이 지정한 목적지로 옮기는 복사가 남습니다. Intel DSA는 이 복사를 비동기로 수행해 CPU의 부담을 줄입니다. 데이터 이동 자체를 없애는 것이 아니므로 전체 경로를 무복사라고 설명하면 실제 완료 조건을 잘못 전달하게 됩니다.
애플리케이션에 완료를 알리는 시점은 필요한 복사가 끝난 뒤여야 합니다. 그보다 먼저 완료를 보고하면 목적지에 유효한 데이터가 없는 상태에서 사용을 시작할 수 있습니다. 해당 구현은 수신 작업의 산포·수집 항목(SGE)을 하나로 제한하므로, 여러 버퍼 조각을 한 번에 지정하는 애플리케이션에는 이 조건도 중요합니다.
DSA 효과는 별도의 100G 시험 환경에서 평가합니다. 이를 400G 다중 NIC 결과와 합쳐 하나의 동일한 구성에서 얻은 수치처럼 설명해서는 안 됩니다. 또한 수신 복사보다 송신이나 패킷 처리가 먼저 한계에 도달한다면 복사 오프로딩의 효과는 제한됩니다. 제거한 비용이 실제 병목에 있었는지 확인해야 합니다.
GPU 메모리 접근과 혼잡 제어의 호환 범위
GPU 송신 경로는 피어 메모리 지원을 이용해 DMA에 필요한 매핑을 얻습니다. NIC는 GPU 메모리에서 페이로드를, 호스트 메모리에서 헤더를 읽어 전송합니다. 이것이 모든 일반 이더넷 NIC와 GPU 조합에서 추가 조건 없이 같은 방식으로 작동한다는 근거는 아닙니다.
실제 서버에서는 피어 DMA가 가능한 토폴로지인지, 메모리 등록과 IOMMU 설정이 맞는지, 드라이버 조합이 지원되는지 확인해야 합니다. API 호출이 성공해도 기대와 다른 데이터 이동 경로를 사용한다면 호스트 메모리 대역폭이나 CPU 소비가 늘어날 수 있습니다. 애플리케이션 호환성과 장치 간 직접 접근은 별도의 검증 항목입니다.
패킷 형식을 맞춰도 혼잡에 대응하는 방식이 다르면 성능이 나빠질 수 있습니다. BURST는 시험한 상용 RNIC의 연결 관리 동작을 관찰해 호환되는 혼잡 제어 모드로 맞춥니다. 본문의 DCQCN 전환 방식은 해당 환경에서 확인한 구현상의 결과이며 모든 RNIC 펌웨어에 공통으로 보장되는 협상 절차로 읽어서는 안 됩니다.
기본 재전송에는 상용 장비와의 호환성을 위해 Go-Back-N을 사용합니다. 알려진 상대 구현에서는 선택적 재전송을 활용할 수 있지만 적용 범위가 더 좁습니다. 따라서 정상 상태의 최대 전송률과 별개로 손실, 혼잡과 수신 버퍼 부족 상황을 시험해야 합니다. 깨끗한 두 노드 시험에서 얻은 수치만으로 혼잡한 운영망의 동작을 대신할 수는 없습니다.
400G에 가까운 결과를 만든 큐 병렬성
400G 시험은 NR2R 경로에서 BURST와 커널 RXE, 커널 TCP를 비교합니다. 하드웨어 RDMA 결과도 참고로 제시하지만 이 경우에는 양쪽 모두 RNIC를 사용합니다. 소프트웨어 호환성이 필요한 시험과 장비 기능의 조건이 다르다는 점을 유지해야 합니다.
다중 NIC 시험은 1MB 메시지, NIC당 여덟 QP와 NUMA 배치를 사용합니다. NIC 한 장에서는 CPU 세 코어로 387.12Gbps를, 네 장에서는 총 14코어로 NIC당 평균 387.6Gbps를 보고합니다. 여러 큐의 작업을 병렬로 처리할 수 있을 때 링크 용량에 가까워지는 결과입니다.
단일 QP 결과는 다릅니다. 부록의 1MB 메시지 시험에서 BURST는 121.9Gbps, 하드웨어 RDMA 비교는 385.4Gbps입니다. 논문은 하나의 QP가 특정 작업 스레드와 하드웨어 큐에 연결되는 처리 구조를 소프트웨어 쪽 한계의 원인으로 설명합니다. NIC 전체의 처리량을 애플리케이션의 단일 전송에도 그대로 적용할 수 없는 이유입니다.
여러 독립 전송을 동시에 발생시키는 작업은 병렬성을 활용하기 좋지만, 하나의 큐로 직렬 전송하는 작업은 다른 코어가 남아 있어도 제한될 수 있습니다. 링크 속도를 높이는 것만으로 이 직렬성이 없어지지는 않습니다. 애플리케이션 동시성을 늘리는 경우에는 추가 버퍼와 큐 대기가 다른 단계에 미치는 영향도 함께 봐야 합니다.
KV 캐시 전송과 첫 토큰 응답의 다른 개선 폭
애플리케이션 시험은 서로 다른 NIC 구성을 가진 GPU 노드 두 대를 연결합니다. 양쪽에 GPU 여덟 장과 400G NIC 네 장이 있으며 한쪽은 상용 RNIC를 사용합니다. 첫 출력 토큰이 나오기 전 경로에 있는 KV 캐시 전송을 측정하고, 평균 전송량은 2.94K토큰에 해당하는 캐시 상태로 설명합니다.
평균 KV 전송 지연은 커널 TCP의 16.9ms에서 BURST의 4.26ms로 줄고, P99는 111ms에서 24.2ms로 줄어듭니다. 새 평균은 기존 평균의 약 25.2%입니다. 이 결과를 표현할 때 전송 대상과 범위를 빼면 전체 추론 응답이 같은 비율로 줄어든 것처럼 보일 수 있습니다.
완전한 첫 토큰 응답 시간(TTFT)의 평균은 1,190ms에서 931ms로 줄어 21.76% 감소합니다. P99는 3,720ms에서 3,210ms로 약 13.7% 줄어듭니다. 여기에는 전송 외의 작업도 포함됩니다. 초록의 넓은 표현보다 본문이 구분한 지표를 따라야 하며, KV 전송의 약 4배 개선을 추론 전체의 배수로 옮겨서는 안 됩니다.
별도로 보고된 평균값만으로 전체 지연을 항목별로 재구성할 수도 없습니다. KV 전송 평균의 차이를 빼는 것만으로 TTFT 변화 전체가 설명되지 않기 때문입니다. 대응하는 요청별 기록과 세부 분해가 없으므로 대기나 중첩 실행의 기여를 임의로 계산하지 않습니다. 이 시험에서 전송과 첫 토큰 응답이 각각 개선됐으며 그 폭이 다르다는 결론까지가 근거에 맞습니다.
연결 생성 폭주와 실제 도입의 기준
확장이나 재시작 직후에는 데이터 전송 전에 많은 연결을 만들어야 합니다. 이 시간이 길면 최대 대역폭이 높아도 서비스 복귀가 늦습니다. BURST는 애플리케이션의 연결 관리 인터페이스를 유지하면서 사용자 공간에서 동시 연결 요청을 처리합니다.
두 서버를 사용한 다중 스레드 연결 시험에서는 초당 24,792개의 연결을 생성해 비교한 기본 연결 관리자보다 약 12배 높은 속도를 보고합니다. 이는 연결 생성 수이며 스토리지 I/O나 추론 요청의 초당 처리량이 아닙니다. 연결 폭주가 복구와 확장 시간의 중요한 부분일 때 별도의 가치가 있는 결과입니다.
도입 여부는 메모리와 프로토콜의 정확성, 실제 큐 구성의 전송 성능, 최종 서비스 지연 순서로 확인해야 합니다. 마지막 단계에는 장애, 동시 실행과 운영망의 혼잡도 포함해야 합니다. 마이크로벤치마크에서 CPU를 절약해도 전송 서비스가 예약한 코어와 데이터 이동이 호스트의 다른 작업을 방해한다면 전체 이점이 달라집니다.
BURST가 가장 직접적으로 답하는 문제는 서로 다른 장비를 계속 활용하면서 RDMA 기반 애플리케이션을 유지하는 방법입니다. 비교한 커널 경로보다 높은 성능을 내는 소프트웨어 구현을 보여주지만, 큐 병렬성, 버퍼 형태, 장치 접근과 전송 밖의 연산은 여전히 남습니다. 이 제약까지 포함해 평가해야 장비 교체를 늦출 수 있는 실용적인 대안인지 판단할 수 있습니다.
출처와 저작권 안내
이 글은 평가와 부록을 포함한 NSDI 2026 최종 논문을 바탕으로 독립적으로 작성했습니다. 수치는 원문의 조건을 유지했으며 도입 판단은 이를 바탕으로 한 편집 분석입니다. 원문 저작권은 USENIX 출판 조건에 따라 저자에게 있으며 © 2026입니다. 도판은 작동 원리와 공개 수치를 바탕으로 새로 만들었고 원문 그림과 표의 배치를 복제하지 않았습니다.