APPENDIX · THEORY

양자화와 KV 압축

Unsloth Dynamic · TurboQuant

양자화와 KV 압축: Unsloth Dynamic과 TurboQuant

연관 문서: 메모리·대역폭 지도, KV 캐시, 최근 여섯 모델

Q4_K_M, Unsloth Dynamic, q8_0 KV, TurboQuant는 모두 "메모리를 줄인다"는 말로 묶이지만, 실제로는 줄이는 대상이 달라요. 가장 흔한 혼동은 모델 파일을 줄이는 기술과 긴 대화 중 생기는 작업 메모리를 줄이는 기술을 같은 층으로 보는 것입니다.

비유로 보면, 모델 가중치(weight, 모델 파일 안 숫자)는 여행 가방에 넣어 출발 전에 챙기는 짐이고, KV cache(Key-Value cache, 긴 대화 중 이미 계산한 attention 중간 결과를 저장하는 작업 메모리)는 여행 중 계속 늘어나는 영수증과 메모예요. 출발 전 짐을 압축해도 여행 중 생기는 종이가 저절로 줄지는 않습니다.

flowchart LR W["모델 가중치(Weights)<br/>출발 전 짐"] --> WQ["Q4_K_M / Unsloth Dynamic<br/>파일 크기 압축"] K["KV cache<br/>대화 중 생기는 작업 메모리"] --> KQ["q8_0 / q4_0 / TurboQuant<br/>런타임 cache 압축"]

한눈에 보는 위치

기술줄이는 대상적용 시점대표 표기핵심 질문
Q4_K_M모델 가중치(weight, 모델 파일 안 숫자)모델 다운로드/로드 전Q4_K_M.gguf모델 파일을 얼마나 작게 만들까
Unsloth Dynamic모델 가중치(weight, 모델 파일 안 숫자)모델 배포/변환 단계UD-Q4_K_XL, UD-IQ4_NL_XL중요한 텐서를 덜 망가뜨리며 줄일 수 있을까
표준 KV 양자화KV cache(Key-Value cache, 추론 중 생기는 작업 메모리)추론 런타임q8_0, q4_0 KV긴 대화의 작업 메모리를 단순하게 줄일까
TurboQuantKV cache(Key-Value cache, 추론 중 생기는 작업 메모리)추론 런타임turbo4, tbq4_0, tbq3_0 등 구현별 상이KV cache를 더 강하게 줄이되 품질을 버틸 수 있을까

여기서 중요한 선은 가운데예요. Q4_K_M과 Unsloth Dynamic은 가중치 양자화(weight quantization, 모델 파일 숫자 정밀도를 낮추는 방법) 입니다. q8_0/q4_0 KV와 TurboQuant는 KV cache 양자화(KV cache quantization, 추론 중 생기는 작업 메모리 숫자 정밀도를 낮추는 방법) 입니다.

Q4_K_M: 표준 4비트 포장

Q4_K_M은 GGUF(GGUF, llama.cpp 계열에서 쓰는 로컬 모델 파일 형식) 생태계에서 널리 쓰는 표준 4비트 양자화예요. 모델 가중치(weight, 모델 파일 안 숫자)를 블록 단위로 묶고, 각 블록의 스케일(scale, 숫자 범위를 맞추는 기준값)을 함께 저장해 원래 BF16(BFloat16, 16비트 부동소수점 형식)보다 훨씬 작게 만듭니다.

일상적인 선택지로는 Q4_K_M이 "무난한 기본값"에 가까워요. 품질 손실은 있지만 파일 크기를 크게 줄이고, llama.cpp, Ollama, LM Studio 같은 로컬 런타임에서 폭넓게 지원돼요.

다만 Q4_K_M은 모델 내부의 모든 텐서(tensor, 모델 내부 숫자 덩어리)가 똑같이 민감하지 않다는 사실을 세밀하게 반영하지는 못해요. 어떤 레이어(layer, 모델을 구성하는 반복 블록)는 조금만 압축해도 성능이 흔들리고, 어떤 레이어는 더 세게 줄여도 버팁니다.

Unsloth Dynamic: 모델별 맞춤 포장

Unsloth Dynamic은 Unsloth가 만든 모델별·레이어별 혼합 양자화 방식이에요. 파일명에는 보통 UD-Q4_K_XL, UD-IQ4_NL_XL, UD-Q8_K_XL처럼 붙습니다.

핵심은 "모든 숫자를 같은 방식으로 누르지 않는다"예요. 깨지기 쉬운 유리컵은 완충재를 넣고, 옷은 더 세게 압축하는 이삿짐 포장에 가까워요. 모델 안에서도 중요한 텐서(tensor, 모델 내부 숫자 덩어리)는 더 보수적으로 저장하고, 덜 민감한 텐서는 더 공격적으로 줄입니다.

Unsloth Dynamic 2.0 문서는 세 가지를 강조해요.

  • 레이어 선택을 더 세밀하게 바꿔 모델마다 다른 조합을 쓴다.
  • MoE(Mixture of Experts, 여러 전문가 블록 중 일부만 켜는 구조)뿐 아니라 non-MoE 모델에도 적용한다.
  • KL Divergence(KL Divergence, 원본 모델 출력 분포와 압축 모델 출력 분포가 얼마나 다른지 보는 지표)와 harder benchmark를 함께 본다.

그래서 UD-Q4는 단순히 "Q4_K_M의 다른 이름"이 아니에요. 같은 4비트급 용량이라도, 중요한 부분을 더 살리고 덜 중요한 부분을 더 줄이는 혼합 포장 전략입니다.

주의할 점도 있어요. Unsloth Dynamic은 여전히 모델 가중치 압축이에요. 긴 컨텍스트에서 새로 생기는 KV cache를 직접 줄이지는 않습니다. 즉 UD-Q4_K_XL 모델을 써도, KV cache를 BF16으로 저장하면 긴 대화에서는 작업 메모리가 크게 늘 수 있어요.

표준 KV 양자화: 작업 메모리를 단순하게 줄이기

KV cache 양자화는 모델 파일이 아니라 추론 중 생기는 Key·Value 벡터를 줄이는 기술이에요. 같은 Q4 모델이라도 KV cache는 따로 BF16, q8_0, q4_0 등으로 저장할 수 있습니다.

KV cache 타입대략적 의미장점주의점
BF16원래 2바이트 정밀도품질 안정적메모리 큼
q8_0 KV8비트 정수 저장품질 손실 작고 메모리 절반 수준극단적 절감은 아님
q4_0 KV4비트 정수 저장메모리 절감 큼모델·작업에 따라 품질 하락 가능

이 방식은 이해하기 쉽고 구현도 비교적 단순해요. Qwen3.6처럼 full attention(full attention, 전체 문맥을 직접 보는 attention) 레이어가 적은 모델에서는 TurboQuant보다 이런 표준 KV 양자화가 더 나은 균형을 보일 수 있습니다. 줄일 KV cache 자체가 많지 않으면, 복잡한 압축을 더 얹는 이득보다 복원 비용과 품질 손실이 더 커질 수 있기 때문이에요.

TurboQuant: KV cache를 코드북으로 압축하기

TurboQuant는 Google Research가 제안한 online vector quantization(online vector quantization, 데이터가 들어오는 즉시 비슷한 벡터를 대표 코드로 바꿔 저장하는 압축 방법) 계열이에요. LLM 추론에서는 특히 KV cache를 줄이는 데 쓰입니다.

표준 q8_0/q4_0 KV가 "모든 상자를 더 작은 상자로 바꾸는 방식"이라면, TurboQuant는 "비슷한 물건을 대표 상자 번호로 바꿔 적는 방식"에 가까워요. KV 벡터를 그대로 저장하지 않고, codebook(codebook, 대표 벡터 사전)의 항목과 보정값으로 표현합니다.

TurboQuant 논문과 Google Research 글의 핵심은 다음이에요.

  • streaming 환경(streaming, 토큰이 순서대로 들어오는 추론 환경)에서 KV cache를 온라인으로 압축한다.
  • 벡터 양자화(vector quantization, 숫자 벡터를 대표 코드로 바꾸는 압축)로 낮은 비트에서도 왜곡을 줄이려 한다.
  • QJL(Quantized Johnson-Lindenstrauss, 남은 오차를 낮은 비트 투영으로 보정해 내적 추정 편향을 줄이는 방법) 같은 보정 아이디어가 포함된다.

하지만 실제 런타임 구현은 논문과 1:1로 같지 않을 수 있어요. 예를 들어 vLLM의 TurboQuant 문서화/실험은 논문 아이디어를 반영하지만, 모든 구성 요소가 그대로 들어간 구현이라고 단정하면 안 됩니다. llama.cpp 쪽도 2026-05 기준으로는 issue와 PR, fork 실험이 중심이고, 모든 백엔드에서 일반 기능으로 안정화됐다고 보기 어렵습니다.

Gemma4와 Qwen3.6에서 결론이 갈리는 이유

Gemma4 계열은 Hybrid Attention(Hybrid Attention, 서로 다른 attention 레이어를 섞는 구조)을 쓰지만, full/global attention layer는 여전히 긴 컨텍스트에 비례하는 KV cache를 갖습니다. Gemma4 31B는 256K에서 실제 KV cache가 약 20.8 GiB까지 올라와요. 이 정도면 TurboQuant 같은 KV cache 압축 실험의 이득이 보일 여지가 있습니다.

Qwen3.6은 구조가 달라요. Qwen3.6 35B-A3B는 40층 중 30층이 Gated DeltaNet(Gated DeltaNet, 긴 문맥 정보를 고정 크기 상태로 압축해 다루는 선형 attention 계열)이고, full/Gated Attention은 10층뿐이에요. 이 full attention도 KV heads가 2개라 262K BF16 KV cache가 약 5 GiB 수준입니다.

그래서 "Qwen3.6은 TurboQuant보다 표준 KV 양자화가 낫다"는 말은 다음처럼 써야 안전해요.

Qwen3.6은 양자화 자체를 전제로 설계됐다기보다는, 긴 문맥의 KV cache 부담을 줄이는 hybrid attention 구조를 채택했어요. 그 결과 TurboQuant 같은 별도 KV cache 압축의 추가 이득이 Gemma4보다 작고, 실측상 표준 q8_0/q4_0 KV 양자화가 더 나은 균형을 보이는 경우가 있습니다.

"항상 더 좋다"는 보편 법칙은 아니에요. 컨텍스트 길이, 배치 크기(batch size, 한 번에 처리하는 요청 수), 하드웨어, 구현 백엔드, 작업 종류에 따라 달라집니다.

선택 가이드

상황먼저 볼 선택지이유
모델 파일이 GPU/RAM에 안 올라감Q4_K_M, Unsloth Dynamic줄여야 하는 대상이 가중치예요
긴 대화에서 OOM이 남q8_0/q4_0 KV줄여야 하는 대상이 KV cache예요
128K 이상 긴 컨텍스트를 많이 씀모델 구조 + KV 양자화architecture가 KV를 얼마나 만들지 먼저 결정해요
Gemma4처럼 global KV가 의미 있게 남음표준 KV 양자화 또는 TurboQuant 실험줄일 cache가 충분히 있어요
Qwen3.6처럼 full attention이 적음표준 KV 양자화 우선복잡한 압축의 추가 이득이 작을 수 있어요
llama.cpp 일반 릴리스 안정성이 중요함q8_0/q4_0 KV 우선TurboQuant는 구현 안정성 확인이 필요해요

실무적으로는 이렇게 생각하면 돼요.

  • 가중치가 안 들어가면 Q4_K_M이나 Unsloth Dynamic.
  • 컨텍스트가 길어져서 터지면 KV cache 양자화.
  • KV cache가 큰 모델에서 더 줄이고 싶으면 TurboQuant 실험.
  • 모델 자체가 이미 KV를 줄이는 구조면 TurboQuant보다 단순 KV 양자화가 더 나을 수 있음.

출처와 검증 기준