KV 캐시 양자화는 왜 ‘가중치 압축’과 다른 문제일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 긴 컨텍스트 에이전트가 느려질 때, 모델 가중치를 더 작게 만드는 것과 KV 캐시를 압축하는 것은 어떤 병목을 각각 해결할까?
• 핵심 출처:
  • Productionizing TurboQuant on AMD GPUs for KV-Cache-Bound LLM Inference — ROCm Blogs - 2026-06-11, 2026-06-13 확인
  • Accelerating vLLM-Omni Inference with AutoRound Quantization - 2026-06-02, 2026-06-13 확인
  • Gemma 4 QAT models: Optimizing model compression for mobile and laptop efficiency - 2026-06-05, 2026-06-13 확인
  • TurboQuant: Redefining AI efficiency with extreme compression - 2026-03-24, 2026-06-13 확인
  • TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate - ICLR 2026, 2026-06-13 확인

1. 왜 지금 봐야 하나

최근 AI 서빙 글을 읽다 보면 “4비트”, “QAT”, “PTQ”, “KV cache quantization”이 한꺼번에 나온다. 모두 메모리를 줄인다는 점에서는 비슷하지만, 개발자가 운영 판단을 할 때는 같은 단어로 묶으면 안 된다.

가중치 양자화는 모델 파일과 레이어 계산에 들어가는 정적인 파라미터를 줄이는 일이다. 반면 KV 캐시 양자화는 요청이 들어오고 토큰이 처리될 때 계속 커지는 동적인 실행 상태를 줄이는 일이다. 긴 문서 요약, 멀티턴 상담, 코딩 에이전트처럼 컨텍스트가 길어지는 서비스에서는 모델 가중치보다 KV 캐시가 먼저 GPU 메모리를 밀어낼 수 있다.

이번 주 자료들이 이 차이를 잘 보여준다. AMD ROCm 블로그는 TurboQuant를 vLLM 위에서 productionized하면서 “KV-cache capacity가 병목일 때 가장 효과가 크다”고 못박았다. Google은 Gemma 4 QAT 체크포인트로 온디바이스 메모리 절감을 발표했고, vLLM-Omni는 AutoRound 기반 W4A16 체크포인트를 “quantize-once, serve-directly” 흐름으로 통합했다. 즉, 지금의 실무 질문은 “양자화할까?”가 아니라 **무엇을, 언제, 어떤 손실을 감수하고 양자화할까?**다.

2. 핵심 개념

LLM이 새 토큰을 생성할 때는 이전 토큰 전체를 매번 처음부터 다시 계산하지 않는다. attention layer는 이전 토큰들의 key/value 벡터를 저장해두고 다음 토큰에서 재사용한다. 이것이 KV 캐시다.

간단히 나누면 메모리에는 세 덩어리가 있다.

1. 가중치 메모리: 모델 자체의 파라미터. 같은 모델을 로드하면 요청과 무관하게 거의 고정된다.
2. 활성값/임시 버퍼: 한 번의 forward 계산 중 필요한 중간값. 배치, 구현, 커널에 따라 달라진다.
3. KV 캐시: 프롬프트와 생성 토큰 길이에 비례해 커지는 실행 상태. 동시 요청 수와 컨텍스트 길이에 직접 영향을 받는다.

가중치 양자화는 1번을 줄인다. 예를 들어 vLLM-Omni의 AutoRound 통합은 W4A16, 즉 4비트 가중치와 16비트 활성값으로 정적 체크포인트를 줄이고, 런타임은 체크포인트 metadata를 읽어 별도 --quantization 플래그 없이 로드하는 방향을 보여준다.

KV 캐시 양자화는 3번을 줄인다. TurboQuant 계열은 attention에 필요한 key/value 벡터를 낮은 비트로 저장해 긴 컨텍스트의 resident cache를 늘리는 데 초점을 둔다. AMD 글의 핵심은 여기다. 100-conversation agentic workload에서 TQ4/4 설정이 테스트 조건상 KV cache hit rate를 5.3%에서 67.7%로 높였고, P50 TTFT를 13.9초에서 0.89초로 줄였다고 보고했다. 이 숫자는 “항상 이렇게 빨라진다”가 아니라, 캐시가 못 버텨서 eviction/recompute가 많던 workload에서는 KV 캐시 압축이 지연을 크게 바꿀 수 있다는 신호로 읽어야 한다.

3. 최신 이슈와 연결

세 출처가 서로 다른 층위를 말한다.

• Google Gemma 4 QAT는 모델이 압축될 상황을 훈련 중에 시뮬레이션해 품질 손실을 줄이는 접근이다. 모바일 특화 포맷에서는 Gemma 4 E2B의 메모리 footprint를 1GB 수준까지 낮추고, embedding과 KV cache 최적화도 언급한다.
• vLLM-Omni AutoRound는 후처리 양자화(PTQ)에 가깝다. 오프라인에서 체크포인트를 만들고, serving path에서는 metadata를 감지해 그대로 실행한다. 운영상 장점은 실험과 serving hot path를 분리하는 것이다.
• Google Research/ICLR의 TurboQuant와 AMD의 ROCm 구현은 KV 캐시를 별도 병목으로 본다. OpenReview 초록은 TurboQuant가 online application에 적합하고 KV cache quantization에서 3.5 bits per channel에서 quality neutrality, 2.5 bits에서 marginal degradation을 보였다고 설명한다. AMD는 이를 실제 GPU kernel, layer sensitivity, QJL 사용 여부, TQ4/4 default 같은 운영 선택으로 바꿔 해석했다.

이 연결에서 중요한 점은 “논문 결과 → 운영 default”가 직선이 아니라는 것이다. AMD는 원 논문의 아이디어를 그대로 켜는 대신, keys와 values의 민감도를 다르게 보고, boundary layer를 남기고, 특정 workload에서 TQ4/4를 추천했다. 즉 양자화는 알고리즘 이름보다 어떤 레이어, 어떤 텐서, 어떤 workload에서 검증했는지가 더 중요하다.

4. 개발자 관점 해석

작은 팀이 LLM 기능을 운영할 때 흔한 오해는 “VRAM이 부족하니 4비트 모델을 쓰면 된다”는 것이다. 그런데 문제가 KV 캐시라면 가중치만 줄여도 병목이 남을 수 있다.

예를 들어 7B 모델을 4비트로 줄여 로드에는 성공했지만, 사용자가 100K 토큰 문서를 넣고 여러 번 follow-up 질문을 하면 KV 캐시는 요청마다 계속 커진다. 동시성이 올라가면 캐시를 유지하지 못해 prefix를 다시 계산하거나, batch scheduler가 요청을 밀어내거나, TTFT가 급격히 늘 수 있다. 이때는 “더 작은 모델”보다 “prefix caching, KV cache quantization, context truncation, retrieval 설계”가 더 직접적인 해결책일 수 있다.

반대로 짧은 프롬프트를 대량 처리하는 분류 API라면 KV 캐시 압축이 별 도움이 안 될 수 있다. AMD 글도 TurboQuant가 보편적인 default는 아니며, compute-bound 설정에서는 quantize/dequantize overhead 때문에 이득이 줄 수 있다고 경고한다. 이 경우에는 batch size, kernel, 가중치 양자화, 모델 크기 선택이 더 중요하다.

정리하면 다음처럼 판단하자.

• 모델이 로드되지 않는다 → 먼저 가중치 양자화/PTQ/QAT, 작은 모델, tensor parallel을 본다.
• 긴 입력에서 TTFT가 튄다 → prefill 비용, prefix cache hit, KV cache residency를 본다.
• 멀티턴 에이전트가 갈수록 느려진다 → KV 캐시 증가, context compaction, tool 결과 보존 전략을 본다.
• 짧은 요청 처리량이 낮다 → batching, scheduler, decode kernel, 모델 선택을 본다.

5. 내 프로젝트에 적용할 체크포인트

1. 요청 길이 분포를 먼저 본다
   평균 토큰 수보다 p95/p99 prompt tokens, generated tokens, conversation turns를 분리해서 보자.

2. TTFT와 TPOT을 나눠 기록한다
   TTFT가 길면 prefill·queue·cache 문제가 의심되고, TPOT이 느리면 decode kernel·메모리 bandwidth·batching 문제가 의심된다.

3. 가중치 메모리와 KV 캐시 메모리를 따로 추정한다
   “모델 파일 몇 GB”만 보고 GPU를 고르면 긴 컨텍스트 동시성에서 실패한다.

4. 양자화 품질 평가는 일반 벤치마크만 보지 않는다
   내 서비스의 긴 문서, 도구 호출 결과, 코드 파일, 한국어 입력처럼 실제 분포로 회귀 테스트를 만든다.

5. 압축 default를 맹신하지 않는다
   AMD가 TQ4/4를 추천한 것은 그들의 모델·GPU·workload·kernel 최적화 조건에서다. 내 환경에서는 FP8 KV, 4-bit KV, no KV quantization을 같이 비교해야 한다.

6. 운영 hot path와 실험 path를 분리한다
   vLLM-Omni AutoRound 사례처럼 오프라인 체크포인트 생성과 런타임 로드를 분리하면 장애 범위가 줄어든다.

7. 실패 모드를 정해둔다
   품질이 애매하게 나빠지는 경우가 가장 위험하다. 긴 숫자 표, 코드 diff, 법률/정책 문서처럼 작은 오류가 큰 문제인 입력은 별도 eval set으로 둔다.

6. 오늘 10분 액션

지금 운영하거나 만들고 있는 LLM 기능 하나를 골라 아래 표를 채워보자.

질문	내 서비스의 값
p95 prompt tokens는 얼마인가?
p95 generated tokens는 얼마인가?
한 사용자의 평균 turn 수는?
TTFT와 TPOT을 따로 보고 있는가?
긴 컨텍스트 요청에서 cache hit/miss를 볼 수 있는가?
모델 가중치가 병목인가, KV 캐시가 병목인가?
양자화 후 비교할 내 서비스 eval 20개는 있는가?

10분 안에 모든 답을 채우지 못해도 괜찮다. 빈칸이 바로 관측성 backlog다. 특히 “가중치가 병목인지 KV 캐시가 병목인지 모른다”면, 양자화 방식을 고르기 전에 계측부터 해야 한다.

7. 더 볼 자료

• AMD ROCm Blog의 TurboQuant productionization 글: 실제 serving workload에서 KV cache hit rate, TTFT, throughput을 어떻게 해석하는지 보기 좋다.
• Google Research TurboQuant 글과 OpenReview 논문: 왜 KV 캐시 quantization이 단순 round-to-nearest가 아니라 inner product distortion 문제인지 이해하는 데 좋다.
• Google Gemma 4 QAT 글: PTQ와 QAT의 차이, edge/mobile에서 static activation과 channel-wise quantization이 왜 중요한지 확인할 수 있다.
• vLLM-Omni AutoRound 글: 양자화 체크포인트를 serving runtime이 어떻게 자동 감지하고 hot path를 단순화하는지 볼 수 있다.

중복 회피 메모

로컬 content/generated와 Supabase의 최근 ai_dev 글을 확인했다. 최근 글은 장기 컨텍스트 메모리 관리, 에이전트 권한 계약, prefill/decode 기반 LLM 서빙 지연, RAG 검색 품질, Tool Search 기반 도구 표면 관리를 다뤘다. 이번 글은 prefill/decode 분리나 일반 지연 분석을 반복하지 않고, 최신 TurboQuant·Gemma QAT·AutoRound 자료를 바탕으로 가중치 양자화와 KV 캐시 양자화가 서로 다른 메모리 병목을 해결한다는 운영 판단 기준에 집중했다.