AWS EFA 환경에서 NCCL을 활용한 분산 학습 성능 최적화
분산 학습(Distributed Training)을 위해 다수의 GPU 간 효율적인 통신이 필수적이며, NCCL(NVIDIA Collective Communications Library)이 핵심 역할을 수행함
AWS EFA(Elastic Fabric Adapter)는 고속 네트워크 인프라를 제공하며, aws-ofi-nccl 플러그인을 통해 NCCL과 통합됨
NCCL은 하드웨어 토폴로지를 자동 감지하고, 데이터 크기에 따라 최적의 통신 알고리즘(Ring, Tree)을 선택하여 성능을 극대화함
GPUDirect RDMA를 통해 CPU와 시스템 메모리 오버헤드를 줄여 GPU 간 직접 데이터 전송을 지원함
MoE(Mixture-of-Experts) 모델과 같은 비대칭 통신 패턴에서는 NCCL의 한계가 존재하며, GPUDirect Async, NVSHMEM, PPLX-kernels과 같은 기술이 대안으로 제시됨
분산 학습 환경에서의 GPU 간 통신 필요성
대규모 딥러닝 모델 학습에는 수십, 수백 개의 GPU를 활용하는 분산 학습(Distributed Training)이 필수적이다. 각 GPU는 데이터의 일부 또는 모델의 일부를 처리하며, 학습 과정에서 지속적인 정보 교환이 필요하다. 데이터 병렬 학습에서는 각 GPU가 그래디언트(Gradient)를 계산한 후, 모든 GPU에 동기화하여 일관된 모델 업데이트를 수행한다. 이 동기화 과정의 효율성이 전체 학습 성능을 좌우하며, GPU 간 통신 병목(Communication Bottleneck)은 학습 시간을 크게 증가시킬 수 있다. 따라서 고성능 GPU 간 통신 라이브러리가 분산 학습의 성패를 결정하는 핵심 요소가 된다.
NCCL과 MPI의 차이점: GPU 간 통신 vs CPU 간 통신
분산 컴퓨팅에서 노드 간 데이터 교환을 위한 통신 라이브러리는 워크로드 특성에 따라 다르다. MPI(Message Passing Interface)는 CPU 프로세스 간 데이터 교환을 위한 표준 인터페이스이며, 엔지니어링 시뮬레이션과 같은 HPC(High-Performance Computing) 워크로드에 주로 사용된다. 반면, NCCL(NVIDIA Collective Communications Library)은 GPU 간 통신을 위해 NVIDIA가 개발한 라이브러리이다. NCCL은 NVLink, NVSwitch, GPUDirect RDMA 등 GPU 전용 하드웨어 기능을 최대한 활용하여, CPU가 네트워크 통신을 중재하는 기존 방식과 달리 GPU가 직접 다른 GPU와 통신할 수 있도록 한다. AWS EFA 환경에서 MPI는 libfabric API를 직접 사용하여 EFA 하드웨어에 접근하는 반면, NCCL은 aws-ofi-nccl 플러그인을 통해 간접적으로 접근한다.
AWS EFA 환경에서의 NCCL 아키텍처
AWS EFA 환경에서 NCCL은 여러 계층의 소프트웨어와 하드웨어 구성 요소로 구성된다. 애플리케이션 계층은 딥러닝 프레임워크(PyTorch, TensorFlow)가 실행되는 영역이며, NCCL 라이브러리의 API를 호출하여 통신을 수행한다. NCCL 계층은 GPU 간 통신의 핵심 오케스트레이터 역할을 하며, 집합 통신 요청을 최적화된 통신 패턴으로 변환한다. aws-ofi-nccl 플러그인은 NCCL과 libfabric 사이의 브리지 역할을 하며, NCCL의 통신 요청을 libfabric API 호출로 변환하여 NCCL이 EFA를 활용할 수 있도록 한다. libfabric은 고성능 네트워크 통신을 위한 표준 인터페이스를 제공하며, EFA provider를 통해 EFA 하드웨어의 기능에 직접 접근한다. EC2 인스턴스는 EFA 드라이버를 로드하여 EFA 하드웨어를 초기화하고, User space에서 하드웨어에 직접 접근할 수 있는 경로를 제공한다.
NCCL의 집합 통신 연산과 자동 최적화
NCCL은 분산 학습에서 여러 GPU가 협력하여 모델을 학습할 때, GPU 간 데이터를 효율적으로 교환하기 위해 집합 통신(Collective Communication)을 사용한다. 집합 통신은 그룹 전체가 조율된 방식으로 데이터를 교환하는 통신 패턴으로, 일대일 통신의 비효율성을 해결한다. NCCL은 하드웨어 토폴로지를 자동으로 감지하고, 데이터 크기와 GPU 개수에 따라 최적의 통신 알고리즘을 선택한다. 링(Ring) 알고리즘은 대용량 데이터 전송에, 트리(Tree) 알고리즘은 소량 데이터 전송에 유리하다. 또한, NCCL은 대용량 데이터를 청크(Chunk)로 나누어 파이프라인 방식으로 처리하여 전송과 연산을 병렬로 수행한다. 이러한 자동 튜닝 덕분에 개발자는 별도의 복잡한 설정 없이 하드웨어의 최대 성능을 활용할 수 있다.
NCCL의 자동 최적화: 링(Ring) vs 트리(Tree)
NCCL은 데이터 크기와 GPU 개수에 따라 최적의 통신 알고리즘을 자동으로 선택한다. 링 알고리즘은 GPU들이 원형으로 연결되어 데이터를 순차적으로 전달하는 방식으로, 모든 GPU가 동시에 인접 GPU와 데이터를 주고받아 네트워크 대역폭을 최대한 활용할 수 있다. 하지만 레이턴시 오버헤드가 GPU 수에 비례하여 커지므로, 수백 MB 이상의 대용량 데이터를 전송할 때 주로 사용된다. 트리 알고리즘은 계층적으로 데이터를 모으는 방식으로, 레이턴시가 O(log N)으로 링의 O(N)보다 낮지만, 대역폭 활용도는 링보다 낮다. 수 KB에서 수 MB 정도의 작은 데이터를 전송할 때 주로 사용된다. NCCL은 이러한 알고리즘 선택을 데이터 크기와 GPU 개수를 기반으로 자동 수행하며, 개발자는 별도 튜닝 없이도 성능을 확보할 수 있다.
NCCL의 한계와 미래 기술: MoE 모델을 위한 대안
NCCL은 AllReduce, AllGather와 같은 집합 통신 연산에 최적화되어 있으며, 모든 GPU가 동일한 크기의 데이터를 주고받는 대칭적 패턴에 적합하다. 하지만 최근 대규모 모델 학습에서 부상하는 MoE(Mixture-of-Experts) 모델은 입력 토큰에 따라 일부 전문가 네트워크만 선택적으로 활성화하는 구조로, 각 토큰이 어떤 전문가로 라우팅될지 매 스텝마다 달라지는 동적·비대칭 All-to-All 통신이 빈번하게 발생한다. NCCL의 대칭적 집합 통신 모델로는 이런 불규칙 패턴을 효율적으로 처리하기 어렵다. 이러한 한계를 극복하기 위해 GPUDirect Async, NVSHMEM, PPLX-kernels과 같은 기술이 제시되고 있으며, 이는 NCCL 중심 모델을 넘어서는 GPU 중심 통신 패러다임을 제시한다.
