엔비디아, 파이썬 기반 고속 I/O 라이브러리 KvikIO와 GPUDirect Storage 연동 가이드 공개

파이썬 환경의 GPU 직접 전송 기술

AI 모델 훈련 규모와 데이터셋 크기가 빠르게 팽창하면서 저장소에서 연산 가속기로 데이터를 지연 없이 공급하는 기술의 중요성이 커지고 있다. 엔비디아의 매그넘 IO GPUDirect Storage(GDS)는 호스트 중앙처리장치(CPU) 메모리를 거치지 않고 호환 저장 장치와 그래픽처리장치(GPU) 메모리 사이의 직접 데이터 전송 경로를 제공해 시스템 부하를 낮춘다. 하지만 주된 인터페이스가 C 언어 기반 cuFile 라이브러리 형태로 제공되어 대다수 신규 AI 프로젝트가 구축되는 파이썬 환경에서는 직접 다루기가 까다로웠다.

엔비디아는 이러한 격차를 해소하기 위해 고성능 파일 입출력 라이브러리인 KvikIO를 제공하고 있다. 파이썬 개발자는 KvikIO가 제공하는 고수준 인터페이스를 통해 복잡한 하위 API를 직접 다루지 않고도 GPU 메모리에 데이터를 바로 읽어 들일 수 있다. 이번 기술 해설에서는 KvikIO의 파이썬 인터페이스를 설정하고 저장 장치 데이터를 GPU 메모리로 적재한 뒤 실제 가속 경로가 활성화되었는지 검증하는 구체적인 동작 구조를 설명한다.

2단계 분기 구조와 전송 경로 결정

KvikIO를 통한 입출력 요청은 KvikIO와 cuFile이라는 두 개의 독립적인 제어 계층을 순차적으로 거친다. 먼저 응용 프로그램이 파일 경로와 GPU 버퍼를 지정하면 KvikIO는 기본 호환 모드 설정과 전송 크기 기준에 따라 cuFile을 호출할지 자체 호스트 메모리 경유 경로를 사용할지 결정한다. 기본 설정인 자동 모드에서는 cuFile 호출을 우선 시도하되 사용 불가능하면 호스트 메모리 경로로 전환하며, 전송 크기가 기준치인 16KiB보다 작으면 즉시 호스트 메모리 경로를 탄다.

KvikIO가 cuFile을 선택하더라도 하드웨어 가속 전송이 무조건 보장되는 것은 아니다. 요청을 전달받은 cuFile은 시스템 하드웨어 지원 여부, 파일 시스템 종류, 드라이버 적재 상태 등을 추가로 평가하여 자체 가속 경로를 쓸지 CPU 경유 호환 경로를 쓸지 최종 판단한다. 즉 상위 계층에서 cuFile 인터페이스를 성공적으로 호출했더라도 실제 하위 물리 계층에서는 가속 드라이버 대신 호환 경로가 동작할 수 있으므로 단계별 경로 확인이 필수적이다.

작업 분할과 내부 병렬 처리 제어

대용량 데이터를 전송할 때 KvikIO와 cuFile은 각각 독립적인 방식으로 작업을 나누어 처리한다. 1GiB 크기의 데이터를 읽는 경우 KvikIO의 기본 작업 단위인 4MiB 설정이 적용되면 전체 요청은 256개의 cuFile 요청 단위로 분할된다. 반대로 KvikIO의 작업 단위를 1GiB 전체로 키우면 단 하나의 거대한 요청이 cuFile로 전달되며, 이 경우 cuFile 내부 작업자 스레드 수와 최대 병렬 처리 제한 수치에 따라 작업이 다시 균등하게 쪼개진다.

cuFile 설정 파일에 정의된 실행 파라미터는 KvikIO 설정과 별개로 작동한다. cuFile은 내부 스레드 풀 활성화 여부, GPU 큐당 최대 스레드 수, 최소 입출력 임계 크기 기준을 참조하여 전달받은 작업을 스케줄링 단위로 나눈다. 대상 버퍼가 사전 등록되지 않은 상태라면 가속 드라이버의 GPU 바운스 버퍼를 거쳐 복사되며, 이때 스케줄링 분할 크기와 물리적 전송 단위는 별개로 관리된다.

가속 경로 검증과 데이터 생태계 확장

입출력 작업이 실제로 하드웨어 가속 경로를 거쳤는지 파악하기 위해서는 cuFile 런타임 통계를 확인해야 한다. 통계 수집 레벨을 3으로 설정한 뒤 전용 진단 도구를 실행하면 가속 커널 모듈을 통해 처리된 작업 횟수와 호환 경로로 우회된 작업 횟수가 분리되어 집계된다. 이를 통해 256개로 분할된 1GiB 작업 전체가 호스트 메모리 복사 없이 가속 커널 모듈을 온전히 통과했는지 수치로 검증할 수 있다.

KvikIO는 데이터 과학을 위한 엔비디아 CUDA-X 라이브러리의 핵심 구성 요소로 자리 잡고 있다. 초기에는 GPU 데이터프레임 라이브러리인 cuDF에서 대용량 파일 형식을 빠르게 읽어 들이기 위해 개발되었으나, 현재는 디지털 병리학 영상 분석 및 분산 데이터 분석 작업 등 다양한 고성능 파이프라인으로 적용 범위가 확장되고 있다. 개발자는 두 제어 계층의 동작 차이를 이해함으로써 각자의 작업 부하에 맞게 입출력 설정을 최적화할 수 있다.

적용 조건과 시스템 구성 요구 사항

KvikIO 기반 GDS 가속 경로를 정상적으로 구동하려면 특정한 시스템 환경과 하드웨어 구성이 갖추어져야 한다. 검증된 환경은 엔비디아 H100 GPU, CUDA 13.3, cuFile 1.18 버전 기반의 리눅스 시스템이며, 로컬 NVMe 저장 장치와 ext4 파일 시스템이 사용된다. 또한 GPU와 저장 장치 사이의 데이터 이동 경로가 단일 PCIe 브리지 이하를 통과하는 직접 토폴로지를 구성해야 한다.

시스템 수준의 제약 사항도 확인해야 한다. PCIe 피어 투 피어 전송을 유지하기 위해 시스템 입출력 메모리 관리 유닛(IOMMU)과 접근 제어 서비스(ACS)를 비활성화해야 하며, 가속 전송을 담당하는 전용 커널 모듈이 정상 적재되어 있어야 한다. 이러한 조건이 하나라도 충족되지 않거나 저장소 권한이 부족한 경우 시스템은 성능이 저하되는 호환 모드로 자동 전환된다.