KV 캐시

KV 캐시는 LLM이 글을 만들 때 앞에서 계산한 결과(Key·Value)를 메모처럼 저장해 두고 새 토큰만 추가로 계산하게 해서 생성 속도를 크게 높이는 장치다. 대신 GPU 메모리를 많이 쓰고, 개발자는 API의 프롬프트 캐싱으로 반복되는 앞부분의 비용과 대기 시간을 줄일 때 직접 쓰게 된다.

Hugging Face 블로그 실험. SmolLM2-1.7B로 토큰 300개를 생성한 시간으로, 약 5배 차이다.

첫 글자만 느리고 그다음은 빠르다

추론은 두 단계로 나뉜다. 프롬프트를 한꺼번에 읽어 캐시를 채우는 단계와, 그 캐시를 읽으며 토큰을 하나씩 만드는 단계다. 긴 문서를 넣으면 첫 글자가 나오기까지 한참 걸리고 그 뒤로 술술 나오는 이유가 이것이다.

속도의 대가는 메모리

캐시는 글이 길수록 커지고, 동시 사용자마다 따로 필요하다. 그래서 GPU에 캐시를 얼마나 담을 수 있느냐가 한 번에 처리할 수 있는 요청 수를 정한다. 예전 서빙 방식은 요청마다 최대 길이만큼 메모리를 미리 잡아 두어 낭비가 컸는데, vLLM의 PagedAttention이 캐시를 작은 블록으로 나눠 필요할 때만 할당하면서 이를 크게 줄였다.

캐시를 낮은 정밀도(FP8 등)로 저장하는 양자화도 메모리를 줄이는 방법으로 널리 쓰인다.

API에서는 프롬프트 캐싱으로 만난다

같은 시스템 프롬프트, 도구 정의, 긴 문서로 시작하는 요청을 반복한다면 프롬프트 캐싱을 켜자. 서버가 그 앞부분의 KV 캐시를 보관해 두었다가 다음 요청에서 다시 계산하지 않는다. 긴 코딩 에이전트 세션이 감당할 만한 비용으로 돌아가는 것도 앞선 대화의 캐시를 계속 재사용하기 때문이다.

vLLM 같은 자체 서빙 엔진에서도 프리픽스 캐싱을 켜면 같은 앞부분을 가진 요청끼리 캐시를 나눠 쓸 수 있다.

바뀌지 않는 내용은 앞에 둔다

캐시는 tools, system, messages 순서로 이어지는 앞부분이 정확히 같아야 적중한다. 고정된 지시문과 문서는 앞에, 매번 바뀌는 질문은 뒤에 둔다. 시스템 프롬프트 맨 앞에 현재 시각을 넣으면 매번 캐시가 깨지는 대표적인 실수가 된다.

같은 앞부분을 반복해서 보내는 곳이면 쓴다

KV 캐시 자체는 모든 LLM이 알아서 쓰고, 사용자가 직접 챙기는 건 반복되는 앞부분을 캐싱하는 일이다. 앞부분이 길고 자주 반복될수록 아끼는 비용과 시간이 커진다.