GeminiFS: Host와 GPU 모두 Storage를 Direct 접근하여 사용할 수 있는 솔루션
AI/ML 워크로드가 대형화되면서, GPU가 데이터를 직접 NVMe SSD에서 불러와 처리하는 구조가 관심을 받고 있습니다. NVIDIA의 GDS(GPU Direct Storage)나 BaM(Big Accelerator Memory)등이 대표적인 기술입니다. 하지만 이 기술들은 GPU는 Block 단위로 Storage I/O는 가능하지만, 파일시스템 수준의 Abstraction이나 Coherency, Metadata 관리 등은 불가능하거나 제한적으로만 가능합니다. 즉, GPU가 실제로 파일을 열 때 여전히 CPU가 개입해야 하거나, CPU와 GPU간 데이터 공유 및 동기화는 개발자나 시스템 수준에서 처리해야 합니다.
이번 포스팅에서는 USENIX FAST 2025에 발표된 "GeminiFS" 논문을 바탕으로, GPU가 파일을 직접 열고 쓰는 파일 시스템 구조와 실험 결과를 소개합니다.
1. 논문 정보
- 제목: GeminiFS: A File System for GPUs
- 저자: Y. Qiu et al.
- 학회: USENIX FAST 2025
- 링크: https://www.usenix.org/conference/fast25/presentation/qiu
2. 기존 솔루션과 한계
| 항목 | BaM | GDS | GeminiFS |
| 파일 시스템 지원 | ❌ | 제한적 | ✅ |
| 접근 방식 | 블록 기반 | 파일 기반 | 파일 기반 |
| GPU 직접 I/O | ✅ | ✅ | ✅ |
| GPU 직접 NVMe 접근 | ✅ | ✅ | ✅ |
| GPU Metadata 접근 | ❌ | 일부 가능 | ✅GVDK 기반 |
| GPU-CPU 동기화/Coherency | ❌ | ❌ | ✅ (G_sync) |
참고: GeminiFS에서 GPU가 접근하는 메타데이터는 GVDK 포맷으로 정의된 GPU-visible metadata를 말합니다. 이에는 다음과 같은 정보들이 포함됩니다:
(1) 파일 크기 (file size)
(2) 파일의 논리 블록 ↔ 물리 블록 매핑 정보: 어떤 offset에 어떤 SSD 블록이 대응되는지
(3) 파일의 alignment, 블록 크기, 파일 타입
(4) 파일 상태 (open/closed), write-back 필요 여부
(5) 캐시 정책, page dirty 상태 등 GPU-side I/O 처리에 필요한 관리 정보
즉, GPU가 G_open() 시점에 메타데이터를 읽어서,
- 어떤 위치를 읽어야 하는지
- 어느 블록부터 얼마나 데이터를 가져올지
- write-back 시 어디에 기록할지 등을 CPU 개입 없이 결정할 수 있게 해주는 핵심 정보들입니다.
3. GeminiFS 주요 설계
- GVDK 포맷: GPU용 메타데이터 포함
- SNVMe 드라이버: GPU와 CPU 각각 NVMe I/O Queue 분리 운영
- GPU-friendly Page Cache: GPU 내부에 별도 캐시 생성
- libGemini: G_open, G_read 등 POSIX 유사 API 제공
4. 실험 환경
- CPU: Intel Xeon 5416S (64코어)
- GPU: NVIDIA 80GB HBM GPU (PCIe Gen4)
- RAM: 512GB
- 스토리지:
- Intel Optane P5800X (주 실험, 4µs latency)
- ZhiTi TiPro 7000 (비교용, TLC SSD)
- OS: Ubuntu 20.04, Linux 5.15
5. 실험 결과 요약
✅ Figure 6: 파일 읽기/쓰기 처리량
- 4KB~1MB 파일 단위 I/O에서 GPUfs 대비 최대 6배, GDS 대비 1.7배 향상
- GPU가 직접 NVMe에 접근하고, 캐시를 활용해 성능 극대화
✅ Figure 7: ML/AI 워크로드
- GNN, GPT 등 모델 로딩 속도에서 BaM 대비 3.1x, GDS 대비 1.8x 향상
- GPU가 직접 파일을 다루는 구조가 실제 워크로드에서 유리함을 증명
6. 결론
GeminiFS는 GPU가 처음으로 파일 시스템을 직접 다룰 수 있도록 설계된 파일 시스템입니다. GPU 관점에서의 File Open, Metadata access, Cache, 동기화까지 모두 제공하며, 실제 ML 워크로드에서도 높은 성능 향상을 보였습니다.
다만, 실험은 대부분 Optane SSD에서 수행되었기 때문에, 일반적인 SSD 환경에서는 성능 이점이 줄어들 수 있습니다. 그럼에도 GeminiFS는 GPU 중심 컴퓨팅 환경에서 Data path를 단순화하고, I/O Bottleneck을 해결하는 방향으로 매우 중요한 설계를 보여주고 있습니다.
기존 BaM, GDS 등의 기술은 개발자가 Device level 까지 직접 제어해야 하는 복잡성 가지고 있습니다. BaM은 GPU가 SSD를 직접 Block 단위로 Access 해야하고, 개발자가 직접 파일 ↔ 블록 주소 Mapping을 관리해야 하며, 파일 단위 Abstraction은 전혀 제공되지 않습니다. GDS는 CPU가 파일 핸들을 열고, GPU에 전달해야만 GPU가 데이터를 Load 할 수 있으므로, 개발자가 CPU ↔ GPU 사이에서 동기화 및 복사 타이밍을 관리해줘야 합니다.
GeminiFS는 GPU에서의 파일 I/O를 추상화함으로써 호스트 개발 자유도를 높여주기 때문에, 복잡한 분산 Training/Inference Pipeline을 구성하는 Echo Build나 다양한 AI 시스템 설계에 있어 실질적으로 유의미한 구조적 이점을 제공합니다.
향후 GPU가 CPU 없이 독립적으로 전체 데이터 파이프라인을 제어하는 시대를 대비한 선행 연구로서, 그 가치를 높게 평가할 수 있습니다.
참고 링크
https://www.youtube.com/watch?v=zE-zVu4huKM
https://www.usenix.org/conference/fast25/presentation/qiu
GeminiFS: A Companion File System for GPUs | USENIX
Open Access Media USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and o
www.usenix.org