토큰당 300KB에서 69KB로: LLM의 KV 캐시 문제, 대체 뭐가 문제이고 어떻게 풀고 있을까

LLM이 긴 대화를 기억하려면 엄청난 메모리가 필요해요

ChatGPT나 Claude 같은 대규모 언어 모델(LLM)을 써보면, 대화가 길어질수록 응답이 느려지거나 비용이 올라가는 걸 느끼신 적 있을 거예요. 이게 단순히 "텍스트가 많아서"만은 아니에요. 그 뒤에는 KV 캐시(Key-Value Cache)라는 구조적인 문제가 숨어 있거든요.

이게 뭐냐면, Transformer 모델이 텍스트를 생성할 때 이전에 처리한 토큰들의 정보를 저장해두는 임시 메모리예요. 우리가 대화할 때 "아까 그거"를 기억하려면 머릿속에 이전 내용을 담아둬야 하잖아요? LLM도 마찬가지예요. 새 토큰을 생성할 때마다 이전 모든 토큰의 Key와 Value 벡터를 참조해야 하는데, 이걸 매번 다시 계산하면 너무 느리니까 캐시에 저장해두는 거예요.

문제는 이 캐시가 차지하는 메모리가 어마어마하다는 거예요. 예를 들어 GPT-3 수준의 모델에서 토큰 하나당 KV 캐시가 차지하는 메모리가 약 300KB 정도 될 수 있어요. 대화가 수천 토큰으로 길어지면? 수 GB의 GPU 메모리가 KV 캐시에만 잡히는 거예요. 배치 처리로 여러 사용자의 요청을 동시에 처리하려면 이게 몇 배로 불어나고요. 결국 "모델의 성능"이 아니라 "메모리"가 병목이 되는 상황이 벌어지는 거죠.

KV 캐시가 왜 이렇게 큰 걸까?

전통적인 Transformer의 Multi-Head Attention(MHA) 구조를 잠깐 살펴볼게요. MHA에서는 어텐션 헤드(attention head)마다 독립적인 Key와 Value를 가져요. 이게 뭐냐면, 모델이 텍스트를 여러 관점에서 동시에 바라보는 거예요. 한 헤드는 문법적 관계를, 다른 헤드는 의미적 관계를 파악하는 식이죠. GPT-3는 96개의 헤드를 가지고 있는데, 각 헤드마다 별도의 K, V를 저장해야 하니까 캐시가 커질 수밖에 없어요.

구체적으로 계산해보면, 모델 차원이 12,288이고 레이어가 96개인 모델에서 FP16(16비트 부동소수점)을 쓸 때, 토큰 하나의 KV 캐시 크기는 대략 2(K와 V) × 96(레이어) × 12,288(차원) × 2(바이트) = 약 4.7MB예요. 레이어 수와 차원이 커질수록 이 값은 기하급수적으로 늘어나고요.

해결책 1: Multi-Query Attention (MQA)

가장 먼저 나온 접근법은 Google이 2019년에 제안한 Multi-Query Attention이에요. 아이디어가 정말 단순한데요, Query는 헤드마다 다르게 두되 Key와 Value는 모든 헤드가 하나를 공유하자는 거예요. 비유하자면, 여러 명의 기자(Query)가 각자 다른 질문을 하지만, 참조하는 자료(Key, Value)는 같은 한 부를 돌려보는 거예요.

이렇게 하면 KV 캐시 크기가 헤드 수만큼 줄어들어요. 96개 헤드를 쓰는 모델이라면 KV 캐시가 1/96로 줄어드는 거죠. 엄청난 절약이에요. 다만 단점도 있어요. Key와 Value의 표현력이 줄어들기 때문에 모델 품질이 약간 떨어질 수 있거든요.

해결책 2: Grouped-Query Attention (GQA)

MQA가 너무 극단적이라면, 그 중간 지점을 찾은 게 Grouped-Query Attention이에요. Google이 2023년에 발표했고, LLaMA 2에서 실제로 채택되면서 널리 알려졌어요. 모든 헤드가 하나의 KV를 공유하는 대신, 헤드들을 몇 개의 그룹으로 나누고 그룹 내에서만 KV를 공유하는 방식이에요.

예를 들어 32개 헤드를 8개 그룹으로 나누면, KV 캐시가 1/4로 줄어들면서도 MQA보다 훨씬 좋은 품질을 유지할 수 있어요. 품질과 효율의 균형을 잘 맞춘 거죠. 실제로 LLaMA 2 70B 모델이 GQA를 적용해서 추론 속도를 크게 개선했어요.

해결책 3: Multi-head Latent Attention (MLA)

DeepSeek이 제안한 MLA는 좀 더 수학적으로 우아한 접근이에요. KV를 그룹핑하는 대신, 아예 저차원 잠재 공간(latent space)으로 압축해서 저장하는 거예요. 이게 뭐냐면, 고해상도 이미지를 JPEG으로 압축하는 것과 비슷한 개념이에요. 원본 정보를 완벽히 보존하진 않지만, 핵심 정보는 거의 손실 없이 훨씬 작은 크기로 저장할 수 있죠.

구체적으로는 Key와 Value를 저차원 벡터로 다운프로젝션(down-projection)해서 캐시에 저장하고, 필요할 때 업프로젝션(up-projection)으로 복원하는 방식이에요. 이렇게 하면 토큰당 KV 캐시 크기를 69KB 수준까지 줄일 수 있어요. 300KB에서 69KB면 약 77%나 줄어든 거예요.

업계 맥락과 현재 흐름

이 세 가지 접근법은 서로 경쟁한다기보다 발전 과정으로 볼 수 있어요. MQA → GQA → MLA 순서로 점점 정교해지고 있죠. 현재 업계의 주요 모델들을 보면, Google의 Gemini 계열은 MQA를 활용하고, Meta의 LLaMA 계열은 GQA를, DeepSeek은 MLA를 각각 채택하고 있어요.

이 외에도 KV 캐시 문제를 우회하는 다른 접근들도 있어요. FlashAttention은 KV 캐시 자체를 줄이진 않지만 GPU 메모리 접근 패턴을 최적화해서 속도를 높이고, PagedAttention(vLLM에서 사용)은 KV 캐시의 메모리 단편화를 줄여서 더 많은 요청을 동시에 처리할 수 있게 해줘요.

한국 개발자에게 주는 시사점

LLM을 서빙하거나 파인튜닝하는 업무를 하고 있다면, KV 캐시 최적화는 직접적으로 비용과 성능에 영향을 주는 핵심 지식이에요. 어떤 어텐션 메커니즘을 사용하는 모델을 선택하느냐에 따라 같은 GPU로 처리할 수 있는 동시 요청 수가 몇 배씩 차이날 수 있거든요.

LLM 기반 서비스를 운영 중이라면, vLLM의 PagedAttention이나 GQA 기반 모델로의 전환을 검토해볼 만해요. 그리고 모델 아키텍처를 공부하고 싶은 분이라면 MHA → MQA → GQA → MLA의 발전 흐름을 따라가보는 게 Transformer의 핵심을 이해하는 좋은 경로가 될 거예요.