오픈AI, AMD, 브로드컴, 인텔, 마이크로소프트, NVIDIA와 협력해 네트워킹 프로토콜 개발

대규모 AI 학습 클러스터에서 GPU 간 통신은 가장 큰 병목 중 하나입니다. 기존 데이터센터 네트워크는 트리 구조의 3~4단 스위치 레이어(leaf-spine-super-spine)를 거치며 패킷을 전달하는데, 10만 개 이상의 GPU를 연결하려면 스위치 단수가 늘어나면서 지연(latency), 전력 소모, 케이블링 비용이 기하급수적으로 증가합니다. OpenAI가 AMD·Broadcom·Intel·Microsoft·NVIDIA와 공동 개발한 MRC(Multi-Path Reliable Connection으로 추정되는 오픈소스 프로토콜)는 단일 RDMA 흐름을 단일 경로에 묶지 않고 수백 개의 경로로 패킷을 동시에 분산(packet spraying)시키는 방식을 채택합니다. 이를 통해 ECMP 해시 충돌로 인한 핫스팟을 제거하고, 스위치 레이어를 2단으로 단축해도 비차단(non-blocking) 토폴로지를 유지할 수 있어 이미 OpenAI의 Stargate 슈퍼컴퓨터에서 운영 중이라고 밝혔습니다.

엔지니어 관점에서 가장 큰 의미는 InfiniBand 중심이던 AI 백엔드 네트워크 시장이 본격적으로 이더넷 기반 오픈 표준으로 재편된다는 점입니다. 그동안 Ultra Ethernet Consortium(UEC), NVIDIA의 Spectrum-X, AWS SRD 등이 각자의 멀티패스 RDMA 해법을 내놓았는데, OpenAI가 5대 칩/클라우드 벤더를 묶어 오픈소스로 공개한 것은 사실상 사용자 측 표준으로 굳어질 가능성이 큽니다. 스위치 단수가 절반으로 줄면 광 트랜시버 수가 수십만 개 단위로 감소하고, 이는 토큰당 학습 비용과 추론 인프라 단가에 직접 반영됩니다. 즉 GPT-5/6급 모델의 학습 사이클이 짧아지고, 동일 예산으로 더 큰 컨텍스트·더 많은 파라미터 모델 서비스가 가능해진다는 뜻입니다.

국내 개발자가 직접 MRC 프로토콜을 구현할 일은 드물지만, 영향은 애플리케이션 계층까지 내려옵니다. PyTorch DDP/FSDP, DeepSpeed, Megatron 등을 사용하는 분산 학습 코드는 NCCL을 통해 네트워크에 접근하는데, NCCL 2.21 이후 멀티패스·packet spraying 옵션이 빠르게 추가되고 있습니다. on-prem에서 GPU 클러스터를 운영한다면 RoCEv2 + DCQCN 튜닝, PFC 데드락 회피 설정, NIC 펌웨어(BlueField/ConnectX, Broadcom Thor2) 버전 관리에 더 신경 써야 하며, 클라우드를 쓰는 경우에도 Azure ND H100/H200, AWS P5en, GCP A3 Mega 같은 인스턴스가 어떤 패브릭(UEC 호환 여부)을 쓰는지 확인하면 동일 GPU에서도 학습 속도가 1.3~1.5배 차이 날 수 있습니다.

실무에서 당장 취할 수 있는 액션은 세 가지입니다. 첫째, OpenAI/UEC GitHub에 MRC 스펙이 공개되면 RFC를 훑어보고 사내 네트워크팀과 향후 패브릭 로드맵을 맞춰두는 것이 좋습니다. 둘째, 분산 학습 잡에서 `NCCL_DEBUG=INFO`와 `NCCL_ALGO`, `NCCL_PROTO`, `NCCL_IB_QPS_PER_CONNECTION` 같은 환경 변수로 현재 단일 경로/멀티 QP 동작을 확인하고, 통신 시간이 전체의 30% 이상이라면 멀티패스 지원 NCCL로 업그레이드만 해도 큰 이득을 얻을 수 있습니다. 셋째, 추론 서비스를 운영한다면 KV 캐시 분산, disaggregated prefill/decode 같은 아키텍처가 저지연 패브릭을 전제로 하므로, 차세대 인프라가 보편화되기 전에 vLLM·SGLang의 분산 모드를 미리 PoC해두는 것이 경쟁력으로 이어질 것입니다.