쉽게 이해하기

LLM은 길고 반복되는 문맥을 처리할 때 attention 계산을 빠르게 하기 위해 KV 캐시를 쌓습니다. 문제는 이 캐시가 GPU 메모리를 급격히 소모해 동시 사용자 수와 컨텍스트 길이가 조금만 늘어나도 병목이 생긴다는 점입니다. 결과적으로 대기 시간이 길어지고, 비용은 오르는데 처리량은 늘지 않는 상황이 잦습니다.

KV 오프로딩은 이 캐시를 한곳에만 두지 않고, 가까운 곳부터 먼 곳까지 층을 나눠 보관하는 방식입니다. 자주 쓰는 물건은 책상 위(GPU), 가끔 쓰는 건 옆 서랍(CPU), 드물게 쓰는 건 창고(NVMe/원격 스토리지)에 두는 것과 같습니다. 필요한 순간엔 가까운 층부터 확인해 맞으면 바로 가져오고, 안 맞으면 더 먼 층으로 내려가 찾습니다.

메커니즘의 핵심은 캐시 적중으로 prefill(긴 프롬프트를 처음 읽어 KV 캐시를 만드는 단계) 재계산을 피하는 것입니다. GPU에 다 못 올리는 KV 블록을 CPU나 디스크로 내려두었다가, 동일하거나 겹치는 문맥이 오면 해당 블록만 다시 올려 decode를 이어갑니다. 여기서 NVMe는 서버에 붙는 빠른 SSD 스토리지, HBM은 GPU 안의 고대역폭 메모리, TTFT(Time To First Token)는 요청 후 첫 토큰이 나오기까지의 시간을 뜻합니다. vLLM의 LMCache나 NVIDIA의 KVBM 같은 구성요소는 블록 단위로 KV를 관리하고, 빈도 기반 필터링이나 블록 수 한도 같은 정책으로 I/O 부담과 SSD 수명을 함께 고려합니다. 핵심 이득은 '느린 저장장치가 GPU보다 빠르다'가 아니라, 긴 prefill을 다시 계산하지 않아도 되는 상황을 만드는 데 있습니다.

비유와 예시

• 장문 시스템 프롬프트 재사용 서비스: 128K 토큰에 달하는 초기 컨텍스트를 여럿이 공유할 때, KV 오프로딩으로 캐시 적중 시 prefill을 생략해 응답 시작 시간을 줄입니다.
• 상담 기록 이어 읽기 챗봇: 이전 세션의 맥락을 다음 세션에서도 활용하기 위해 KV를 내구성 있는 스토리지에 보관, 재접속 시 같은 문맥을 빠르게 이어갑니다.
• 멀티모델 공용 컨텍스트 허브: 동일 도메인 지침을 여러 모델이 공유할 때, 중앙 스토리지에 KV 블록을 저장해 노드 간 재사용을 늘립니다.

한눈에 비교

컨텍스트가 크고 재사용이 잦을수록 NVMe 등 하위 계층의 I/O 지연을 감수하고도 전체 처리량과 비용 효율이 좋아진다.

어디서 왜 중요한가

• vLLM Production Stack (LMCache): GPU 밖으로 KV를 이동해 캐시 적중을 늘리고, 긴 문맥 동시 처리에서 메모리 병목을 완화.
• NVIDIA Dynamo KVBM: vLLM·TensorRT-LLM과 연동되는 통합 KV 메모리 계층 제공, CPU/디스크 캐시 크기·정책을 세밀하게 제어.
• 내구성 있는 원격 스토리지 운용: 세션 간·노드 간 KV 재사용을 가능하게 하는 플랫폼 오케스트레이션(공유 스토리지 + 제어 plane) 전략이 제시됨.
• NVMe 오프로딩의 효과 조건: 장문·반복 문맥에서 캐시 적중이 prefill 재계산을 대체할 때 TTFT를 줄일 수 있다. 반대로 적중률이 낮으면 디스크 I/O만 늘어 지연이 커질 수 있다.
• 확장 전략의 변화: 단일 GPU 증설보다 계층형 메모리·캐시 정책·관측(모니터링) 튜닝이 동시성 확장의 핵심 과제로 부상.

자주 하는 오해

• ❌ 오해: NVMe는 빠르니 무조건 속도가 오른다 → ✅ 실제: 이득은 NVMe 자체 속도 때문이 아니라 캐시 적중으로 prefill을 건너뛰기 때문이며, 짧은 문맥엔 이득이 적다.
• ❌ 오해: 오프로딩이면 GPU 메모리는 거의 안 써도 된다 → ✅ 실제: 뜨거운(hot) KV는 여전히 GPU에 있어야 지연을 줄일 수 있고, 모두를 내리면 I/O 병목이 커진다.
• ❌ 오해: 전용 하드웨어가 없으면 의미가 없다 → ✅ 실제: 표준 서버와 네트워크만으로도 소프트웨어 정의 아키텍처가 충분히 성과를 낼 수 있음이 보고됐다.

대화에서는 이렇게

• "이번 릴리스에서 KV 오프로딩 켰더니 첫 토큰 시간(TTFT)이 장문 프롬프트 기준 줄었어요. 대신 I/O 모니터링 대시보드가 꼭 필요하네요."
• "KVBM CPU 캐시 블록 수를 늘리면 히트율은 오르는데, 디코드 지연이 늘어서 최적점을 다시 찾아야 합니다."
• "이 워크로드는 문맥이 매번 달라요. 그래서 NVMe 오프로딩 이득이 적고, 차라리 배치 크기 늘리는 게 낫습니다."
• "LMCache 정책을 보수적으로 잡았더니 SSD 쓰기는 줄었지만, prefill 재계산이 늘어서 처리량이 떨어졌습니다."
• "운영에선 캐시 적중률·PCIe 대역·SSD 쓰기량을 같이 봐야 합니다. 한쪽만 최적화하면 SLA 변동이 생겨요."

함께 읽으면 좋은 용어

• 기초
  GPU — KV 캐시가 처음 상주하는 고속 메모리 계층을 이해하는 전제.
• 기초
  쿠다 — (CUDA) — GPU 메모리 이동·커널 실행의 비용 구조를 파악하기 위한 배경.
• 유사
  텐서RT-LLM — (TensorRT-LLM) — 동일 영역 추론 스택으로 KVBM과 연동해 비교 학습에 적합.
• 유사
  vLLM — LMCache 기반 오프로딩을 지원하는 추론 서버로 운영 관점 차이를 이해하기 좋다.
• 심화
  컨텍스트 길이 — (Context Length) — 오프로딩 이득/손해를 좌우하는 핵심 변수라 심층 이해가 필요.
• 심화
  정량화 — (Quantization) — 메모리 사용을 줄여 오프로딩 의존도를 낮추는 대안/보완책.