Ray Data와 Ray Serve로 GPU 활용률을 끌어올린 구조

요약

네이버가 NAVER ENGINEERING DAY 2025에서 발표한 GPU 활용률 개선 작업기. 기존 ML 파이프라인은 GPU를 할당받고도 데이터 로딩·전처리 대기로 실제 연산 시간이 짧아 활용률이 낮았던 상태. Ray Data 스트리밍으로 CPU 전처리와 GPU 추론을 겹치고, Ray Serve + vLLM으로 동시 요청을 단일 GPU 배치로 묶어 처리량을 끌어올림. KubeRay Operator로 Kubernetes 위에서 클러스터 라이프사이클 관리. 동일 GPU 수 대비 처리량 수 배.

내용

GPU를 할당받아도 실제 연산이 차지하는 시간이 짧고 데이터 로딩·전처리 대기가 길어 GPU Utilization이 낮게 나오는 게 출발점. 배치 처리는 CPU 전처리와 GPU 추론이 직렬로 도는 구조라 한쪽이 비는 동안 다른 쪽이 놀고, 모델 서빙은 트래픽 변동에 따라 GPU가 유휴 상태로 남음. 한 곳에서 짠 손실이 다른 곳에서 그대로 노출되는 두 갈래 손실.

본 발표는 분산 처리 프레임워크 Ray로 두 갈래를 모두 다듬은 작업기. Ray의 핵심 컴포넌트 Ray Data·Ray Serve·Ray LLM·KubeRay가 어떻게 결합되는지가 본문 줄기.

해결 / 접근

Ray Data — CPU·GPU 파이프라인 스트리밍 오버랩

Ray Data의 스트리밍 실행 모델로 CPU 전처리와 GPU 추론을 시간상 겹침. map_batches()로 배치 단위 변환을 선언하고 num_gpus 파라미터로 GPU 할당 제어. 데이터 로딩 → 전처리 → 추론 → 후처리를 하나의 파이프라인으로 묶고, 단계 사이엔 백프레셔가 자동 적용되어 빠른 단계가 느린 단계를 밀어내지 않음. 발표 본문에선 트러블슈팅 4건과 PipelineStep 추상 클래스도 같이 다룸.

Ray Serve + vLLM — 서빙에서 GPU 활용률 극대화

Ray Serve의 deployment 단위로 vLLM 엔진을 래핑. 오토스케일링 정책은 GPU 메트릭 기반으로 설정. vLLM의 continuous batching이 동시 요청을 GPU 단일 배치로 묶어 처리량을 늘리고, 멀티 모델 서빙은 Ray Serve 라우팅으로 모델별 GPU를 동적 할당. 배치 + 서빙 양쪽을 같은 인터페이스로 다룰 수 있도록 ModelInference, BaseDeployment 인터페이스를 노출.

KubeRay 기반 클러스터 운영

Kubernetes 위에서 Ray 클러스터를 운영하기 위해 KubeRay Operator로 라이프사이클 관리. Head node와 Worker node를 Pod으로 배포하고, GPU 노드는 tolerations + nodeSelector로 스케줄링. 클러스터 오토스케일러와 연동해 배치 잡 실행 시에만 GPU 노드를 스케일 아웃 — 노는 GPU에 비용을 태우지 않는 구조.

Ray LLM — ServeManager로 LLM 배포

vLLM 기반 LLM 추론 파이프라인을 ServeManager로 통합 배포. 발표에서는 ServeManager 구조 + 트러블슈팅 4건도 같이 공유.

결과 / 참고

• 동일 GPU 수 대비 처리량 수 배 (구체 수치는 발표 슬라이드 기준)
• GPU 활용률 100% 달성 — 배치 사이즈 / prefetch 버퍼 / actor 수 조합으로 idle 구간 제거
• 모니터링: Ray Dashboard에서 GPU utilization, throughput, 큐 깊이를 실시간 추적
• 적용 범위: 사내 ML 배치 추론 + 모델 서빙 + LLM 추론 파이프라인
• 발표 채널: NAVER ENGINEERING DAY 2025(5월) 사내 세션, 네이버 D2에 영상 공개
• 출처: NAVER D2, "Ray를 활용한 GPU Util 100% MLOps: 배치처리부터 모델 서빙까지"