▲

KVSplit - 애플 실리콘에서 2-3배 더 긴 컨텍스트 실행

 (github.com/dipampaul17)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • KVSplit은 애플 실리콘에서 대형 LLM과 긴 컨텍스트 윈도우를 실행할 수 있게 하는 오픈소스 프로젝트임
  • 키와 값의 분리된 정밀도 할당을 통해 최대 72% 메모리 감소와 품질 저하 1% 미만을 달성함
  • M1/M2/M3 칩 및 Metal 프레임워크에 최적화되어 있음
  • 실행 속도 개선 및 메모리 절약을 실측 벤치마크와 시각화 도구로 증명함
  • 손쉬운 설치, 원커맨드 비교, 그리고 다양한 벤치마크 및 분석 도구를 제공함

소개: 왜 KVSplit가 중요한가

KVSplit은 KV 캐시 내부의 키와 값에 상이한 정밀도의 양자화를 적용함으로써 애플 실리콘(M1/M2/M3) 환경에서 대용량 LLM과 훨씬 긴 컨텍스트 윈도우 실행을 가능하게 하는 오픈소스 도구임. 기존 프로젝트들이 키와 값을 동일하게 양자화하는 한계를 극복하고, 메모리 사용량을 획기적으로 감축하면서도 품질 저하를 거의 느끼기 어려운 수준으로 억제함. 실제 벤치마크, 속도, 그리고 품질 지표가 모두 공개되어 있어 신뢰할 수 있으며, Metal 지원과 직관적인 비교 및 시각화 툴로 개발 효율성이 높음.

동종 프로젝트 대비 주요 장점은 다음과 같음:

  • 키-값 정밀도 분리로 한층 효율적인 메모리 관리 실현
  • 애플 실리콘 특화 및 풀 Metal 프레임워크 최적화 지원
  • 벤치마크, 퍼플렉서티, 메모리/속도/품질 측정 및 시각화 통합 제공
  • 원커맨드 설치, 모델 호환, llama.cpp 통합
  • 실시간 메모리 절감 시각화 및 다양한 비교 테스트 도구

주요 특징 및 핵심 내용

개요

  • KVSplit을 이용하면 기존보다 훨씬 더 큰 LLM과 긴 컨텍스트 길이를 애플 실리콘에서 실행 가능함
  • 키와 값 각각에 다르게 양자화 정밀도를 할당하여 메모리 절감과 속도 개선을 모두 달성함
  • 최대 72% 메모리 절약 및 속도 개선(5-15%↑) , 품질 저하 1% 미만 확인됨
  • Metal 완전 지원, 최적의 애플 실리콘 가속효과 실현

주요 벤치마크 결과

  • K8V4(키 8비트, 값 4비트) 구성에서
    • 59% 메모리 절감 및 0.86% 품질 저하(퍼플렉서티 기준)
    • FP16 대비 5.7% 속도 향상
  • K4V4(키/값 모두 4비트) 구성에서는
    • 최대 72% 메모리 절감
    • 품질 약 6% 손실 발생. 품질 민감도가 낮은 용도에 추천

메모리 절감 효과 비교

  • FP16 기준 176MB(8K 토큰)에서
    • K8V8(8비트 키/값) : 93.5MB(47%)
    • K8V4(8비트 키, 4비트 값) : 71.5MB(41%)
    • K4V4(4비트 키/값) : 49.5MB(28%)

주요 기능

  • KV 캐시 키·값 개별 양자화 기능
  • 애플 실리콘·Metal 완전 최적화
  • 벤치마크/품질(퍼플렉서티)/메모리 사용량 분석 스크립트
  • 시각화 툴 및 퍼블리케이션 품질의 그래프 생성
  • 원커맨드 셋업과 실시간 비교 기능

프로젝트 폴더 구성

  • llama.cpp: Metal 최적화 빌드 포함
  • models: 모델 파일 저장
  • scripts: 벤치마크/설치/비교/시각화 스크립트 포함
  • results, plots: 벤치마크 결과 및 시각화 파일 저장
  • README.md

과학적 인사이트 및 실험 결과

KV 캐시의 핵심 현상

  • 키 벡터는 양자화 민감도가 값 벡터보다 훨씬 높음 → 키에 더 높은 정밀도를 할당해야 품질 유지가 가능함
  • K8V4가 Sweet Spot: 키 8비트/값 4비트 배분이 품질-메모리 절충 최적임
    • 59% 메모리 절약, 퍼플렉서티 0.86%만 악화, 속도도 FP16보다 빠름
  • K4V8은 K8V4와 같은 비트수임에도 7배 이상 더 큰 품질 저하 발생 → 키 쪽 정밀도 중요성 입증

종합적인 시사점

  • 메모리 효율 확보와 모델 품질 보존을 모두 실현 → 소비자용 하드웨어에서 훨씬 더 긴 컨텍스트와 큰 모델 운용 가능

사용 예시 및 설정 추천

다양한 양자화 정밀도로 실행 예시

  • 기본(FP16): ./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "프롬프트" -t 8 --flash-attn
  • K8V4 추천: --kvq 8
  • K4V8(DEMO): --kvq-key 4 --kvq-val 8
  • K4V4(최대 절감): --kvq 4

긴 컨텍스트 예시

  • 32K 컨텍스트: FP16은 ~1.4GB 필요하지만 K8V4는 ~400MB로 실행 가능

커맨드라인 플래그 설명

  • -t 8: 스레드 수, M1/M2/M3에 8추천
  • --flash-attn: 애플 실리콘 최적화
  • --kvq N: 키/값 모두 N비트 설정
  • --kvq-key, --kvq-val: 개별 설정 지원
  • -c N: 컨텍스트 토큰 수(길수록 KVSplit 효과 극대)
  • -n N: 생성 토큰 수
  • -f FILE: 문서 입력 파일
  • -m MODEL: 모델 경로

고급 벤치마킹 및 시각화

  • benchmark_kvsplit.py로 구성별, 시퀀스 길이별, 메모리/속도/퍼플렉서티/스케일 특성 측정
  • visualize_results.py로 논문 수준 그래프 생성
  • 결과는 CSV/JSON 자동저장 및 요약 제공

애플 실리콘 최적화 및 메모리 시각화

  • Metal 프레임워크 완전 활용
  • 메모리 부담 큰 M1/M2/M3 기종에 결정적 효과
  • capture_memory.sh로 실시간 메모리 절감 시각화 가능
  • 맞춤 페이지 정렬로 실제 절감 용량은 이론치와 소폭 차이 발생

요약 기능 정리

  • 독립 키/값 비트 정밀도 및 맞춤형 양자화
  • 애플 실리콘 및 Metal 완전 최적화
  • 메모리/속도/품질 종합 벤치마크 제공
  • 논문 품질 시각화 및 실시간 비교, 메모리 캡처 지원
  • 초간단 설치/사용 인터페이스

인용 및 참고 연구

  • "More for Keys, Less for Values: Adaptive KV Cache Quantization"(2024)
  • "Unifying KV Cache Compression for Large Language Models with LeanKV"(2025)
  • 기반 구현: [llama.cpp], 테스트 모델: [TinyLlama]

설정 추천 및 향후 계획

  • K8V4(키 8비트/값 4비트) : 품질 손실 0.86%, 메모리 59% 절감, 속도 +5.7%로 최적의 균형
  • K4V4: 최대 메모리 절감(72%), 품질 약 6% 하락. 메모리 최우선시 용도에 적합
  • 긴 컨텍스트 실행에 특히 강점, 2-3배 더 긴 컨텍스트 운용 가능

향후 로드맵

  • 토큰 중요도 기반 적응형 정밀도
  • 레이어별 개별 양자화
  • 모델별 맞춤 최적화(Mistral, Phi-3 등)
  • 웹 데모 및 모바일(iOS/iPadOS) 지원 예정

라이선스 및 기여 안내

  • MIT 라이선스
  • 개발자/AI 연구자 누구든지 Issue 및 PR로 기여 가능
▲
GN⁺ 11시간전  [-]
Hacker News 의견

  • 흥미롭게 느껴짐이라는 관심 표현, 이런 현상이 왜 나타나는지에 대한 직관과 발견 경로에 대한 질문, 설치 스크립트에 패치 적용 단계가 미완인 점과 git submodule 활용 등 사용자 친화적 개선 제안, 그리고 다양한 파이썬 환경을 고려해 llama.cpp와 파이썬 의존성 분리 필요성 제안

    • 좋은 질문이라는 반응, 주된 차이는 어텐션의 핵심 역할과 연관 있음이라는 설명, 키는 어떤 토큰에 주목할지 결정해 어텐션 패턴을 만들고 값은 주어진 정보만 전달함을 강조, 키 벡터의 양자화가 너무 강하면 모든 토큰 상호작용에 왜곡이 커지는 반면 값 벡터의 오류는 해당 토큰의 정보만 영향을 줌을 비교, 도서관 서가 번호(키)가 틀리면 완전히 엉뚱한 책을 찾는다는 비유, 수학적으로도 키는 소프트맥스에 들어가서 작은 오류도 크게 증폭되나 값은 선형 평균이라 오류가 상쇄된다는 정보, 본인도 논문에서 이 비대칭성을 접하고 Apple Silicon에서의 영향에 대해 계량적으로 확인하려 했다는 경험, 설치 피드백과 파이썬 의존성 개선 약속
    • 패치가 실제로는 llama.cpp에 적용되지 않음, 아규먼트 파싱 코드가 이미 arg.cpp로 이동되어 무의미함을 지적, K/V 양자화 옵션도 2023년에 이미 llama.cpp에 추가된 상태임을 설명, 패치의 존재 의의를 의문시하며 단순히 명령줄 아규먼트만 다르게 만든 것처럼 보인다는 의견, 이런 간단한 패치 파일 적용에 굳이 새로운 저장소의 install.sh 파일을 실행하는 것을 자제해야 한다는 강력 권고

  • 이 패치가 MLX에서도 가능할지 묻는 질문, MLX에서 속도가 더 잘 나오고 해당 접근 방식이 맥 유저에게 실사용 속도의 장기 대화 지원에 도움이 된다는 기대

    • 아마 가능성이 있을 듯하나, 직접 MLX를 깊게 파고드는 중이고, 프레임워크 자체는 잘 설계됐지만 예제 코드나 벤치마킹 정보가 부족해 아직은 미성숙한 느낌이라는 소감, 오히려 Haskell 바인딩이 가장 기대된다는 개인적 인상, lazy evaluation 특성이 적합할 수 있고, 순수 함수적인 컴파일 그래프 구조도 잘 맞을 수 있다는 의견, Haskell에서의 ML도 흥미로울 것이라는 바람

  • --cache-type-k, --cache-type-v 옵션과 실질적으로 차이가 있는지 질문

    • LLM이 단순히 GitHub 별을 얻으려는 시도처럼 보이며 실제로는 기존 기능과 다르지 않다는 강한 의견
    • MLX/MPS에서 4비트 지원이 없거나 8비트조차 부족하던 기억, bf16 지원도 최근에 추가, 과거에는 애플 GPU에서 type_k/v 방식으로 최저 16비트(f16/bf16)까지만 가능했기에 llama.cpp 내부는 명확히 모르나 약간 다른 접근일 수 있다는 추측
    • 자신도 해당 차이점이 궁금하다는 간결한 동의

  • 코드를 읽은 뒤 패치가 불필요하다고 판단, 이미 2023년에 해당 기능이 llama.cpp에 반영되어 있음을 PR 링크로 확인, 굳이 포크 저장소가 아닌 패치 적용 방식으로 install.sh를 실행하도록 유도하는 점에서 경계 필요, 저장소에는 여러 개 패치 파일과 중복 코드, 패치 파일을 덮어쓰는 등 혼란스러운 구조 지적, 실제로는 --kvq 옵션만 추가하는데 이미 별도 K/V 양자화 옵션 존재, 작성자가 이러한 기존 기능을 인지하지 못했을 리 없다고 의심, 복잡한 스크립트를 제공하는 저장소의 스크립트 실행은 추천하지 않음, HN 포스트와 GitHub 스타 수가 높지만 내용이 오해의 소지가 크다는 비판, 저자가 계속 질문을 회피한다는 점도 우려, 덧붙여 저장소와 스크립트가 모두 과거의 llama.cpp 코드베이스와 혼재되어 있고 최신 구조와 맞지 않아 혼란스럽다는 결론

    • 본인도 여러 의심스러운 부분이 있으나 혹시나 자신이 뭔가 놓쳤는지 저자의 설명을 기다렸다는 언급, 하지만 여러 위험 신호가 있고 Github 활동 내역을 보면 LLM으로 생성된 코드로 Popular 프로젝트를 도배하는 의도가 의심된다는 지적
    • 드디어 합리적을 말하는 사람이 나왔다는 의견, 패치를 적용하는 것이 아니라 원본 프로젝트를 포크하는 구조가 되어야 한다는 점만으로도 신뢰 위험, 작성자의 GitHub 존재 자체도 수상하고, 인기 프로젝트에 LLM 잔여 PR을 대량 제출해 본인을 기여자로 위장하는 경향, 정보 오염 내지 AI로 인한 신뢰 붕괴 초입에 대한 우려 표출

  • 이미 변환된 .gguf 포맷 모델에도 차별적 KV 양자화(K8V4 등) 적용이 가능한지, 모델 종류나 토크나이저 설정의 제한 여부 질문

    • KVSplit의 주요 장점이 바로 기존 .gguf 모델에 특수 변환 없이 바로 쓸 수 있다는 점, 양자화는 실행 시점의 KV 캐시에만 적용되며 모델 가중치와 무관, --kvq-key와 --kvq-val 플래그로 메모리 저장 형식만 정해줌, 본인이 LLama-3, Mistral, Phi-2/Phi-3, TinyLlama, Qwen 등 다양한 모델에서 성공 테스트, 다만 llama.cpp Metal 백엔드 전용이며 Flash Attention이 현재 사용자 지정 KV 캐시 포맷을 우회하므로 -fa 0 옵션 필요, 그 외엔 어텐션을 쓰는 트랜스포머 구조라면 모두 적용 가능

  • 64GB, 128GB 등 고용량 Apple Silicon에서 이 패치가 더 빠르거나 좋은지 질문, 애플 실리콘에서 컨텍스트 창 확장이 실제로는 느리다는 소문, 큰 메모리에 실질적 의미가 있는지 궁금함을 표현

    • KVSplit의 메모리 절감 효과는 컨텍스트 길이에 비례해서 고용량 Mac일수록 절대적인 이점이 커짐, 128GB Mac Studio에서 수십만 토큰 컨텍스트를 다룰 수 있을 정도, 다만 근본적인 계산 속도를 빠르게 하진 않고 메모리 효율만 개선, 벤치마크상 K8V4 세팅에서 14.5%의 처리량 증가가 관찰되나 이는 메모리 접근 효율의 영향, 대형 모델에서 '느린 속도' 문제는 주로 연산 성능 한계 때문이기에 RAM이나 KV 캐시 최적화 유무와 무관, 즉 KVSplit는 메모리 한계를 느끼는 상황에서 유용하고, 실사용에서는 7B~13B 등 소형 모델에 더 큰 컨텍스트 창을 할당하는 것이 이상적, 대형 모델+초장문 창 모두 필요하면 서버급 GPU가 여전히 적합하나 애플 하드웨어로 가능한 한계를 넓혀준다는 점에서 의의

  • 흥미롭다는 관심 및 조금 더 상위 관점의 설명 요청, 2048 토큰 모델을 4~6k 등 확장에 쓸 수 있는지, 128k 컨텍스트 모델을 256k+ 창으로 쓸 수 있는지, 로컬 모델의 이상적 사용사례 질문

    • K8V4 구성에서 59% 메모리 절감이 가능하므로 최대 컨텍스트 길이가 2.4배까지 늘어남, 즉 2048 토큰 모델을 약 5000 토큰, 8K 모델을 ~19.5K까지 확장, 실제로는 맥북에서 한 번에 책 전체를 처리하거나 대형 코드베이스 분석, 대화형 앱에서 긴 대화 기록 유지처럼 활용, 메모리 절약효과는 컨텍스트 길이에 따라 선형적으로 증가, 본인 경험상 8K 컨텍스트에서 KV 캐시가 176MB에서 72MB로 줄었고 128k일 때 절감분이 기가바이트 단위가 됨, 입력 길이 한계로 OOM이 발생하는 경우에 가장 유효한 해법
    • 메모리 절감 효과로 특정 모델의 리소스를 줄여주므로, 사용 목적에 맞추어 어떻게든 응용 가능, 다만 컨텍스트 창 자체를 증설하는 것은 비전문가에게 쉽지 않으니 더 큰 창에 맞게 트레이닝된 모델을 사용하는 게 나음, 로컬 모델은 오프라인/보안/실험 목적으로 다양하게 쓸 수 있으며, 대부분은 모델 튜닝 실험 용도

  • 정말 좋은 아이디어이자 시도라는 칭찬, GPU에도 적용될 수 있는지, 기타 양자화 기법과 병용 가능한지 추가 질문

    • 이 방식은 아마도 NVIDIA/AMD GPU에도 똑같이 적용 가능, 키가 값보다 고정밀이 필요한 원리가 하드웨어 독립적이기 때문, llama.cpp의 CUDA 백엔드도 이미 --cache-type-k, --cache-type-v 옵션으로 분리 설정 지원, 현재 패치는 Metal을 위한 특화이지만 원리는 그대로 이식 가능, 다른 양자화 기법과도 병행할 수 있고, KV 캐시 양자화는 실행 중에만 적용되기에 가중치 양자화와 충돌 없음, 변환 파이프라인의 분리된 단계임, 다만 vLLM, TensorRT-LLM 등 별도 캐시 구조를 쓰는 엔진에는 별도 구현 필요, GPU에서 가장 큰 효과는 FlashAttention 구조에 바로 통합할 때 발생할 것, 메모리 절감이 곧 속도 향상으로 연결될 수 있음

  • 잘 이해가 되지 않는 부분이 있고 이상함을 감지, 해당 스크립트 실행 자제 권유, 신고했다는 안내

  • 성능이 어떻게 변화하는지 궁금, 더 긴 컨텍스트를 메모리에 넣어도 결국 연산 속도는 같지 않을까 질문

    • 실제로 동일 모델, 동일 프롬프트에서 fp16, q8, q4로 캐시 타입을 달리해봐도 이터레이션 속도는 비슷하다고 느낌, 내부 동작을 확인하진 않았으나 4~8비트 SIMD 일괄처리로 벡터가 패킹되길 기대했으나 실제론 패킹이 안 된 듯한 인상
답변달기