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

 (github.com/dipampaul17)
1P by GN⁺ | ★ favorite | 댓글 1개
  • KVSplit은 Apple Silicon에서 LLM의 attention KV cache에 key와 value별로 다른 양자화 정밀도를 적용해 같은 메모리 예산에서 더 긴 컨텍스트와 더 무거운 모델 실행을 목표로 함
  • 핵심 결과는 K8V4 구성이며, 8K 토큰 기준 FP16 176.00MB 대비 71.50MB로 줄이고 토큰 처리 속도는 54,360 tokens/sec에서 57,438 tokens/sec로 높이며 perplexity 변화는 +0.86%로 제시됨
  • key가 value보다 양자화에 더 민감하다는 결과를 바탕으로, 같은 총 비트 수를 쓰는 K4V8은 K8V4보다 품질 저하가 약 7배 크다고 정리함
  • 제공 기능은 llama.cpp 패치 적용, Metal 지원 빌드, 메모리·속도·perplexity 벤치마크, CSV/JSON 결과 저장, 시각화 도구, Activity Monitor 기반 메모리 절감 캡처를 포함함
  • 권장 구성은 품질과 메모리 절감의 균형을 위한 K8V4이며, 최대 메모리 절감이 필요하면 K4V4로 72% 절감과 약 6% 품질 손실을 감수하는 선택지가 있음

KVSplit이 해결하려는 문제

  • KVSplit은 Apple Silicon Mac에서 LLM 추론 시 KV cache 메모리를 줄이기 위한 프로젝트임
  • attention 메커니즘의 KV cache에서 key와 value에 서로 다른 양자화 정밀도를 적용함
  • 목표는 다음과 같음
    • 메모리 사용량을 최대 72% 절감
    • 같은 메모리 예산에서 2-3배 긴 컨텍스트 실행
    • FP16 대비 추론 속도를 유지하거나 개선
    • Apple Silicon에 맞춘 Metal 지원 제공

핵심 벤치마크 결과

  • 8K 토큰 기준 구성별 결과는 다음과 같음
    • FP16: 176.00MB, 54,360 tokens/sec
    • K8V8: 93.50MB, 51,503 tokens/sec, perplexity +0.03%
    • K8V4: 71.50MB, 57,438 tokens/sec, perplexity +0.86%
    • K4V8: 71.50MB, 58,690 tokens/sec, perplexity +6.06%
    • K4V4: 49.50MB, 55,193 tokens/sec, perplexity +6.15%
  • 메모리 절감 표에서는 K8V4가 8K 토큰에서 59% 절감, K4V4가 72% 절감으로 제시됨
  • 성능 표에서는 K8V4가 FP16 대비 +5.7%, K4V8이 +8.0%, K4V4가 +1.5% 속도 향상을 보임
  • K8V8은 FP16 대비 메모리를 줄이지만 속도는 -5.3% 로 낮아짐

시퀀스 길이에 따른 메모리 사용

  • 컨텍스트 길이가 길어질수록 KV cache 메모리 절감 효과가 커짐
  • 8192 토큰 기준 메모리 사용량은 다음과 같음
    • FP16: 176.00MB
    • K8V8: 93.50MB
    • K8V4: 71.50MB
    • K4V8: 71.50MB
    • K4V4: 49.50MB
  • 4096 토큰 기준으로도 FP16 88.00MB 대비 K8V4/K4V8은 35.75MB, K4V4는 24.75MB를 사용함
  • 128 토큰 기준에서는 FP16 5.50MB, K8V4/K4V8 2.23MB, K4V4 1.55MB로 제시됨

key와 value의 비대칭성

  • KV cache 메모리는 각 토큰의 key 벡터와 value 벡터 저장이 지배함
  • 프로젝트의 핵심 관찰은 key가 value보다 양자화에 훨씬 민감하다는 점임
  • K8V4는 8-bit key와 4-bit value를 사용해 다음 균형점을 제공함
    • FP16 대비 perplexity 저하 0.86%
    • 메모리 절감 59%
    • FP16보다 빠른 추론 속도
  • K4V8은 K8V4와 같은 총 비트 수를 쓰지만, 품질 저하가 K8V4보다 약 7배 크다고 정리됨
  • 이 비대칭성 덕분에 consumer hardware에서 더 긴 컨텍스트와 더 큰 모델 실행이 가능해진다고 설명함

설치와 통합 방식

  • 설치는 저장소를 clone한 뒤 scripts/install_kvsplit.sh를 실행하는 방식임
git clone https://github.com/dipampaul17/KVSplit.git
cd kvsplit

chmod +x scripts/install_kvsplit.sh
./scripts/install_kvsplit.sh
  • 설치 스크립트는 Python 환경 설정 방식을 선택할 수 있음
    • Virtual Environment: 프로젝트 폴더 안에 독립 Python 환경 생성
    • System Python: 기존 Python 설치 사용
    • Skip Python Setup: 사용자가 Python 환경을 직접 관리
  • llama.cpp 통합 방식도 선택 가능함
    • 표준 방식: llama.cpp를 clone하고 KV split 패치를 적용
    • Git submodule 방식: 개발자나 고급 사용자를 위해 llama.cpp를 submodule로 추가
  • 설치 과정은 Apple Silicon용 Metal 지원 llama.cpp 설정, differentiated KV cache quantization 활성화, 선택적 테스트 모델 다운로드, 시각화 도구 설정을 포함함

사용 예시와 CLI 옵션

  • 빠른 비교는 사용자가 가진 GGUF 모델로 실행할 수 있음
python scripts/quick_compare.py --model models/your-model.gguf
  • 비교 대상은 FP16, K8V8, K8V4, K4V8, K4V4이며 메모리, 속도, 품질 지표를 함께 보여줌
  • README의 실행 예시는 llama-cli에 --flash-attn과 KV 양자화 옵션을 함께 사용함
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq 8
  • K4V8 예시는 key와 value 비트를 따로 지정함
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "Your prompt" \
  -t 8 --flash-attn --kvq-key 4 --kvq-val 8
  • 32K 컨텍스트 예시는 FP16에서는 약 1.4GB, K8V4에서는 약 400MB가 필요하다고 제시됨
./llama.cpp/build/bin/llama-cli -m models/your-model.gguf \
  -c 32768 -n 4096 -t 8 --flash-attn --kvq 8 \
  -f your-long-document.txt
  • 주요 CLI 플래그는 다음과 같음
    • -t 8: 스레드 수, 대부분의 Apple Silicon 칩에서 8 권장
    • --flash-attn: 최적화 attention 활성화, Apple Silicon에서 권장
    • --kvq N: key와 value 비트 설정
    • --kvq-key N: key 비트만 설정
    • --kvq-val N: value 비트만 설정
    • -c N: 컨텍스트 크기
    • -n N: 생성할 토큰 수
    • -f FILE: 입력 파일
    • -m MODEL: .gguf 모델 파일 경로

벤치마크와 시각화 도구

  • 전체 벤치마크는 scripts/benchmark_kvsplit.py로 실행함
python scripts/benchmark_kvsplit.py
python scripts/benchmark_kvsplit.py --config K8V4 --seq-len 4096
  • 시각화는 scripts/visualize_results.py로 생성함
python scripts/visualize_results.py
  • 벤치마크는 다음 항목을 측정함
    • Memory Usage: VRAM과 KV cache 메모리
    • Performance: 시퀀스 길이별 tokens/sec
    • Quality: llama-perplexity를 사용한 perplexity
    • Scaling: 시퀀스 길이에 따른 메모리와 성능 변화
  • 결과는 CSV/JSON 형식으로 저장되며 자동 요약 통계와 시각화 플롯을 생성함
  • capture_memory.sh는 Activity Monitor에서 메모리 절감을 캡처하는 도구임

Apple Silicon 최적화와 제약

  • KVSplit은 Apple의 Metal framework에 맞춰 최적화됨
  • Apple Silicon M series처럼 메모리 제약이 있는 장치에서 메모리 효율을 강조함
  • README는 llama.cpp의 256B page alignment 때문에 실제 메모리 절감이 이론 계산과 약간 다를 수 있다고 밝힘
  • 지원 대상으로 M1, M2, M3, M4 칩을 포함함

권장 구성과 로드맵

  • 권장 구성은 K8V4임
    • 8-bit key, 4-bit value
    • 59% 메모리 절감
    • 0.86% 품질 손실
    • FP16 대비 +5.7% 추론 속도
  • 최대 메모리 절감은 K4V4임
    • 4-bit key와 4-bit value
    • 72% 메모리 절감
    • 약 6% 품질 손실
    • 덜 민감한 애플리케이션에 적합하다고 제시됨
  • 매우 긴 컨텍스트에는 K8V4 또는 K4V4가 권장되며, 컨텍스트 길이가 길수록 메모리 절감이 누적됨
  • 향후 계획은 다음과 같음
    • 토큰 중요도 기반 Adaptive Precision
    • 레이어별 다른 정밀도를 쓰는 Layer-Specific Quantization
    • Mistral, Phi-3 등에 맞춘 모델별 최적화
    • 웹 데모
    • iOS와 iPadOS 지원
  • 라이선스는 MIT이며, 기여는 issue 또는 pull request로 받을 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 흥미로움. 왜 이런 결과가 나오는지에 대한 직관이 있는지 궁금함. 그 직관으로 발견한 건지, 아니면 무작위 실험으로 찾은 건지도 궁금함
    설치 스크립트의 "apply patch" 단계에는 아직 자리표시자가 남아 있는 것 같음. git clone 후 패치를 적용하게 하기보다 llama.cpp를 포크하고 이를 Git 서브모듈로 포함하는 편이 사용자 친화적일 듯함
    또 사람마다 로컬 Python 설정이 제각각이라, Homebrew Python 의존성을 박아두기보다 llama.cpp 관련 부분과 Python 관련 부분을 분리할 수 있게 하면 좋겠음

    • 직관에 대한 질문이 좋음. 차이는 어텐션에서 각 구성요소가 맡는 핵심 역할에서 나옴
      키는 어떤 토큰에 주목할지를 결정하며, 유사도 계산을 통해 실제 어텐션 패턴을 만듦. 값은 어텐션이 결정된 뒤 전달될 정보를 저장할 뿐임
      키 벡터를 너무 공격적으로 양자화하면 모든 토큰 상호작용의 유사도 계산이 왜곡됨. 키의 작은 오차가 어텐션을 완전히 엉뚱한 토큰으로 돌릴 수 있음
      값은 훨씬 관대함. 값 벡터 양자화 오차는 어텐션 패턴이 이미 정해진 뒤 해당 단일 토큰의 정보 내용에만 영향을 줌
      도서관 목록 시스템과 책 자체의 차이와 비슷함. 목록 번호(키)가 망가지면 완전히 엉뚱한 서가를 보게 되지만, 책의 일부 단어(값)가 번져도 여전히 올바른 책을 읽고 있고 가끔 잡음만 생김
      수학적으로 키는 softmax 계산에 들어가며 작은 오차가 정규화 과정에서 지수적으로 증폭됨. 값은 선형 가중 평균만 거치므로 오차가 상쇄되는 경향이 있음
      처음에는 "More for Keys, Less for Values", "KV-AdaQuant" 같은 논문에서 이 비대칭을 접했고, Apple Silicon 추론에서 정확히 얼마나 영향이 있는지 정량화하고 싶었음. 동일 메모리에서 K8V4와 K4V8의 품질 차이가 7배였던 점이 인상적이었음
      설치 피드백도 고맙고, 자리표시자를 고치고 Python 의존성을 더 유연하게 만들 예정임
    • 패치는 실제로 llama.cpp에 적용되지 않음. 인자 파싱이 8개월 전에 arg.cpp로 옮겨졌기 때문임
      그래도 상관없는 이유는 K와 V 양자화를 설정하는 옵션이 이미 2023년에 llama.cpp에 추가됐기 때문임
      이 패치가 왜 존재하는지 이해가 안 됨. 이미 있는 설정을 다른 명령줄 인자로 바꾸면서 새로워 보이게 하려는 것 말고는 이유를 모르겠음
      이런 새 저장소의 install.sh 파일은 아무도 실행하지 않기를 강하게 권함. 특히 패치 파일 하나 적용하는 것처럼 단순한 일에 불필요할 때는 더 그렇다

  • 이게 --cache-type-k와 --cache-type-v를 쓰는 것과 다른가?

    • 아니오. GitHub 스타를 얻으려는 LLM 생성 시도처럼 보임
      저장소의 다른 이상한 점들은 다른 댓글에 일부 적어둠
    • 조금 다를 것으로 추측함. MLX/MPS에는 네이티브 4비트 지원이 없고, 기억이 맞다면 8비트도 없을 수 있음. 처음 출시 때 bf16 지원도 없었음
      그래서 예전 type_k/v 방식과 Apple GPU에서 내려갈 수 있는 최저는 16비트 f16/bf16이었을 것 같음. 다만 llama.cpp 내부 전문가가 아니라 틀릴 수도 있음

  • 이 패치를 MLX에서도 할 수 있는지 궁금함. MLX에서 속도가 더 잘 나오고 있어서, 이 접근과 합쳐지면 Mac 사용자도 쓸 만한 속도로 긴 대화를 할 수 있을 듯함

    • 아마 가능하겠지만, 지금 MLX 깊은 곳을 파고 있는 중이고 잘 설계된 프레임워크이긴 해도 이미 누군가 "최선의 방법"을 벤치마크해둔 예제 코드를 가져다 쓸 수 있는 성숙도는 훨씬 낮다는 걸 알게 됨
      개인적으로 가장 기대하는 건 믿기 어렵겠지만 Haskell 바인딩임. 며칠 전 누가 Haskell의 지연 평가가 이 패러다임에 꽤 잘 맞고, 컴파일 그래프에 대한 거의 순수 함수식 접근도 도움이 된다고 짚어줬음. Haskell에서 기계학습을 하는 건 재미있을 것 같음

  • 차등 KV 양자화(예: K8V4)를 이미 .gguf 형식으로 변환된 모델에 적용할 수 있는지 궁금함. 아니면 특수 지원을 넣어 모델을 다시 빌드해야 하나?
    어떤 .gguf 파일과도 호환된다면 모델 유형(Mistral, Phi-3 등)이나 토크나이저 설정에 제한이 있는지도 궁금함

    • 가능함. KVSplit의 핵심 장점 중 하나는 기존 .gguf 모델을 재구성하거나 특수 변환하지 않고 그대로 쓸 수 있다는 점임. 양자화는 모델 로딩이나 변환 중이 아니라 실행 시점의 KV 캐시에서 일어남
      KV 캐시는 토큰을 처리하면서 추론 중에 생성되며 모델 가중치와 완전히 별개라서 가능함. --kvq-key와 --kvq-val 플래그는 이 중간 텐서를 메모리에 어떻게 저장할지만 llama.cpp에 알려줌
      Llama-3, Mistral, Phi-2/Phi-3, TinyLlama, Qwen 변종에서 성공적으로 테스트했음
      유일한 제한은 llama.cpp의 Metal 백엔드가 필요하고, 현재 llama.cpp의 Flash Attention 구현이 커스텀 KV 캐시 형식을 우회하므로 -fa 0으로 Flash Attention을 꺼야 한다는 점임. 기법 자체는 표준 어텐션 메커니즘을 쓰는 어떤 트랜스포머 아키텍처에도 동작할 것임

  • 코드를 읽을 시간이 났음. 이 PR을 제대로 이해했다면 이 기능은 이미 2023년부터 llama.cpp에 있었기 때문에 패치가 불필요함: https://github.com/ggml-org/llama.cpp/pull/4312
    변경사항을 커밋으로 적용한 llama.cpp 포크를 제공하는 대신, 저장소는 install.sh 스크립트를 실행하게 함. 이 스크립트는 리비전을 지정하지 않고 llama.cpp의 master 브랜치를 체크아웃한 다음 짧은 패치를 적용함. 이것만으로도 뭔가 이상하다는 경고 신호가 됨
    저장소에는 서로 다른 패치 파일이 4개 있고, 설치 스크립트 안에는 Heredoc으로 박힌 추가 패치 버전이 하나 더 있음. 스크립트에는 저장소를 클론하고 패치를 시도하는 코드도 두 버전이 들어 있음
    install.sh는 cp patch/split_kv_quant.diff patch/fixed_kv_patch.diff 줄로 패치 파일 하나를 다른 패치 파일로 덮어씀. 그래서 저장소에 체크인된 fixed_kv_patch.diff는 적용되기 전에 덮어써짐
    내가 보기에는 원래 이 패치를 쓰려는 것 같음: https://github.com/dipampaul17/KVSplit/blob/main/patch/split... (수정: 끝의 댓글을 보면 실제로는 이쪽인 듯함: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... )
    이 패치가 추가하는 것은 K와 V 양자화를 동시에 설정한다는 --kvq 인자뿐인데, 바로 위에 K와 V 양자화를 각각 설정하는 내장 인자가 이미 있음. 이 패치들을 이리저리 옮기는 동안 기능이 이미 존재한다는 걸 저자가 알아차리지 못했을 리가 있나?
    이런 새 저장소의 셸 스크립트는 실행하지 않기를 강하게 권함. 특히 이렇게 복잡한 스크립트라면 더더욱 그렇다
    HN 글은 200개 넘는 추천을 받았고 GitHub 저장소도 200개 넘는 스타를 모으며 계속 늘고 있지만, 내용은 오해를 부르는 것 같음. 이 스레드에서 문제를 짚다가 플래그를 잔뜩 받은 댓글이 실제로는 맞았음. 저자가 계속 이 스레드에 답하면서도 기능이 이미 존재한다는 질문은 피하고 있는 점도 우려됨
    수정: 셸 스크립트를 잘못 읽었음. 실제로는 이 패치를 적용하는 것 같음: https://github.com/dipampaul17/KVSplit/blob/main/patch/fixed... 패치를 적용한 뒤 이상하게도 fixed_kv_patch.diff를 split_kv_quant.diff로 덮어쓰지만, 그 뒤에는 아무것도 하지 않음. 이게 바이브코딩의 결과인지, 그냥 부주의한 코드 편집인지는 모르겠지만, 모르는 저장소의 이런 셸 스크립트는 실행하면 안 된다는 말을 반복하고 싶음
    수정 2: 더 혼란스러움. install.sh 스크립트는 llama.cpp 저장소의 예전 URL(https://github.com/ggerganov/llama.cpp)을 참조하는데, 이 URL은 한동안 전에 바뀌어서 지금은 리다이렉트됨. 패치들은 common.cpp의 인자 파싱을 수정하려 하지만, 그 코드는 8개월 전에 arg.cpp로 옮겨졌음(https://github.com/ggml-org/llama.cpp/commit/bfe76d4a17228bf...). 그러면 이 설치 스크립트와 저장소는 2024년쯤의 코드를 기반으로, 2023년쯤 llama.cpp에 추가된 옵션을 쓰는 셈임. 대체 무슨 일인가?

    • 맞음. 혹시 내가 뭔가 놓친 것이고 저자가 여기서 짚어줄 수도 있어서 나머지 의심스러운 부분은 굳이 말하지 않았음
      경고 신호가 많음. 좋게 봐도 LLM 생성 코드로 GitHub 프로필을 부풀리려는 사람처럼 보임. 그 프로필의 5월 12일 활동만 봐도 됨
    • 드디어 말이 되는 내용이 나옴. 이 프로젝트가 원본 프로젝트를 포크해 변경사항을 커밋하는 대신 패치를 적용하는 방식으로 동작한다는 사실만으로도 우려할 이유가 충분함
      하지만 원글 작성자의 GitHub 활동 전체가 수상함. 5월 12일에 여러 인기 프로젝트에 LLM 잡탕 PR을 날렸고, JAX 쪽만 거절됐음. 그런데도 이를 통해 마치 기여자인 것처럼 인기 프로젝트들을 프로필에 고정할 수 있었음
      이게 얼마나 혐오스러운지 말로 표현하기 어려움. AI 분야에서 일하는 누구나 정보 오염에 공모하고 있으며, 그 결과는 아직 예측조차 못 함. 죽은 인터넷과 AI 잡탕의 홍수는 시작일 뿐임

  • 64GB나 128GB Apple Silicon에서는 36GB나 48GB보다 이것들이 유의미하게 더 빠르거나 나은가?
    큰 컨텍스트와 큰 모델은 돈으로 살 수 있는 가장 빠르고 큰 Apple Silicon에서도 고통스러울 정도로 느리다고 읽어왔음
    그래서 이게 더 큰 메모리를 더 잘 활용하게 해주는지, 아니면 실용적으로는 여전히 Apple Silicon에서는 비교적 작은 모델이 답인지 궁금함

    • KVSplit의 메모리 절감은 컨텍스트 길이에 비례해서 커지므로, 64GB/128GB 같은 고용량 RAM Mac은 절대량 기준으로 더 큰 이익을 봄. 128GB Mac Studio라면 잠재적으로 수십만 토큰의 컨텍스트 창도 다룰 수 있음
      다만 KVSplit은 계산 속도를 근본적으로 바꾸지는 않고 메모리 효율만 바꿈. 벤치마크에서는 K8V4로 처리량이 14.5% 향상됐지만, 이는 계산량 감소가 아니라 메모리 지역성 개선 때문임
      Apple Silicon에서 대형 모델이 "고통스럽게 느린" 주된 이유는 메모리 제약이 아니라 계산 성능 한계임. 70B 파라미터 모델은 사용 가능한 RAM이나 KV 캐시 최적화와 관계없이 비슷한 토큰 생성 속도로 돌 것임
      KVSplit은 사용 가능한 메모리를 더 잘 쓰게 해줌. 모델 크기보다 컨텍스트 길이가 병목일 때 특히 가치가 있음
      실용적인 Apple Silicon 사용에서는 여전히 더 작은 모델(7B~13B)에 확장된 컨텍스트 창을 붙이는 것이 적정 지점임. 이렇게 하면 합리적인 생성 속도를 유지하면서 훨씬 많은 텍스트를 처리할 수 있음
      작업 흐름이 거대한 컨텍스트와 큰 모델을 모두 필요로 한다면 여전히 서버급 GPU를 고려해야 하지만, KVSplit은 Apple 하드웨어에서 가능한 범위를 조금 더 밀어줌

  • 훌륭한 작업이고 매우 흥미로워 보이지만, 이해하려면 조금 더 상위 수준 설명이 필요함
    예를 들어 2048 토큰 컨텍스트 창 모델을 4~6K 컨텍스트 창으로 돌릴 수 있게 해주는 건가? 아니면 gemma3 같은 128K 모델을 256K 이상 컨텍스트 창으로 돌릴 수 있게 해주는 건가?
    로컬 모델의 이상적인 사용 사례는 무엇인가?

    • K8V4 설정은 메모리를 59% 절약하므로 같은 하드웨어에서 사실상 2.4배 긴 컨텍스트를 실행할 수 있음. 2048 토큰 컨텍스트 모델은 약 5000 토큰을 처리할 수 있고, 8K 컨텍스트 모델은 약 19.5K까지 갈 수 있음
      실용적으로는 MacBook에서 책 전체를 한 번에 처리하거나, 파일을 쪼개지 않고 큰 코드베이스를 분석하거나, 채팅 애플리케이션에서 긴 대화 기록을 유지할 수 있다는 뜻임
      메모리 절감은 컨텍스트 길이에 선형으로 비례함. 컨텍스트 창이 길수록 절대적으로 절약되는 메모리가 커짐. 내 M4 MacBook에서 8K 컨텍스트일 때 KV 캐시가 176MB에서 72MB로 줄었음. 128K 컨텍스트라면 같은 비율의 절감이 기가바이트 단위 메모리를 비워줌
      이 최적화는 모델 파라미터 한계보다 컨텍스트 창 한계에 부딪힐 때 가장 가치 있음. 큰 모델 가중치가 아니라 긴 입력 때문에 메모리 부족 오류가 난다면 KVSplit이 직접적인 병목을 해결함
    • 특정 모델의 메모리 사용량을 줄여줌. 그 여유를 어떻게 쓸지는 사용자가 정하면 됨
      학습 후 컨텍스트 창을 늘리는 건 간단하지 않으므로, 무엇을 하는지 정확히 모른다면 더 큰 컨텍스트 창으로 학습된 모델을 찾는 편이 나음
      로컬 모델의 용도는 오프라인 작업, 프라이버시/보안 등 다양함. 다만 대부분은 모델을 조정하며 실험하는 데 쓰는 편임

  • 이상한 일이 벌어지고 있으니 이걸 설치하거나 저 스크립트를 실행하지 않는 게 좋겠음
    제출 글은 플래그했음

  • 훌륭한 아이디어이자 시도임. 이것도 GPU에 적용되는가? 그리고 다른 양자화 기법과도 호환될 것 같은데, 아마 각각 별도 패치가 필요하다고 보면 되나?

    • 맞음. 이 접근은 NVIDIA/AMD GPU에서도 가능할 가능성이 큼. 키가 값보다 높은 정밀도를 필요로 한다는 기본 원리는 하드웨어와 무관함
      llama.cpp의 CUDA 백엔드는 이미 --cache-type-k와 --cache-type-v 플래그로 별도 캐시 타입 설정을 지원함. 이 특정 패치는 Metal 전용 최적화에 초점을 둔 것이지만, 핵심 기법은 그대로 이전됨
      다른 양자화 방법과의 호환성도 있음. 이 KV 캐시 최적화는 모델 가중치 양자화(Q4_K_M, GPTQ, AWQ 등)와 상호 보완적임. 비대칭 KV 캐시 정밀도와 어떤 모델 가중치 형식도 함께 쓸 수 있음
      KV 캐시 양자화는 토큰 처리 중 실행 시점에 일어나며 모델 가중치와 별개라서, 모델 자체가 어떻게 양자화됐는지와 충돌하지 않음. 추론 파이프라인의 서로 다른 부분에서 동작함
      추가 작업이 필요한 부분은 vLLM이나 TensorRT-LLM처럼 커스텀 KV 캐시 처리를 가진 특수 추론 엔진과의 통합임. 각각 비대칭 KV 정밀도를 별도로 구현해야 함
      GPU에서 가장 즉각적인 이득은 아마 FlashAttention 구현에 이 통찰을 직접 통합하는 데서 나올 것임. CUDA 하드웨어에서는 메모리 대역폭 절감이 더 큰 속도 향상으로 이어질 수 있음

  • 작은 컨텍스트 크기에서 퍼플렉서티 +0.86% 면 꽤 큰 편 아닌가? 64~128K 같은 더 현실적인 컨텍스트 크기에서는 어떤가?

    • 요지는 메모리 사용량을 줄인다는 데 있어 보임. 제한된 같은 메모리에서 이전에는 불가능했던 더 긴 컨텍스트를 실행할 수 있게 해줌
      또는 여유 메모리를 IDE 같은 다른 용도에 쓸 수도 있음
답변달기