Hard numbers on Qwen3.8-27B's KV cache: q8_0 is free, K is ~2x as touchy as V, and a 2k recent-token window makes 6/5-bit basically lossless
Qwen3.8-27B KV 캐시 실측: q8_0에 거의 손실 없는 저비트 설정, K는 V보다 민감하고 최근 2k 토큰 보존이 효과적
RTX 3090 한 장에서 Qwen3.8-27B를 실행하는 CUDA 엔진이 KV 캐시 저비트화와 최근 토큰 보존 효과를 측정했습니다. K 6비트, V 5비트에 최근 2,048개 위치만 8비트로 유지하면 q8_0과 비슷한 점수를 보이며, 262k 컨텍스트도 24GB GPU에 적재합니다.
- 주제
에디터 노트
저비트 캐시의 성능 주장은 24GB RTX 3090과 Qwen3.8-27B의 측정 결과로 한정해 읽어야 합니다. 특히 이 모델은 64개 레이어 중 어텐션 레이어가 16개뿐인 하이브리드 구조라, 같은 2k 창이 다른 모델에서도 동일하게 작동한다고 글은 주장하지 않습니다. 262k 실행 결과도 제시하지만 그 길이에서 q8_0 기준 KL 비교는 하지 못했습니다. 댓글에서 제기된 KIVI식 per-channel 양자화는 후속 시험으로 다뤄졌고, 창이 없는 설정에서는 K 오차를 줄였지만 2k 창을 켜면 일반 블록 방식보다 나아지지 않았다고 작성자가 보고합니다. 따라서 이 글의 가장 설득력 있는 결과는 범용 양자화 규칙보다 최근 토큰 창과 K/V 비트 수를 함께 조정한 이 모델의 실측입니다. 반면 llama.cpp와의 속도 비교 및 정확도 수치는 엔진 구현과 특정 테스트셋에 종속되므로 모든 추론 환경의 우열로 확대할 근거는 없습니다.
AI 요약
Qwen3.8-27B를 RTX 3090 한 장에서 실행하는 CUDA 엔진과 서버가 공개됐습니다. 글은 추론 속도와 대화 캐시 재사용, 에이전트 API 지원을 설명하며 특히 KV 캐시를 낮은 비트로 저장할 때 품질과 메모리가 어떻게 달라지는지 수치로 제시합니다. 측정은 unsloth의 UD-Q4_K_XL 모델과 llama.cpp의 토큰별 출력을 기준으로 했습니다.
KV 캐시 저비트화
기본 q8_0 설정은 120k 컨텍스트에서 GPU 메모리 21.1GB를 사용합니다. 실험 설정 D는 K를 6비트, V를 5비트로 저장하고 최근 2,048개 위치는 8비트 링 버퍼에 둡니다. 이 설정은 같은 조건에서 20.0GB를 사용해 약 1.1GB를 아낍니다. 저자 측정으로는 32k에서 KL 발산이 q8_0의 0.00219에서 0.00236으로 늘었고, 282개 벤치마크 문제 정답 수는 둘 다 230개였습니다. 101.6k 프롬프트 처리 시간은 q8_0이 74.5초, 설정 D가 77.6초였습니다.
최근 토큰 보존은 컨텍스트가 창 크기보다 짧을 때 전체 KV를 8비트로 남겨 출력이 q8_0과 같도록 합니다. 창을 넘긴 뒤에도 낮은 비트 설정의 품질 저하가 작았다는 것이 저자의 측정 결과입니다. 64k의 KL 값은 q8_0 0.00163, 설정 D와 8비트 MTP를 쓴 D'는 0.00161이었습니다. 100k와 160k의 산문 테스트에서도 설정 D의 값은 각각 0.00317, 0.00468로 q8_0의 0.00311, 0.00467과 가까웠습니다. 다만 262,144 토큰 전체 길이에서는 llama.cpp 기준 KL 비교를 할 수 없었습니다. 기준 캐시를 같은 24GB 카드에 올릴 수 없기 때문입니다. 이 길이에서 엔진은 260,896토큰 프롬프트를 처리하고 초당 66토큰으로 디코딩했으며, needle-in-a-haystack 테스트는 4개 중 4개를 맞혔습니다.
엔진 속도와 캐시 재사용
RTX 3090에서 짧은 프롬프트의 greedy 디코딩은 llama.cpp의 초당 82.7토큰에 비해 155.1토큰이었습니다. 101.6k 컨텍스트에서는 각각 53.4, 108.7토큰이었고, 101.6k 프롬프트 처리에는 101.0초와 74.5초가 걸렸습니다. 엔진은 MTP 헤드로 한 단계에서 최대 7개 토큰을 초안으로 만들며, 글에 따르면 초안 수가 0, 4, 7일 때 greedy 토큰 ID가 같습니다. 정확 재사용 모드에서는 대화 수정이나 세션 복원 뒤에도 새 요청으로 처리했을 때와 같은 출력을 내도록 캐시 상태를 검사합니다. Windows와 Linux 빌드 사이에서도 토큰 ID가 일치했다고 설명합니다.
서버는 OpenAI Chat Completions와 Responses API, Anthropic Messages API 및 llama-server 호환 엔드포인트를 제공합니다. Claude Code, Codex CLI, Qwen Code 등 여러 클라이언트로 테스트했으며 이미지와 비디오 입력도 지원합니다. 빌드는 CUDA 13.2와 Ampere 이상 NVIDIA GPU를 요구합니다. RTX 3090에서 조정했고 RTX 40 시리즈는 실행 가능하지만 테스트하지 않았다고 명시합니다.
Reddit 반응
- @Nice_Profession_9078 — 작성자는 댓글에서 q8_0과 fp16 캐시의 차이가 측정상 거의 없고, K를 낮은 비트로 저장할 때 V보다 오차에 민감하다고 설명합니다. 2k 최근 토큰 창을 두면 6비트 K와 5비트 V의 손실이 거의 사라진다는 것이 실험의 요지입니다.
- @TheSvelteOrientation — 늘 보던 근거 없는 q4 권고 대신 실제 수치가 나왔다며 반겼습니다. 최근 2k 창이 손실을 사실상 지운 점과 24GB 카드에서 262k 컨텍스트가 들어가는 점을 특히 인상적으로 봤습니다.
- @Poprouter — 이 기능은 단순한 포맷 옵션이 아니라 레이어별 두 KV 경로와 위치별 분기가 필요하다고 지적했습니다. 창 경계가 움직일 때 블록을 다시 양자화해야 하므로 메인라인 기본 기능보다는 별도 기능에 가깝다고 설명했습니다.
- @daniellenton — K의 민감도가 큰 현상이 KIVI 연구 결과와 비슷하다며, 토큰마다 32개 값으로 묶는 대신 토큰 축으로 K를 양자화하는 방식도 시험했는지 물었습니다.
- @Nice_Profession_9078 — per-channel K는 실험하지 않았지만 최근 창이 없는 저비트 설정에서는 효과를 볼 만하다고 답했습니다. 후속 측정에서는 창을 켠 상태에서 per-channel 방식이 일반적인 블록 방식보다 낫지 않았고, 창 없이 5비트 K를 쓸 때는 오차를 줄였다고 덧붙였습니다.
- @starkruzr — 180k 컨텍스트보다 긴 테스트를 하지 않았다며 최대 컨텍스트에서도 품질이 유지되는지 질문했습니다.
- @Nice_Profession_9078 — 262,144 토큰을 24GB 카드에 올렸고 260,896토큰 프롬프트 처리와 최대 길이의 테스트를 했다고 답했습니다. 상대가 본 표의 컨텍스트 수치는 q8_0 메모리 사용량을 기준으로 한 비교값이라고 설명했습니다.
- @Fun_Jaguar8231 — Qwen의 KV 캐시는 잘 양자화된다는 점과 K 캐시를 보존해야 한다는 점은 이미 알려져 있다고 반박하며 BeeLlama의 KVarN도 언급했습니다.
- @Nice_Profession_9078 — 최근 토큰 창을 쓰면 K를 8비트로 유지해야 한다는 통념과 달리 5비트 K도 q8_0에 가까운 결과를 냈다고 답했습니다. KVarN의 '사실상 공짜'라는 설명을 비교할 수 있도록 KL 수치를 공유해 달라고 요청했습니다.
원문: Reddit / 번역·요약: Trawling