쉽게 이해하기

LLM은 한 번에 글 전체를 완성하지 않고 토큰을 하나씩 만든다. 매번 새 토큰을 만들 때 앞에 나온 모든 토큰을 다시 참고해야 하므로, 아무 장치가 없으면 같은 attention 계산이 반복된다. KV Cache는 앞부분에서 이미 계산한 Key와 Value 텐서를 저장해 두었다가 다음 토큰을 만들 때 다시 사용한다. 이 덕분에 긴 프롬프트, 긴 대화, 공통 시스템 프롬프트가 있는 서비스에서 첫 토큰 시간과 GPU 사용량을 더 잘 통제할 수 있다.

비유와 예시

• 책갈피: 긴 책을 매번 첫 페이지부터 다시 읽지 않고, 읽어 둔 위치와 메모를 남겨 다음 문장을 빠르게 이해한다.
• 고객지원 챗봇: 모든 요청 앞에 긴 정책 문서가 붙는다면, 공통 prefix의 K/V를 재사용해 반복 계산을 줄일 수 있다.
• 코드 리뷰 에이전트: 같은 파일을 두고 여러 질문을 이어가면, 이전 context의 K/V가 디코딩 속도에 영향을 준다.

한눈에 비교

방식	장점	비용	잘 맞는 상황
캐시 없음	메모리 단순	prefix 재계산으로 느림	짧은 실험, 교육용 구현
일반 KV Cache	디코딩이 빨라짐	토큰 길이에 비례해 메모리 증가	대부분의 LLM serving
Prefix Caching	같은 앞부분 재사용	prefix match 관리 필요	시스템 프롬프트·RAG 템플릿 반복
Offloaded KV	GPU 메모리 절감	CPU/SSD 전송 지연	긴 context, GPU 메모리 부족

어디서 왜 중요한가

KV Cache는 “모델이 얼마나 똑똑한가”보다 “같은 모델을 얼마나 안정적으로 서빙할 수 있는가”에 가까운 주제다. 긴 context를 지원할수록 K/V 텐서도 커지고, batch size와 동시성은 줄어든다. 그래서 vLLM의 PagedAttention, TensorRT-LLM의 KV cache system, Hugging Face의 cache strategy처럼 서빙 런타임마다 캐시 배치·eviction·offloading 전략이 따로 존재한다. 뉴스나 릴리스 노트에서 “long context”, “lower time to first token (TTFT)”, “prefix caching”, “serving throughput”이 함께 나오면 KV Cache가 배경에 있을 가능성이 높다.

자주 하는 오해

• “KV Cache는 텍스트를 저장한다” → 텍스트가 아니라 attention에 쓰이는 key/value 텐서를 저장한다.
• “캐시를 많이 쓰면 무조건 빠르다” → GPU 메모리가 부족해지면 batch가 줄거나 CPU/SSD 전송 때문에 느려질 수 있다.
• “Context Window만 늘리면 된다” → window가 길어질수록 캐시 메모리도 커져 serving 비용과 지연이 같이 올라간다.
• “Prefix caching은 항상 안전하다” → tenant, adapter, system prompt가 다르면 잘못된 재사용을 막는 분리 키가 필요하다.

대화에서는 이렇게

• “긴 시스템 프롬프트가 반복되니 prefix caching을 켜고 hit rate를 봅시다.”
• “TTFT(첫 토큰 시간)가 튀는 원인이 모델 compute인지 KV cache eviction인지 분리해 보죠.”
• “HBM이 부족하면 offloading을 검토하되, 전송 지연이 재계산보다 싼지 먼저 측정해야 합니다.”
• “LoRA adapter나 tenant가 섞이는 환경에서는 cache key에 구분자를 넣어야 합니다.”

함께 읽으면 좋은 용어

• Context Window: 길수록 KV Cache 메모리가 선형으로 커진다.
• Attention: Key, Query, Value가 실제로 어디에 쓰이는지 이해하기 위한 선행 개념.
• PagedAttention: KV Cache를 블록처럼 관리해 fragmentation과 낭비를 줄이는 방식.
• vLLM: PagedAttention과 prefix caching을 실무 serving에서 자주 언급하게 만든 런타임.
• GPU HBM: KV Cache가 가장 먼저 차지하는 빠르고 비싼 메모리 계층.