KV 캐시(Key-Value Cache)란? LLM이 앞선 토큰 계산을 다시 쓰는 방법

TL;DR

KV 캐시(Key-Value Cache)는 LLM이 이미 처리한 토큰의 어텐션 Key와 Value를 저장해, 다음 토큰을 만들 때 같은 계산을 반복하지 않도록 돕는 추론용 메모리입니다. 답변 생성을 빠르게 만들지만 입력과 출력이 길어지고 동시 요청이 많아질수록 메모리 사용량도 커집니다. 프롬프트 캐싱이나 시맨틱 캐시와 이름은 비슷해도 저장 대상과 재사용 범위가 다릅니다.

핵심 3줄 요약

• 핵심 1
  KV 캐시는 이전 토큰의 어텐션 중간 계산을 재사용합니다. 완성된 답변이나 사용자의 장기 기억을 저장하는 기능이 아닙니다.
• 핵심 2
  계산량을 줄이는 대신 메모리를 씁니다. 긴 컨텍스트와 많은 동시 대화에서는 캐시 용량이 중요한 운영 기준이 됩니다.
• 핵심 3
  프롬프트 캐싱·시맨틱 캐시와 구분해야 합니다. 제품 기능으로서의 캐싱, 답변 재사용, 모델 내부 추론 캐시는 서로 다른 층의 개념입니다.

이 글에서 다룰 내용

KV 캐시를 한 문장으로 정의하면 무엇인가요?

KV 캐시는 자기회귀 LLM이 앞서 처리한 토큰에서 계산한 어텐션의 Key와 Value 벡터를 계층별로 저장하고, 다음 토큰을 예측할 때 다시 사용하는 추론용 캐시입니다.

자기회귀 언어 모델은 답변을 한 토큰씩 만듭니다. 새 토큰을 예측할 때는 앞에 놓인 토큰과의 관계를 다시 살펴야 합니다. 캐시가 없다면 모델은 생성 단계마다 이전 토큰의 Key와 Value를 반복해서 계산합니다.

Hugging Face 문서는 KV 캐시가 이미 처리한 토큰의 어텐션 계층에서 나온 KV 쌍을 저장한다고 설명합니다. 다음 단계에서는 과거 Key와 Value를 캐시에서 꺼내고, 새 토큰에 해당하는 값만 계산해 이어 붙입니다. 이 캐시는 모델의 각 어텐션 계층에서 따로 관리됩니다.

한 줄 정리: KV 캐시는 LLM이 방금까지 읽고 계산한 토큰의 어텐션 중간값을 잠시 보관해 다음 토큰 생성에 다시 쓰는 작업 메모리입니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 2,000토큰짜리 회의록을 AI에 넣고 세 줄 요약을 요청했다고 가정해 보겠습니다. 모델은 회의록과 지시문을 먼저 처리한 뒤 요약문의 첫 토큰을 만듭니다. 두 번째 토큰을 만들 때도 앞선 회의록과 첫 출력 토큰을 참고하고, 세 번째 토큰에서는 여기에 두 번째 출력 토큰까지 더해 살펴봅니다.

KV 캐시가 없다면 새 토큰을 하나 만들 때마다 이미 읽은 회의록과 앞선 출력의 Key와 Value를 다시 계산해야 합니다. KV 캐시를 쓰면 회의록과 이전 출력 토큰의 계산 결과를 보관하고, 방금 추가된 토큰의 값만 계산합니다.

답변이 길어질수록 다시 계산하지 않아도 되는 부분이 늘어납니다. 대신 보관해야 할 Key와 Value도 계속 쌓입니다. 그래서 긴 문서를 처리하거나 여러 사용자의 답변을 동시에 생성할 때는 연산 속도뿐 아니라 캐시가 차지할 메모리도 함께 봐야 합니다.

쉬운 예시: 2,000토큰 회의록을 매 출력 단계마다 처음부터 다시 계산하지 않고, 이미 처리한 부분의 어텐션 결과를 저장한 뒤 새 토큰 계산만 보태는 방식입니다.

KV 캐시는 어떤 순서로 작동하나요?

1. 입력 토큰을 한 번 처리합니다

모델은 프롬프트의 토큰을 어텐션 계층에 통과시킵니다. 이 단계에서 각 토큰의 Query, Key, Value가 만들어집니다. 처음 입력을 처리하는 구간은 보통 프리필(Prefill)이라고 부릅니다.

2. 이전 토큰의 Key와 Value를 저장합니다

각 계층에서 나온 과거 Key와 Value가 KV 캐시에 들어갑니다. Query는 현재 토큰이 무엇을 참고할지 계산할 때 쓰이며, 보통 다음 생성 단계에 그대로 쌓아 두는 대상은 Key와 Value입니다.

3. 새 토큰의 값만 계산합니다

모델이 출력 토큰을 하나 만들면 그 토큰의 새 Key와 Value를 계산해 캐시에 덧붙입니다. 다음 단계의 Query는 캐시에 쌓인 과거 Key 전체와 비교하고, 관련도에 따라 Value를 조합합니다.

4. 답변이 이어지는 동안 캐시가 자랍니다

일반적인 동적 캐시는 토큰이 늘어날수록 커집니다. Hugging Face 문서는 동적 캐시, 고정 크기 캐시, 양자화 캐시처럼 속도와 메모리 사용 특성이 다른 방식을 제공합니다. 슬라이딩 윈도우 어텐션처럼 최근 구간만 유지하는 구조도 있습니다.

5. 요청이 끝나면 캐시를 정리하거나 재사용합니다

한 요청의 생성이 끝나면 캐시를 해제하는 구성이 일반적입니다. 서버는 같은 앞부분을 가진 요청 사이에서 KV 블록을 재사용하는 프리픽스 캐싱을 적용하기도 합니다. AWS Neuron 문서는 vLLM이 사용 가능한 메모리를 확인하고 계층별 요구량에 맞춰 캐시 블록을 할당한다고 설명합니다.

핵심 인사이트: KV 캐시는 계산을 없애는 기술이 아니라, 이미 끝낸 계산을 메모리에 보관해 같은 일을 반복하지 않도록 바꾸는 기술입니다.

AI 제품과 개발에서 왜 중요한가요?

토큰 생성의 반복 계산을 줄입니다

Hugging Face 문서에 따르면 KV 캐시가 없으면 생성 단계마다 과거 Key와 Value를 다시 계산합니다. 캐시를 쓰면 현재 토큰의 값만 새로 계산합니다. 긴 출력에서 같은 연산을 되풀이하는 일을 줄여 응답 생성을 효율적으로 만듭니다.

긴 컨텍스트의 실제 비용을 이해하게 합니다

컨텍스트 윈도우가 크다고 해서 긴 입력이 항상 가볍게 처리되는 것은 아닙니다. 입력과 출력 토큰이 늘면 계층마다 저장하는 KV 데이터도 커집니다. 모델 크기, Key·Value 헤드 수, 숫자 정밀도, 배치와 동시 요청 수에 따라 필요한 메모리가 달라집니다.

동시 사용자 수와 처리량에 영향을 줍니다

AI 서버가 여러 대화를 동시에 생성하면 요청마다 캐시 공간이 필요합니다. 캐시가 메모리를 많이 차지하면 동시에 처리하는 요청 수가 줄고, 일부 캐시를 CPU 메모리로 옮기는 상황도 생깁니다. NVIDIA TensorRT와 AWS Neuron 문서는 KV 캐시의 메모리 할당과 업데이트를 추론 시스템의 별도 관리 대상으로 다룹니다.

캐시 전략 선택이 서비스 설계가 됩니다

동적 캐시는 필요한 만큼 자라 메모리를 비교적 유연하게 쓰고, 고정 크기 캐시는 미리 공간을 잡아 컴파일 최적화에 유리한 경우가 있습니다. 양자화나 오프로딩은 메모리 부담을 낮추지만 지원 모델, 속도와 품질 영향을 실제 환경에서 확인해야 합니다.

실전 팁: LLM 서버를 비교할 때 모델 파일 크기만 보지 마세요. 최대 입력·출력 길이, 동시 요청 수, KV 캐시 정밀도, 캐시 사용률과 초과 시 처리 방식까지 함께 확인해야 합니다.

헷갈리는 용어와 무엇이 다른가요?

KV 캐시와 일반 캐시

일반 캐시는 같은 키나 요청에 대응하는 완성된 결과를 저장했다가 돌려주는 넓은 개념입니다. KV 캐시는 완성 답변이 아니라 LLM 어텐션 계층의 Key와 Value 중간 계산을 저장합니다. 캐시를 사용해도 새 출력 토큰은 계속 생성합니다.

KV 캐시와 프롬프트·컨텍스트 캐싱

프롬프트 캐싱이나 컨텍스트 캐싱은 여러 요청에서 반복되는 긴 입력의 처리를 재사용하도록 제공되는 제품·API 기능입니다. 구현 과정에서 KV 상태를 활용하기도 하지만, 사용자가 보는 만료 시간, 할인, 최소 토큰과 지원 모델은 서비스별 정책입니다. Google Cloud는 Vertex AI의 컨텍스트 캐싱이 이전 요청의 상태인 KV 쌍을 활용할 수 있다고 설명합니다.

KV 캐시는 모델 추론 내부의 계산 구조이고, 프롬프트 캐싱은 그 재사용 범위를 요청 사이로 넓혀 사용자에게 제공하는 서비스 기능에 가깝습니다. 모든 제품의 프롬프트 캐싱이 같은 방식으로 구현된다고 단정해서는 안 됩니다.

KV 캐시와 시맨틱 캐시

시맨틱 캐시는 새 질문의 의미가 과거 질문과 비슷하면 저장된 답변 자체를 재사용합니다. KV 캐시는 비슷한 질문을 찾지 않으며 완성 답변도 돌려주지 않습니다. 같은 문맥을 계산할 때 필요한 어텐션 중간값을 재사용할 뿐입니다.

KV 캐시와 컨텍스트 윈도우

컨텍스트 윈도우는 모델이 한 요청에서 다룰 수 있는 토큰 범위를 가리킵니다. KV 캐시는 그 범위 안의 토큰을 생성 과정에서 효율적으로 참고하기 위한 메모리 구조입니다. 컨텍스트 한도가 크면 KV 캐시 메모리 요구량도 커질 수 있지만 두 용어는 같은 뜻이 아닙니다.

KV 캐시와 AI 메모리

AI 제품의 메모리는 사용자 선호나 이전 대화 정보를 다음 세션에도 활용하는 기능을 뜻하기도 합니다. KV 캐시는 보통 현재 추론이나 서버가 허용한 재사용 구간에서 쓰는 계산 상태입니다. 사용자 프로필을 장기 저장하는 메모리 기능과 구분해야 합니다.

비교 정리: 일반 캐시는 결과 재사용, 프롬프트 캐싱은 반복 입력 처리 재사용, 시맨틱 캐시는 비슷한 질문의 답변 재사용, 컨텍스트 윈도우는 처리 가능한 토큰 범위, KV 캐시는 어텐션 Key·Value 계산 재사용입니다.

실전에서는 무엇을 점검해야 하나요?

1. 입력과 출력 길이를 따로 측정합니다

짧은 질문에 긴 답을 만드는 서비스와 긴 문서를 넣고 짧게 요약하는 서비스는 캐시가 자라는 방식과 지연 구간이 다릅니다. 평균값만 보지 말고 상위 길이의 요청도 확인합니다.

2. 동시 요청 수를 실제 조건으로 시험합니다

한 명의 데모가 빠르더라도 여러 요청이 겹치면 캐시 공간이 부족해집니다. 목표 동시 사용자 수에서 첫 토큰 시간, 토큰 생성 속도, 처리량, GPU 메모리와 캐시 사용률을 함께 기록합니다.

3. 캐시가 찼을 때의 동작을 확인합니다

새 요청을 대기시키는지, 오래된 블록을 지우는지, 일부를 CPU나 디스크로 옮기는지 확인합니다. 오프로딩은 더 많은 캐시를 보관하게 돕지만 데이터 이동 때문에 응답이 느려지기도 합니다.

4. 모델 구조와 런타임 지원 범위를 확인합니다

모든 생성 모델이 같은 KV 캐시 구조를 쓰는 것은 아닙니다. Hugging Face는 Mamba처럼 어텐션 KV 상태를 사용하지 않는 모델은 일반 KV 캐시 클래스와 호환되지 않는다고 안내합니다. 모델과 서빙 엔진의 공식 문서를 기준으로 설정해야 합니다.

5. 캐시 데이터의 처리 정책을 확인합니다

KV 캐시는 원문 자체와 같지는 않지만 사용자 입력에서 계산된 내부 상태입니다. 관리형 AI 서비스의 캐시 격리, 보존 시간, 삭제, 데이터 레지던시와 비보존 설정은 제품마다 다릅니다. 민감한 문서를 처리한다면 해당 서비스의 최신 데이터 처리 문서를 따로 확인합니다.

실전 체크: 요청 길이, 동시성, 캐시 메모리, 캐시 부족 시 동작, 지원 모델, 데이터 처리 정책을 같은 부하 테스트와 운영 문서에서 확인하세요.

사용할 때 무엇을 주의해야 하나요?

첫째, KV 캐시를 장기 기억으로 오해하지 않습니다. 캐시는 추론 계산을 재사용하는 구조이며, 사용자의 선호를 기억하거나 사실을 저장하는 데이터베이스가 아닙니다.

둘째, 속도 향상만 보고 메모리 비용을 빼지 않습니다. 컨텍스트와 출력이 길고 동시 요청이 많을수록 캐시가 GPU 메모리의 큰 부분을 차지합니다.

셋째, 훈련에 그대로 적용하지 않습니다. Hugging Face 문서는 해당 캐싱을 추론에만 사용해야 하며 훈련 중 활성화하면 예상하지 못한 오류가 생길 수 있다고 안내합니다.

넷째, 프롬프트 캐싱의 제품 조건을 KV 캐시의 일반 원리로 바꾸어 말하지 않습니다. 지원 모델, 최소 입력 길이, 보존 시간과 가격은 서비스마다 자주 바뀌므로 최신 공식 문서를 확인합니다.

다섯째, 캐시 적중률 하나로 성능을 판단하지 않습니다. 첫 토큰 시간, 토큰당 생성 속도, 처리량, 메모리 부족, 캐시 축출과 품질 검증을 함께 봅니다.

여섯째, 민감한 입력의 보관 여부를 추측하지 않습니다. 관리형 서비스의 캐시가 어디에 얼마나 오래 남는지는 공급자의 데이터 처리 정책과 설정으로 확인해야 합니다.

주의: KV 캐시는 빠른 생성을 돕지만 공짜 메모리가 아닙니다. 긴 컨텍스트와 높은 동시성을 설계할 때는 속도·용량·데이터 정책을 한 묶음으로 검증하세요.

자주 묻는 질문

Q1. KV 캐시의 K와 V는 무엇인가요?

K는 Key, V는 Value입니다. 어텐션에서 현재 토큰의 Query가 어떤 과거 토큰을 얼마나 참고할지 Key와 비교하고, 그 비중에 따라 Value 정보를 조합합니다. KV 캐시는 과거 토큰의 Key와 Value를 저장합니다.

Q2. KV 캐시를 쓰면 AI 답변 내용이 달라지나요?

올바르게 구현했다면 같은 계산을 반복하지 않도록 줄이는 최적화이므로 원래 계산과 같은 결과를 목표로 합니다. 다만 캐시 양자화, 제한된 윈도우, 축출이나 구현 오류는 속도·메모리뿐 아니라 출력에도 영향을 주기도 해 검증이 필요합니다.

Q3. KV 캐시는 챗GPT의 메모리 기능인가요?

아닙니다. 챗GPT 같은 제품의 메모리는 사용자 정보를 이후 대화에 활용하는 기능을 뜻하기도 합니다. KV 캐시는 LLM 추론 중 어텐션 계산을 재사용하는 내부 메모리 구조입니다.

Q4. 입력이 길수록 KV 캐시도 커지나요?

일반적인 트랜스포머 추론에서는 그렇습니다. 저장할 토큰 수, 모델 계층, KV 헤드, 헤드 크기, 숫자 정밀도와 동시 시퀀스 수가 메모리 사용량에 영향을 줍니다. 슬라이딩 윈도우나 양자화 캐시는 증가 폭을 줄입니다.

Q5. KV 캐시와 프롬프트 캐싱은 같은가요?

같지 않습니다. KV 캐시는 모델 내부의 Key·Value 중간 계산을 저장하는 구조입니다. 프롬프트 캐싱은 반복되는 입력 처리를 요청 사이에서 재사용하도록 제품이나 API가 제공하는 기능입니다. 구현상 KV 상태를 활용하기도 하지만 적용 범위와 정책은 서비스마다 다릅니다.

출처

마무리

KV 캐시는 LLM이 앞서 처리한 토큰의 어텐션 Key와 Value를 저장해 다음 토큰 생성에 다시 쓰는 추론용 메모리입니다. 반복 계산을 줄여 생성을 효율적으로 만들지만 토큰과 동시 요청이 늘수록 메모리 부담도 커집니다.

감자나라ai님이 LLM 제품이나 서버 사양을 검토한다면 모델 크기와 최대 컨텍스트만 보지 말고 KV 캐시 용량, 동시 요청 수, 캐시 부족 시 동작과 데이터 처리 정책까지 확인해 보세요. 이 네 가지를 함께 봐야 실제 사용 환경의 속도와 안정성을 판단하기 좋습니다.