
llama.cpp PR을 통해 x86 CPU에서 Q2_0 속도가 3.0~3.6배 향상, 8B 디코딩이 2.39 → 8.20 tok/s로 개선
요약
llama.cpp의 새로운 PR을 통해 x86 CPU에서 Q2_0 양자화 모델의 처리 속도가 3~3.6배 향상되었습니다. AVX-VNNI/AVX-512 VNNI를 활용한 커널 최적화가 핵심이며, AMD EPYC 및 Intel 소비자용 CPU 모두에서 유의미한 성능 개선을 보여줍니다.
핵심 포인트
- x86 VNNI 구현 추가로 Q2_0 내적 연산 속도 대폭 개선
- AMD EPYC 및 Intel i5 환경에서 약 3배 이상의 처리량 향상 확인
- AVX-512 비활성화 환경(Intel 12-14세대)에서의 성능 이슈 주의 필요
- 비트 단위 일치 및 높은 토큰 선택 확률로 수치적 정확도 검증 완료
현재 llama.cpp CPU PR(Pull Request)들을 살펴보던 중, #26348이 눈에 띄었는데 이는 일반적인 +5% 수준의 커널 최적화가 아니기 때문입니다. 이 PR은 Q2_0 × Q8_0 내적 (dot product)을 위한 x86 VNNI 구현을 추가하며, 작성자의 통제된 CPU 전용 벤치마크 결과에 따르면 1.7B에서 27B 사이의 Bonsai 모델 전반에 걸쳐 약 3~3.6배 더 높은 처리량 (throughput)을 보여줍니다.
설정:
- AMD EPYC 9645
- 8 CPU 코어
- CPU 전용
- GGML_NATIVE=ON
- OpenMP 활성화
- BLAS 비활성화
- -t 8 -ngl 0 -fa off
- 워밍업 후 3회 실행
- group-64 Q2_0 Bonsai GGUF
결과:
1.7B pp512: 14.07 → 50.47 tok/s (3.59x)
tg128: 10.22 → 33.28 tok/s (3.26x)
4B pp512: 5.41 → 19.40 tok/s (3.59x)
tg128: 4.45 → 13.36 tok/s (3.00x)
8B pp512: 2.82 → 10.26 tok/s (3.64x)
tg128: 2.39 → 8.20 tok/s (3.43x)
27B pp128: 0.79 → 2.85 tok/s (3.59x)
tg32: 0.72 → 2.37 tok/s (3.32x)
27B 베이스라인은 너무 느려서 pp128 패스 한 번에 거의 3분이 걸렸던 것으로 보입니다. 실제로 변경되는 내용은 꽤 작습니다. 기존의 Q2_0 내적 (dot product)이 일반적인 구현에 의존하는 대신 AVX-VNNI / AVX-512 VNNI를 사용하는 경로를 갖게 됩니다. 이 기능이 채택된 참조 모델인 Prism 구현은 일반적인 소비자용 Intel CPU에서 흥미로운 문제도 드러냈습니다. i5-13400에서 Q2_0는 빠른 경로 (fast path)를 조용히 놓치고 있었는데, 이는 12~14세대 Intel CPU가 AVX-VNNI는 지원하지만 AVX-512는 통합 비활성화 (fused off)되어 있기 때문입니다. 사용자에게 이런 일이 발생했다는 알림이 전혀 없으며, 그저 Q2_0가 극도로 느린 것처럼 보일 뿐입니다.
그들의 통제된 i5-13400 A/B 테스트:
Ternary-Bonsai-8B Q2_0 디코딩 (decode): 2.17 → 6.92 tok/s
프롬프트 평가 (prompt eval): 2.7 → 8.6 tok/s
마찬가지로 VNNI 경로를 사용함으로써 약 3.2배 향상되었습니다.
몇 가지 중요한 주의 사항이 있습니다:
- 업스트림 (upstream) llama.cpp PR은 아직 열려 있는 상태이며, 병합(merged)되지 않았습니다.
- 이것은 구체적으로 Q2_0에 관한 것이며, Q4/Q5 등에서 자유롭게 3배 향상된다는 의미는 아닙니다.
- 주요 업스트림 벤치마크는 단 8개의 코어만 사용하는 EPYC에서 수행되었습니다.
- i5-13400 결과는 정확히 동일한 group-64 업스트림 PR이 아닌, Prism 레퍼런스 구현 (reference implementation)에서 나온 것입니다.
- 결합 곱셈-가산 (fused multiply-add) 동작으로 인해 아주 미세한 수치적 차이가 존재합니다.
정확도 측면에서, 저자는 커널 (kernel) 수준에서 14,000개의 무작위 비교가 비트 단위로 일치했다고 보고했습니다. 퍼플렉시티 (perplexity) 스모크 테스트 (smoke test)에서 두 버전은 매우 작은 KLD 차이를 보이며, 99.216% ± 0.554%의 확률로 동일한 최상위 토큰을 선택했습니다. 이것이 바로 제가 또 다른 서버 CPU가 아닌, 지루한 소비자용 하드웨어에서 테스트되기를 정말로 바라는 llama.cpp 최적화의 모습입니다.
만약 Alder/Raptor Lake 또는 Zen 4/5를 사용 중이고 PR 브랜치를 컴파일할 수 있는 분이 있다면, llama-bench의 전/후 결과를 게시해 주세요. 특히 노트북의 경우, 3배의 성능 향상이 전력/메모리 대역폭 (memory-bandwidth) 제한 속에서도 유지되는지, 아니면 실제 하드웨어에서는 크게 줄어드는지 매우 궁금합니다.
제출자: /u/BTA_Labs [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기