MLA KV Cache, 긴 문맥에서 먼저 줄어드는 병목

2026년 4월 28일 | 개발 공부

---

MLA(Multi-Head Latent Attention)는 긴 문맥 추론에서 key/value cache를 토큰마다 그대로 쌓는 대신, attention에 필요한 정보를 더 작은 latent 표현으로 압축해 저장하는 방식이다. 나는 처음에 이걸 “attention을 줄이는 기법” 정도로만 읽었는데, 조금 더 들여다보니 포인트가 달랐다. attention을 없애는 게 아니라, 긴 문맥에서 제일 먼저 메모리를 잡아먹는 KV Cache의 저장 형태를 바꾸는 쪽에 가깝다.

긴 컨텍스트 모델 이야기를 할 때 보통은 “몇 토큰까지 읽느냐”를 먼저 본다. 64K, 128K, 1M 같은 숫자가 워낙 눈에 잘 들어온다. 그런데 실제로 서버에 올려 보는 관점에서는 숫자보다 먼저 걸리는 게 있다. 이미 지나간 토큰의 key와 value를 다음 디코딩을 위해 계속 들고 있어야 하고, 이 저장소가 길이에 거의 비례해서 커진다. 그래서 컨텍스트 길이를 늘리는 문제는 모델이 기억을 잘하느냐 이전에, 그 기억을 어떤 모양으로 보관하느냐의 문제로 바뀐다.

1. KV Cache는 왜 먼저 병목이 되는가

Transformer decoder는 새 토큰을 만들 때마다 이전 토큰들의 key/value를 다시 계산하지 않으려고 cache에 남긴다. 짧은 대화에서는 이게 당연한 최적화처럼 보인다. 하지만 문맥이 길어지면 cache는 단순한 부가물이 아니라 inference runtime의 주된 메모리 점유자가 된다. 특히 batch를 키우거나 여러 요청을 동시에 처리하면, 모델 파라미터보다 “지금 살아 있는 문맥들”이 운영 비용을 더 직접적으로 흔들 수 있다.

내가 헷갈렸던 지점은 여기였다. 긴 문맥 개선이라고 하면 RoPE scaling, position interpolation, sparse attention 같은 이름을 먼저 떠올렸다. 그런데 serving 쪽에서 보면 위치 인코딩이 버틴다고 끝나는 게 아니다. 실제 병목은 “이 긴 문맥을 매 요청마다 들고 있을 수 있느냐”로 내려온다. 그래서 MLA 같은 구조는 정확도 향상 기법이라기보다, 긴 문맥을 계속 들고 있을 수 있게 만드는 저장 구조로 보는 편이 더 자연스럽다.

구분	짧은 문맥에서 보이는 문제	긴 문맥에서 먼저 커지는 문제
계산	forward latency	prefill 시간, attention 범위
저장	큰 체감이 적음	요청별 KV Cache 누적
운영	단일 요청 성능 중심	동시성, eviction, cache allocator

2. MLA는 attention을 없애지 않고 cache 모양을 바꾼다

MLA를 읽을 때 조심해야 할 점은 “linear attention으로 완전히 바꾸는 이야기”와 섞지 않는 것이다. HyLo 같은 하이브리드 구조에서는 Mamba2나 Gated DeltaNet 같은 linear block도 들어가지만, MLA layer는 여전히 attention의 역할을 남긴다. 대신 full key/value를 모든 head 차원으로 저장하지 않고, 더 낮은 차원의 latent key-value 표현을 저장한 뒤 필요한 순간에 다시 펼쳐 쓴다. 이 덕분에 cache footprint가 줄어든다.

이 구조는 타협에 가깝다. attention을 모두 지우면 긴 문맥의 특정 위치를 다시 집어내는 힘이 약해질 수 있고, attention을 모두 남기면 cache가 감당하기 어려워진다. MLA는 그 사이에서 “일부 layer는 여전히 global retrieval 감각을 갖되, 저장 비용은 줄이자”는 선택지다. 그래서 나는 MLA를 모델 구조 이름으로만 보지 않고, 긴 문맥 모델의 운영 가능한 attention 예산을 정하는 장치로 읽게 됐다.

3. 하이브리드 업사이클링에서 MLA가 하는 역할

하이브리드 LLM 업사이클링은 이미 학습된 Transformer checkpoint를 버리지 않고, 일부 block을 더 효율적인 sequence module로 바꾸는 접근이다. 여기서 MLA는 꽤 애매하지만 중요한 위치에 있다. Mamba2나 Gated DeltaNet은 긴 sequence를 더 싸게 흘려보내는 쪽에 강하고, MLA는 attention을 완전히 포기하지 않으면서 cache 비용을 낮추는 쪽에 강하다. 둘을 섞으면 “긴 문맥을 읽는 비용”과 “중요한 위치를 다시 찍는 능력”을 같이 맞춰 볼 수 있다.

이런 관점으로 보면 업사이클링의 난점도 조금 선명해진다. 기존 Transformer가 배운 표현을 최대한 살리고 싶지만, block을 갈아끼우는 순간 activation 분포와 hidden state 흐름이 흔들린다. 그래서 HyLo 쪽에서는 teacher-guided distillation이나 staged long-context training 같은 절차가 같이 나온다. 구조만 바꾸는 게 아니라, 바뀐 구조가 이전 모델의 언어 감각을 잃지 않도록 다시 맞춰 주는 과정이 필요하다.

4. 내가 실제로 메모해 둔 구분

앞으로 긴 문맥 모델을 읽을 때는 “컨텍스트 길이” 하나로 뭉개지 않으려고 한다. 적어도 세 칸은 나눠 보는 게 낫다. 첫째, 위치를 얼마나 멀리까지 표현할 수 있는가. 둘째, 그 길이에서 학습 신호를 어떻게 안정적으로 넣는가. 셋째, 실제 serving에서 그 문맥을 cache로 얼마나 오래 들고 있을 수 있는가. MLA는 이 중 세 번째 칸에 가장 직접적으로 닿아 있다.

• RoPE scaling이나 long-context SFT는 “멀리 있는 토큰을 다루는 학습/표현” 쪽에 가깝다.
• Chunked KL이나 hidden-state KL은 “긴 sequence로 distillation을 돌릴 수 있느냐”에 가깝다.
• MLA KV Cache는 “그 긴 문맥을 운영 중에 들고 있을 수 있느냐”에 가깝다.

이렇게 나누면 논문을 읽을 때 덜 헷갈린다. 같은 “long-context”라는 말 안에서도 학습 길이, 평가 길이, serving 길이가 서로 다를 수 있고, 어느 하나가 늘었다고 나머지가 자동으로 따라오지는 않는다. 특히 2M token 같은 숫자를 볼 때는 모델이 그 길이를 “이해했다”는 주장과 시스템이 그 길이를 “올려서 돌렸다”는 주장을 분리해서 읽어야 한다.

5. 당장 써먹을 수 있는 읽기 순서

긴 문맥 모델 논문이나 모델 카드를 볼 때 나는 이제 아래 순서로 먼저 표시해 둔다. 첫 줄에는 최대 컨텍스트 길이를 적고, 바로 다음 줄에는 KV Cache 처리 방식을 적는다. 그다음에 attention을 얼마나 남겼는지, linear block이 어디에 들어갔는지, distillation이나 SFT 길이는 얼마인지 본다. 이 순서가 좋은 이유는 간단하다. 숫자가 큰 모델일수록 “얼마나 읽는가”보다 “어떤 비용으로 읽는가”가 먼저 흔들리기 때문이다.

MLA가 모든 긴 문맥 문제의 답이라는 뜻은 아니다. latent 표현으로 줄이는 만큼 복원 과정과 layer 배치가 중요하고, attention layer를 얼마나 남길지도 품질과 latency 사이에서 계속 trade-off가 난다. 다만 내 머릿속 분류는 조금 정리됐다. 긴 문맥은 단순히 창을 넓히는 일이 아니라, 창을 넓힌 뒤에도 cache를 감당할 수 있게 저장 모양을 바꾸는 일이다. MLA KV Cache는 그 저장 모양을 먼저 보게 만드는 좋은 체크포인트로 남았다.

관련해서 더 깊게 보려면 HyLo 논문 리뷰에서 다룬 하이브리드 업사이클링 흐름을 같이 보면 좋다. 거기서는 MLA만 따로 떼기보다 Mamba2, Gated DeltaNet, long-context distillation, vLLM runtime까지 한 번에 묶어 설명했다. 이 글은 그중에서 내가 다음 논문을 읽을 때 바로 재사용하려고 남겨 둔 작은 구분표에 가깝다.