파라미터 착시: KV 캐시의 진실

LLM 추론 비용의 구조를 이해하는 데 가장 핵심이 되는 그림입니다.

Qwen2.5-Coder-32B-Instruct와 Qwen3.6 35B-A3B는 둘 다 Q4 기준 20 GB 안팎의 로컬 모델이에요. 그런데 긴 컨텍스트를 켰을 때 단기 기억 비용은 정반대로 움직입니다. Qwen2.5-Coder-32B는 128K 컨텍스트에서 BF16 기준 KV 캐시가 약 32 GiB까지 올라가고, Qwen3.6 35B-A3B는 더 긴 262K 컨텍스트에서도 full attention 레이어가 적어 약 5 GiB 수준으로 잡혀요. 모델 파일 크기는 비슷한데 작업 메모리는 6배 이상 차이가 납니다. 이 비대칭이 어디서 오는지 — 그게 이 부록의 전부예요.

본문 §2에서 "모델 크기만 보고 GPU를 사지 말라"고 했던 경고의 구조적 이유가 여기에 있습니다. 결론부터 말하면, 컨텍스트가 긴 추론에서 메모리를 잡아먹는 주범은 모델 가중치가 아니라 KV 캐시이고, KV 캐시의 크기는 파라미터 수와 거의 무관합니다.

"모델 크기 = KV 캐시 크기"는 틀렸어요

두 모델을 나란히 놓을게요.

항목	Qwen2.5-Coder-32B-Instruct	Qwen3.6 35B-A3B
모델 가중치 (BF16)	~65 GB	~69.4 GB
모델 가중치 (Q4_K_M/UD)	~19.9 GB	~21.4 GB
긴 컨텍스트	128K (YaRN)	262K native
attention 구조	GQA 중심	Gated DeltaNet 30층 + Gated Attention 10층
full attention KV 구조	64층 × 8 KV heads × 128 dim	10층 × 2 KV heads × 256 dim
KV 캐시 (BF16 기준)	~32 GiB	~5 GiB
KV / Q4 가중치 비율	~1.6배	~0.2배

두 모델은 파일 크기만 보면 같은 급으로 보여요. 하지만 Qwen2.5-Coder-32B는 긴 문맥에서 표준 GQA(Grouped Query Attention, 여러 Query head가 더 적은 KV head를 공유하는 방식) KV cache가 그대로 쌓이고, Qwen3.6 35B-A3B는 대부분의 레이어가 Gated DeltaNet(Gated DeltaNet, 긴 문맥 정보를 고정 크기 상태로 압축해 다루는 선형 attention 계열)이라 표준 KV cache가 필요한 레이어가 훨씬 적습니다.

Q4로 양자화한 20 GB 모델에 128K KV 캐시 약 32 GiB — 모델 파일보다 단기 기억이 더 무거워질 수 있습니다. 4비트로 가중치를 줄여도, 긴 대화에서 새로 생기는 작업 메모리는 별도 청구서처럼 따라와요. 파라미터 크기만 보면 시야가 잘못 잡힙니다.

KV 캐시란: 트랜스포머의 어텐션(attention) 계산 시, 이전 토큰들의 Key·Value 벡터를 저장해두는 메모리. "이미 읽은 것을 다시 읽지 않겠다"는 캐시인데, 컨텍스트가 길어질수록 저장할 과거 토큰이 폭발적으로 늘어납니다.

이 표의 핵심은 "모델 파일 크기"와 "긴 문맥의 작업 메모리"가 같은 축이 아니라는 점이에요. 같은 20 GB 안팎의 모델이라도, 표준 attention 레이어가 많이 남아 있으면 KV 캐시가 모델 파일보다 커질 수 있고, linear attention(linear attention, 긴 문맥에서 메모리 증가가 작은 attention 계열)을 많이 섞으면 더 긴 컨텍스트에서도 KV 캐시가 작게 유지될 수 있습니다.

비유 하나: 책을 동시에 펼쳐두기

모델 가중치가 "서가에 꽂혀 있는 책"이라면, KV 캐시는 "지금 이 순간 책상에 펼쳐 둔 책"이에요. 서가에 책이 1만 권 있어도 책상 위 펼친 책 한 권만 읽고 있다면 책상은 그 한 권만큼만 차지해요. 반대로, 서가에 책이 100권뿐이어도 그 100권을 모두 동시에 펼쳐서 페이지를 넘기며 비교하고 있다면 책상은 100권만큼 차지하죠.

추론 중인 LLM이 하는 일이 정확히 두 번째예요. 컨텍스트의 모든 토큰을 매 스텝마다 함께 봐야 하므로, 토큰 하나하나의 K·V 벡터가 책상 위에 동시에 펼쳐져 있어야 합니다. 컨텍스트가 길어질수록 책상 위에 동시에 펼쳐 두는 책 수가 늘어나는 것이고, 그 책상 면적이 KV 캐시예요.

KV 캐시 폭발의 수학

KV 캐시 크기는 다음 수식으로 결정됩니다:

KV cache (bytes) = T x L x 2 x H_kv x d x 2

기호	의미	Qwen2.5-Coder-32B 스펙 예시
T	시퀀스 길이 (토큰 수)	131,072
L	레이어(layer) 수	64
2	Key + Value 두 벡터	—
H_kv	KV 헤드(head) 수	8
d	헤드 차원(head_dim)	128
2 bytes	bf16 정밀도	—

같은 수식을 다른 모델들에 대입한 결과입니다. Qwen3.6 35B-A3B는 40층 전체가 표준 attention이 아니라, 30층은 Gated DeltaNet이고 10층만 Gated Attention이에요. 그래서 아래 표에서는 "표준 KV cache가 필요한 레이어"만 따로 계산합니다.

모델	T	L	H_kv	d	계산 방식	최대 KV
Llama-3.1-70B (GQA)	128K	80	8	128	모든 레이어 full	~40 GiB
Qwen2.5-Coder-32B-Instruct	128K	64	8	128	모든 레이어 GQA	~32 GiB
Qwen3.6 27B	262K	16	8	128	64층 중 full attention 16층만	~16 GiB
Qwen3.6 35B-A3B	262K	10	2	256	40층 중 Gated Attention 10층만	~5 GiB
GLM-5.1 (MLA 무시)	203K	78	64	256	naive full attention 가정	~990 GiB

같은 식, 같은 단위인데 모델 구조 차이만으로 비용이 크게 갈려요. 핵심은 T와 표준 attention 레이어 수에 선형 비례한다는 것입니다. 컨텍스트를 2배 늘리면 KV 캐시도 2배지만, full attention 레이어를 1/4로 줄여도 KV 캐시가 1/4로 줄어요.

모델 가중치는 추론 중 고정입니다. KV 캐시만이 세션마다, 토큰마다 쌓여요.

Gemma4:31b처럼 Hybrid Attention(Hybrid Attention, 서로 다른 attention 레이어를 섞는 구조)을 쓰는 모델은 같은 수식에서 실제 기울기가 더 낮아져요. 이 곡선을 한눈에 보면:

KV 캐시 크기 vs 컨텍스트 길이 — Gemma4:31b naive 60 global과 Hybrid 50 SWA + 10 global 비교

naive 가정의 직선은 컨텍스트가 끝까지 갔을 때 240 GB에 닿아요. 같은 모델이라도 일부 레이어를 슬라이딩 윈도우로 바꾸고, full attention용 global KV head를 따로 줄이면 기울기가 훨씬 낮아져 21 GB 부근에 머뭅니다 — 같은 토큰을 더 가벼운 단가로 저장하는 것이고, §5에서 그 메커니즘을 봐요.

GPU는 왜 90% 놀고 있을까요

GPU가 느린 이유는 연산이 부족해서가 아니에요. 데이터를 꺼내오는 속도(대역폭) 가 병목입니다.

flowchart TD HBM["GPU 메모리(GPU Memory, HBM)"] Cores["GPU 연산 코어(Compute Cores) 데이터 대기 중(waiting for data)"] HBM -->|"대역폭(bandwidth, GB/s)"| Cores

KV 캐시가 클수록, 어텐션 계산마다 더 많은 데이터를 메모리에서 불러와야 해요. 대역폭이 부족하면 연산 코어가 데이터를 기다리며 놀아요. 극단적으로는 GPU 활용률의 90%가 메모리 이동 대기에 잡아먹힙니다.

연산 코어를 아무리 추가해도 대역폭이 병목이면 의미가 없어요. 코어가 아니라 대역폭을 넓혀야 합니다.

산술 강도(Arithmetic Intensity): FLOPs ÷ Bytes(메모리 이동량). 어텐션은 산술 강도가 낮은 연산이에요 — 계산 자체보다 메모리 읽기/쓰기가 훨씬 많죠. 이것이 HBM 대역폭이 AI 추론 성능의 핵심 지표가 되는 이유입니다.

MoE: 파라미터가 많아도 KV는 왜 작을까요

GLM-5.1은 744B 파라미터인데 왜 naive 계산조차 KV 캐시가 "모델보다 작은 쪽"에 놓일 수 있을까요?

KV 캐시 수식을 다시 볼게요:

KV cache = T x L x 2 x H_kv x d x 2

이 수식에 FFN(Feed-Forward Network) 파라미터가 없어요. KV 캐시는 오직 attention 헤드 구조에만 비례합니다.

MoE(Mixture of Experts) 모델은 파라미터의 대부분이 FFN expert에 집중돼요. 추론 시 토큰당 일부 expert만 활성화되어 FFN 계산에 쓰이고, KV 벡터로 캐시되지는 않아요.

비유 둘: 무대 위 배우와 전체 캐스팅

뮤지컬 한 편에 캐스팅된 배우가 200명이라고 쳐요. 그렇다고 무대 위에 매 장면 200명이 다 올라와 있는 건 아니에요. 한 장면에 무대에 서는 인원은 5명, 다음 장면에 다른 5명. 무대 위에 동시에 올라간 사람만이 조명·마이크·동선을 차지하죠. 대기실의 195명은 같은 극장의 일부지만 그 장면의 자원은 거의 쓰지 않아요.

MoE의 expert가 정확히 이 구조예요. 전체 캐스팅(744B 파라미터)은 디스크와 GPU 메모리에 다 올라와 있어야 하지만, 한 토큰을 계산할 때 무대 위에 올라가는 expert는 일부뿐입니다. 그리고 KV 캐시는 그중에서도 무대 자체(어텐션 부분) 비용만 청구해요 — 배우(FFN expert)가 몇 명이든 무대 크기는 안 변하기 때문이에요.

비유의 한계: 실제로는 expert 가중치도 GPU 메모리에 상시 올라와 있어야 하므로, "대기실의 배우는 자원을 안 쓴다"는 비유는 메모리 용량 측면에서는 맞지 않아요. 정확히는 "추론 한 스텝의 계산량과 KV 캐시 비용은 활성 expert에만 비례한다"가 맞고, "총 파라미터를 GPU에 올리는 비용은 전체 캐스팅에 비례한다"는 별개예요. 비유는 KV 비용 구조를 직관화하는 도구일 뿐, 모든 측면을 덮지는 않아요.

GLM-5.1 744B의 파라미터 배분 (추정 — ZhipuAI 공개 모델 카드와 config.json 기반 추산. 정확 비율은 1차 출처 재검증 권장):

구성 요소	파라미터	비중	KV 캐시 기여
Attention	~84B	11%	반영
FFN expert	~660B	89%	없음
합계	744B	100%	—

MoE로 모델 지능(파라미터 수)을 키우는 건 KV 캐시에 거의 청구서가 오지 않아요. 반면 컨텍스트를 늘리는 건 T에 선형 비례하여 직접 청구서가 날아와요.

Hybrid Attention: naive 계산은 과대평가예요

Gemma4:31b는 256K 컨텍스트를 지원하지만, 실제 KV 캐시는 naive 계산의 9% 수준이에요. 이유는 Hybrid Attention 구조 때문입니다. SWA(Sliding Window Attention)와 attention sink의 1차 출처 메커니즘은 어텐션 변형 §1 SWA에서 따로 다뤄요.

Gemma4 시리즈는 두 종류의 어텐션 레이어를 혼합해요:

레이어 타입	설명	KV 캐시
Sliding Window Attention (SWA)	최근 1024 토큰만 봄	컨텍스트 길이와 무관, 고정 크기
Global Attention	전체 컨텍스트를 봄	T에 선형 비례

Gemma4:31b (60층): sliding × 5 + full × 1 패턴이 10회 반복되어 SWA 50층 + Global 10층 (HuggingFace config.json 검증).

KV cache (256K):
  SWA 50층:    50 x 1024 x 2 x 16 x 256 x 2 =  0.78 GiB  (고정)
  Global 10층: 10 x 256K x 2 x  4 x 512 x 2 = 20.00 GiB  (T에 비례)
  실제 합계:                                   20.78 GiB

  naive 계산 (60층 x 256K):                  240.00 GiB
  절감:                                        91%

여기서 Global 레이어의 4 x 512는 Hugging Face Transformers 구현의 num_global_key_value_heads=4, global_head_dim=512를 반영한 값이에요. sliding 레이어는 num_key_value_heads=16, head_dim=256을 씁니다.

Gemma4:26b A4B (30층, 256K 지원): SWA 25층 + Global 5층, MoE (Active 3.8B)

KV cache (256K):
  SWA 25층:    25 x 1024 x 2 x  8 x 256 x 2 =  0.20 GiB
  Global 5층:   5 x 256K x 2 x  2 x 512 x 2 =  5.00 GiB  (256K = 262,144 통일)
  실제 합계:                                    5.20 GiB

Gemma4:26b A4B는 MoE(Global 레이어 KV 헤드가 2개뿐) + Hybrid Attention(Global 레이어가 5층뿐)의 이중 효과로 256K 컨텍스트에서 KV 캐시가 5.2 GiB 수준이에요. 31B Dense 대비 약 4배 작아요(20.78 ÷ 5.20 ≈ 4.00).

MLA: GQA를 한계까지 밀어붙인 구조

GLM-5.1과 DeepSeek 시리즈(V3.1, R1-0528)는 MLA(Multi-head Latent Attention) 를 써요. 취지는 Hybrid Attention과 비슷하지만 접근이 다릅니다. MLA의 잠재 압축 수식과 Decoupled RoPE 처리(qk_rope_head_dim이 따로 분리되는 이유)는 어텐션 변형 §3 MLA에서 1차 출처(DeepSeek-V2 논문) 기준으로 더 깊이 들어가요.

Hybrid Attention: 일부 레이어의 "보는 범위(T)"를 줄여요
MLA: 모든 레이어의 K/V 벡터 자체를 저차원 잠재(latent)로 압축해 저장해요

MLA는 Key와 Value를 공유된 저차원 잠재 벡터 c_kv로 투영해 캐시하고, 어텐션 계산 시 이 잠재 벡터에서 K/V를 재구성해요. 캐시되는 차원이 원래 K/V 차원의 수십 분의 일이라 바이트가 극적으로 줄어듭니다.

GLM-5.1의 config.json에서 직접 읽은 값:

kv_lora_rank      = 512   (압축된 K/V 잠재 차원)
qk_rope_head_dim  =  64   (RoPE positional 부분, 압축 불가)

MLA가 토큰 1개·레이어 1개당 캐시하는 바이트:

(kv_lora_rank + qk_rope_head_dim) x 2 bytes
= (512 + 64) x 2
= 1,152 bytes

GLM-5.1 (78 레이어, 203K 컨텍스트) 전체 KV 캐시:

KV cache (203K):
  MLA 압축 후 실제: 78 x 202752 x 1,152 = 16.97 GiB
                                        = 18.22 GB

  naive (GQA 가정, head_dim 256):           ~990 GB
  압축률:                                     약 57배

notes/model-context-windows.md 의 "MLA는 GQA 대비 60배 이상 작다" 기록과 일치해요.

이제 §1의 비교표를 "실제 KV" 기준으로 다시 써보면:

모델	모델 BF16	실제 KV 캐시	KV / 모델
Gemma4:31b (Hybrid Attention, 256K)	61.4 GB	20.78 GiB	~0.3배
GLM-5.1 (MLA, 203K)	1,488 GB	~17.0 GiB	~0.01배

GLM-5.1은 1.5 TB 모델인데 KV 캐시는 약 17.0 GiB(십진 표기로는 약 18.2 GB). MLA 덕에 "모델 본체를 로드할 수만 있다면 컨텍스트는 거의 공짜"라는 설계가 성립해요. 파라미터 착시는 반대 방향으로도 작동합니다 — 거대 MoE 모델이라고 반드시 단기 기억까지 거대하게 먹는 건 아니에요.

위 비교표를 차트로 보면:

모델 가중치 vs 실제 KV 캐시 — Gemma4:31b는 Q4 weights와 KV가 비슷하고 GLM-5.1은 KV가 Q4 weights의 4% 안팎에 불과해요

깜짝 사실: 작은 Dense 모델에서는 KV 캐시가 모델 본체와 맞먹는 역전 현상이 일어나요. Q4 양자화한 Gemma4:31b는 weights 20 GB / KV 21 GB로 단기 기억이 모델 파일과 비슷해요. naive 가정이라면 12배. "20 GB 모델"이라는 라벨만 보고 24 GB GPU를 사면 — 컨텍스트 채우는 순간 OOM(Out Of Memory)이 납니다. 모델 카드의 파라미터 수가 GPU 견적의 시작점이 아니라는 뜻이에요.

DeepSeek V4: CSA+HCA로 1M 컨텍스트를 압축해요

DeepSeek V4는 MLA(Multi-head Latent Attention, K/V를 저차원 잠재 벡터로 압축해 캐시하는 attention)만 쓰는 직전 계열에서 한 단계 더 나아가, CSA(Compressed Sparse Attention, 압축한 뒤 필요한 압축 블록만 고르는 attention) 와 HCA(Heavily Compressed Attention, 훨씬 큰 묶음으로 장거리 정보를 요약하는 attention) 를 섞어요.

핵심은 "모든 토큰의 K/V를 그대로 보관하지 않는다"예요. 책상 비유로 보면, 표준 attention은 모든 페이지를 펼쳐두는 방식이고, DeepSeek V4는 가까운 몇 페이지는 그대로 두되 오래된 페이지는 4쪽짜리 요약 묶음이나 128쪽짜리 큰 요약 묶음으로 바꿔 보관하는 방식에 가까워요.

flowchart LR T["원본 토큰 스트림 (1M tokens)"] Local["로컬 창(Local window) 최근 128 토큰은 세밀하게 유지"] CSA["CSA 4토큰 → 1 compressed KV query별 top-k 선택"] HCA["HCA 128토큰 → 1 compressed KV 전역 요약 신호"] Attn["Attention local + compressed entries"] T --> Local --> Attn T --> CSA --> Attn T --> HCA --> Attn

Transformers 구현 기준으로 V4 cache는 세 덩어리예요.

덩어리	역할	Pro 1M 기준 대략
Sliding branch	최근 128 토큰의 K=V를 그대로 유지	매우 작음
CSA compressor	4토큰마다 1개 compressed KV 생성	CSA layer당 256 MiB
CSA indexer	compressed KV 중 query별로 볼 top-k를 고름	CSA layer당 64 MiB
HCA compressor	128토큰마다 1개 compressed KV 생성	HCA layer당 8 MiB

DeepSeek-V4-Pro의 config.json 기준 레이어 구성은 HCA 31층 + CSA 30층이에요. 그래서 1M 컨텍스트의 cache는 대략 이렇게 계산됩니다.

DeepSeek-V4-Pro, 1M context, batch=1, BF16 cache:
  CSA 30층: 30 x (256 MiB compressor + 64 MiB indexer) = 9,600 MiB
  HCA 31층: 31 x   8 MiB compressor                      =   248 MiB
  sliding branch: 61층 x 128 tokens x 512 dim x 2 bytes   =   ~8 MiB
  합계:                                                     ~9.6 GiB

DeepSeek-V4-Flash는 더 작아요. config 기준 CSA(Compressed Sparse Attention, 압축한 뒤 필요한 압축 블록만 고르는 attention) 21층 + HCA(Heavily Compressed Attention, 훨씬 큰 묶음으로 장거리 정보를 요약하는 attention) 20층이라 1M 컨텍스트 cache가 약 6.7 GiB예요. 공식 모델 카드의 "1M-token context에서 V3.2 대비 KV cache 10%"라는 표현은 이 구조적 압축을 말합니다. 다만 이 값은 batch 1, cache dtype, 구현 방식에 따라 조금 달라질 수 있어요.

출처 메모: DeepSeek V4 공식 Hugging Face 모델 카드는 Pro/Flash의 1M 컨텍스트와 "FLOPs 27%, KV cache 10%"를 명시하고, Hugging Face Transformers DeepSeek V4 문서는 HCA cache와 CSA cache가 sliding-window K=V branch, compressor, indexer state를 어떻게 나눠 들고 가는지 설명해요.

완화 전략: 모델 설계 vs 런타임 최적화

KV 캐시 압력을 줄이는 기법들은 두 계층으로 나뉘어요.

(1) 모델 설계 단계 — 학습 전 결정

이 계층은 모델이 만들어질 때 정해지고, 사용자는 "이런 구조의 모델을 고르느냐"로 결정해요.

기법	내용	대표 모델
GQA (Grouped Query Attention)	KV 헤드 수를 쿼리 헤드 수보다 적게 두어 공유	Llama-3, Mistral, Gemma4:31b (H_kv=16, H_q=32)
MLA (Multi-head Latent Attention)	K/V를 저차원 잠재 벡터로 압축해 캐시	DeepSeek, GLM-5.1
Hybrid Attention (SWA + Global 혼합)	일부 레이어를 고정 윈도우로 제한	Gemma4 시리즈
CSA+HCA (Compressed Sparse Attention + Heavily Compressed Attention)	4토큰/128토큰 단위 compressed KV를 만들고 필요한 항목만 봄	DeepSeek V4
Linear/SSM 하이브리드	일부 어텐션 레이어를 Gated DeltaNet·Mamba-2로 대체 (KV 캐시 자리에 고정 hidden state)	Qwen3-Next 80B-A3B, Nemotron 3 Super

이 선택은 KV 캐시 크기를 구조적으로 수~수십 배 줄여요. GQA·MLA·Hybrid·Linear/SSM 하이브리드의 메커니즘과 1차 출처 수치는 어텐션 변형 — SWA·GQA·MLA·RoPE/YaRN·Linear 하이브리드에서 묶어 다뤄요.

(2) 런타임 최적화 — 이미 학습된 모델에도 적용

Flash Attention

어텐션 계산을 타일(tile) 단위로 쪼개 HBM↔SRAM 왕복 횟수를 최소화해요. KV 캐시 크기 자체는 줄지 않지만, 읽기 패턴을 최적화해 대역폭 낭비를 줄입니다. v1/v2/v3 별 수치와 PagedAttention·Continuous Batching까지 묶은 시스템 레이어는 추론 시스템·커널 최적화 §1 FlashAttention에서 상세히 다뤄요.

Prefix Caching (Prompt Caching)

시스템 프롬프트처럼 반복되는 입력의 KV 벡터를 서버가 재사용해요. Claude, OpenAI API에서 지원합니다. 대화마다 같은 컨텍스트를 다시 계산하지 않아 비용과 지연 시간을 줄여요. (트랜스포머 추론의 두 단계에서 더 자세히) 서버측 KV 재사용 구현(vLLM APC·SGLang RadixAttention)은 추론 시스템·커널 최적화 §4 Prefix Caching에서 다뤄요.

KV 캐시 양자화와 TurboQuant

KV 캐시 양자화(KV cache quantization)는 이미 계산된 Key·Value 벡터를 BF16 그대로 저장하지 않고 8비트나 4비트 이하로 줄여 저장하는 런타임 압축이에요. 가중치 양자화(weight quantization, 모델 파일 자체를 줄이는 압축)와 다르게, 대화가 길어질수록 새로 생기는 작업 메모리를 줄입니다.

가중치 양자화와 KV cache 압축의 차이, Unsloth Dynamic과 TurboQuant의 위치는 양자화와 KV 압축에서 따로 정리해요.

flowchart LR W["가중치(weights) 모델 파일 자체"] --> WQ["Q4_K_M / UD 로드 전 압축"] K["KV 캐시(KV cache) 추론 중 생기는 단기 기억"] --> KQ["q8_0 / q4_0 / TurboQuant 런타임 압축"]

방식	줄이는 대상	장점	주의점
`q8_0` KV	KV 캐시를 8비트 정수로 저장	품질 손실이 작고 구현이 단순	BF16 대비 절반 수준이라 극단적 절감은 아님
`q4_0` KV	KV 캐시를 4비트 정수로 저장	메모리 절감이 큼	모델·작업에 따라 품질 하락 가능
TurboQuant	vector quantization(vector quantization, 비슷한 숫자 벡터를 대표 코드로 바꿔 저장하는 압축 방법) 기반으로 KV 캐시를 더 세밀하게 압축	긴 컨텍스트·동시 요청에서 추가 절감 가능	구현별 품질·속도 차이가 큼. 2026-05 기준 llama.cpp 일반 릴리스 기능으로 단정하면 위험

TurboQuant는 Google Research가 제안한 KV 캐시 압축 계열이에요. 핵심 아이디어는 벡터를 그대로 저장하지 않고, 비슷한 벡터들을 코드북(codebook, 대표 벡터 사전)에 매핑해 더 작은 코드로 저장하는 것입니다. 이삿짐 비유로 보면, q8_0은 모든 상자를 절반 크기로 바꾸는 방식이고, TurboQuant는 비슷한 물건들을 묶어 "몇 번 상자와 거의 같음"이라고 적어두는 방식에 가까워요.

다만 실전 결론은 모델 구조에 따라 달라져요. Gemma4처럼 full/global attention 레이어의 KV 캐시가 여전히 의미 있게 남는 모델은 TurboQuant 실험의 이득이 잘 드러날 수 있어요. 반면 Qwen3.6처럼 Gated DeltaNet(Gated DeltaNet, 긴 문맥을 고정 상태로 압축해 다루는 선형 어텐션 계열) 레이어가 대부분인 모델은 TurboQuant가 줄일 표준 KV 캐시 비중이 작아요. 이 경우에는 q8_0/q4_0 같은 표준 KV 캐시 양자화가 품질·속도 균형에서 더 나은 사례가 보고됩니다. "항상 그렇다"가 아니라, 줄일 대상이 얼마나 남아 있느냐의 문제예요.

출처 메모: TurboQuant 원 논문과 Google Research 글은 KV 캐시 압축의 가능성을 보여주고, vLLM 실측 글은 공격적 TurboQuant가 작업에 따라 정확도와 처리량에서 손해를 낼 수 있음을 보여줘요. llama.cpp 쪽은 2026-05 기준 issue와 PR, fork 실험이 중심이라, 정식 일반 기능으로 단정하지 않는 편이 안전합니다.

한계: 이 모든 최적화는 압축률에 상한이 있고, 결국 T에 선형 비례하는 부분은 남아요. 컨텍스트 길이와 배치 크기가 함께 커지면 물리적 메모리 용량과 대역폭의 벽에 부딪혀요.

컨텍스트가 길어질수록 HBM 대역폭이 병목이 돼요

컨텍스트가 더 길어질수록, 더 많은 에이전트가 병렬로 돌수록, 단기 기억을 퍼 나르는 하드웨어의 속도가 지능의 실제 천장이 됩니다.

MoE는 FFN 파라미터를 KV 비용 밖으로 빼주고, MLA·Hybrid Attention은 K/V 저장량 자체를 줄여요. 하지만 셋 다 T 의존성을 완전히 없애지는 못해요. 그래서 "컨텍스트를 길게 쓰려면 HBM 대역폭에 투자해야 한다"는 결론은 흔들리지 않습니다.

KV 캐시를 실제로 얼마나 담을 수 있는지, 어떤 하드웨어가 어떤 대역폭을 제공하는지는 메모리·대역폭 지도에서 구체적인 숫자로 이어 다룹니다.