| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- LLM
- Kubernetes
- Java
- CKA 기출문제
- PETERICA
- kotlin
- Spring
- AI
- 기록으로 실력을 쌓자
- CKA
- SRE
- 오블완
- 공부
- aws
- Rag
- golang
- 바이브코딩
- Pinpoint
- Linux
- go
- AWS EKS
- 코틀린 코루틴의 정석
- APM
- minikube
- CloudWatch
- MySQL
- kotlin coroutine
- 정보처리기사 실기 기출문제
- 티스토리챌린지
- tucker의 go 언어 프로그래밍
- Today
- Total
피터의 개발이야기
[AI] KV Cache — LLM은 어떻게 ‘생각의 흐름’을 기억하는가 본문
[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해
ㅁ 들어가며
Attention과 Encoder–Decoder 구조를 정리하다 보면,
실제 LLM을 운영하는 단계에서 반드시 마주치는 문제가 있다.
컨텍스트가 길어질수록 응답이 느려지고, p95 latency가 튀며, GPU 메모리가 급격히 소모된다.
여기서 자연스럽게 이런 질문을 하게 된다.
“이미 계산한 내용을 왜 계속 다시 계산하고 있을까?”
KV Cache는 바로 이 질문에 대한 답이다.
단순한 성능 최적화가 아니라, LLM이 과거 맥락을 유지하면서 사고를 이어가기 위한 구조다.
ㅁ Decoder는 실제로 어떻게 다음 토큰을 만드는가
Decoder는 Autoregressive 방식으로 동작한다.
즉, 매 토큰마다:
- 지금까지 생성된 모든 토큰을 다시 바라보고
- 현재 Query와 전체 Key/Value로 Attention을 수행한 뒤
- 다음 토큰을 예측한다.
KV Cache가 없다면,
매 스텝마다 과거 전체를 다시 계산한다.
구조적으로 보면 Decoder는 매 단어마다
자신의 기억을 전부 다시 훑는 셈이다.
이 때문에 연산량은 O(n²)로 증가한다.
문장이 길어질수록 비용이 폭증하는 이유다.
ㅁ KV Cache의 본질 — 과거를 저장하고 현재만 계산한다
KV Cache는 간단하다.
이미 계산된 Key / Value를 메모리에 저장해 두고,
다음 스텝에서는 새 Query만 계산한다.
즉,
과거는 재사용하고
현재만 새로 계산한다.
한 줄로 요약하면 이렇다.
KV Cache는 Decoder의 기억 장치다.
사람이 글을 쓸 때
앞 문단을 매번 처음부터 다시 읽지 않듯,
LLM도 이미 본 맥락을 기억하고 그 위에 사고를 이어간다.
ㅁ Without vs With KV Cache — 직관적으로 보기
KV Cache가 없으면:
1² + 2² + 3² + …
KV Cache가 있으면:
1 + 2 + 3 + …
수식보다 중요한 건 관점이다.
“매번 전체를 다시 계산하느냐” vs “이미 본 것은 기억하느냐”
이 차이가 latency와 비용을 결정한다.
ㅁ Prefill과 Decode — 사고의 준비 단계와 실행 단계
LLM 추론은 두 단계로 나뉜다.
Prefill 단계:
- 프롬프트 전체를 병렬 처리
- 초기 KV Cache 생성
- 첫 토큰까지의 시간(TTFT)을 결정
Decode 단계:
- 토큰을 하나씩 생성
- KV Cache를 읽고 쓰며 반복
- 토큰당 생성 시간(TPOT)을 결정
그래서:
긴 프롬프트는 Prefill 비용
긴 대화는 Decode + KV Cache 비용으로 나타난다.
ㅁ 메모리 관점 — 왜 Long Context가 비싼가
KV Cache는 시퀀스 길이에 선형 비례한다.
대략적으로:
레이어 수 × hidden dimension × 토큰 수
예를 들어 Llama-2-7B 기준으로:
4K 토큰 ≈ 약 2GB
8K 토큰 ≈ 약 4GB
컨텍스트는 공짜가 아니다.
우리가 프롬프트에 넣는 모든 토큰은 GPU 메모리를 직접 소비한다.
ㅁ RAG와 KV Cache
Retriever가 문서를 많이 가져올수록:
- Encoder 부담 증가
- Decoder KV Cache 증가
쓸모없는 Chunk는:
- Attention 낭비
- Cache 낭비
그래서 나는 이렇게 정리한다.
RAG 품질은 결국 KV Cache 효율로 드러난다.
ㅁ 운영 관점 인사이트
Prompt 길이 = KV Cache 크기
Multi-turn 대화 = Cache 누적
Streaming 응답 = Cache 위에서 사고 흐름 실시간 출력
즉,
KV Cache는 단순한 성능 옵션이 아니라
컨텍스트 설계 문제다.
ㅁ 인사이트 — 의식의 흐름을 저장한다는 것
이 챕터를 정리하면서 개인적인 인사이트가 하나 생겼다.
사람도 글을 쓸 때,
이미 쓴 문장과의 연관성을 계속 의식한다.
“지금 흐름에서 다음 말이 자연스러운가”
LLM도 구조적으로 같은 일을 한다.
이미 생성된 문장은 내부 상태 벡터가 되고,
다음 토큰은 그 상태와의 관계를 확률로 계산해 이어 붙인다.
차이는 하나다.
사람은 이를 감각적으로 느끼고,
모델은 벡터 연산으로 수행한다.
나는 이렇게 이해하게 되었다.
사람은 생각을 기억으로 저장하고,
LLM은 생각을 벡터로 저장한다.
표현 방식만 다를 뿐,
과거 맥락을 참고하고
현재 상태를 재해석하며
다음 생각을 만들어간다는 점에서
둘은 놀라울 만큼 닮아 있다.
ㅁ 마무리
KV Cache는 단순한 추론 최적화가 아니다.
Transformer가
- 과거 맥락을 유지하고
- 현재 상태를 재해석하며
- 다음 생각을 만들어가는
사고 구조의 일부다.
그래서 LLM을 운영하다 보면 결국 KV Cache까지 이해하게 된다.
성능 문제가 아니라, 사고 흐름의 문제이기 때문이다.
사람과 AI의 차이는 결국 표현 방식이다.
우리는 의미를 느끼고, 모델은 그 의미를 수치로 계산한다.
하지만 구조적으로 보면, 우리는 같은 방식으로 생각을 이어가고 있다.
'AI > AI이론 | 공부' 카테고리의 다른 글
| [AI] 온톨로지에서 Agentic GraphRAG까지 - “관계 기반 AI”가 필요한 이유 (0) | 2026.02.05 |
|---|---|
| [AI] Embedding 기초 — Transformer가 만든 의미를 저장하는 방법 (0) | 2026.02.05 |
| [AI] Transformer Encoder-Decoder 구조 - Attention 다음 단계, 메커니즘에서 시스템으로 (0) | 2026.02.03 |
| [AI] Attention 메커니즘 — LLM은 어떻게 ‘중요한 정보’를 골라내는가 (0) | 2026.02.02 |
| [AI] Backend · DevOps · SRE를 지나 AI Platform Engineer를 지향하게 된 이유 (0) | 2026.01.27 |