backend.ai

Agentic AI를 위한 LLM 서빙 환경에서 GPU 메모리 가용량을 결정하는 변수 중 하나가 컨텍스트 길이입니다. AI가 더욱 많은 일을 할 수 있게 되면서 Multi-turn conversation, Agentic AI과 같이 세션이 길게 유지되고 컨텍스트가 수만 토큰 단위로 누적되는 워크로드가 빠르게 늘고 있죠. 이런 워크로드에서 GPU 메모리를 가장 빠르게 잠식하는 요소가 KV cache입니다. KV cache는 추론 과정에서 생성된 Key / Value* 텐서를 보관해 다음 토큰 생성에 재사용하는 메모리 영역으로, 모델 가중치와 달리 사용자 수와 컨텍스트 길이에 비례해 커집니다. 예를 들어, Llama 3 70B에 128K 컨텍스트 윈도우를 열면 사용자 한 명의 KV cache가 40GB에 이릅니다¹. H100 GPU의 총 GPU 메모리의 50%에 달하는 어마어마한 규모죠.

* Key는 쿼리와 매칭하는 벡터를, Value는 실제 정보 벡터를 의미합니다.

그러면, KV cache를 GPU 메모리 밖으로 꺼내서 두면 안 될까요? 이런 아이디어에서 출발한 접근 방식이 바로 KV cache offloading입니다. vLLM과 LMCache의 연동, NVIDIA의 Dynamo 플랫폼, VAST Data 등의 GPU-스토리지 직결 솔루션 등 AI 업계의 여러 분야에서 KV cache offloading을 가속화하기 위한 기술을 선보이고 있습니다.

KV cache offloading은 조건에 따라 효과가 크게 갈립니다. 이상적인 조건에서는 좋은 효과를 발휘할 수 있지만, 그렇지 않다면 외려 KV cache offloading을 비활성화 한 것 보다도 느린 결과를 받아볼 수도 있습니다. 이번 글에서는 KV cache가 무엇이고, offloading이 실제로 어떻게 동작하며, 어떤 조건에서 효과적인지를 살펴보고자 합니다.

KV cache의 구조와 메모리 압박

Transformer 기반 LLM의 추론은 두 단계를 거칩니다. 첫 번째는 Prefill 단계입니다. 이 단계에서는 사용자가 입력한 모든 프롬프트를 바탕으로 K/V 벡터를 생성하고, KV cache에 저장합니다. Prefill 연산의 경우 높은 병렬성을 활용한 계산이 가능하다는 특징을 가지기에, GPU 연산 코어의 절대 성능이 크게 영향을 끼치게 됩니다. Prefill이 완료되고 나면 이제 Decode 단계에 진입합니다. Decode에서는 KV cache 형태로 표현되는 사용자의 입력 프롬프트를 바탕으로 이후 토큰을 생성하게 됩니다. Decode 단계에서는 KV cache를 매번 읽어야 하기 때문에, 높은 Decode 성능을 선보이기 위해서는 더욱 빠른 메모리 입출력 속도가 중요합니다. 이처럼 Prefill과 Decode 단계의 자원 요구 특성이 다르기 때문에, Prefill 특화와 Decode 특화라는 서로 다른 특성을 가진 AI 가속기를 이용하는 Prefill Decode Disaggregation 기술 또한 활발히 논의되고 있습니다.

이상적인 환경에서는 사용자가 LLM과 대화를 이어가는 경우, 사용자가 하나의 질문을 마무리하고 바로 세션을 종료하는 패턴을 기대할 수 있습니다. 그러나 현실은 그렇지 않죠. 사용자는 연속된 대화 대신, 여러 대화 기록을 쌓아두고 그때그때 다른 맥락의 질문을 이어 가기도 합니다. 이 문제를 GPU 메모리를 이용해서만 풀려고 한다면 비활성 세션의 KV cache가 GPU 메모리에 그대로 남아 있게 되고, 여러 사용자가 같은 세션에 시간차로 접근하는 환경에서도 메모리 압력이 점점 증가하게 됩니다. 결국 GPU 메모리가 더 이상 남지 않게 되면 오래된 KV cache부터 eviction 및 재계산이 일어나게 되고, 이는 전반적인 연산 자원 낭비로 이어지게 됩니다. 그렇다면 이제 KV cache offloading이 실제로 어떻게 KV 블록을 이동하는지 살펴봅시다.

데이터 이동 경로

KV cache offloading의 데이터 흐름은 크게 캐시 쓰기와 캐시 읽기로 나뉩니다. 이 기술의 핵심은 GPU가 KV cache를 연산하는 것보다 빠르게 외부에 저장된 KV cache를 불러오는 것이기에, 외부 저장소의 빠른 읽기 및 쓰기 능력이 자연스레 중요해집니다.
가장 최적화된 읽기 경로를 구성하는 방법은 CPU 메모리를 우회하는 것입니다. NVIDIA Magnum IO GPUDirect Storage(이하 GDS) 는 CPU의 개입 없이 GPU와 스토리지 사이의 직접 데이터 경로를 만드는 기술입니다². GDS는 다양한 로컬, 리모트를 가리지 않는 스토리지 백엔드를 지원합니다. 로컬 NVMe SSD에서는 PCIe P2P 전송으로, 리모트 스토리지에서는 NVMe-over-Fabrics나 NFS-over-RDMA, WEKA·VAST Data·DDN Exascaler 같은 RDMA 대응 분산 파일시스템 위에서 동작합니다. 어느 경우든 스토리지에서 GPU 메모리로 KV 데이터를 직접 배치해 호스트 RAM의 CPU 사이클과 대역폭 점유를 줄이는 구조입니다.

토큰 해싱 기반 캐시 식별

데이터 이동 비용을 줄이기 위해서는 KV 블록을 정확히 찾아 재사용해야 합니다. vLLM과 LMCache는 토큰 시퀀스의 해시로 캐시 블록을 식별합니다. 프롬프트 전체를 하나의 덩어리로 저장하는 대신 더 큰 단위의 토큰 조각으로 쪼개고, 각 조각의 토큰 ID 시퀀스에서 해시를 계산해 캐시 블록의 식별자로 사용하는 방식이죠.

추론 엔진에 새 추론 요청이 들어오면 먼저 입력 프롬프트를 토큰 ID 시퀀스로 변환하고, 변환된 시퀀스를 토큰 블록으로 분할한 뒤, 각 블록의 해시를 계산합니다. 추론 엔진은 GPU 메모리에서 캐시 블록 존재 여부를 먼저 확인하고, 존재하지 않을 경우 CPU 메모리, 그다음 외부 저장 공간 순으로 계층적 탐색을 시도합니다. 해시가 순수하게 토큰 내용에서만 계산되기 때문에, 캐시 블록 맵은 영속적으로 유지될 필요가 없습니다. 서로 다른 호스트에서 여러 추론 엔진 인스턴스가 실행될 때도 조정이 필요하지 않고, 스토리지 시스템이 Lifecycle 설정으로 시간 기반 만료를 구현해도 삭제된 블록은 그냥 탐색 실패로 처리되는 구조입니다. S3, Redis, 로컬 디스크 같은 이질적인 백엔드를 같은 인터페이스로 묶을 수 있는 이유입니다.

또 다른 마법은 바로 다중 사용자에 대한 대응입니다. 서로 다른 두 명의 사용자가 같은 시스템 프롬프트를 입력하거나, 같은 RAG 문서를 포함한 프롬프트를 전송하는 경우 해당 청크의 일치하는 해시를 식별, KV cache의 재사용이 가능합니다. RAG 워크로드에서 같은 검색 문서가 여러 프롬프트에 임베딩되는 경우 그 문서를 커버하는 청크들이 매치되어 prefill을 건너뛸 수 있고, 이를 통해 재사용성이 확보되어 효율적인 시스템 운용이 가능해지는 것입니다.

Prefill 단계: 로드와 재계산의 비용 곡선

이제 KV cache offloading이 기술적으로 어떤 구조를 가지고 있는지 확인했으니, KV cache를 외부에서 로딩하는 것이 정말로 GPU에서 재계산하는 것 보다 빠른지를 확인해봐야 합니다. 워크로드와 하드웨어 조건에 따라 무엇이 빠른지는 달라질 수 있기 때문에 다양한 조건을 확인해봐야 하는데요, 다행히 우리에게는 선행 연구를 통해 확인해볼 수 있는 자료들이 조금 있습니다. "Compute Or Load KV Cache? Why Not Both?" arXiv:2410.03065 (2024)³ 라는 논문을 보면, 저자는 prefix caching이 GPU의 연산 부담을 줄여주긴 하지만, 항상 첫 토큰 출력 시간(TTFT)을 가장 빠르게 만드는 것은 아니라고 설명합니다. KV cache를 외부 저장소에서 가져오려면 그만큼 데이터를 전송해야 하고, 이 전송 시간이 생각보다 길어질 수 있기 때문입니다. 예를 들어 SATA SSD나 HDD처럼 대역폭이 낮은 저장장치를 쓰면 KV cache를 읽어오는 데만 몇 초가 걸릴 수 있고, 네트워크로 연결된 원격 스토리지를 거치면 이 시간은 더 길어질 수 있습니다. 반대로 GPU에서 prefill을 다시 수행하는 비용도 무시할 수는 없습니다. 특히 70B급처럼 큰 모델과 긴 컨텍스트가 결합되면, KV cache를 새로 생성하는 데 수십 초가 걸릴 수 있습니다. 그래서 “불러오는 시간”과 “다시 계산하는 시간”이 서로 비슷해지는 구간이 생기고, 그 지점부터는 어떤 방식이 더 유리한지 실제 환경에 따라 따져봐야 합니다.

여기서 KV cache offloading의 우위를 결정하는 중요한 기준이 컨텍스트 길이와 모델 크기입니다. 입력이 짧고 모델이 작으면 GPU가 prefill을 아주 빨리 끝내기 때문에, 오히려 외부에서 KV cache를 가져오는 시간이 더 길 수 있습니다. 이런 경우에는 offloading이 도움이 되지 않거나, 오히려 느려질 수도 있습니다. 반대로 CPU 메모리처럼 비교적 빠른 계층에 KV cache를 두면, 대부분의 경우 재계산보다 로드가 더 유리합니다. LMCache와 vLLM을 함께 쓴 벤치마크⁴에서 3~10배 수준의 레이턴시 감소가 보고된 것도 이 때문입니다. 더 나아가, 고대역폭 RDMA 스토리지를 사용할 수 있다면 외부 저장소에서도 충분히 경쟁력이 생깁니다. 예를 들어 VAST Data가 DGX SuperPOD 환경에서 vLLM과 LMCache를 테스트⁵했을 때, 사전에 계산해 둔 KV cache를 로드하면 128K 컨텍스트에서 TTFT가 11초 이상에서 1.5초로 줄었습니다. 다만 이 결과는 400Gbps RDMA 패브릭, BlueField-3 DPU, NVIDIA Magnum IO GPUDirect Storage, 충분히 긴 컨텍스트 같은 조건이 모두 맞아떨어졌을 때의 이야기입니다.

모델 크기, 컨텍스트 길이, 네트워크 대역폭 & 지연율: 로드와 재계산을 가르는 중요한 변수들

이러한 다양한 케이스에 대응하기 위해 살펴봐야 하는 세 가지 중요한 변수들이 있습니다. 바로 모델 크기, 컨텍스트 길이, 그리고 네트워크 대역폭 & 지연율이죠. 첫번째, 모델 크기가 클수록 토큰당 prefill 비용이 높아지고, 캐시할 KV cache의 크기도 비례해서 커집니다. 다만 연산 비용의 증가를 같이 살펴봐야 하는데요, 모델 크기가 특정 규모 이상으로 커지는 경우에는 연산 비용이 더 빠르게 증가하기 때문에 대형 모델에서는 KV cache offloading 방식이 더 유리해집니다. 두번째, 컨텍스트 길이가 길어질수록 attention 재계산 비용이 빠르게 불어나는 반면에 KV cache 전송 시간은 데이터 크기에 비례하여 상대적으로 완만하게 늘어납니다. 즉, 수백 토큰 수준의 짧은 컨텍스트에서는 KV cache 재계산이 더 나은 선택이 될 확률이 높고, 컨텍스트가 수만 토큰 수준으로 늘어나면 KV cache offloading 방식이 더 나은 선택이 될 확률이 높습니다. 세번째, 고대역 NFS-over-RDMA 환경이 아닌 일반 NAS를 NFS로 연결 후에 이 곳에 KV cache offloading을 설정하려 할 경우, 캐시된 KV cache를 제 시간 안에 읽어가지 못하게 됩니다. 100400Gbps NFS-over-RDMA(1250 GB/s, 수~수십 μs 지연)와 같은 더욱 빠르고 대역폭이 넓은 네트워크 환경을 구축하면 작은 블록에서의 RTT (Round trip time), 그리고 큰 블록에서의 전송 시간이 줄어드는 효과를 볼 수 있습니다.

추가적으로 고려할 수 있는 Decode 단계의 HBM 여유와 세션 이동

HBM 슬롯 확보로 동시성 확장

비활성 채팅 세션의 KV cache를 NAS, CPU, 디스크로 옮기면 GPU 메모리 저장 공간이 확보됩니다. Offloading 없이 10명의 긴 컨텍스트 사용자를 대상으로 추론하는 GPU는 메모리 한계에 도달해 새 요청을 큐에 넣어야 하지만, offloading을 사용하는 경우에는 유휴 세션 캐시를 내보내고 GPU 메모리를 회수해 더 많은 decode 작업을 동시에 처리할 수 있게 됩니다. Decode 연산 자체가 빨라지기를 바라기는 어렵지만, 대신 동시 처리 수가 늘어나기에 간접적으로라도 추론 시간이 줄어드는 효과를 볼 수 있습니다.

세션 마이그레이션: prefill 재실행 회피

KV cache offloading을 통해 prefill이 불필요하게 재실행되는 것을 회피할 수 있습니다. 멀티노드 AI 클러스터에서는 로드 밸런싱, 탄력적 자원 할당, 장애 복구 등의 이유로 서로 다른 GPU간의 워크로드 이동이 빈번할 수 있는데요, 로컬에 저장된 KV cache가 유실되면 새 GPU에서 prefill을 다시 돌려야 하죠. 그러나 KV cache offloading이 있으면 새 GPU가 저장된 KV 블록을 로드해 중단된 지점부터 decode를 재개할 수 있다는 특징을 볼 수 있습니다.

KV cache offloading을 지원하는 SW 스택

KV cache offloading을 구현하기 위해 흔히 쓰이는 vLLM + LMCache 조합 외에도, 여러 추론 프레임워크가 KV cache offloading을 지원합니다.

스택	역할	KV cache 관련 기능
vLLM + LMCache	추론 엔진 + KV cache 계층	CPU·디스크·원격(S3, Redis 등) 계층적 오프로드. 본문에서 다룬 구현
NVIDIA Dynamo	분산 추론 프레임워크	disaggregated prefill/decode + NIXL 라이브러리로 GPU 간 KV cache 전송(RDMA, NVMe-oF, S3)6
llm-d	Kubernetes 기반 분산 스케줄러	KV cache indexer로 pod 간 캐시 상태 추적, prefix-aware routing. vLLM + LMCache 위에서 동작7
KServe	Kubernetes 모델 서빙	vLLM backend에서 LMCache KV offloading 통합
SGLang	추론 엔진	자체 prefix caching, Dynamo disaggregation 통합 지원

추론 및 KV cache 관리 프레임워크 외에도, NVIDIA의 NIXL (NVIDIA Inference Xfer Library) 등 더욱 빠른 KV cache 전송을 지원하기 위한 다양한 기반 라이브러리들 또한 존재합니다.

시나리오별 유불리

KV cache offloading은 모든 시나리오에 대해 효과적이지 않습니다. 따라서 워크로드 특성과 시나리오 특성에 따라 효과가 있을 작업에 해당 방법을 적용하는 것이 중요합니다. 아래의 표를 통해 일반적인 시나리오에서 KV cache offloading의 유불리를 짐작할 수 있습니다.

시나리오	판단	이유
일반 챗봇 (단발 프롬프트 위주)	불리	매 요청이 서로 다른 prefix라 이전 KV가 재사용될 일이 없음. offload는 불필요한 I/O 추가
팀 단위 RAG·agentic (단일 긴 공유 prefix)	불리	같은 prefix가 매 요청마다 재사용되어 GPU에서 축출되지 않음. offload해도 히트가 발생하지 않음
일반적인 TCP NFS 환경	불리	전송 지연이 재계산 지연을 상회
다부서 RAG·멀티 코드베이스 agentic (다중 긴 공유 prefix)	유리	prefix 집합이 번갈아 축출되어, 재로드 이득이 재계산 비용을 초과
70B+ 장문 멀티턴 대화 (10K 토큰 이상)	유리	prefill 비용이 RDMA 전송 비용을 추월하는 교차점
노드 간 세션 마이그레이션	유리	새 GPU에서 prefill을 다시 돌릴 필요 없이 저장된 KV에서 decode 재개

참고로 팀 단위 RAG의 경우 긴 시스템 프롬프트가 적용되고, 또 지식 검색의 특성상 반복되는 프롬프트가 여러 요청에서 공유되기에 KV cache offloading이 유리하다고 생각할 수 있습니다. 그렇지만 이러한 시나리오에서는 해당하는 prefix의 KV가 GPU에 계속 상주하는 성향을 보이기 때문에, 실질적으로 cache eviction이 자주 일어나지 않게 됩니다. 이러한 상황에서 KV cache offloading이 적용되면 해싱과 이동을 위한 불필요한 오버헤드만 발생하게 되어 전체적인 시스템 성능 및 속도 저하로 이어질 수 있습니다. 이 경우에는 외부 offload 계층을 붙이지 말고 vLLM 기본 prefix caching만 남기는 편이 낫습니다.

마치며

KV cache offloading은 쓸모가 많은 기술이지만, 적용을 통해 효과를 볼 수 있는 시나리오가 제한되어 있는 만큼 유용한 때와 유용하지 않은 때를 구분하는 것이 중요합니다. 따라서 적용하고자 하는 시나리오가 KV cache offloading이 실제로 효과를 발휘할 수 있는 종류인지 확인이 필요하고, 유불리를 판단하기 위한 실제 측정부터 진행해보는 것이 효과적입니다. 적합도를 판단할 때, 모델 크기, 컨텍스트 길이, 네트워크 대역폭 및 지연율이 동시에 움직이는 변수들이기 때문에 단순화한 단일 임계치로 판단하기는 다소 어렵다는 한계가 있지만, 대표 워크로드 두세 개를 골라 prefill 시간과 cache load 시간을 직접 측정한 뒤, 두 값이 교차하는 토큰 길이를 자체 환경의 임계치로 잡는 게 일반적입니다. 운영 초기 며칠 동안 위 네 지표를 관찰하면서 CPU 버퍼 크기를 단계적으로 올리면, 캐시 히트율이 임계치를 향하는 지점이 자연스럽게 드러납니다. 결괏값이 유리한 구간에 속하지 않는다면 외부 offload 계층을 붙이기보다는 추론 프레임워크의 기본 캐싱 기능에 의존하는 것도 충분할 수 있습니다. 반대로 스케일아웃 환경이라면 Backend.AI Continuum Router 처럼 KV 상태를 실시간으로 추적하는 라우터를 활용해보세요. 래블업의 Backend.AI는 VAST Data 등의 RDMA 스토리지 벤더와의 통합 테스트를 거쳤고, 사용자가 그동안 사용해온 방식을 Backend.AI에서도 그대로 활용할 수 있습니다.

---

KV cache offloading을 포함한 추론 인프라 최적화에 관심이 있으시다면, Backend.AI 웹사이트 또는 래블업 웹사이트를 참고하세요.

Footnotes

1. Llama 3.1 — 128K 컨텍스트, GQA (KV heads 8), 70B 128K KV cache ≈ 40GB. Meta, "Llama 3.1 - 405B, 70B & 8B with multilinguality and long context." Hugging Face Blog. https://huggingface.co/blog/llama31 ↩

2. GPUDirect Storage는 로컬 NVMe(PCIe P2P)와 원격 스토리지(NVMe-oF, NFS-over-RDMA, WEKA·VAST·DDN Exascaler 등 RDMA 대응 분산 파일시스템) 양쪽을 지원. NVIDIA, "GPUDirect Storage Overview Guide." https://docs.nvidia.com/gpudirect-storage/overview-guide/index.html / NVIDIA Developer Blog, "GPUDirect Storage: A Direct Path Between Storage and GPU Memory." https://developer.nvidia.com/blog/gpudirect-storage/ ↩

3. 양방향 스케줄링, SSD/HDD/NVMe 대역폭 비교, 3 GB/s·25GB·8초 / 70B·72K = 30초 / 평균 2.6× TTFT 감소 수치. S. Jin, X. Liu, Q. Zhang, Z. M. Mao, "Compute Or Load KV Cache? Why Not Both?" arXiv:2410.03065 (2024). https://arxiv.org/abs/2410.03065 ↩

4. LMCache + vLLM 3~10× 레이턴시 감소 벤치마크. LMCache Project, GitHub repository. https://github.com/LMCache/LMCache ↩

5. DGX SuperPOD 참조 아키텍처 + 400Gbps RDMA + BlueField-3 DPU + GDS 조건에서 128K 컨텍스트 TTFT 11초 → 1.5초. VAST Data, "Accelerating Inference." https://www.vastdata.com/blog/accelerating-inference ↩

6. NVIDIA Dynamo 분산 추론 프레임워크 및 NIXL KV cache 전송 라이브러리(RDMA, NVMe-oF, S3 지원). NVIDIA, "Introducing NVIDIA Dynamo" (GTC 2025). https://developer.nvidia.com/blog/introducing-nvidia-dynamo-a-low-latency-distributed-inference-framework-for-scaling-reasoning-ai-models/ ↩

7. 프로덕션 프리픽스 캐싱 히트율 (warm cache 약 87%) 및 Prometheus 지표 (kv_cache_usage_percent, prefix_cache_hit_rate, eviction rate, effective cache throughput). llm-d, "KV-Cache Wins You Can See: From Prefix Caching in vLLM to Distributed Scheduling with llm-d." https://llm-d.ai/blog/kvcache-wins-you-can-see ↩