KV 캐시 (KV Cache)

KV 캐시(KV Cache)는 트랜스포머 모델이 토큰을 하나씩 만들어 낼 때, 앞서 처리한 토큰들의 계산 결과를 다시 쓰기 위해 메모리에 담아 두는 저장 공간입니다. 이름의 K와 V는 어텐션 메커니즘에서 쓰는 키(Key)와 값(Value) 행렬을 가리킵니다. 눈에 보이지 않는 내부 구조지만, 실제 서비스에서 응답 속도와 동시 처리량을 결정하는 가장 큰 변수 가운데 하나입니다.

왜 저장해 두는가

언어 모델은 답변을 한 번에 만들지 않고 토큰을 하나 뽑을 때마다 지금까지의 문장 전체를 다시 참조합니다. 아무것도 저장하지 않는다면 100번째 토큰을 만들 때 앞의 99개 토큰에 대한 키와 값을 처음부터 다시 계산해야 하고, 이 과정을 토큰마다 반복하면 계산량이 길이의 제곱에 비례해 늘어납니다. 한 번 계산한 키와 값은 뒤에서도 그대로 쓰이므로, 저장해 두고 새 토큰의 몫만 덧붙이면 됩니다.

이 덕분에 생성 단계는 토큰당 계산량이 거의 일정해집니다. 프롬프트 전체를 한 번에 읽는 앞부분(프리필)과 토큰을 하나씩 뽑는 뒷부분(디코드)의 성격이 다른 것도 이 때문입니다. 프리필은 계산량이 많고, 디코드는 계산보다 메모리를 읽고 쓰는 속도에 발목이 잡힙니다. 스트리밍으로 글자가 또박또박 나오는 구간이 바로 디코드 단계입니다.

메모리를 얼마나 먹는가

KV 캐시 크기는 레이어 수, 어텐션 헤드 수, 헤드 차원, 시퀀스 길이, 그리고 키와 값 두 벌이라는 점을 모두 곱한 값입니다. 여기에 숫자 하나를 몇 바이트로 저장하는지가 다시 곱해집니다. 중요한 것은 이 값이 대화가 길어질수록 선형으로 커지고, 사용자 한 명마다 따로 잡힌다는 사실입니다. 모델 가중치는 한 번만 올리면 되지만 KV 캐시는 동시 접속자 수만큼 늘어납니다.

그래서 긴 컨텍스트 윈도우를 지원한다는 말과 실제로 긴 문맥을 여러 명이 동시에 쓸 수 있다는 말은 다릅니다. GPU 메모리에서 모델 가중치가 차지하고 남은 공간을 KV 캐시가 나눠 쓰는 구조라, 캐시가 커지면 동시에 받을 수 있는 요청 수가 줄어듭니다. 서빙 비용이 예상보다 빨리 오르는 원인을 추적해 보면 여기에 닿는 경우가 많습니다.

숫자 감각을 잡아 두면 판단이 쉬워집니다. 같은 모델이라도 대화 길이가 두 배가 되면 그 사용자가 잡는 캐시도 대략 두 배가 되고, 그만큼 다른 사용자가 쓸 자리가 줄어듭니다. 그래서 추론 서버를 운영할 때는 최대 컨텍스트 길이를 모델이 지원하는 최댓값 그대로 열어 두지 않고, 실제 필요한 길이로 제한해 동시 처리량을 확보하는 경우가 많습니다.

줄이는 방법

가장 널리 쓰이는 접근은 네 가지입니다. 첫째, 여러 어텐션 헤드가 키와 값을 공유하게 만드는 GQA(Grouped-Query Attention) 같은 구조 변경입니다. 최근 모델 상당수가 기본으로 채택하고 있습니다. 둘째, 캐시에 담는 숫자의 정밀도를 낮추는 KV 캐시 양자화입니다. 셋째, 캐시를 고정 크기 블록으로 쪼개 관리해 조각난 빈 공간을 없애는 PagedAttention 방식으로, vLLM이 이 방식을 대중화했습니다. 넷째, 같은 앞부분을 여러 요청이 공유하는 프리픽스 캐싱입니다.

프리픽스 캐싱은 API 사용자에게도 익숙한 형태로 노출됩니다. 긴 시스템 프롬프트나 매번 붙이는 문서가 있을 때, 그 앞부분에 대한 KV 캐시를 재사용해 요금과 지연을 줄여 주는 것이 프롬프트 캐싱입니다. 캐시를 활용하려면 변하지 않는 내용을 프롬프트 앞쪽에 몰아 두어야 한다는 실무 규칙도 여기서 나옵니다.

긴 대화를 압축해 다시 넣는 컨텍스트 압축도 결국 같은 문제를 다른 쪽에서 푸는 방법입니다. 캐시를 효율적으로 관리하는 대신 캐시에 들어갈 내용 자체를 줄이는 접근입니다. 두 방법은 대체 관계가 아니라 함께 쓰는 관계이고, 어느 쪽이 먼저인지는 병목이 메모리인지 토큰 비용인지에 따라 갈립니다.

정리하면 KV 캐시는 계산을 메모리와 맞바꾸는 장치입니다. 없으면 너무 느리고, 있으면 메모리를 잡아먹습니다. 모델을 직접 서빙하지 않더라도 이 구조를 알아 두면 긴 대화에서 응답이 느려지는 이유, 프롬프트 순서를 바꾸는 것만으로 비용이 달라지는 이유를 설명할 수 있습니다.