사례

KV 캐시 양자화는 모델이 이전 토큰 계산값을 다시 쓰려고 들고 있는 KV 캐시를 더 작은 숫자 형식으로 저장해 메모리를 아끼는 방법이야. 메모리를 줄이는 기능이지, 품질을 보장하는 기능은 아니라는 점을 함께 두고 읽으면 좋아. 이 선을 먼저 잡아야 해.

LocalLLaMA의 해당 Reddit 스레드에는 Qwen3.6-27B를 FP8 safetensors로 vLLM에서, GPU는 RTX 3090 두 대로 돌린 운영 사례가 올라왔어. 작성자는 KV 캐시도 FP8로 낮췄을 때 긴 코딩 흐름에서 미묘한 실수, 도구 호출 문제, 추론 품질 저하를 봤고, KV를 16비트로 고정했을 때 성능이 더 높았다고 설명했어. 다만 이건 아직 단일 Reddit 사례야.

댓글에서는 Q8 KV 캐시와 FP8 KV 캐시가 다른 선택지라는 점도 따로 짚혔어. 그래서 이 글에서 FP8은 두 층위를 나눠 읽어야 해. 모델 파일은 FP8 safetensors였고, 문제로 제기된 KV 캐시 설정은 FP8 KV야. Q8 KV는 작성자의 같은 조건 실험값이 아니라 댓글에서 비교 대상으로 나온 논점에 가까워.

왜 보수적으로 봐야 하나

vLLM 문서와 Hugging Face 정리는 KV 캐시 양자화가 메모리와 품질을 함께 봐야 하는 선택이라는 점만 받쳐줘. 이 Qwen3.6-27B 사례를 독립 재현한 표는 아직 없어.

어떤 의미인가

KV 캐시 양자화는 나쁜 기능이 아니라 메모리를 줄이는 선택지야. 다만 긴 작업에서는 공개 벤치 점수와 내 작업 로그를 따로 봐야 해.

어디를 먼저 비교할까

같은 프롬프트를 다음처럼 나눠 돌리고 로그를 먼저 보는 쪽이 좋아.

  • FP16 기본: 메모리를 더 쓰는 대신 품질 비교 기준으로 둬.

  • FP8 모델 + FP16 KV: 모델 파일만 줄였을 때 긴 작업 로그가 어떤지 보여줘.

  • FP8 모델 + FP8 KV: 문제로 제기된 KV 캐시 설정까지 같이 줄인 조건이야.

  • Q8/INT8 계열 KV: 댓글에서 따로 나온 비교 대상이라, FP8 KV와 같은 말로 뭉치지 말고 별도 후보로 봐야 해.

  • 코딩 작업: 함수 이름, 파일 경로, 이전 수정 지시를 잊는지 봐.

  • 멀티턴 RAG: 같은 검색을 반복하거나 앞 답과 어긋나는지 봐.

  • 공통 기준: 공개 평가 점수보다 네 실제 작업 흐름을 기준으로 보는 게 더 맞아.