여러분, 내용이 좀 길고 읽을거리가 많습니다. 지루하시다면 TLDR(요약)만 읽고 본인에게 가치가 있을지 판단해 보세요. TLDR; Deepseek에게 KVarN 논문을 PrismML의 Bonsai 런타임(runtime)으로 포팅해달라고 요청했습니다. 결과적으로 120K 컨텍스트에서 속도는 68% 더 빨라졌고(73 vs 43 tok/s), VRAM 사용량은 3.3GB 줄었습니다. PrismML은 방금 3.8GB 크기의 Bonsai-27B 1-bit 모델과 약간 더 큰 5.6GB 모델을 출시했으며, 벤치마크 결과도 탄탄해 보입니다. 하지만 이런 소형 모델들이 등장할 때 아무도 말하지 않는 문제가 있습니다. 바로 KV 캐시(KV cache)가 모델의 성능을 저하시키고, 무한 루프를 유발하거나, 부적절한 도구 호출(toolcalling)로 골칫거리를 만들 수 있다는 점입니다. Q1_0 양자화(quantization)를 적용한 27B 모델은 매우 작습니다. 하지만 일반적인 q8_0 KV 캐시를 사용하는 120K 컨텍스트라면? 그것만으로 7.8GB를 차지합니다. 모델보다 캐시에 더 많은 VRAM을 소비하게 되는 셈이죠. 저는 KIVI + QuIP#의 Hadamard 전처리에 기반한 구조화된 KV 캐시 양자화(structured KV cache quantization) 방식인 KVarN을 가지고 놀고 있었습니다. 핵심 아이디어는 양자화하기 전에 Walsh-Hadamard 변환(transform)과 Sinkhorn 분산 균형(variance balancing)을 적용하여, 4-bit 양자화가 일반적인 flat q4_0처럼 품질을 떨어뜨리지 않게 하는 것입니다. 저는 이를 Bonsai 런타임에 포팅했습니다(원래는 제가 즐겨 쓰는 beellama.cpp 포크의 다른 포크에 있었습니다). 23개의 파일, 약 1,300줄의 코드입니다. 솔직히 마법 같았습니다. 좋은 하네스(harness, Cherry studio)를 갖춘 Deepseek에게 요청했더니 스스로 다 해냈기 때문입니다. 하지만 GPT나 Claude도 여러분의 llama.cpp를 가지고 이 작업을 수행할 수 있을 것이라 확신하며, 수치가 이를 증명합니다. Bonsai-27B Q1_0, 120K 컨텍스트, RX 9070 XT 환경: - q8_0 캐시: 43.4 tok/s, 총 ~13.1 GB - kvarn4 캐시: 73.0 tok/s, 총 ~9.8 GB. 이는 생성 속도가 68% 향상된 것이며, 연산 버퍼(compute buffer)를 위한 여유 공간을 두면서도 10GB 미만으로 여유롭게 구동할 수 있음을 의미합니다. 제 생각에 이 방식은 정보 유지(retention)가 실제로 중요한 사용 사례에서 TurboQuant보다 더 유망합니다. TurboQuant는 속도를 제공하지만 품질을 희생하며, 4-bit를 넘어서면 마치 취한 것처럼 작동합니다. KVarN은 마법을 부립니다. 제가 왜 이렇게 되는지 정말 이해하고 있다고 허풍을 떠는 것이 아닙니다. 저는 그저 arXiv를 읽고 해결책을 찾아달라고 맹목적으로 요청했을 뿐입니다. lol.

단점: 이는 100% 확률로 DFlash를 깨뜨릴 것입니다. 하지만 저에게는 그것이 그리 나쁜 부분은 아니었습니다. 작동하게 만들려고 시도하는 과정에서 아주 적은 컨텍스트에서도 메모리 부족 (Out of Memory) 오류가 발생했기 때문에, 어차피 저는 놓칠 것이 없었거든요. 하지만 만약 여러분이 Bonsai나 다른 밀집 모델 (Dense Model)을 긴 컨텍스트에서 실행하고 싶고, 그것이 실제로 메모리에 맞게 들어가기를 원한다면: --cache-type-k kvarn4 --cache-type-v kvarn4를 사용하는 kvarn4 방식은 시도해 볼 가치가 있습니다. 10GB 미만에서 120K 컨텍스트를 지원하며, 정확도 급락 (Accuracy Cliff)도 없습니다. 아직 어떤 GitHub 저장소에도 업로드하지 않았지만, 솔직히 말해서 좋은 AI를 원하는 사람이라면 누구든 10분 안에 얻을 수 있습니다. /u/Suitable_Currency440 제출 [link] [comments]