KV Cache(Key-Value Cache)

잘난 척을 위한 한 줄 요약

KV Cache는 LLM이 답변을 한 토큰씩 만들 때마다 이전 토큰들의 Key와 Value 계산 결과를 저장해두는 장치로, 속도를 빠르게 만드는 대신 GPU 메모리를 크게 잡아먹는 LLM 추론의 핵심 병목이다.

 

KV Cache란 무엇인가? LLM은 왜 이전 계산을 저장해두고 답변할까?

먼저, KV Cache가 뭔지부터

KV Cache는 Key-Value Cache의 줄임말이다.

LLM이 문장을 생성할 때 Transformer의 어텐션 계산에서 사용되는 Key와 Value 벡터를 저장해두는 캐시를 뜻한다.

 

여기서 캐시는 “나중에 다시 쓰기 위해 저장해두는 임시 기억 공간”이다.

 

예를 들어 ChatGPT 같은 언어모델이 답변을 만들 때는 문장을 한 번에 통째로 완성하는 것이 아니라, 보통 토큰을 하나씩 생성한다.

오늘
→ 오늘은
→ 오늘은 날씨가
→ 오늘은 날씨가 좋습니다

 

이때 매번 앞에 나온 모든 토큰을 다시 처음부터 계산하면 너무 비효율적이다.

 

그래서 모델은 이미 계산한 이전 토큰들의 Key와 Value를 저장해두고, 다음 토큰을 만들 때 재사용한다.

 

Hugging Face 문서는 KV cache가 자기회귀 모델의 텍스트 생성을 최적화하기 위해 필요하며, 모델이 토큰을 하나씩 예측할 때 이전 계산을 재사용하게 해준다고 설명한다.

 

쉽게 말하면 이렇다.

 

KV Cache는 LLM이 “아까 읽은 문맥을 다시 계산하지 않기 위해 저장해두는 어텐션용 메모장”이다.

 

왜 Key와 Value를 저장할까

Transformer의 어텐션에는 보통 세 가지가 나온다.

 

Query
Key
Value

 

이 셋은 셀프 어텐션을 이해할 때 자주 등장한다.

 

Query는 현재 토큰이 던지는 질문이다.
Key는 각 토큰이 가진 검색용 표지다.
Value는 실제로 가져올 정보다.

 

예를 들어 모델이 다음 단어를 만들고 있다고 해보자.

민지는 도서관에서 책을 빌렸다. 그것을

 

모델은 “그것” 다음에 어떤 단어가 와야 할지 판단해야 한다.

 

이때 “그것”은 앞 문맥의 “책”과 강하게 연결된다.

 

어텐션 계산은 현재 토큰의 Query를 이전 토큰들의 Key와 비교하고, 관련성이 높은 토큰의 Value를 더 많이 가져오는 방식으로 작동한다.

 

문제는 이전 토큰들의 Key와 Value는 한 번 계산하면 다음 토큰을 만들 때도 계속 필요하다는 점이다.

 

그래서 매번 다시 계산하지 않고 저장한다.

 

이 저장된 Key와 Value 묶음이 KV Cache다.

 

KV Cache가 없으면 어떤 일이 생길까

KV Cache가 없다고 가정해보자.

 

모델이 1,000개의 토큰으로 된 문맥을 읽고 답변을 생성한다.

 

첫 번째 새 토큰을 만들 때 1,000개 토큰을 계산한다.
두 번째 새 토큰을 만들 때 1,001개 토큰을 다시 계산한다.
세 번째 새 토큰을 만들 때 1,002개 토큰을 다시 계산한다.

이 과정을 계속 반복한다.

 

앞 문맥은 그대로인데도 매번 다시 계산하는 셈이다.

 

마치 문장을 한 글자씩 쓸 때마다, 앞에 쓴 글 전체를 처음부터 다시 읽고 정리하는 것과 같다.

 

KV Cache가 있으면 이미 계산한 이전 토큰들의 Key와 Value를 저장해두고, 새로 들어온 토큰에 대해서만 추가 계산한다.

이전 토큰들의 K,V → 저장
새 토큰의 Q,K,V → 새로 계산
현재 Q와 저장된 K,V → 어텐션 계산

 

즉, KV Cache는 생성 속도를 크게 높인다.

 

NVIDIA TensorRT-LLM 문서도 LLM 추론에서 KV cache 시스템을 다루며, 요청 간 재사용, 오프로딩, 우선순위 기반 제거 같은 기능으로 캐시 재사용과 효율을 높일 수 있다고 설명한다.

 

LLM 답변 생성은 두 단계로 나뉜다

KV Cache를 이해하려면 LLM 추론이 보통 두 단계로 나뉜다는 점을 알아두면 좋다.

 

1. Prefill 단계

사용자가 입력한 프롬프트 전체를 모델이 한 번 읽는 단계다.

 

예를 들어 사용자가 2,000토큰짜리 문서를 붙여넣고 질문했다고 해보자.

 

모델은 먼저 이 2,000토큰을 처리하면서 각 레이어의 Key와 Value를 계산한다.

 

이때 KV Cache가 만들어진다.

사용자 프롬프트 2,000토큰
→ 한 번에 처리
→ 각 토큰의 K,V 저장

 

이 단계는 프롬프트가 길수록 오래 걸린다.

 

2. Decode 단계

이제 모델이 답변을 한 토큰씩 생성하는 단계다.

 

새 토큰을 하나 만들고, 그 토큰의 K,V도 캐시에 추가한다.

 

다음 토큰을 만들 때는 기존 캐시와 새 토큰을 함께 활용한다.

답변 토큰 1 생성 → K,V 추가
답변 토큰 2 생성 → K,V 추가
답변 토큰 3 생성 → K,V 추가

 

즉, 답변이 길어질수록 KV Cache도 계속 커진다.

 

KV Cache는 어디에 저장될까

보통 KV Cache는 GPU 메모리, 즉 VRAM에 저장된다.

 

이유는 간단하다.

 

LLM 추론은 GPU에서 빠르게 계산해야 하고, 어텐션 계산에 필요한 K,V도 GPU 가까이에 있어야 빠르다.

 

하지만 여기서 문제가 생긴다.

 

GPU 메모리는 비싸고 제한적이다.

 

모델 파라미터도 GPU 메모리를 차지한다.
입력 텐서와 중간 계산값도 메모리를 쓴다.
여기에 KV Cache까지 들어간다.

 

그래서 긴 문맥을 처리하거나 동시에 많은 사용자의 요청을 처리하면 KV Cache가 메모리 병목이 된다.

 

Hugging Face 문서도 KV cache가 긴 컨텍스트 생성에서 상당한 메모리를 차지할 수 있고 병목이 될 수 있다고 설명한다.

 

왜 긴 문맥에서 KV Cache가 문제가 될까

KV Cache 크기는 대체로 다음 요소에 따라 커진다.

 

토큰 수
레이어 수
어텐션 헤드 수
Key와 Value의 차원
데이터 타입
배치 크기
동시 요청 수

 

문맥이 길어지면 저장해야 할 토큰의 K,V가 늘어난다.

 

예를 들어 4,000토큰보다 32,000토큰 문맥을 처리하면 KV Cache가 훨씬 커진다.

 

또 사용자 한 명만 쓰는 것이 아니라 여러 사용자가 동시에 요청하면 각 요청마다 KV Cache가 필요하다.

사용자 A의 KV Cache
사용자 B의 KV Cache
사용자 C의 KV Cache
사용자 D의 KV Cache
...

 

서빙 시스템 입장에서는 모델 자체보다 KV Cache가 더 큰 운영 문제로 떠오를 수 있다.

 

최근 AI 인프라 논의에서도 긴 대화, 장기 문맥, 복잡한 워크플로가 늘어나면서 KV Cache가 GPU 메모리와 비용의 핵심 제약이 된다는 분석이 나오고 있다.

 

KV Cache의 장점

KV Cache의 장점은 분명하다.

 

1. 생성 속도를 높인다

이전 토큰의 K,V를 다시 계산하지 않아도 되므로 답변 생성이 빨라진다.

 

2. 중복 계산을 줄인다

앞 문맥은 이미 처리했으므로 새 토큰에 대해서만 계산을 추가하면 된다.

 

3. 긴 답변 생성에 유리하다

답변이 길어질수록 이전 계산 재사용의 효과가 커진다.

 

4. 같은 프롬프트 재사용에 도움이 된다

여러 요청이 같은 시스템 프롬프트나 긴 문서 앞부분을 공유한다면, prefix caching 또는 KV cache reuse로 계산을 줄일 수 있다.

 

NVIDIA TensorRT-LLM은 같은 프롬프트로 시작하는 요청들이 KV cache 페이지를 공유하고 재사용할 수 있는 KV cache reuse 기능을 설명한다.

 

KV Cache의 단점

하지만 KV Cache는 공짜가 아니다.

 

가장 큰 단점은 메모리 사용량이다.

 

속도를 얻는 대신 메모리를 쓴다.

 

긴 문맥을 지원하려면 KV Cache가 커진다.
동시 사용자를 많이 받으려면 KV Cache가 많이 필요하다.
큰 모델일수록 레이어와 헤드가 많아 KV Cache도 커질 수 있다.

 

그래서 LLM 서빙에서 자주 나오는 고민이 이것이다.

모델은 GPU에 올라갔는데,
동시 요청을 늘리려 하니 KV Cache 때문에 메모리가 부족하다.

 

즉, KV Cache는 LLM을 빠르게 만들지만, 동시에 LLM 서비스의 처리량과 비용을 제한하는 병목이 된다.

 

KV Cache를 비유로 이해해보자

KV Cache는 회의록을 쓰는 사람의 메모장과 비슷하다.

 

회의가 길어진다고 해보자.

 

앞에서 누가 무슨 말을 했는지 매번 처음부터 다시 읽으면 너무 느리다.

 

그래서 핵심 내용을 옆 메모장에 적어둔다.

 

김 대리는 일정 지연을 말했다.
박 팀장은 예산 증액을 승인했다.
이 과장은 고객사 요청을 정리했다.

 

새로운 발언이 나올 때마다 이 메모장을 참고하면 빠르게 이어 쓸 수 있다.

 

LLM도 비슷하다.

 

이전 토큰들의 Key와 Value를 매번 다시 계산하지 않고, 옆에 저장해둔다.

 

다만 이 메모장이 너무 커지면 책상, 즉 GPU 메모리를 차지한다.

 

그래서 KV Cache는 “속도를 위한 메모장”이면서 동시에 “책상을 잡아먹는 메모장”이다.

 

KV Cache와 컨텍스트 윈도우의 관계

컨텍스트 윈도우는 모델이 한 번에 참고할 수 있는 토큰 범위다.

 

예를 들어 8K, 32K, 128K, 1M 컨텍스트 같은 표현을 본 적이 있을 수 있다.

 

컨텍스트가 길어지면 모델은 더 많은 정보를 볼 수 있다.

 

긴 문서
긴 대화
코드베이스
보고서 묶음
여러 회의록
장기 에이전트 작업

 

이런 것을 처리하기 좋아진다.

 

하지만 컨텍스트가 길어질수록 KV Cache도 커진다.

 

그래서 긴 컨텍스트 모델은 단순히 “입력을 많이 넣을 수 있다”만의 문제가 아니다.

 

긴 컨텍스트를 실제 서비스에서 빠르고 싸게 처리하려면 KV Cache 메모리 관리가 매우 중요하다.

 

KV Cache와 배치 처리

LLM 서비스는 보통 여러 사용자의 요청을 묶어 처리한다.

 

이를 배치 처리라고 한다.

 

여러 요청을 함께 처리하면 GPU를 더 효율적으로 쓸 수 있다.

 

하지만 요청마다 길이가 다르다.

 

사용자 A는 짧은 질문을 한다.
사용자 B는 긴 문서를 넣는다.
사용자 C는 긴 답변을 생성한다.
사용자 D는 중간에 생성을 멈춘다.

 

이렇게 요청 길이가 제각각이면 KV Cache도 제각각 커진다.

 

문제는 GPU 메모리를 미리 크게 잡아두면 낭비가 생긴다는 점이다.

 

짧은 요청에 너무 큰 공간을 할당하면 빈 메모리가 생긴다.
긴 요청은 중간에 공간이 부족할 수 있다.
요청이 끝날 때마다 메모리 조각화가 생길 수 있다.

 

이 문제를 해결하기 위해 나온 대표적 접근이 PagedAttention이다.

 

PagedAttention은 무엇일까

PagedAttention은 KV Cache를 운영체제의 가상메모리처럼 페이지 단위로 관리하는 방식이다.

 

vLLM 논문은 기존 LLM 서빙에서 KV Cache가 동적으로 커지고 요청마다 길이가 달라 메모리 낭비와 조각화가 크다고 지적했다. 이를 해결하기 위해 운영체제의 페이징 개념에서 영감을 받은 PagedAttention을 제안했고, KV Cache 메모리 낭비를 거의 없애며 요청 간 캐시 공유를 가능하게 했다고 설명한다.

 

쉽게 말하면 이렇다.

 

기존 방식은 각 요청마다 큰 연속 공간을 잡아두는 방식에 가깝다.

 

PagedAttention은 KV Cache를 작은 블록으로 나누고, 필요한 만큼만 붙여 쓰는 방식이다.

기존 방식:
요청 A → 큰 연속 메모리 공간
요청 B → 큰 연속 메모리 공간

PagedAttention:
요청 A → 블록 1, 2, 7
요청 B → 블록 3, 4
요청 C → 블록 5, 6, 8, 9

 

이렇게 하면 길이가 다른 요청을 더 유연하게 처리할 수 있다.

 

그래서 vLLM 같은 LLM 서빙 엔진에서 PagedAttention과 KV Cache 관리가 핵심 기술로 언급된다.

 

Prefix Caching은 무엇일까

KV Cache와 함께 자주 나오는 개념이 Prefix Caching이다.

 

여러 요청이 같은 앞부분을 공유할 때, 그 앞부분의 KV Cache를 재사용하는 방식이다.

 

예를 들어 기업용 챗봇은 모든 요청 앞에 긴 시스템 프롬프트를 붙일 수 있다.

당신은 우리 회사 고객지원 챗봇입니다.
다음 정책을 반드시 따르세요.
...

 

사용자가 1,000명이 질문해도 이 시스템 프롬프트는 같을 수 있다.

 

그렇다면 매번 이 앞부분을 다시 계산하는 것은 낭비다.

 

Prefix Caching은 이 공통 앞부분의 KV Cache를 저장해두고 재사용한다.

 

TensorRT-LLM 문서는 같은 프롬프트로 시작하는 요청들이 KV cache 페이지를 공유할 수 있다고 설명한다.

 

이 방식은 다음 상황에서 유용하다.

 

긴 시스템 프롬프트
같은 문서에 대한 여러 질문
같은 코드베이스에 대한 반복 질의
에이전트 워크플로의 공통 지시문
멀티턴 대화에서 반복되는 앞 문맥

 

즉, Prefix Caching은 “같은 앞부분을 또 읽지 말자”는 최적화다.

 

KV Cache Quantization은 무엇일까

KV Cache가 메모리를 많이 먹기 때문에, 이를 줄이기 위한 방법 중 하나가 KV Cache Quantization이다.

 

Quantization은 숫자의 정밀도를 낮춰 메모리 사용량을 줄이는 기법이다.

 

예를 들어 원래 FP16이나 BF16으로 저장하던 KV Cache를 INT8, FP8, 4비트, 2비트 같은 더 낮은 정밀도로 저장할 수 있다.

 

정밀도를 낮추면 메모리를 덜 쓴다.

 

하지만 너무 낮추면 모델 품질이 떨어질 수 있다.

 

Hugging Face 문서는 KV Cache quantization이 KV Cache 메모리를 줄이는 전략 중 하나이며, KIVI 같은 연구에서 영감을 받은 양자화 캐시가 제공된다고 설명한다.

 

즉, KV Cache Quantization은 다음 질문에 답하려는 방법이다.

 

“K,V를 꼭 높은 정밀도로 저장해야 할까? 조금 덜 정확하게 저장해도 답변 품질이 유지된다면 메모리를 아낄 수 있지 않을까?”

 

KV Cache Offloading은 무엇일까

또 다른 방법은 Offloading이다.

 

Offloading은 GPU 메모리에 다 담기 어려운 KV Cache를 CPU 메모리나 다른 저장 공간으로 일부 옮기는 방식이다.

 

GPU 메모리는 빠르지만 비싸고 작다.
CPU 메모리는 느리지만 상대적으로 크다.

 

따라서 덜 자주 쓰는 KV Cache 일부를 CPU로 옮겼다가 필요할 때 다시 가져올 수 있다.

 

물론 이 방식은 속도 손실이 생길 수 있다.

 

그래서 언제 GPU에 두고, 언제 CPU로 내릴지 전략이 중요하다.

 

NVIDIA TensorRT-LLM의 KV cache 시스템도 offloading과 prioritized eviction 같은 도구를 지원해 캐시 재사용과 메모리 효율을 높인다고 설명한다.

 

KV Cache Eviction은 무엇일까

메모리가 부족하면 어떤 캐시는 버려야 한다.

 

이를 Eviction이라고 한다.

 

브라우저 캐시나 CPU 캐시에서도 비슷한 일이 일어난다.

 

자주 쓰는 것은 남겨두고, 덜 중요한 것은 지운다.

 

KV Cache에서도 마찬가지다.

 

모든 요청의 모든 K,V를 계속 저장할 수는 없다.

 

그래서 오래된 요청, 낮은 우선순위 요청, 재사용 가능성이 낮은 캐시를 지우는 전략이 필요하다.

 

NVIDIA는 TensorRT-LLM에서 우선순위 기반 KV cache eviction을 도입해 토큰 범위별로 우선순위와 유지 시간을 지정할 수 있고, 캐시 적중률을 높일 수 있다고 설명했다.

 

즉, KV Cache Eviction은 “한정된 GPU 메모리에서 무엇을 남기고 무엇을 버릴 것인가”의 문제다.

 

KV Cache와 MQA, GQA

KV Cache 크기를 줄이는 또 다른 접근은 어텐션 구조 자체를 바꾸는 것이다.

 

대표적으로 다음이 있다.

 

MHA, Multi-Head Attention
MQA, Multi-Query Attention
GQA, Grouped-Query Attention

 

일반적인 Multi-Head Attention에서는 여러 헤드마다 Key와 Value가 따로 있다.

 

그러면 KV Cache도 헤드 수에 따라 커진다.

 

MQA는 여러 Query 헤드가 하나의 Key·Value 헤드를 공유하는 방식이다.

 

GQA는 여러 Query 헤드를 몇 개 그룹으로 나누고, 각 그룹이 Key·Value를 공유하는 방식이다.

 

이렇게 하면 KV Cache 크기를 줄일 수 있다.

 

NVIDIA TensorRT-LLM 문서는 KV cache가 Transformer layer마다 존재하며, MQA와 GQA 같은 최적화 기법을 지원한다고 설명한다.

 

쉽게 말하면 이렇다.

 

MHA는 헤드마다 각자 메모장을 가진다.
MQA는 여러 헤드가 같은 메모장을 공유한다.
GQA는 몇 개 그룹별로 메모장을 공유한다.

 

메모장을 공유하면 KV Cache가 줄어든다.

 

KV Cache는 학습에도 쓰일까

KV Cache는 주로 추론(inference)에서 중요하다.

 

즉, 이미 학습된 모델이 답변을 생성할 때 속도를 높이기 위해 쓰인다.

 

학습 단계에서는 보통 전체 시퀀스에 대해 병렬 계산을 수행하고, 역전파를 위해 중간 활성값을 저장해야 한다.

 

그래서 KV Cache라는 표현은 주로 LLM 서빙, 텍스트 생성, 추론 최적화 맥락에서 많이 나온다.

 

물론 모델 구조와 구현에 따라 세부는 다르지만, 일반 사용자가 이해할 때는 이렇게 기억하면 된다.

 

KV Cache는 모델을 학습시키는 기술이라기보다, 학습된 모델이 답변을 빠르게 생성하게 하는 추론 최적화 기술이다.

 

KV Cache와 대화 기록

사용자가 챗봇과 대화할 때, 이전 대화 내용이 길어질수록 컨텍스트도 길어진다.

 

컨텍스트가 길어지면 KV Cache도 커진다.

 

그래서 긴 대화는 비용이 많이 든다.

 

예를 들어 같은 질문이라도,

 

짧은 질문 하나만 처리하는 경우와
수십 턴의 대화 기록을 모두 넣고 처리하는 경우는 다르다.

 

후자는 모델이 훨씬 많은 토큰을 참고해야 하고, 그만큼 KV Cache도 커진다.

 

그래서 실제 서비스에서는 다음 전략을 쓴다.

 

오래된 대화 요약
중요하지 않은 메시지 제거
검색 기반 메모리
컨텍스트 압축
세션별 KV Cache 관리
프롬프트 캐싱

 

즉, “AI가 대화를 기억한다”는 경험 뒤에는 꽤 현실적인 메모리 비용 문제가 있다.

 

KV Cache와 RAG

RAG에서도 KV Cache는 중요하다.

 

RAG는 외부 문서를 검색해 LLM 프롬프트에 붙인다.

 

문서 조각이 길어질수록 입력 토큰이 늘어난다.

 

입력 토큰이 늘어나면 prefill 비용이 늘고, KV Cache도 커진다.

 

예를 들어 사용자가 질문 하나를 했는데 관련 문서 10개를 붙였다고 해보자.

 

각 문서가 길면 프롬프트가 매우 커진다.

 

그러면 다음 문제가 생긴다.

 

첫 응답까지 시간이 오래 걸린다.
GPU 메모리를 많이 쓴다.
동시 처리 가능한 요청 수가 줄어든다.
불필요한 문서까지 넣으면 비용이 낭비된다.

 

그래서 RAG에서는 검색 품질뿐 아니라 얼마나 필요한 문맥만 넣을 것인가가 중요하다.

 

나이브 RAG처럼 문서를 많이 붙이는 방식은 답변 품질을 높일 수도 있지만, KV Cache 비용을 키울 수 있다.

 

KV Cache와 긴 추론 모델

최근 reasoning model은 답변 전에 긴 추론 과정을 생성하는 경우가 많다.

 

이런 모델은 출력 토큰이 길어질 수 있다.

 

출력 토큰이 길어지면 decode 단계에서 KV Cache가 계속 누적된다.

 

2026년 연구들은 reasoning LLM이 긴 chain-of-thought를 생성하면서 decoding 단계에서 거대한 KV Cache를 축적하고, 이 때문에 지연시간과 처리량 문제가 커진다고 지적한다. 예를 들어 Kara 연구는 sliding-window KV cache compression으로 이 문제를 줄이려 한다고 설명한다.

 

즉, KV Cache는 단순히 긴 입력만의 문제가 아니다.

 

긴 출력도 문제다.

 

모델이 오래 생각하고 길게 답할수록 캐시가 쌓인다.

 

KV Cache를 줄이는 대표 방법

KV Cache 문제를 줄이기 위한 방법은 여러 가지다.

 

1. 짧은 컨텍스트 사용

필요한 문서만 넣고, 불필요한 대화 기록은 줄인다.

 

2. 프롬프트 요약

긴 문맥을 요약해 토큰 수를 줄인다.

 

3. Prefix Caching

공통 프롬프트의 KV Cache를 재사용한다.

 

4. PagedAttention

KV Cache를 페이지 단위로 관리해 메모리 낭비와 조각화를 줄인다.

 

5. KV Cache Quantization

K,V를 낮은 정밀도로 저장해 메모리 사용량을 줄인다.

 

6. KV Cache Offloading

일부 캐시를 CPU 메모리 등으로 옮긴다.

 

7. MQA/GQA 사용

어텐션 구조를 바꿔 Key와 Value 저장량을 줄인다.

 

8. Sliding Window Attention

최근 일정 범위의 토큰만 보게 하여 캐시 크기를 제한한다.

 

9. Cache Compression

중요도가 낮은 K,V를 압축하거나 제거한다.

 

이런 방법들은 각자 장단점이 있다.

 

속도, 품질, 메모리, 구현 복잡도 사이의 타협이 필요하다.

 

KV Cache를 간단한 숫자로 감각 잡기

정확한 KV Cache 크기는 모델 구조마다 다르다.

 

하지만 감각은 이렇다.

 

모델이 클수록 레이어가 많다.
레이어가 많을수록 각 토큰마다 저장해야 할 K,V가 많다.
컨텍스트가 길수록 저장할 토큰 수가 많다.
동시 요청이 많을수록 캐시가 요청 수만큼 늘어난다.

 

그래서 긴 컨텍스트 LLM 서비스에서 GPU 메모리는 모델 파라미터만 보는 것으로 부족하다.

총 GPU 메모리 사용량
= 모델 가중치
+ KV Cache
+ 중간 계산 메모리
+ 배치 처리 오버헤드
+ 시스템 여유 공간

 

실제 서비스에서는 KV Cache가 동시성의 한계를 정하는 경우가 많다.

 

KV Cache가 사용자 경험에 미치는 영향

KV Cache는 사용자에게 직접 보이지 않는다.

 

하지만 사용자 경험에는 큰 영향을 준다.

 

응답 속도

KV Cache가 잘 작동하면 다음 토큰 생성이 빨라진다.

 

긴 문서 처리

긴 컨텍스트를 얼마나 안정적으로 처리할 수 있는지에 영향을 준다.

 

동시 접속 처리

서버가 동시에 몇 명의 요청을 처리할 수 있는지와 연결된다.

 

비용

GPU 메모리 사용량이 늘면 더 비싼 인프라가 필요하다.

 

대화 지속성

긴 대화를 유지하려면 더 많은 KV Cache 또는 컨텍스트 관리 전략이 필요하다.

 

즉, 사용자는 “답변이 빠르다/느리다” 정도로 느끼지만, 뒤에서는 KV Cache가 매우 중요한 역할을 한다.

 

KV Cache와 Prompt Caching은 같은가

비슷하지만 완전히 같지는 않다.

 

KV Cache는 Transformer 내부의 Key와 Value 벡터를 저장하는 기술적 구조다.

 

Prompt Caching 또는 Prefix Caching은 같은 프롬프트 앞부분에 대해 이미 만들어진 KV Cache를 재사용하는 응용 전략이다.

 

즉,

KV Cache = 저장되는 내부 계산 결과
Prompt Caching = 같은 프롬프트에 대해 그 결과를 재사용하는 전략

 

라고 볼 수 있다.

 

모든 KV Cache가 곧 Prompt Caching은 아니지만, Prompt Caching은 KV Cache를 활용한다.

 

KV Cache와 모델의 ‘기억’은 다르다

KV Cache를 모델의 기억이라고 표현할 수는 있지만, 조심해야 한다.

 

KV Cache는 장기 기억이 아니다.

 

모델이 영구적으로 학습하는 것도 아니다.

 

대화 세션이나 요청 처리 중에 필요한 계산 결과를 임시로 저장하는 것이다.

 

세션이 끝나거나 캐시가 지워지면 사라진다.

 

즉, KV Cache는 “모델이 새 지식을 배웠다”는 뜻이 아니다.

 

그저 현재 문맥을 빠르게 처리하기 위해 임시 저장한 계산 결과다.

 

쉽게 말하면,

 

파인튜닝은 모델의 공부다.
RAG는 참고자료를 가져오는 것이다.
KV Cache는 방금 읽은 내용을 계산 메모장에 적어두는 것이다.

 

자주 헷갈리는 포인트

1. KV Cache는 모델 파라미터인가?

아니다. 모델 파라미터는 학습된 가중치이고, KV Cache는 추론 중에 입력 토큰마다 생성되는 임시 계산 결과다.

 

2. KV Cache를 쓰면 답변 품질이 좋아지나?

직접적으로 품질을 높이는 기술은 아니다. 이전 계산을 재사용해 속도를 높이는 기술이다. 다만 긴 문맥을 효율적으로 처리할 수 있어 서비스 품질에는 영향을 줄 수 있다.

 

3. KV Cache는 항상 켜는 것이 좋은가?

대부분의 자기회귀 생성에서는 유리하다. 하지만 메모리 제약, 배치 방식, 특수한 학습·평가 환경에 따라 캐시 사용 여부를 조정할 수 있다.

 

4. 긴 컨텍스트 모델은 KV Cache 문제가 더 큰가?

그렇다. 컨텍스트가 길수록 저장해야 할 K,V가 많아지므로 KV Cache 메모리 부담이 커진다.

 

5. KV Cache를 압축하면 품질이 떨어지나?

압축 방식에 따라 다르다. 낮은 정밀도 양자화나 일부 캐시 제거는 메모리를 줄이지만, 지나치면 정확도나 문맥 유지력이 떨어질 수 있다.

 

결국 핵심은 이것이다

KV Cache는 LLM 추론을 빠르게 만드는 핵심 기술이다.

 

LLM은 답변을 한 토큰씩 생성한다.
각 토큰을 만들 때 앞 문맥의 Key와 Value가 필요하다.
이전 토큰들의 K,V를 매번 다시 계산하면 느리다.
그래서 한 번 계산한 K,V를 저장해두고 재사용한다.

 

한마디로 정리하면 이렇다.

 

KV Cache는 LLM이 이전 문맥을 매번 다시 계산하지 않도록 저장해두는 어텐션 계산 결과다.

 

하지만 이 편리함에는 비용이 있다.

 

KV Cache는 GPU 메모리를 많이 차지한다.
긴 문맥일수록 더 커진다.
동시 요청이 많을수록 더 부담된다.
그래서 LLM 서빙에서는 KV Cache 관리가 속도, 비용, 처리량을 좌우한다.

 

요즘 LLM 인프라에서 PagedAttention, Prefix Caching, KV Cache Quantization, Offloading, MQA, GQA 같은 기술이 계속 나오는 이유도 여기에 있다.

 

결국 KV Cache는 단순한 내부 구현 디테일이 아니다.

 

LLM이 빠르게 답하고, 긴 문맥을 다루고, 많은 사용자를 동시에 처리할 수 있게 만드는 AI 인프라의 핵심 메모리 기술이다.

 

참고 자료

1. Hugging Face / KV cache strategies
   https://huggingface.co/docs/transformers/kv_cache
   KV Cache가 자기회귀 생성에서 이전 Key·Value 벡터를 재사용해 텍스트 생성을 최적화하는 방식과 다양한 캐시 전략을 설명한 공식 문서다.
2. Hugging Face / Best Practices for Generation with Cache
   https://huggingface.co/docs/transformers/v4.44.2/kv_cache
   KV Cache가 토큰 단위 생성에서 왜 필요한지, 캐시 클래스와 양자화 캐시를 어떻게 활용하는지 설명한 문서다.
3. NVIDIA TensorRT-LLM / KV Cache System
   https://nvidia.github.io/TensorRT-LLM/latest/features/kvcache.html
   TensorRT-LLM의 KV Cache 시스템, 요청 간 재사용, 오프로딩, 우선순위 기반 제거, MQA·GQA 지원 등을 설명한 공식 문서다.
4. NVIDIA TensorRT / KV Cache
   https://docs.nvidia.com/deeplearning/tensorrt/latest/inference-library/transformers-kv-cache.html
   Transformer 기반 LLM 추론에서 TensorRT가 KV Cache를 어떻게 지원하는지 설명한 NVIDIA 공식 문서다.
5. NVIDIA Developer Blog / Introducing New KV Cache Reuse Optimizations in NVIDIA TensorRT-LLM
   https://developer.nvidia.com/blog/introducing-new-kv-cache-reuse-optimizations-in-nvidia-tensorrt-llm/
   Paged KV Cache, Quantized KV Cache, Circular Buffer KV Cache, 우선순위 기반 eviction 등 KV Cache 최적화 기법을 다룬 NVIDIA 기술 블로그다.
6. Kwon et al. / Efficient Memory Management for Large Language Model Serving with PagedAttention
   https://arxiv.org/abs/2309.06180
   vLLM과 PagedAttention을 제안한 논문으로, KV Cache 메모리 낭비와 조각화를 줄여 LLM 서빙 처리량을 높이는 방식을 설명한다.
7. vLLM / PagedAttention Paper
   https://arxiv.org/abs/2309.06180
   PagedAttention이 운영체제의 페이징 개념을 KV Cache 관리에 적용해 동적이고 길이가 다른 요청을 효율적으로 처리하는 원리를 확인할 수 있다.
8. NVIDIA TensorRT-LLM / KV Cache Reuse
   https://nvidia.github.io/TensorRT-LLM/advanced/kv-cache-reuse.html
   동일한 prefix prompt를 공유하는 요청들 사이에서 KV Cache 페이지를 재사용하는 방법을 설명한 공식 문서다.

 

참고 영상

1. KV Cache Explained
   https://www.youtube.com/results?search_query=KV+Cache+explained+LLM
   LLM 추론에서 KV Cache가 왜 필요한지, 이전 토큰의 Key와 Value를 어떻게 재사용하는지 설명하는 영상을 찾을 수 있는 검색 링크다.
2. vLLM PagedAttention Explained
   https://www.youtube.com/results?search_query=vLLM+PagedAttention+KV+Cache+explained
   vLLM의 PagedAttention이 KV Cache를 페이지 단위로 관리해 메모리 낭비를 줄이는 원리를 설명하는 영상을 찾을 수 있다.
3. Transformer KV Cache
   https://www.youtube.com/results?search_query=Transformer+KV+Cache+attention+explained
   Transformer의 Query, Key, Value와 KV Cache가 어텐션 계산에서 어떤 역할을 하는지 설명하는 영상을 찾을 수 있다.
4. LLM Inference Optimization KV Cache
   https://www.youtube.com/results?search_query=LLM+inference+optimization+KV+cache
   LLM 추론 속도, GPU 메모리, 배치 처리, KV Cache 최적화 전략을 설명하는 영상을 찾을 수 있다.
5. Prefix Caching LLM
   https://www.youtube.com/results?search_query=prefix+caching+LLM+KV+cache
   같은 시스템 프롬프트나 공통 문맥을 가진 요청에서 KV Cache를 재사용하는 prefix caching 개념을 설명하는 영상을 찾을 수 있다.