ChatGPT나 Claude를 쓸 때 첫 번째 토큰이 나오기까지 눈에 띄게 오래 걸리고, 이후 토큰은 거의 즉시 스트리밍된다. 이 비대칭의 이유는 KV 캐싱(KV Caching)이다. 중복 행렬 연산을 제거해 자동회귀 생성 속도를 최대 5배 높이는 LLM 추론의 핵심 최적화 기법이다.

왜 중복 연산이 발생하는가

트랜스포머는 입력 토큰 전체를 처리해 각 토큰의 히든 스테이트를 만든다. 그 중 마지막 토큰의 히든 스테이트만 다음 토큰 예측에 사용된다. 나머지는 중간 부산물이다.

어텐션 레이어에서 각 토큰은 세 벡터를 얻는다: 쿼리(Q), 키(K), 값(V). 마지막 토큰의 어텐션 출력을 계산하려면 다음이 필요하다.

• 마지막 토큰의 Q 벡터
• 시퀀스 전체의 K·V 벡터

문제는 토큰 생성 루프에서 발생한다. 50번째 토큰을 생성할 때 1~49번 토큰의 K·V가 필요하다. 51번째 토큰에도 1~50번 토큰의 K·V가 필요하다. 1~49번의 K·V는 이미 계산됐고 값이 변하지 않는다. 그럼에도 매 스텝마다 처음부터 다시 계산한다. 스텝당 O(n)의 중복 연산, 전체 생성에 걸쳐 O(n²) 낭비다.

KV 캐싱: 한 번 계산하고 영원히 재사용

해법은 단순하다. 계산한 K·V를 메모리에 저장하고, 새 토큰이 추가될 때마다 그 토큰의 K·V만 새로 계산해 캐시에 붙인다.

각 스텝의 처리 흐름:

1. 최신 토큰의 Q, K, V만 계산
2. 새 K·V를 캐시에 추가
3. 이전 K·V는 캐시에서 불러옴
4. 새 Q로 전체 캐시된 K·V에 대해 어텐션 실행

어텐션 연산 자체는 여전히 시퀀스 길이에 비례한다. 그러나 K·V를 생성하는 비싼 투영 연산은 토큰당 한 번만 일어나고, 다시는 반복되지 않는다.

TTFT: 첫 번째 토큰이 느린 이유

프리필(Prefill) 단계: 프롬프트를 제출하면 모델이 전체 입력을 한 번의 포워드 패스로 처리하면서 모든 토큰의 K·V를 계산해 캐시를 채운다. 연산량이 가장 많은 구간이다.

캐시가 채워진 뒤부터는 디코드(Decode) 단계: 신규 토큰 하나의 포워드 패스만 필요하다. 이전 토큰들은 캐시에서 읽어온다.

이 초기 지연을 TTFT(Time-to-First-Token)라고 부른다. 프롬프트가 길수록 프리필이 길어지고 TTFT도 커진다. TTFT 최적화 기법(청크 프리필, 투기적 디코딩, 프롬프트 캐싱)은 모두 이 구조에 기반한다.

트레이드오프: 연산 vs. 메모리

KV 캐싱은 연산을 메모리로 교환한다. 모든 레이어가 모든 토큰의 K·V 벡터를 GPU 메모리에 유지해야 한다.

Qwen 2.5 72B(80개 레이어, 32K 컨텍스트, 히든 차원 8192) 기준 단일 요청의 KV 캐시는 수 기가바이트에 달한다. 수백 개의 동시 요청이 처리될 때 캐시 크기가 모델 가중치 자체를 초과하는 경우도 흔하다.

컨텍스트 길이를 두 배로 늘리면 KV 캐시도 두 배로 커진다. 같은 GPU에서 처리할 수 있는 동시 사용자 수가 줄어드는 직접적인 이유다.

메모리 병목을 줄이는 기법들

실무 적용 포인트

• 긴 프롬프트는 TTFT에 비용이 든다. 출력 길이가 아니라 입력 길이가 체감 대기 시간을 결정한다.
• 컨텍스트 창 확장은 동시 처리량과 트레이드오프다. 창을 2배 늘리면 배치 크기가 줄어든다.
• vLLM, TGI, TensorRT-LLM은 모두 KV 캐싱 위에 구축된다. 서빙 스택 선택 시 각 구현의 캐시 관리 방식이 성능을 결정한다.

관련 문서

• llm-inference — 토큰화부터 KV 캐시까지 LLM 추론 전 과정 해설
• turboquant — KV 캐시·임베딩을 2~4비트로 압축하는 양자화 알고리즘
• deepseek-v4 — KV 캐시를 10분의 1로 줄인 하이브리드 어텐션 아키텍처
• inference-caching — LLM 추론 캐싱 세 가지 전략 비교
• vllm-recipes — 하드웨어별·모델별 vLLM 실행 레시피

참고 자료

• KV Caching in LLMs, Clearly Explained — X @_avichawla (2026-05)