ObjectCache: KV 캐시를 오브젝트 스토리지에 저장해 LLM 서빙 DRAM 병목을 해소하는 방법

KV 캐시가 DRAM을 채우는 이유

LLM 서빙에서 프리픽스 KV 캐싱(prefix KV caching)은 TTFT(Time to First Token)를 줄이는 핵심 기법이다. 여러 요청이 같은 시스템 프롬프트나 공통 컨텍스트를 공유할 때, 이미 계산한 KV 쌍을 메모리에 보관해 두고 재사용한다. 중복 프리필(prefill) 연산을 건너뛰어 TTFT를 크게 단축한다.

문제는 캐시 크기다. RAG 파이프라인, 에이전트 루프, 멀티-턴 대화 시스템은 수천~수만 토큰 길이의 공유 프리픽스를 가진다. 모델 파라미터 수와 레이어 수에 비례해 KV 캐시 크기도 커진다. 대형 모델을 다수의 동시 세션으로 서빙하면 KV 캐시가 GPU VRAM을 넘어 호스트 DRAM을 채운다.

현재 주류 해법: 원격 DRAM 풀(remote DRAM pool). 서빙 클러스터에 KV 캐시 전용 메모리 노드를 추가한다. 속도는 빠르지만 비용이 선형으로 증가한다. 캐시 크기가 DRAM 용량 상한에 부딪히면 클러스터 규모를 키워야 하는 구조다.

2026년 5월, ETH 취리히·HPE Labs·홍콩중문대(선전)의 공동 연구팀은 이 한계를 정면으로 다룬 논문 ObjectCache를 arXiv에 공개했다(arXiv:2605.22850). 핵심 아이디어는 단순하다. KV 캐시를 값비싼 DRAM 풀 대신 S3 호환 오브젝트 스토리지에 저장한다.

오브젝트 스토리지와 런타임 KV 캐시 사이의 의미론적 간격

"S3에 KV 캐시를 저장한다"는 발상은 직관적이다. 그런데 실제로 구현하면 즉각 문제가 드러난다.

오브젝트 스토리지는 오브젝트 단위로 데이터를 이동한다. 오브젝트 하나를 PUT하고 나중에 GET한다. 반면 LLM 프리필 중 GPU가 KV 캐시를 소비하는 방식은 전혀 다르다.

트랜스포머 프리필 과정을 생각해 보자. 입력 토큰들은 레이어 0부터 레이어 N-1까지 순차적으로 처리된다. 레이어 k를 계산하려면 레이어 k의 K·V 행렬이 있어야 한다. 레이어 0의 KV가 준비되어야 레이어 1 연산을 시작할 수 있다.

이것이 ObjectCache가 말하는 의미론적 간격(semantic gap)이다.

전체 KV 캐시를 하나의 오브젝트로 저장하면, GPU가 레이어 0을 필요로 할 때 레이어 N-1까지 포함된 전체 오브젝트를 받아야 한다. 전체 전송이 끝날 때까지 GPU는 기다린다. 이 방식으로는 오브젝트 스토리지의 높은 TTFT 페널티를 피할 수 없다.

ObjectCache 핵심 설계: 레이어 순서 프로토콜

ObjectCache는 KV 캐시를 레이어 단위로 분할해 저장한다. 레이어 k의 KV 데이터는 독립적인 스토리지 오브젝트로 관리된다.

그리고 전송 스케줄을 GPU 소비 순서에 맞춘다. 프리필 요청이 들어오면 ObjectCache는 레이어 0 KV 블록 전송부터 시작한다. GPU가 레이어 0 연산을 마치기 전에 레이어 1 KV 블록이 도착하도록 타이밍을 조율한다. 연산과 전송이 파이프라인 방식으로 겹친다.

핵심 통찰: 프리필이 레이어 k를 처리하는 시간 동안 레이어 k+1, k+2, … 의 KV 블록을 스토리지에서 미리 가져올 수 있다. GPU 연산 시간이 I/O 전송 시간을 대부분 가려준다.

대역폭 스케줄러

프로덕션 서빙 서버에서는 수십~수백 개의 요청이 동시에 처리된다. 모든 요청이 스토리지 네트워크 대역폭을 공유한다. 단순히 모든 요청에 동일한 대역폭을 배분(equal bandwidth sharing)하면 어떤 요청은 레이어 KV를 늦게 받아 GPU 연산이 멈춘다.

ObjectCache의 대역폭 스케줄러는 각 요청의 레이어 진행 상태를 추적한다. GPU가 레이어 k를 처리 중일 때, 레이어 k+1의 KV 블록이 아직 전송되지 않은 요청을 우선순위로 올린다. 반대로 이미 다음 레이어가 준비된 요청에는 대역폭을 덜 준다.

결과: 공유 대역폭 상한이 있는 환경에서 단순 균등 분배 대비 TTFT를 1.2~1.8배 개선한다.

구현: NIXL·Ceph RGW·DAOS

ObjectCache는 세 가지 컴포넌트를 조합해 프로토타입을 구현했다.

NIXL (NVIDIA Inference Xfer Library) NIXL은 GPU, CPU DRAM, NVMe, 원격 스토리지 사이의 데이터 전송을 추상화하는 라이브러리다. vLLM의 PD 분리 기능, NVIDIA Dynamo의 KV 계층 오프로딩에도 쓰이는 동일한 라이브러리다. ObjectCache는 NIXL 위에서 오브젝트 스토리지 전송을 구현해 기존 서빙 프레임워크와의 통합 경로를 확보했다.

Ceph RGW (RADOS Gateway) Ceph는 오픈소스 분산 스토리지 시스템이다. RGW는 S3 호환 HTTP 인터페이스를 제공한다. ObjectCache는 Ceph RGW를 주 오브젝트 스토리지 백엔드로 사용해 실험을 수행했다. S3 호환 인터페이스를 쓰므로 MinIO, AWS S3, GCS 등 다른 오브젝트 스토리지로 이식 가능하다는 의미다.

DAOS (Distributed Asynchronous Object Storage) Intel이 개발한 고성능 분산 오브젝트 스토리지로, NVMe-oF와 RDMA를 활용해 일반 S3보다 낮은 지연을 제공한다. 연구팀은 DAOS도 지원하여 고성능 HPC 환경에서의 동작을 검증했다.

실험 환경: 100 Gbps RoCE 네트워크 클러스터. 이 대역폭은 KV 캐시 전송의 선행 조건이다. 10 Gbps 환경에서는 I/O 지연이 GPU 연산 시간을 초과해 파이프라인 오버랩 효과가 줄어든다.

성능 결과

연구팀은 로컬 DRAM 대비 TTFT 오버헤드를 컨텍스트 길이별로 측정했다.

64K 컨텍스트에서 5.6% 오버헤드는 운영 관점에서 매우 작은 수치다. DRAM 풀 비용 절감을 고려하면 충분히 수용 가능한 트레이드오프다.

4K 컨텍스트의 56~75ms 오버헤드는 짧은 대화 세션이나 빠른 응답이 필요한 앱에서 체감될 수 있다. 컨텍스트가 짧을수록 레이어 연산 시간도 짧아 I/O를 숨길 기회가 줄어든다는 물리적 한계다.

대역폭 공유 시나리오: 동일 대역폭 조건에서 단순 균등 분배 대비 ObjectCache 스케줄러가 TTFT를 1.2~1.8배 낮췄다. 요청별 레이어 진행 상태를 반영한 스케줄링이 효과적임을 보인다.

기존 KV 캐시 계층 구조와의 비교

현재 LLM 서빙 시스템의 KV 캐시 계층은 일반적으로 다음과 같다.

vLLM v0.26.0은 오브젝트 스토리지를 3계층(secondary tier)으로 지원하는 KV 오프로딩 기능을 추가했다. ObjectCache는 이와 유사한 방향이지만, 레이어 순서 프로토콜과 대역폭 스케줄러라는 두 가지 핵심 메커니즘에 초점을 맞춘 연구 논문이다. 프로덕션 시스템으로의 통합은 미래 과제다.

운영 고려사항

어떤 워크로드에 적합한가?

ObjectCache의 효과는 컨텍스트가 길수록 두드러진다. 다음 조건에서 효과적이다.

• 64K+ 토큰 길이의 RAG 파이프라인
• 동일한 긴 시스템 프롬프트를 공유하는 다수 세션
• 문서 처리, 코드 리뷰, 롱-폼 분석 등 장문 입력 시나리오

네트워크 요구사항: 논문의 실험은 100 Gbps RoCE 클러스터에서 수행됐다. 일반 10 Gbps 이더넷 환경에서는 I/O 지연이 레이어 연산 시간을 초과해 파이프라인 효과가 크게 줄어든다. 클라우드 환경의 고대역폭 네트워크(AWS EFA, Azure InfiniBand 등)가 적합하다.

스토리지 선택: 오브젝트 스토리지의 GET latency가 낮을수록 유리하다. DAOS처럼 RDMA 기반 고성능 오브젝트 스토리지가 이상적이다. S3 표준 API를 쓰는 범용 클라우드 스토리지는 4K 컨텍스트 시나리오에서 오버헤드가 커진다.

비용 계산: DRAM 풀 서버를 줄이고 오브젝트 스토리지로 대체했을 때 비용이 얼마나 절감되는지는 워크로드, 네트워크 비용, 스토리지 서비스 가격에 따라 크게 달라진다. 논문은 정량적 비용 분석을 제공하지 않으므로 직접 환경에 맞게 계산해야 한다.

한계와 Open Question

단거리 컨텍스트의 한계: 4K 토큰 미만 짧은 컨텍스트에서는 오버헤드가 50ms 이상으로 증가한다. 짧은 응답 지연이 중요한 챗봇, 코드 자동완성 시나리오에서는 DRAM 풀이 여전히 더 나은 선택이다.

프로덕션 배포 검증 부재: 이 연구는 프로토타입 수준의 검증이다. 수천 개의 동시 요청, 노드 장애, 재시작 등 프로덕션 엣지 케이스에 대한 데이터는 공개되지 않았다. (Open question)

KV 캐시 유효성 관리: 오브젝트 스토리지에 저장된 KV 캐시의 만료, 버전 관리, 무효화 정책은 복잡한 운영 과제다. 캐시된 KV가 특정 모델 버전에 묶이므로 모델 업데이트 시 모든 캐시를 무효화해야 한다.

NIXL 의존성: 현재 구현은 NIXL 생태계에 의존한다. NIXL이 vLLM, SGLang 등 주요 서빙 프레임워크에 통합되는 수준에 따라 ObjectCache의 채택 가능성이 달라진다.

정리

ObjectCache는 "S3에 KV 캐시를 저장하면 느릴 것"이라는 통념에 구체적인 반론을 제시한다.

핵심은 레이어 순서 프로토콜이다. KV 캐시를 레이어 단위로 분할해 GPU 소비 순서에 맞춰 스트리밍하면, 전송 시간이 GPU 연산 시간 뒤에 숨는다. 64K 컨텍스트에서 5.6% 오버헤드는 오브젝트 스토리지라는 저비용, 무제한 용량 계층으로의 교환 가치로 충분하다.

대역폭 스케줄러는 공유 네트워크 환경에서 이 효과를 유지한다. 레이어 진행 상태를 고려한 우선순위 배분이 단순 균등 분배보다 1.2~1.8배 나은 TTFT를 제공한다.

다음 단계는 프로덕션 시스템으로의 통합이다. NIXL이 vLLM·SGLang의 기본 전송 레이어로 자리잡으면서, ObjectCache의 아이디어가 서빙 프레임워크의 KV 계층화 구현에 반영될 가능성이 높다. 긴 컨텍스트 시나리오가 더 일반화될수록 레이어 순서 프로토콜의 가치도 커진다.

References

• ObjectCache: Layerwise Object-Storage Retrieval for KV Cache Reuse — arXiv:2605.22850
• ObjectCache HTML Paper — arXiv:2605.22850v1
• NIXL: NVIDIA Inference Xfer Library — GitHub
• Ceph Object Gateway (RGW) Documentation
• DAOS: Distributed Asynchronous Object Storage
• vLLM v0.26.0 Release Notes — Tiered KV Offloading
• NVIDIA Dynamo: Disaggregated Inference Orchestration