AI 네트워크 패브릭이란? GPU를 늘려도 학습이 빨라지지 않는 이유
"GPU를 10배 늘리면 학습 속도도 10배 빨라질까요?"
이론적으로는 더 많은 GPU가 더 많은 연산을 처리합니다. 하지만 실제 GPU 클러스터에서는 장비를 추가할수록 성능이 선형적으로 증가하지 않는 경우가 많습니다. GPU가 늘어나면 연산 자원만 늘어나는 것이 아니라, GPU들이 서로 주고받아야 하는 데이터와 동기화 작업도 함께 늘어나기 때문입니다. 통신이 연산 속도를 따라가지 못하면, 추가된 GPU는 계산보다 데이터를 기다리는 데 더 많은 시간을 씁니다.
결국 중요한 것은 GPU의 개수가 아니라, GPU들이 하나의 시스템처럼 움직이도록 연결하는 AI 네트워크 패브릭(AI Network Fabric)입니다.
이번 글에서는 GPU를 늘려도 분산 학습 속도가 기대만큼 향상되지 않는 이유와 네트워크 병목을 확인하는 방법, 그리고 엔터프라이즈 GPU 클러스터에서 점검해야 할 과제를 정리합니다.
GPU 확장의 핵심은 개수가 아니라 스케일링 효율입니다
GPU 8대를 16대로 늘렸을 때 처리량이 정확히 2배가 된다면 이상적인 확장입니다. 하지만 실제 환경에서는 GPU 수가 늘어날수록 성능 증가 폭이 점차 작아지는 경우가 많습니다.
이를 판단하는 기준이 스케일링 효율(Scaling Efficiency)입니다.
스케일링 효율은 GPU를 추가했을 때 실제 처리량이 이론적으로 기대한 증가량에 얼마나 가까운지를 나타냅니다. 예를 들어 GPU를 2배로 늘렸지만 처리량이 1.5배만 증가했다면, 추가된 연산 능력의 일부가 통신과 동기화, 대기 과정에서 소모되고 있다는 뜻입니다.
그 이유를 이해하려면 분산 학습이 진행되는 방식을 살펴봐야 합니다.
분산 학습 구조의 흐름
분산 학습의 한 스텝은 일반적으로 다음과 같이 진행됩니다.
각 GPU가 할당받은 데이터를 계산합니다.
GPU별로 계산한 그래디언트를 집계합니다.
전체 GPU의 결과를 동기화합니다.
모든 GPU의 작업이 완료되면 다음 스텝으로 넘어갑니다.
PyTorch의 DistributedDataParallel과 같은 기능은 각 프로세스에서 계산된 그래디언트를 동기화합니다. 실제 GPU 간 All-Reduce와 같은 집단 통신에는 NVIDIA NCCL처럼 GPU 토폴로지를 인식하는 통신 라이브러리가 활용됩니다.
문제는 가장 늦게 통신을 마친 GPU가 전체 스텝 시간을 결정한다는 점입니다.한 노드의 네트워크가 느리거나 특정 경로에 혼잡이 생기면, 다른 GPU가 연산을 끝냈어도 다음 스텝으로 넘어가지 못하고 기다려야 합니다. GPU가 늘어날수록 통신 경로도 많아지므로, 작은 네트워크 비효율이 클러스터 전체의 확장 효율을 더 크게 떨어뜨립니다.
그렇다면 GPU들은 실제로 어떤 경로를 통해 데이터를 주고받을까요?
노드 안과 밖의 통신은 다른 방식으로 이뤄집니다
GPU 간 통신 경로는 크게 서버 내부와 서버 간 구간으로 나눌 수 있습니다.
노드 내부: NVLink와 PCIe
한 서버 안에 있는 GPU들은 NVLink 또는 PCIe를 통해 데이터를 주고받습니다.
NVLink는 GPU 간 대용량 데이터를 빠르게 교환하도록 설계된 고대역폭 스케일업 패브릭입니다. 하나의 서버나 랙 내부에서 여러 GPU를 긴밀하게 연결하는 역할을 합니다.
하지만 같은 서버에 설치된 GPU라고 해서 모두 동일한 조건으로 연결되는 것은 아닙니다. GPU와 CPU, NIC가 어떤 PCIe 스위치와 NUMA 노드에 연결되어 있는지에 따라 데이터가 이동하는 경로와 유효 대역폭이 달라질 수 있습니다.
노드 간: InfiniBand와 RoCE
여러 서버에 분산된 GPU가 통신하려면 InfiniBand 또는 RoCE 기반 이더넷과 같은 스케일아웃 패브릭이 필요합니다.
RoCE는 이더넷 환경에서 RDMA(Remote Direct Memory Access)를 지원해, CPU 개입을 줄이고 서버 간 데이터를 낮은 지연시간으로 전달하는 방식입니다.
NCCL은 NVLink, PCIe, InfiniBand와 네트워크 인터페이스 등 다양한 연결 구조를 인식해 통신 경로를 선택합니다. 그러나 통신 라이브러리가 토폴로지를 인식한다고 해서 물리적인 대역폭 부족이나 잘못된 배선, 네트워크 혼잡까지 자동으로 해결되는 것은 아닙니다. 노드 내부 통신은 빠른데 노드 간 통신이 느리다면, 서버 수를 늘릴수록 전체 학습시간에서 네트워크가 차지하는 비중이 커집니다.
이런 병목은 GPU 사용률 지표만으로는 잘 드러나지 않습니다. GPU가 다른 GPU의 데이터를 기다리는 시간도 "사용 중"으로 집계될 수 있기 때문입니다.
업계는 네트워크를 연산 아키텍처의 일부로 보고 있습니다
네트워크는 더 이상 GPU 서버를 잇는 부속 설비가 아니라, 클러스터의 처리량과 확장성을 결정하는 연산 아키텍처의 일부로 다뤄지고 있습니다.
Spectrum-X: AI 워크로드를 위한 이더넷 패브릭
Spectrum-X는 스위치, SuperNIC, 네트워크 소프트웨어를 결합한 NVIDIA의 AI 전용 이더넷 플랫폼입니다. NVIDIA에 따르면 범용 이더넷 대비 AI 네트워크 성능을 최대 1.6배 높이고, 10만 개 이상 GPU 환경에서도 95% 수준의 효율을 유지하도록 설계됐습니다. 여러 워크로드가 네트워크를 공유할 때 발생하는 성능 편차를 줄이기 위해 적응형 혼잡 제어와 부하 분산을 지원합니다.
이는 NVIDIA가 제시한 특정 구성과 워크로드 기준의 수치이지만, AI 인프라의 성능 경쟁이 GPU 칩을 넘어 NIC, 스위치와 혼잡 제어 소프트웨어까지 확대되고 있음을 보여줍니다.
MRC: 하나의 연결이 여러 네트워크 경로를 활용합니다
2026년 5월에는 OpenAI가 AMD, Broadcom, Intel, Microsoft, NVIDIA와 함께 개발한 MRC(Multipath Reliable Connection)를 Open Compute Project를 통해 공개했습니다.
기존 RDMA 연결은 하나의 흐름이 특정 경로에 묶이는 구조였지만, MRC는 패킷을 여러 경로로 분산 전송해 특정 경로에 혼잡·장애가 생겨도 다른 경로를 활용할 수 있게 합니다. MRC는 RoCE(RDMA over Converged Ethernet)를 확장한 사양으로, SRv6 기반 소스 라우팅을 통해 대규모 AI 네트워크 패브릭을 지원합니다. 특정 기업의 독점 기술이 아닌 개방형 사양으로 공개됐다는 점이 이 흐름의 방향을 보여줍니다.
실제로 MRC는 이미 OpenAI의 대규모 NVIDIA GB200 슈퍼컴퓨터와 Microsoft Fairwater 클러스터 등 프런티어 모델 학습 환경에 배포되어, 프로토타입 수준을 넘어 실운영 단계에 들어와 있습니다.
이러한 움직임이 보여주는 공통된 방향은 하나입니다. GPU 클러스터가 커질수록 네트워크는 단순한 연결 수단이 아니라, 전체 연산 성능을 결정하는 핵심 시스템으로 다뤄지고 있다는 것입니다.
엔터프라이즈 GPU 클러스터도 네트워크 병목에서 자유롭지 않습니다
다만 이 흐름을 수만 대 GPU를 운영하는 하이퍼스케일러만의 이야기로 읽으면 놓치는 게 있습니다. 오히려 수십~수백 대 규모의 엔터프라이즈 환경에서는 제한된 예산 안에서 범용 네트워크와 AI 워크로드를 함께 운영하다 보니, 병목의 원인을 GPU·스토리지·네트워크 중 어디인지 구분하기가 더 어려운 경우가 많습니다.
예를 들어 GPU 노드는 계속 늘었지만 스위치 업링크 용량은 그대로일 수 있습니다. RoCE를 도입했더라도 혼잡 제어 설정이 실제 워크로드와 맞지 않거나, NCCL이 의도하지 않은 NIC를 선택할 수도 있습니다. 학습 트래픽과 스토리지 트래픽이 같은 경로에서 경쟁하는 경우도 흔합니다.
"100GbE를 쓴다", "InfiniBand를 도입했다"는 사실만으로는 충분하지 않습니다. 실제 워크로드가 어느 경로로 통신하는지, 이론 대역폭 중 얼마를 유효하게 쓰고 있는지 확인해야 합니다.
AI 네트워크 패브릭 점검 체크리스트
✅ GPU를 늘렸을 때 실제 처리량 증가폭을 측정하고 있는가?
✅ 학습 스텝의 연산시간과 통신시간을 구분해 확인하고 있는가?
✅ NCCL 집단 통신의 대역폭·지연시간을 정기적으로 테스트하는가?
✅ 여러 팀이 동시에 작업할 때 처리량이 급격히 떨어지지 않는가?
✅ GPU 증설 계획에 스위치·NIC·업링크 용량 확장이 포함되어 있는가?
하나라도 확인하기 어렵다면, GPU는 충분하지만 네트워크 때문에 그 성능을 제대로 활용하지 못하고 있을 가능성이 있습니다.
RA:X로 병목을 진단하고, AIPub으로 운영합니다
GPU를 얼마나 더 구매할지 결정하기 전에, 현재 인프라의 병목이 어디에서 발생하는지부터 확인해야 합니다.
TEN의 RA:X는 실제 AI 워크로드를 기반으로 GPU, CPU, 메모리, 네트워크와 스토리지 성능을 벤치마킹합니다.장비의 표기 사양만 비교하는 것이 아니라 모델 아키텍처, 데이터 크기와 병렬화 방식에 따른 실제 처리량과 통신 패턴을 측정합니다. 이를 통해 GPU 연산 성능이 부족한지, 노드 간 통신이나 스토리지가 처리량을 제한하고 있는지 실측 데이터를 기반으로 구분할 수 있도록 지원합니다.
RA:X가 병목을 실측하고 최적 구성을 설계했다면, 그 이후엔 지속적인 운영이 필요합니다. AIPub은 데이터센터부터 노드, GPU 카드와 컨테이너 수준까지 PCIe 트래픽과 NVLink 대역폭을 포함한 40개 이상의 지표를 실시간으로 모니터링하고, 여러 팀이 클러스터를 공유하는 환경에서 사용자·팀·프로젝트별로 자원을 분리해 관리합니다.
결론: GPU를 더 사기 전에 확장 효율부터 확인해야 합니다
GPU 클러스터의 성능은 가장 빠른 GPU 한 대의 사양이나 전체 GPU 수만으로 결정되지 않습니다. GPU 간 통신, 물리적 토폴로지, 네트워크 혼잡과 워크로드 배치가 함께 맞물려야 전체 클러스터가 하나의 시스템처럼 움직일 수 있습니다.
GPU를 추가했는데 학습시간이 기대만큼 줄지 않는다면, 먼저 추가된 GPU가 실제 처리량 향상으로 이어지고 있는지 확인해야 합니다. GPU가 연산하고 있는 시간과 통신을 기다리는 시간을 구분하지 못하면, 장비를 늘릴수록 비용만 커지고 확장 효율은 오히려 낮아질 수 있습니다.
AI 인프라의 경쟁력은 GPU를 몇 대 보유했는지를 넘어, 여러 GPU를 얼마나 효율적으로 연결하고 하나의 연산 시스템으로 운영하느냐에서 결정됩니다.
현재 GPU 클러스터의 확장 효율과 네트워크 병목을 실측하고, 투자 전에 무엇을 먼저 개선해야 할지 TEN의 전문가와 함께 확인해 보세요.
참고 자료
Open Compute Project, Multipath Reliable Connection (MRC) Specification
Broadcom, Enabling AI Networking @ Scale with Multi-path Reliable Connections (MRC)
NVIDIA, Overview of NCCL