Co-Design and Evaluation of a CPU-Free MPI GPU Communication Abstraction and Implementation

이 논문은 HPE Slingshot 11 네트워크 카드의 기능을 활용하여 CPU 를 통신 경로에서 제거하고 프로그래머의 동기화 부담을 줄인 새로운 MPI 기반 GPU 통신 API 를 설계·구현하였으며, Cabana/Kokkos 프레임워크와 Frontier 슈퍼컴퓨터에서의 평가를 통해 중간 크기 메시지 대기 시간을 최대 50% 단축하고 대규모 할로 교환 벤치마크에서 28% 의 속도 향상을 입증했습니다.

핵심

🏭 1. 배경: 왜 지금까지 문제가 있었을까요? (중간 관리자의 비효율)

상상해 보세요. 거대한 공장이 있습니다.

• GPU는 공장에서 실제로 물건을 만들고 계산하는 고성능 로봇입니다.
• CPU는 공장을 관리하는 관리자입니다.
• 네트워크는 다른 공장들과 물건을 주고받는 운송대입니다.

기존 방식 (CPU 개입):
로봇 (GPU) 이 물건을 보내고 싶을 때, 직접 운송대에게 줄 수 없습니다. 반드시 **관리자 (CPU)**에게 "이거 보내줘"라고 보고해야 합니다. 관리자는 로봇의 작업을 멈추고 확인한 뒤, 운송대에 지시를 내립니다.

• 문제점: 로봇이 일하는 속도가 매우 빠른데, 매번 관리자 (CPU) 를 거쳐야 하므로 시간이 많이 걸립니다. 마치 고위급 직원이 간단한 택배 지시 하나를 내리기 위해 회의실로 달려가는 꼴입니다.

🚀 2. 이 논문의 해결책: "로봇이 직접 운송대를 부르는 시스템"

이 논문은 관리자 (CPU) 를 완전히 배제하고, 로봇 (GPU) 이 직접 운송대 (네트워크 카드) 와 대화할 수 있는 새로운 시스템을 설계했습니다. 이를 **"CPU-Free(중간 관리자 없는) 통신"**이라고 부릅니다.

🌟 핵심 비유: "미리 준비된 주문서 (Persistent Operations)"와 "자동 문 (Trigger)"

이 시스템은 두 가지 마법 같은 도구를 사용합니다.

1. 미리 준비된 주문서 (Persistent Operations):

   • 기존에는 로봇이 물건을 보낼 때마다 "누구에게, 무엇을, 어떻게 보낼까?"를 매번 물어보고 지시해야 했습니다.
   • 새로운 방식은 미리 모든 주문서를 작성해 두고 (Setup 단계), 로봇이 일할 때 이 주문서를 바로 꺼내서 사용합니다. 매번 지시를 내릴 필요가 없으니 훨씬 빠릅니다.

2. 자동 문 (Stream-Triggered Communication):

   • 로봇이 일을 마치고 물건을 준비하면, 스스로 문을 열어서 운송대가 들어오게 합니다.
   • 관리자가 "문 열어!"라고 외칠 필요가 없습니다. 로봇이 "준비 완료!" 신호 (Counter) 를 보내면, 문이 자동으로 열리고 물건이 나갑니다.

🛠️ 3. 어떻게 작동하나요? (HPE Slingshot 11 네트워크 카드의 힘)

이 시스템은 HPE Slingshot 11이라는 최신 네트워크 카드의 특수 기능을 활용합니다. 이 카드는 로봇 (GPU) 이 직접 신호를 보낼 수 있는 전용 버튼을 가지고 있습니다.

• 과거: 로봇이 버튼을 누르면 관리자 (CPU) 가 와서 확인하고, 다시 운송대에 지시.
• 현재: 로봇이 버튼을 누르면, 네트워크 카드가 바로 "준비 완료!" 신호를 받아 운송을 시작합니다.

이 과정에서 관리자 (CPU) 가 개입할 틈이 전혀 없습니다. 그래서 통신 속도가 비약적으로 빨라집니다.

📊 4. 결과는 어땠나요? (실제 슈퍼컴퓨터에서의 테스트)

연구팀은 미국의 거대 슈퍼컴퓨터인 Frontier와 Tuolumne에서 이 시스템을 테스트했습니다.

• 속도 향상: 작은 크기의 데이터를 보낼 때, 기존 방식보다 최대 50% 더 빨라졌습니다. (마치 10 분 걸리던 출근길이 5 분으로 줄어든 것과 같습니다.)
• 대규모 확장: 8,192 개의 GPU 가 함께 일하는 상황에서, 복잡한 계산 (할로 교환) 을 할 때 28% 더 빠른 속도를 기록했습니다.
• 편의성: 기존에 쓰던 복잡한 프로그래밍 방식 (MPI) 을 크게 바꾸지 않아도, 이 새로운 시스템을 적용할 수 있어 개발자들이 쓰기에도 편리합니다.

💡 5. 요약: 왜 이것이 중요한가요?

이 논문은 **"AI 와 과학 계산의 속도를 한 단계 업그레이드하는 열쇠"**를 찾았습니다.

• 기존: 로봇이 일할 때 관리자가 방해해서 느림.
• 새로운 방식: 로봇이 스스로 네트워크를 제어해서 빠름.

이 기술은 앞으로 더 빠르고 강력한 AI 모델 학습이나 기후 변화 예측, 신약 개발 같은 초고성능 컴퓨팅 (HPC) 작업들이 훨씬 더 효율적으로 이루어지도록 돕는 게임 체인저가 될 것입니다.

한 줄 요약:

"중간 관리자 (CPU) 를 쫓아내고, 로봇 (GPU) 이 직접 운송대 (네트워크) 를 부르는 시스템을 만들어, 슈퍼컴퓨터의 통신 속도를 50% 이상 높였습니다."

기술 요약

1. 문제 정의 (Problem)

현대 HPC(고성능 컴퓨팅) 및 머신러닝 시스템에서 GPU 기반 애플리케이션의 성능을 극대화하기 위해서는 **통신 경로에서 CPU 를 제거하는 것 (CPU-free communication)**이 필수적입니다.

• 기존 방식의 한계: 전통적인 GPU 인지 (GPU-aware) MPI 통신은 데이터 수신, GPU 커널 실행, 결과 전송 과정에서 CPU 와 GPU 간의 동기화 (Kernel Launch, Memory Barrier, Stream Synchronization) 가 필수적입니다. 이로 인해 14 마이크로초의 추가 지연 (Latency) 이 발생하며, 특히 작은 메시지 (예: Halo 교환) 의 경우 전체 지연 시간의 2080% 를 차지할 수 있습니다.
• 기존 대안의 부족:
  • 일부 CPU-free 접근법 (예: NVSHMEM) 은 1 면 (One-sided) 통신만 지원하거나, 메시지 매칭 (Message Matching) 과 같은 HPC 에서 필수적인 2 면 (Two-sided) 통신 기능을 제거하여 사용성을 떨어뜨립니다.
  • NCCL 과 같은 다른 라이브러리는 여전히 CPU 가 통신의 주요 경로 (Fast Path) 에 개입하거나, 프로그래머에게 복잡한 동기화 부담을 줍니다.
• 핵심 과제: MPI 의 익숙한 2 면 통신 추상화를 유지하면서, CPU 개입 없이 GPU 가 직접 네트워크 인터페이스 카드 (NIC) 와 통신할 수 있는 고성능 API 를 설계하는 것입니다.

2. 방법론 (Methodology)

이 논문은 HPE Slingshot 11 네트워크 카드의 기능을 활용하여 CPU-free MPI GPU 통신 API를 설계하고 구현했습니다.

가. API 설계 (Proposed MPI GPU Triggering API)

기존 MPI 표준을 최대한 유지하면서 GPU 스트림 트리거링을 지원하는 새로운 추상화를 도입했습니다.

• MPI_Queue: GPU 스트림과 연결된 통신 작업의 순서 집합을 관리하는 객체입니다. 통신 시작과 대기 작업을 GPU 스트림에 큐잉하여 CPU 개입을 배제합니다.
• MPI_Match: 기존 영구 (Persistent) 통신 요청을 미리 매칭 (Matching) 시키는 함수입니다. 이를 통해 통신의 임계 경로 (Critical Path) 에서 메시지 매칭 로직을 제거하고, GPU 스트림 트리거링을 가능하게 합니다.
• 지연 작업 (Deferred Work): libfabric 의 지연 작업 큐 (DWQ) 와 트리거 카운터 (Triggering Counters) 기능을 활용합니다. GPU 커널이 카운터 값을 변경하면 NIC 가 자동으로 데이터 전송을 수행하고, 수신 측의 완료를 GPU 가 직접 폴링 (Polling) 할 수 있도록 설계되었습니다.

나. 구현 전략 (Implementation on HPE Slingshot 11)

• 데이터 이동: fi_write(지연 작업) 를 사용하여 데이터를 직접 수신 버퍼로 전송합니다.
• 수신 준비 확인 (Receiver Readiness): 표준 MPI 전송은 수신 버퍼가 준비될 때까지 데이터를 보낼 수 없습니다. 이를 해결하기 위해, 수신 측 GPU 가 준비되면 fi_atomic 을 통해 송신 측에 'CTS(Clear-To-Send)' 신호를 보내는 메커니즘을 구현했습니다. 이는 추가적인 네트워크 왕복 (Round-trip) 없이 GPU 간 메모리 폴링으로 완료 상태를 확인합니다.
• 데드락 방지: GPU 스케줄러가 통신 스트림을 실행하지 않아 발생하는 데드락을 방지하기 위해, 모든 통신을 우선순위 GPU 스트림에서 수행하도록 권장합니다.

다. 적용 사례 (Cabana/Kokkos 프레임워크)

이 API 를 Cabana 성능 이식성 프레임워크의 StreamHalo 클래스에 적용하여, Halo 교환 (Halo Exchange) 과 같은 복잡한 통신 패턴을 CPU 없이 수행하도록 개조했습니다.

3. 주요 기여 (Key Contributions)

1. 새로운 GPU 통신 API 설계: CPU-free 통신을 지원하면서도 MPI 의 친숙한 2 면 통신 추상화 (Two-sided semantics) 를 대부분 유지하는 API 설계.
2. Halo 교환 객체 개선: Cabana 프레임워크의 성능을 높이기 위해 스트림 트리거링을 활용한 StreamHalo 구현 및 평가.
3. HPE Slingshot 11 최적화 구현: libfabric 의 지연 작업 큐와 카운터 기능을 활용하여 완전한 CPU-free MPI 포인트 투 포인트 통신을 구현.
4. 성능 평가: Frontier 및 Tuolumne 슈퍼컴퓨터를 이용한 광범위한 벤치마크를 통해 성능 향상 효과 입증.

4. 평가 결과 (Results)

ORNL Frontier(8,192 개 GPU) 및 LLNL Tuolumne 슈퍼컴퓨터에서 Cray MPICH 와 비교 평가했습니다.

• 마이크로벤치마크 (GPU Ping-Pong):
  • 중간 크기 메시지 (Medium messages) 에서 지연 시간 (Latency) 이 최대 50% 감소했습니다.
  • 작은 메시지 (4KB ~ 1MB) 에서 대역폭이 크게 향상되었으나, 매우 큰 메시지 (8MB 이상) 에서는 Cray MPICH 가 더 높은 대역폭을 보였습니다 (하드웨어 최적화 차이).
• 강한 확장성 (Strong Scaling) - Halo Exchange:
  • Frontier 시스템의 8,192 개 GPU 에서 실행된 Cabana Halo 교환 벤치마크에서 **최대 28% 의 속도 향상 (Speedup)**을 기록했습니다.
  • 특히 대규모 문제 (30GB) 에서 스트림 트리거링 'Ready Send' 방식이 Cray MPICH 보다 28% 더 높은 평균 속도 향상을 보였습니다.
  • Tuolumne 시스템에서도 유사한 경향을 보였으나, 노드당 GPU 수에 따른 MPICH 성능 변동이 더 컸습니다.

5. 의의 및 결론 (Significance and Conclusion)

• 성능 혁신: CPU 를 통신 경로에서 완전히 제거함으로써, 통신 지연이 지배적인 HPC 워크로드 (예: 격자 기반 시뮬레이션) 의 성능을 획기적으로 개선할 수 있음을 입증했습니다.
• 프로그래밍 모델 유지: 기존 MPI 프로그래밍 모델을 크게 변경하지 않으면서도 GPU 네이티브 통신의 이점을 얻을 수 있어, 기존 HPC 애플리케이션의 마이그레이션 장벽을 낮춥니다.
• 미래 지향성: 이 연구는 GPU 와 네트워크 하드웨어의 긴밀한 협력 (Co-design) 이 필요함을 보여주며, 향후 더 다양한 아키텍처 (NVIDIA GPU 등) 로의 확장과 집단 통신 (Collective Communication) 최적화를 위한 기반을 마련했습니다.

요약하자면, 이 논문은 HPE Slingshot 11 하드웨어의 기능을 활용하여 MPI 의 2 면 통신 semantics 를 유지하면서 CPU 개입 없이 GPU 가 직접 통신하는 새로운 API 를 설계하고, 이를 통해 대규모 HPC 시스템에서 통신 지연을 획기적으로 줄이고 확장성을 높였음을 증명하는 연구입니다.