r/LocalLLaMA•약 2개월 전•240•40

llama.cpp PR, x86 CPU에서 Q2_0 속도 3.0~3.6배 향상 (8B 모델 기준 2.39 → 8.20 tok/s)

A llama.cpp PR makes Q2_0 3.0–3.6x faster on x86 CPUs, 8B decode goes 2.39 → 8.20 tok/s

핵심 요약

llama.cpp의 새로운 PR이 x86 CPU의 Q2_0 연산 속도를 3배 이상 가속화하여 삼항 가중치 모델의 효율을 크게 높였습니다.

성능 향상 — Q2_0 연산에 AVX-VNNI/AVX-512 VNNI 경로를 추가하여 3배 이상의 처리량 달성함
삼항 모델 최적화 — 일반적인 2비트 양자화가 아닌, 삼항 가중치로 학습된 Bonsai 모델에 특화된 가속임
하드웨어 제약 — 인텔 12~14세대 CPU처럼 AVX-512가 비활성화된 경우 가속 경로를 타지 못하는 이슈 존재함
테스트 요청 — 작성자가 일반 소비자용 하드웨어(Zen 4/5, Raptor Lake 등)에서의 벤치마크 결과를 공유해달라고 요청함

llama.cpp CPU PR들 훑어보다가 #26348이 눈에 띄었는데, 이건 평소 보던 5%짜리 커널 최적화 수준이 아니더라.

Q2_0 × Q8_0 내적 연산에 x86 VNNI 구현을 추가한 건데, 작성자가 직접 돌린 CPU 전용 벤치마크 보니까 1.7B부터 27B까지 Bonsai 모델 전반에서 처리량이 대략 3~3.6배 정도 떡상함.

환경:

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.59배)

tg128: 10.22 → 33.28 tok/s (3.26배)

pp512: 5.41 → 19.40 tok/s (3.59배)

tg128: 4.45 → 13.36 tok/s (3.00배)

pp512: 2.82 → 10.26 tok/s (3.64배)

tg128: 2.39 → 8.20 tok/s (3.43배)

27B

pp128: 0.79 → 2.85 tok/s (3.59배)

tg32: 0.72 → 2.37 tok/s (3.32배)

27B 베이스라인은 pp128 한 번 돌리는 데 3분 가까이 걸릴 정도로 원래 존나 느렸음.

실제로 바뀐 건 별거 없음. 기존 Q2_0 내적 연산이 범용 구현에 의존하던 걸 AVX-VNNI / AVX-512 VNNI를 타도록 경로를 뚫어준 게 다임.

이걸 가져온 Prism 레퍼런스 구현에서 일반 소비자용 인텔 CPU 관련해서 흥미로운 문제도 하나 발견됨.

i5-13400 같은 경우, 12~14세대 인텔은 AVX-VNNI는 있는데 AVX-512는 막혀있거든. 그래서 Q2_0이 빠른 경로를 못 타고 그냥 느려터진 상태로 돌아가는데, 사용자한테는 아무런 알림도 안 뜸. 그냥 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은 아직 오픈 상태고 머지 안 됨

원문

커뮤니티 목록

r/LocalLLaMA•약 2개월 전•240•40

llama.cpp PR, x86 CPU에서 Q2_0 속도 3.0~3.6배 향상 (8B 모델 기준 2.39 → 8.20 tok/s)

A llama.cpp PR makes Q2_0 3.0–3.6x faster on x86 CPUs, 8B decode goes 2.39 → 8.20 tok/s

핵심 요약

llama.cpp의 새로운 PR이 x86 CPU의 Q2_0 연산 속도를 3배 이상 가속화하여 삼항 가중치 모델의 효율을 크게 높였습니다.

성능 향상 — Q2_0 연산에 AVX-VNNI/AVX-512 VNNI 경로를 추가하여 3배 이상의 처리량 달성함
삼항 모델 최적화 — 일반적인 2비트 양자화가 아닌, 삼항 가중치로 학습된 Bonsai 모델에 특화된 가속임
하드웨어 제약 — 인텔 12~14세대 CPU처럼 AVX-512가 비활성화된 경우 가속 경로를 타지 못하는 이슈 존재함
테스트 요청 — 작성자가 일반 소비자용 하드웨어(Zen 4/5, Raptor Lake 등)에서의 벤치마크 결과를 공유해달라고 요청함

llama.cpp CPU PR들 훑어보다가 #26348이 눈에 띄었는데, 이건 평소 보던 5%짜리 커널 최적화 수준이 아니더라.

환경:

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.59배)

tg128: 10.22 → 33.28 tok/s (3.26배)

pp512: 5.41 → 19.40 tok/s (3.59배)

tg128: 4.45 → 13.36 tok/s (3.00배)

pp512: 2.82 → 10.26 tok/s (3.64배)

tg128: 2.39 → 8.20 tok/s (3.43배)

27B

pp128: 0.79 → 2.85 tok/s (3.59배)

tg32: 0.72 → 2.37 tok/s (3.32배)

27B 베이스라인은 pp128 한 번 돌리는 데 3분 가까이 걸릴 정도로 원래 존나 느렸음.

실제로 바뀐 건 별거 없음. 기존 Q2_0 내적 연산이 범용 구현에 의존하던 걸 AVX-VNNI / AVX-512 VNNI를 타도록 경로를 뚫어준 게 다임.

이걸 가져온 Prism 레퍼런스 구현에서 일반 소비자용 인텔 CPU 관련해서 흥미로운 문제도 하나 발견됨.

작성자가 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은 아직 오픈 상태고 머지 안 됨

지금 같이 볼 만한 글

r/LocalLLaMA•약 9시간 전

드디어 내 하드웨어로 풀 정밀도 구동이 가능한 모델을 찾았다: 바로 나

사용자가 자신의 타이핑 속도를 측정해 LLM의 토큰 생성 속도(t/s)와 비교하는 웹 도구를 만들어 공유했습니다.

Finally found a model my hardware can run at full precision: me

사용자가 자신의 타이핑 속도를 측정해 LLM의 토큰 생성 속도(t/s)와 비교하는 웹 도구를 만들어 공유했습니다.

923110

Reddit 원문

r/Anthropic•약 13시간 전

엄청난 반등이네

사용자들은 Claude Opus 5.5 모델이 이전 버전인 Opus 5의 단점을 완벽히 개선하며 뛰어난 성능을 보여준다고 평가합니다.

36155

Reddit 원문

r/vibecoding•1일 전

소프트웨어 경제의 현주소

AI를 활용한 '바이브 코딩(vibecoding)'이 소프트웨어 산업과 SaaS 시장에 미칠 영향에 대한 논의입니다.

AI를 활용한 '바이브 코딩(vibecoding)'이 소프트웨어 산업과 SaaS 시장에 미칠 영향에 대한 논의입니다.

1010139논쟁

Reddit 원문

커뮤니티 전체 보기

원문

주요 댓글

r/localllama

llama.cpp의 Q2_0 성능 향상 PR에 대해 사용자들은 속도 개선을 긍정적으로 평가하며, 기술적인 구현 방식과 Bonsai 모델 지원에 대해 토론하고 있습니다.

멋지긴 한데, 좀 물어볼 게 있어. Q2_0은 1T 파라미터급 모델이 아닌 이상 사실상 쓸모없지 않아? 그 정도면 그냥 Deepseek V4 Flash에서 Q4 돌리는 게 낫지 않나?

이건 그냥 "쓸모없는 결과물을 3배 더 빠르게 생성할 수 있게 됐다"는 말로 들리는데.

작성자가 Bonsai 모델을 선택한 이유는 그게 네이티브 1비트 모델이라서 그래. 그래서 특히 저 모델들은 Q2로도 거의 풀 정밀도에 가까운 성능을 내거든.

내 생각에 핵심 차이는 Bonsai가 Q2_0으로 억지로 압축한 일반 모델이 아니라는 점이야. 이건 {-1, 0, +1}의 삼항 가중치로 학습됐고, Q2_0은 기본적으로 그 가중치들의 네이티브 표현 방식이거든.

그러니까 이건 "나쁜 2비트 양자화를 빠르게 만드는 것"보다는 "삼항 모델을 CPU에서 훨씬 빠르게 만드는 것"에 가까워.

Q2에 4개의 값을 넣을 수 있는데 왜 굳이 3진법(ternary)을 쓰는지 쉽게 설명해 줄 사람?

내가 이해하기로는 모든 추가 요소(주로 그룹 스케일링 메타데이터)를 고려하면 파라미터당 거의 2비트 정도가 돼. 공짜 점심은 없지. Bonsai의 전체 전제는(내가 헛소리하는 게 아니라면 말이야) 곱셈 대신 훨씬 '저렴한' 누산기(ALU)를 사용하기 위해 복잡한 수학을 활용하는 데 기반을 두고 있어. 실리콘 다이 면적이나 전력 소모 같은 기준에서 저렴하다는 뜻이야. 어쨌든 이건 처음에 생각했던 것보다 훨씬 흥미로운 문제네.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

이 PR은 최신 CPU에서 모든 모델의 Q2_0 양자화를 훨씬 빠르게 만들어줌

Q2 모델 써본 적 있어? 난 자주 쓰는데 전혀 동의 못 하겠네.

Q2가 완벽하진 않지만, 그렇다고 쓸모없는 것도 아냐. 모델 비교할 때 GB 크기를 맞춰서 비교하면 충분히 제 몫을 해. doom loop(무한 루프) 피하려고 최대 토큰 제한 같은 설정을 좀 더 신경 써주면, 작은 우리 안에 갇힌 유능한 짐승 같은 놈이 된다고.

IQ2_M 같은 걸 말하는 거야, 아니면 진짜 Q2_0을 말하는 거야?

다들 Q2_0를 흔한 양자화 방식인 것처럼 말하네. Q2_0는 Bonsai를 지원하기 위해 최근에야 메인라인 llama.cpp에 추가됐어. 그래서 이런 식의 성능 향상이 아직 가능한 거야.

모델을 실제로 쓸 수 없는 상황이라도 제대로 작동하고 로드되는지 확인하는 용도로는 유용할 수 있음. 1.5TB짜리 모델을 일일이 띄우고 로드하는 대신, 500GB 정도로 로드해서 작동 여부를 체크할 수 있으니까. 그래서 버그 잡거나 품질 검사할 때 이 작업이 3배 더 수월해지고, 로딩도 3배 빨라지고, 추론도 3배 빨라지는 셈이지.

게다가 K3 같은 모델들은 워낙 커서 작은 양자화 모델도 멍청하지 않고 이미지 인식 같은 기능도 여전히 쓸만함. 툴 사용 같은 경우에도 중요하고, 다시 말하지만 만약 네가...

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

좋네, 나 듀얼 Xeon 8276l이랑 듀얼 8260 가지고 있는데 둘 다 AVX512랑 DLboost 지원함

그거야말로 이상적인 테스트 환경이네. PR 적용해보고 전후 llama-bench 수치 여기 올려줘.

원문r/LocalLLaMA